每晚八点，我们在社区分享知识，等你。
NervosFans 微信公号：Nervosfans
入群请加乐乐微信：sensus113 美果大冰微信：xj73226
备注入群，谢谢！
人们对区块链设计中有关‘更多功能究竟应该构建在基础层区块链本身（第1层），还是构建在区块链之上无论创建或修改都不涉及区块链变更的协议中（第2层）’的看法莫衷一是。这个问题在有关扩容的诸多争论中表现的最为突出，一边是增加块大小（还有分片），另一边是各种诸如Plasma、通道类的二层解决方案。某些时候区块链治理也会进来凑个热闹，如恢复失窃的DAO分叉或通用EIP 867再或者是可逆以太币（RETH）这种二层手段。所以，到底哪种方法更理想？熟悉我的人，或视我为‘老好人’的盆友，知道我肯定会讲:“两者兼而有之”。然而，长远看来，我也确实认为随区块链日益成熟，第1层必然会稳定下来，而第2层将承担起更多不断创新与变革的重任。
这么讲当然有原因。首先，layer 1解决方案需要不断在基础协议层做协议变更，而基础层协议变更又涉及治理，目前来讲，还没有高度“激进的”区块链治理不会引发持续的政治不确定或深陷集权的例子。
来看看其他领域，有关Moxie Marlinspike对Signal协议集中、非联合性质是怎么说的。一家企业捍卫其维持对其主要业务所依赖的生态系统的控制权的文件，理所应当应谨慎对待，却也可以从这些论点中受益。以下为援引：
我们早期对Signal做的一件有争议的事情就是把它建成一个非联合服务。我们开发的任何协议都不需要集中化；且完全可以建立一个以联合制Signal协议为基础的信使，但我不相信有还能建立一个有竞争力的联合信使。
和：
他们反驳说：“太蠢了，要是没有第三方定义的可互操作协议，互联网能走多远？”我有想到这一点。第一个生产版本的IP之后的20年里我们一直努力转向第二个生产版本，却收效甚微。1997有了HTTP1.1版本，到现在还是这样。同样，SMTP、IRC、DNS、XMPP也都在上世纪90年代末期进入冰封期。所以，回答上面的问题，互联网走到90年代末（就不动了）。
不是说互联网技术发展的不好，但不能否认的是，一旦协议联合，想做改变就非常困难了。而当前，在应用层面，生态系统的不断变化的意味着不变则不通......只要联合意味着停滞，而集中意味着移动，那么今时今日瞬息万变的软件气候下联合协议迟早吃不消的。
未来一段时间内（中期），诸如去中心化应用平台、加密货币支付、身份&信誉系统、去中心化交易机制、拍卖、隐私解决方案、支持隐私解决方案的编程语言以及其他很多可以在区块链上愉快玩耍的应用依旧是重要的创新领域。去中心化应用平台需要不断减少确认时间、付款需要快速确认、低交易成本、隐私和许多其他内置功能；交易所有各种形式及规模，包括链上自动造市商、频繁的批量拍卖、组合拍卖等。因此，“内置”任何这些到基础层区块链中应该是个烂主意，原因是平台必须不断讨论、实施和协调新技术改进而产生很高的治理开销。联合信使很难在不重新集中的情况下开始工作，同理，区块链中也要在采取激进治理手段并承担异一定的风险跟永远赶不上热乎的新替代方案之间做出选择。
即使是以太坊的特定应用功能、预编译，也没能躲过这些影响。去年，以太坊部署拜占庭硬分叉，包括（增加）环签名、ZK-SNARKs等其他应用所需的椭圆曲线操作的各种辅助操作。现在，Zcash和其他区块链正在朝BLS-12-381迈进，而以太坊需要再次分叉才能追赶上。为避免将来出现类似的问题，以太坊社区正在寻求升级EVM到E-WASM。E-WASM是种更为高效的虚拟机，很少需要整合特定应用的预编译。
当然，支持layer 2的第二个论点，不以技术发展的速度为转移：所谓tradeoffs不可避免，自然不存在单一的最优全局解决方案。但是这种论断在以太坊1.0这种某些模型还是相当普遍的区块链中表现的并不十分明显（比方说以太坊基于账户的模型是个例子）。然而，在分片区块链中，就出现了当前以太坊中尚不存在的一类问题：如何进行跨分片交易？也就是说，假设区块链状态分为区域A、B，且基本没有节点A、B都处理。那么，系统如何处理影响A和B的交易？
当前的答案涉及异步跨分片通信，能传输资产及一部分应用，但是剩下的多数应用就处理不了了。可以通过跨分片（锁定）处理引入同步操作（例如，解决车票和酒店问题），但需要多轮跨分片交互，进而导致显着延迟。可以通过同步执行方案解决这些问题，但还是有些tradeoffs：
• 每个区块中，系统无法为同一账户处理超过一笔交易
• 交易必须事先声明其影响的分片与地址
• 交易仅被其影响的若干分片接受时，该交易失败的风险很高（仍需支付费用！）
应该是可以开发出更好的方案，但会非常复杂，且很可能带出点上述方案没有的局限/问题。也有些已知方案果断放弃了朝完美方案进军；比方说Amdahl定律对某些应用及某些类型的交互通过并行化每秒处理更多交易的能力做出严格限制。
那么，如何创建一个得以测试并部署更优方案的环境？答案归功于Justin Drake这位盆友的点子，叫layer 2执行引擎。用户可以将资产发送至“桥接合约”，合约使用一系列区块链处理的替代规则（可以理解类似比特币上Mastercoin/OMNI和Counterparty等的二层“元协议”）计算出（使用某些间接技术，如交互式验证或ZK-SNARKs）状态根（桥接合约使这些协议能够处理“基础分类账”定义在底层协议上的资产），并且当且仅当替代规则集生成撤回请求时才会撤回。
注意，任何人都能随时创建layer 2执行引擎，不同用户可以使用不同执行引擎，且能从一个执行引擎快速切换到其他执行引擎或基础协议。基础区块链从此不用担心成必须成为最佳智能合约处理引擎；只需成为一个具有准图灵完备执行规则的数据可用性层，支持在其上构建任意layer 2桥接合约，并支持基本操作在分片间传送状态（其实，跨分片的ETH传输是可替换的就足够了，但是想支持跨分片调用也不是难事，所以也一并支持好了。），又无需额外的复杂性。另外，layer 2执行引擎的状态管理规则可以与layer 1不同。譬如说，无存储租金；鉴于该特定执行引擎的用户有责任确保其可持续，反之出现问题时，任何后果也仅控制在该特定执行引擎的用户中。
长远来看，layer 1并不会积极参与所有这些改进；它只为layer 2创新提供稳定的平台。可这样一来，是不是就不要分片了？是不是应该把区块链和状态大小保持在很低的程度，进一步降低交易处理设备的配置门槛？
当然不是了。
即便执行引擎被部分或完全转移至layer 2，数据排序与可用性的共识（过程）仍是个高度概括的必要功能；想要了解没有layer 1可扩展数据可用性共识的情况下layer 2执行引擎有多困难，可以参见Plasma研究中遇到问题，还有Plasma自然扩展到完全通用区块链的难度就知道了。若人们想要将每秒100兆字节的数据投入某系统中，系统还得有可用性共识，相应的，这个共识过程就得是每秒百兆字节的数据。
此外，layer 1仍可改善延迟；若layer 1确认速度慢，能实现低延迟的唯一策略便是状态通道，但是状态通道通常具有高资本要求且难以通用化。由于状态通道仅需单个网络消息，因此总会在在延迟上（相比layer 1区块链）略胜一筹。
因此，‘区块链基础层可以实现绝对的最小化，既不考虑准图灵完备执行引擎也不考虑超过单个节点大小的可扩展性’的另个极端，显然也是错误的；基础层为了能有效支持构建在其上的应用，复杂性当然不是无下限的，只能说我们还未到那个层面。额外的复杂性有必要，前提是谨慎选择，最好确保能实现最大限度的通用目的，而非特定于某些应用或技术，万一这些东西红不过两年怎么办。
未来，基础层升级的脚步不能停歇，特别是当新技术（譬如STARKs发展空前）强劲来袭，不过当今的开发者已经在潜心促进基础层平台最大限度地向前兼容这样或那样的改进。因此，仍需在layer 1和layer 2方案中不断平衡，以期扩展性、隐私及多样性上的完善，长远看来，layer 2在创新层面具有会很大上行潜力。
https://vitalik.ca/general/2018/08/26/layer_1.html
网友评论