背景：扩展性问题
“为何扩展性很难实现？我经常谈论有关‘扩展性的三难困境’(scalability trilemma)，即区块链系统必须在不同的特性之间进行权衡。它们很难同时都具备三个特性，其中之一就是去中心化，另一个就是扩展性，第三个就是安全性。"
-- Vitalik Buterin,2017年11月
诸如比特币 (Bitcoin) 和 以太坊 (Ethereum) 等无需许可的公链平台已经在第一层 (Layer 1) 选择了优化安全性和去中心化程度，而不是高交易吞吐量。任何想要成为验证者 (validator) 的人都可以参与，且成为验证者要求只需要相当少的时间和资金投入。
在 PoW 机制中参与挖矿的节点保护整个区块链网络免受 51% 攻击 (按照2019年4月份的价格计算，这种攻击在以太坊区块链和比特币区块链上的攻击成本分别为每小时约10万美元和超过35万美元)。
以太坊的真正无需许可的去中心化属性和高安全性使其成为全球经济信任层的首选平台，并确保了该平台上的区块链应用程序的安全。
然而，安全性和去中心化是以扩展性为代价的。当前以太坊每秒处理的交易量约为5笔，并且如果每秒处理的交易量为6笔就会出现超负荷问题，且理论上每秒处理的简单交易的限制为14-15笔。对于任何主流的现存消费者或金融应用来说，这个数字都是九牛一毛的。
“其核心限制是，像以太坊这样的公共区块链要求网络中的每个节点都要处理每一笔交易。”
--Josh Stark，2018年2月
在以太坊2.0阶段，以太坊基金会 (EF) 有着一个升级以太坊区块链基础设施的先进路线图，将在接下来的几年中大大地改善以太坊的扩展性。
但是，很多项目当前就在以太坊平台上搭建应用程序，这些程序现在就需要实现扩展！此外，基于这些应用的实际用例，即便 Serenity (Eth 2.0) 已经实现，那你可能也不希望所有的交易都运行在以太坊主网 (即第一层) 之上，而是选择第二层解决方案。
当前的主要挑战
缓慢 -- 交易吞吐量低，满块 (full block) 情况下的网络延迟依赖性；
昂贵 -- 用户必须为每笔交易支付 gas 费用
用户体验不佳 -- 用户必须为每笔交易进行签名并等待交易被确认，之后下一笔交易才能被执行。
扩展性方案
当前可以实现的用于扩展交易吞吐量的扩展性方案，当然还存在其他一些包含链下计算和其他扩展向量的解决方案，但本文将主要探讨以下扩展性方案：
链下消息签名 (元交易) -- 使用以太坊密钥对 (key pairs) 在链下对消息进行签名，存储并发出事件，或将事件传递给 P2P，然后根据这些消息上的内容和签名更新链上的状态;
支付通道 -- 交易双方之间实现价值交换的链下通道，并在链上对交易;
状态通道 -- 实现交易双方之间多次更新状态的链下通道，并在链上对这笔交易进行最终的状态更新；
侧链 x 桥接 (bridges) -- 功能齐全的侧链通过桥接只能合约和中继机制来锚定以太坊主网;
Plasma 链 -- 功能齐全的子链 (child chain) 会定期地将其状态树 (state tree) 提交至根链 (即以太坊主网) 之上。
扩展性方案的折衷之处
(点击图片可放大)
扩展性方案的描述 & 实现
下方的扩展性方案都是开源的，可用于开发者搭建应用程序，尽管所有的扩展性方案都处于发展中，并且在将应用部署到主网之间，强烈建议进行安全审计 (下方涉及到实现扩展性方案的项目，不包括尚未发布可用产品或者代币库的项目)。
01. 消息签名
用户通过密钥对 (公钥 + 私钥) 使用 keccak256 哈希算法，在链下对消息进行签名；
消息可以存储在 IPFS (星际文件系统) 或者 DB (数据库) 中，之后分批处理成一笔链上交易；
消息也可以通过 P2P 传递，并且一旦消息 (通过公钥) 被验证为来源于有效或者授权的一方，则该消息就可以被作为 oracle 输入到主网的智能合约中；
之后智能合约就会接收并执行该信息；
在 ETH Berlin 会议期间，MakerDAO 就使用消息签名的方法，提议了一个链下价格预测的解决方案。
相关资源：
Karl Floersch -- 哈希算法和消息签名基础知识：
https://cryptoeconomics.study/
Mario Conti -- 通过链下签名消息进行价格预测 (price oracle)：
https://view.ly/v/Rt275OYzLCI1
Vitalik Buterin -- 预言机：
https://blog.ethereum.org/2014/07/22/ethereum-and-oracles/
02. 支付通道 & 状态通道
状态通道 (state channels) 包含三个主要步骤：
交易双方将初始的区块链状态 (比如双方的余额) 锁定在一个智能合约中，该智能合约非常类似于一个多重签名的钱包。这确保了只有当双方都已经对更新进行签名之后，钱包中的资金才能被解锁并进行转移。
双方通过在批次之间传递状态更新 (比如余额的更新) 来实现交易。如果双方同意，则对某个状态更新进行“签名”，该状态更新会被提交给智能合约中以便解锁资金；
当双方完成交易时，他们各自都会将状态更新提交给智能合约。如果双方提交的状态更新相匹配，那双方的区块链的状态 (比如双方的余额) 将会被解锁，该状态通常会与双方的初始状态不一样。
支付通道 (payment channels)：
支付通道是一种受到限制的状态通道解决方案，仅限于 ETH 或者 ERC20 代币的支付。其简化的结构允许更大的吞吐量和更高效的设计，因为只有一个 (或几个) 状态会被更新，即净余额 (net balance)。
争议解决：
交易双方签名的每个状态更新都会被分配一个“nounce”，也即一个独特的用于确认此次更新的数字。较新的 nouce 会取缔旧的 nonce。
一旦 A 方提交了一个状态更新，一个挑战期 (challenge period) 就会启动。在该挑战期期间，B 方可以提交一个带有更新的 nonce 的状态更新。当挑战期结束时，带有最新 nonce 的更新将被用于解锁区块链状态，并适当地分配资金。
现有的项目 & 实现：
