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