...
1、总体架构
...
Settlement Chain： 支持结算的链，可以是Starcoin、AptOS、Sui 支持结算的链，可以是AptOS、Sui 或者 RoochRooch。
蓝色的P2P Node： 状态通道的Leader 节点，所有对状态通道的写操作，都需要转发给Leader节点
白色的P2P Node: 状态通道的Follow 状态通道的Follower 节点，从Leader 节点同步最新的交易并验证执行。
...
2、如何防止P2PNode作弊
所有参与状态通道的P2P Node 需要抵押一定的原生代币，如果P2P 需要抵押一定的虚拟资产，如果P2P Node 作弊或者不合作。将扣除抵押的原生代币。为了防止每次进入状态通道都质押币，用户可以选择将币质押给状态通道共享质押合约。这样用户进入状态通道时，指定使用共享质押合约作为抵押就可以。当用户的P2P Node出现作弊或者不合作将从共享质押合约中扣币。作弊或者不合作。将扣除抵押的原虚拟资产。为了防止每次进入状态通道都质押资产，用户可以选择将资产质押给状态通道共享质押合约。这样用户进入状态通道时，指定使用共享质押合约作为抵押就可以。当用户的P2P Node出现作弊或者不合作将从共享质押合约中扣出资产。
作弊的场景：
场景 | 1人状态通道 | 两人状态通道 | 三人状态通道 | n人状态通道 |
|---|---|---|---|---|
Leader 修改MoveVM实现/合约代码 | ？ | Follower 本地运行立即可以发现，然后举报，合约强制Leader退出通道，5分钟内不许再次进入，不罚款 | 任何Follower 本地运行立即可以发现，然后举报，两票赞成后，合约强制Leader退出状态通道，5分钟内不许再次进入，并罚款 | 任何Follower 本地运行立即可以发现，然后举报，两票赞成后，合约强制Leader退出状态通道，5分钟内不许再次进入，并罚款 |
Leader 丢弃/延迟对手的交易 | Follower发现Leader没有回复自己的交易，可以举报，合约关闭状态通道，不罚款 | Follower发现Leader没有回复自己的交易，可以举报，合约关闭状态通道，不罚款 |
...
3、如何选举状态通道的Leader节点
任何状态通道成员可以发起结算提案，一般状态通道的Leader会定时发起结算提案，有成员要离开状态通道时也会发起结算提案。结算提案包括结算的起始高度、结算高度、状态通道的变更集和发起方的签名。发起方创建结算提案后，需要通知所有Peer对提案进行投票，Peer收到通知后会使用本地交易数据对提案进行验证，验证的逻辑是计算起始高度和结算高度的变更集是否和提案中的变更集一致，如果一致认为提案没有问题，可以投赞成票，如果不一致投反对票。当发起方收到2/3的赞成票后，发起方执行提案，完成状态通道的结算。状态通道结算完成后，所有成员可以生成结算高度的快照，并清理结算高度之前的交易数据。所有加入状态通道的成员，需要和合约保持心跳，15s内有心跳的成员认为是有效成员。
...
当状态通道小于等于5个成员：
所有加入状态通道的成员，需要和合约保持心跳，15s内有心跳的成员认为是有效成员。
第一个进入状态通道的成员，查询状态通道状态，没有Leader, 将调用合约方法申请成为Leader, 合约检查只有1个有效成员，将验证通过。
其他成员进入状态通道的成员，查询状态通道状态，发现有Leader, 他将从Leader同步状态，并和Leader保持心跳， 如果和Leader15s心跳没有响应，他调用状态通道合约申请自己为Leader如果和Leader 15s 心跳没有响应，他调用状态通道合约申请自己为Leader, 合约检查之前的Leader如果有效将拒绝申请，如果之前的leader无效了，将通过申请。
...
对应申请失败的成员，将再次查询状态通道的最新状态，并和最新的Leader保持状态同步。
当状态通道大于5个成员：
需要选举5个成员作为候选成员，其他成员需要将投票权委托给候选成员，每个候选成员最大只能接受n/5-1个其他成员的委托。候选成员需要提供代理连接Leader节点功能，其他成员优先通过候选成员和Leader通讯。
问题：
选举过程中状态通道不可写。选举过程中状态通道不可写？
Leader故障如何快速切换？
...
4、如何选择和Leader的最优通信路径问题
状态通道的Follower需要从Leader同步状态和转发交易，但是有可能Follower直连Leader响应延迟没有经其他Follower中转效率高，所以为了发现最优路径。所有的和Peer的心跳包需要带上和Leader通信的最优延迟。
...
那么Follower1 将选择经过Follower 和 Leader通信。
5、如何加载状态
首先Leader从链上状态通道合约中获取状态通道的代码和初始账号状态。为了防止Leader加载过程中有其他成员加入，每个加入成员需要分配一个加入序号，Leader需要记录他加载时的最大序号，Leader加载成功后，其他成员从Leader同步初始状态，并也从链上加载状态通道状态并执行验证。当有新成员加入时，加入序号加1，有Leader验证后并同步给其他成员节点。
6、如何结算状态
任何状态通道成员可以发起结算提案，一般状态通道的Leader会定时发起结算提案，有成员要离开状态通道时也会发起结算提案。结算提案包括结算的起始高度、结算高度、状态通道的变更集和发起方的签名。发起方创建结算提案后，需要通知所有Peer对提案进行投票，Peer收到通知后会使用本地交易数据对提案进行验证，验证的逻辑是计算起始高度和结算高度的变更集是否和提案中的变更集一致，如果一致认为提案没有问题，可以投赞成票，如果不一致投反对票。当发起方收到2/3的赞成票后，发起方执行提案，完成状态通道的结算。状态通道结算完成后，所有成员可以生成结算高度的快照，并清理结算高度之前的交易数据。
四、详细设计
1、合约设计
状态通道的合约包括两部分，一部分给Dapp合约调用的合约接口，另一部分给P2P Node调用的合约接口。
...
2、P2P Node
2.1 模块图
...
2.2 Stream模块
Steam模块，维护和SDK的双向流连接。Steam模块，维护和SDK的双向流连接，并转发SDK的请求给对应的状态通道实例。
2.2.1 加入状态通道
命令：state_channel.join
...
错误码 | 描述 |
|---|---|
100001 | 状态通道不存在 |
返回值：
状态通道状态的快照。
2.3 状态通道
状态通道模块，负责状态通道的创建和关闭。状态通道模块，负责状态通道的状态的分发和验证。
2.3.1 Controller
状态通道控制器，负责协调其他模块完成状态通道功能。状态通道控制器，负责处理Sessions模块和Peers模块发送过来的请求。对于游戏类应用主动产生Tick交易。
2.3.1.1 初始化状态通道
业务逻辑：
当状态通道不存在时，调用状态通道合约接口，获取合约详细信息，检查 自己是不是 当状态通道不存在时，调用状态通道合约接口，获取合约详细信息，检查自己是不是 Leader ，
如果是Leader:
就加载初始状态到MemStore，合约代码到 MoveVM，然后监听 state_channel.call 消息，如果有消息就执行合约调用，把调用产生的副作用，广播给其他 Peer 节点和连接的所有客户端。设置一个定时，触发Tick，运行合约的 OnTick 函数，如果有副作用产生就广播给Peer节点和连接的所有客户端。
如果不是Leader如果是Follower:
和Leader Peer 建立连接， 然后从Leader Peer 获取通道的初始状态和合约代码。然后监听Leader发送过来的消息。如何是合约执行结果消息，就在本地的MoveVM中执行，如果执行产生的副作用和Leader一致，就广播给客户端。如果不一致，就调用主链的合约创建一个提案，惩罚Leader, 并请求其他Peer投票，如果收到的投票数足够，就执行提案惩罚Leader，获取罚金。
如果状态通道配置有Tick函数和间隔：
配置定时器，触发Tick交易。
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负责运行状态通道中的合约，生成新的状态变更，同时提供状态订阅功能。
...
https://cookbook.starcoin.org/zh/docs/concepts/multisig/
https://wiki.biligame.com/mc/%E5%AE%9A%E5%88%B6%E6%9C%8D%E5%8A%A1%E5%99%A8 《MineCraft定制服务器》
https://www.zhihu.com/question/24459078