...
就加载初始状态到MemStore，合约代码到 MoveVM，然后监听 state_channel.call 消息，如果有消息就执行合约调用，把调用产生的副作用，广播给其他 Peer 节点和连接的所有客户端。设置一个定时，触发Tick，运行合约的 OnTick 函数，如果有副作用产生就广播给Peer节点和连接的所有客户端。
如果不是Leader如果是Follower:
和Leader Peer 建立连接， 然后从Leader Peer 获取通道的初始状态和合约代码。然后监听Leader发送过来的消息。如何是合约执行结果消息，就在本地的MoveVM中执行，如果执行产生的副作用和Leader一致，就广播给客户端。如果不一致，就调用主链的合约创建一个提案，惩罚Leader, 并请求其他Peer投票，如果收到的投票数足够，就执行提案惩罚Leader，获取罚金。
2.3.1.2 处理加入状态通道请求
业务逻辑：
如果是Leader:
当某个SDK发送加入状态通道请求时，需要检查链上状态通道是否存在该成员地址，如果不存在拒绝加入请求。如果存在，创建成员加入交易，并将执行结果和交易一起广播给其他Peer。
如果是Follower:
当从Leader收到加入状态通道请求，从链上获取成员状态和带入的资产，验证交易是否合法。如果合法更新本地MoveSandbox状态，如果不合法，发起惩罚Leader的提案。
2.3.1.3 处理离开事件/
...
离开状态通道请求
业务逻辑：
当调用合约或者调用Tick函数，如果返回的事件包括离开状态通道事件 或者 用户主动发起离开状态通道API调用：就发起提案结算状态通道的状态，投票达标后执行状态结算，结算成功后通知对应的Peer下线。
2.3.1.4 处理关闭事件/
...
关闭状态通道请求
业务逻辑：
当调用合约或者调用Tick函数，如果返回的事件包括关闭状态通道事件 或者 用户主动发起关闭状态通道API调用：就发起提案结算状态通道的状态，投票达标后执行状态结算，结算成功后通知所有的Peer下线。
2.3.1.5
...
处理合约调用请求
业务逻辑：
当用户调用合约时，判断自己是否为Leader, 如果为Leader, 在本地执行合约调用，将结果广播给其他Peers, 然后保存到本地Store. 如果自己不是Leader, 将合约调用转发给Leader.
...
当用户请求订阅状态时，从本地获取快照返回给调用方，同时从快照高度开始从本地Store获取交易，在MoveVM中执行，并将执行产生的状态变更发送给调用方，如果已经运行过，直接返回状态变更。当从Leader接受到新的交易时，在MoveVM中运行，和Leader的结果对比，如果相同，则将变更转发给调用方，如果不相同发起举报投票。
2.3.1.7 处理投票请求
业务逻辑：
当收到其他成员发送的请求投票请求，
对于结算提案的投票：
首先验证投票的内容是否和本地的MoveSandbox状态一致，如果一致投赞成票，如果不一致投反对票。
对于惩罚Leader的投票：
首先使用本地的MoveSandbox状态验证Leader是否作弊，如果验证结果为Leader确实有作弊，投赞成票，否则投反对票。
2.3.2 MoveSandbox
MoveSandbox负责运行状态通道中的合约，生成新的状态变更，同时提供状态订阅功能。
...