0 为什么要做链下扩容
- 人类经济活动的定义：信息传输和价值传输之间的转换。
- 目前的情况是：信息的传输进步很大；因为信任壁垒，价值传输演进的过程十分缓慢。
- 比特币、以太坊带来价值传输的进步。但是比特币和以太坊的非常慢。
1 扩容的目标
- 对标visa
- 作者认为应该对标整个信息传输的体量。从8到15TPS，进步到5.3亿TPS，10毫秒的延时。
2 链上扩容
传统区块链的技术架构：blockchain + dApps
- 改变共识算法的问题：无论如何改变，共识算法仍然是分布式算法，需要多个server达成一致，处理的上限是一台机器处理能力的上限。
- 分片扩容的问题：艾木塔（音）理论——只要有X%的东西不能并行，则无论分多少片，也无法突破这个瓶颈。
3 链下扩容
在blockchain和dApps层之间添加链下扩容层：
- 链上作为仲裁层，相当于法院
- 链下运行智能合约和交易
- 大量交易仅限于交易者之间，有较强的隐私性
state channel 101：
on-chain bond contract：在智能合约中放入各自的钱，通过balance proof证明各自拥有的账户余额，就可以进行链下交易。
- Alice将有自己签名的balance proof发给Bob，Bob就知道Alice给自己发钱了，因为只要他自己签上名发到合约中，就可以修改合约中的balance proof
- balance proof有序列号，逐渐递增，合约总是承认序列号最大的balance proof
- 结束交易，将balance proof提交到链上，合约按照balance proof中的金额给Alice和Bob打钱
- 中途有人提交balance proof，合约就在一定的时间内接受争议和仲裁，如果另一个人能发布一个序列号更新的balance proof到合约中，就能根据新的balance proof进行账户余额的分配
state channel 201：
每两个人之间的state channel都要存钱，当人多了以后，存的钱就很多，对支付者压力很大。
如果Alice和Bob之间可以通过其他人连接，并且可以无需信任的通过其他人进行价值传输，就可以解决这个问题：
- 发钱的人发送带锁的交易，发送给中间人，如果有人能用钥匙解开，就可以获得这个钱。中间人无法解开这个交易，就把这个带锁的交易发送给下一个人。
- 到了接收钱的人手里，出示钥匙，请求中间人将交易解锁，中间人将这个请求转发给上一个人，直到转发到发送者手里，发送者解锁交易，交易才顺利完成。
- 如果有中间人不愿意转发交易，交易无法达到接受者，或者接收者的钥匙无法到达发送者，就可以将交易放到真实的链上运行，交易仍然可以完成，所以流程仍然是安全的。
也就是说链下是可以执行带条件的支付（you can do off-chain conditional payment）
4 state channel 599: celer network
cStack：cChannel -> cRoute -> cOS
cChannel：链下支付和链下智能合约，state channel、side chain联合架构，可以接入多个公链，为多个公链进行扩容
以象棋为例：
- Alice和Bob只有最开始的时候的象棋合约的创建是在链上进行的，其他的时候都是在celernetwork的链下虚拟机进行下棋。下棋的过程中不收取手续费，响应非常快，互联网产品的体验。
- 如果棋手作弊，则需要通过链上的智能合约进行仲裁，对作弊者进行惩罚。
- 比赛结束，链下合约的条件支付自动改成无条件支付。添加赌资，合约可以根据象棋的结局决定谁能赢得比赛，获取全部的赌资。
cRoute：可证明最优的状态路由
链下智能合约：效能瓶颈消失，因为只需要合约的双方维护智能合约的状态，不需要主链的所有的节点去维护合约的状态。
传统无状态通道模型，流量的总量一直不变；状态通道的链路是有状态的，链路可以发送的钱的多少取决于已经发送的钱。
传统路由方式是最短路径路由，会造成网络的状态的不平衡，cRoute是可证明最有的状态路由，可以改变这中不平衡的状态。仅仅发送交易，效率是雷电、闪电网络的10到15倍。
构建纯虚智能合约：不需要在链上运行的智能合约
cOS：开发者SDK，celer全节点，celernetwork的入口层
链下编译器，方便开发者，一套代码，可以同时运行在链上和链下的智能合约
challenge：
- 不在线的情况下被诬告的情况，用历史状态提交，不在线的人无法用新的状态更新链上状态；
- 链下服务商需要和很多人连接，需要很高的成本；
无法用技术解决，运用区块链的重要特点：技术不够，经济来凑，使用经济激励解决问题。
解决方案：
-
SGN(State Guardian Networ)状态守护网络，一种侧链，celer token的拥有者。拥有的celer token越多，有越高的概率获得状态保护的请求，获取一定的收入。发送状态是一种自动的过程，防止用户下线前忘记发送自己当前的状态。SGN是整个网络的分布式的守护体。
非常灵活的保险机制：动态为自己的状态投保，投保额度的大小决定获得的SGN的多少。相当于如果出现问题，恢复状态所需要花费的时间的多少。
用户使用的时候只需要决定自己需要一个月为自己的状态花费多少钱去投保，celer系统会为用户计算出相应的投保额度。如果相应的比例的SGN没有提供状态守护，用户可以获得对应比例的celer token作为赔偿。
用户断电下线的情况：
- 我方已发送状态，对方接收状态，签名发送回给我方，我没有收到就断电下线了：相当我方没有收到最新的状态，任何的计算机系统都无法解决这类问题。
- 我方已发送状态，对方接收状态，签名发送回给我方，我放收到后没有存入本地，断电下线：在存入本地之前发送给SGN，有一定的回滚的可能，这和底层区块链的安全程度相当，因为底层区块链在交易发送以后断电也有可能造成交易失效。这也是计算机系统所能承受的极限。多个人同时看守状态，只要有一个人执行状态看守，就能确保状态可信。
除了SGN没有更好的保护状态的方案。
- 中心化的状态守护可能有和对方合谋作弊的可能。
- 抵押获取赔偿，用户抵押的钱太多，会造成流动性问题。
- Proof of Liquidity Commitment Mining：锁定流动性可以获取celer token的奖励
- Liquidity Backing Auction：可以通过系统进行借款，获取利率回报
5 side chain
侧链101：
侧链：在主链的智能合约，是由block proposers（区块申请人）组成，不是矿工，抵押自己的token，维护一条区块链。有很多交易，交易的merkle tree的merkle root会被提交到主链上自己的智能合约中。
在以太坊中，侧链的实现形式叫plasma，是UTXO模型，是O(1)的算法算法复杂度，在侧链中证明无效交易最为快速。只要将有争议的交易放到主链中进行验证，如果两笔交易使用的是同一个UTXO，那么后面的交易就是无效的。invalid block也会被取消掉，相当于中侧链中发生了一次回滚。所以侧链的状态并不是最终的状态，不能保证是否会被revert。
如果不用UTXO，用account modal，过程就会变得很复杂，验证account余额的有效，需要验证每一笔交易，这样消耗的gas太大，难以实现。
侧链201：
plasma侧链难以实现智能合约：因为智能合约的代码和状态太多，难以约定所有合约的使用者同意将合约迁移到主链中，所以难以实现。相当于在EVM中实现EVM，gas消耗及状态处理太复杂。
但是可以借助zero knowledge技术实现侧链中的智能合约，暂且不细说。
侧链301：
Data availability challenge：block proposer（区块申请人）只提交区块头的hash，不广播交易，其他人无法了解其中包含的交易。其他用户觉得有风险，要到主链确认交易，区块申请人提出和自己打包的区块中的交易有冲突。主链作为法官，最难解决的问题就是不知道谁是正确的交易，需要看到交易被真正的包含在主链中才能算交易成功。
解决：
Alice转钱给Bob，Bob可以认为自己还没有收到钱，Alice需要在链下发消息说已经看到这个交易被打包到区块当中，Bob才能确认自己收到了钱。可以通过零知识证明比较方便的解决这个问题。
6 interactive compute
想计算一个很复杂的能用EVM执行的程序，放到一个智能合约中，这个智能合约不执行这个程序，只是储存这个程序，甚至是储存程序的hash。
有人（需要在链上锁定一定的ETH）在线下计算结果，然后将结果上传到区块链中，但是可信度不够。
其他人计算结果不同，可以挑战他，折半查找直到最后一次计算结果相同。然后由链进行计算（区块链有能力进行这个单步运算），进行仲裁，挑战者获胜可以赢得被挑战者的保证金。
通过互动运算将大的计算变成许多小的计算。
