在区块链的设计当中，最为关键的权衡之一，是将更多的功能构建到基础区块链层（layer 1）？还是将这些功能构建于区块链基础层之上的二层网络（ layer 2）协议当中（在不改变区块链本身的情况下进行创建及修改）。迄今为止，这种权衡在区块链扩容争论中体现的凌厉尽致，其中一方支持区块扩容（和分片），而另一方则支持二层解决方案（例如Plasma以及状态通道），此外在区块链治理问题中也有体现这种权衡，是通过the DAO式的分叉或EIP 867这类方案解决丢失及盗窃恢复问题？还是通过可逆以太（RETH）这类二层解决方案来解决？那么，哪种方法最终会是更好的？那些了解我的人，或者把我视作是一名肮脏的中间派的人，他们知道，我会不可避免地用“两者兼而有之”作为解答。然而，从长远来看，我确实认为，随着区块链越来越成熟，区块链基础层（layer 1）必然会趋于稳定，而二层网络（ layer 2）将承担越来越多的持续创新及改变负担。
原因有多个。首先，第一层（layer 1）解决方案要求在基础协议层进行持续的协议更改，而基础层协议变更就需要治理，而从长远来看，高度“活跃”的区块链治理会造成持续的政治不确定性或崩溃，导致区块链趋于中心化。
举个另一领域的例子，请参考莫西·马琳斯巴克（Moxie Marlinspike）为通信中心化和非联合性质所做的辩护。人们可以从这些争论中受益。引用：

“我们早期在使用通讯时所面临的一个争议问题，是将它作为非联合服务（unfederated service）来构建。我们所开发的任何协议，都不需要中心化，我们完全有可能构建基于一个基于联合通讯协议（ federated Signal Protocol）的通信应用，但我不再相信有可能建立一个有竞争力的联合通信应用。”

还有：

他们的反驳是：“这是愚蠢的，如果没有第三方定义的互操作协议，互联网能走多远呢？”我思考过这个问题，自从我们有了第一个生产版本的IP协议，而在过去的20年当中，我们一直试图转换到第二个版本的IP协议，但取得的成功却是有限的。我们在1997年迎来了1.1版本的HTTP，而其至今依旧未曾发生变动。同样的，SMTP、IRC、DNS、XMPP这类协议都停留在上世纪90年代末的状态。回答他的问题，互联网走了多远？我的答案是它走到了90年代末。他们的反驳是：“这是愚蠢的，如果没有第三方定义的互操作协议，互联网能走多远呢？”我思考过这个问题，自从我们有了第一个生产版本的IP协议，而在过去的20年当中，我们一直试图转换到第二个版本的IP协议，但取得的成功却是有限的。我们在1997年迎来了1.1版本的HTTP，而其至今依旧未曾发生变动。同样的，SMTP、IRC、DNS、XMPP这类协议都停留在上世纪90年代末的状态。回答他的问题，互联网走了多远？我的答案是它走到了90年代末。
互联网驱使我们走得很远，但不可否认的是，一旦让你的协议“结成联邦”，就很难做出改变。而现在，对于应用层面而言，在生态系统不断运转的世界里，静止的东西是不太好的… 只要形成联邦就意味着停滞，而去中心化则意味着运动，而在今天对软件运动要求很高的环境下，联合协议就会存在着问题。
而在此刻以及今后的短中期，似乎很清楚的是，去中心化的应用平台、密码货币支付、身份系统、信誉系统、去中心化交易所机制、拍卖、隐私解决方案、支持隐私解决方案的编程语言，以及其他大多数可在区块链上完成的有趣应用，这些领域将继续有重大和持续的创新。去中心化应用平台通常需要交易确认时间的持续减少、支付需快速确认、低交易费、隐私以及很多其他内置特性，交易所以多种形式及规模出现，包括链上的自动做市商、频繁批量拍卖、组合拍卖等等。
因此，将以上任何一个应用构建于区块链基础层将是一个坏主意，因为这样会制造出大量的治理问题，平台将不得不面对更多关于新技术改进实施及协调问题的讨论。由于同样的原因，联合通信应用（federated messengers）在没有实现重中心化的情况下，很难离开地面，区块链还是需要在采用积极治理和带来危险、落后于新出现的替代方案之间，做出平衡选择。
甚至以太坊有限的特定应用功能、预编译，也看到了一些这样的效应。不到一年前，以太坊采用了拜占庭硬分叉，包括使用alt-bn128曲线来促进环签名、ZK-SNARK和其他应用。现在，零币（Zcash）和其他区块链正朝着BLS-12-381（译者注：新的zk-SNARK椭圆曲线构造）迈进，而以太坊需再次分叉才能赶上步伐。部分原因是为了避免将来出现类似的问题，以太坊社区正寻求将EVM虚拟机升级至E-WASM，这种新虚拟机的效率会更高，其不太需要结合专用预编译程序。
而第二种支持二层网络（layer 2）解决方案的论点在于，其不依赖于预期技术的发展速度：有时会存在不可避免的权衡，世上并没有单一的全局最优解决方案。这在以太坊 1.0类型的区块链中不太容易看到，其中有一些模型是相当通用的（例如，以太坊的账户模型就是一个）。而在分片区块链（sharded blockchain）身上，在以太坊平台上不存在的一类问题出现了：如何进行跨分片交易（cross-shard transaction）？也就是说，假设区块链状态具有区域A和区域B，其中很少或没有节点在处理A和B。系统该如何处理影响A和B的交易？
当前的答案涉及异步跨分片通信，这对于转移资产和其他一些应用而言已经足够了，但对于很多其他应用来说却是不够的。同步操作（例如，解决火车和旅馆问题《 train and hotel problem》 ）可附加在yanking跨分片（cross-shard yanking）上，但是，这需要经过多轮跨分片交互操作，从而它会导致显著的延迟问题。当然，我们可以用同步执行方案解决这些问题，但是这里需要几类权衡：
系统不能为每个区块的同一账户处理超过1笔交易；
交易必须预先声明其影响的分片及地址。
如果交易仅在部分分片当中被接受，其并不影响其他人，那么任何给定的交易，失败的风险都很高（并且仍需要支付费用！）。
似乎很有可能会开发出更好的方案，但同时这些方案也将更复杂，并且很有可能具有以上方案所没有的局限性。已知的案例，很好地证明了完美是无法实现的。至少，阿姆德尔定律（Amdahl’s law ）严格限制了一些应用及一些类型的通过并行化处理实现更多tps的交互能力。
那我们如何创造一个环境，其可被更好的方案所测试和部署？Justin Drake给出了一个答案：二层网络执行引擎（layer 2 execution engines）。用户将能够将资产发送到一个“桥接合约”（bridge contract）当中，该合约将使用一些间接技术（例如交互验证或ZK-SNARKs）来计算状态根，其使用的是一些替代的区块链处理规则集（把它认为是二层网络方案的‘元协议’，比如建立在比特币之上的Mastercoin/OMNI 协议以及Counterparty协议） ，而且，当且仅当替代规则集生成撤回请求时，该合约才会处理撤回请求。

注意，任何人都可以在任何时候创建二层网络执行引擎，不同的用户可以使用不同的执行引擎，并且可以相当快地从一个执行引擎切换到任何其他的执行引擎，或者切换回基础层协议。基础层区块链不必一种最优的智能合约处理引擎，它只需要成为一个具有图灵完备执行规则的数据可用性层，那么任何二层的桥接合约都可以建立在其顶部，并且允许基本操作在分片之间传递状态（实际上，只要ETH传输在跨分片之间是可替代就足够了，但要允许跨分片的调用，我们还需要少许的努力，所以我们不妨也支持它们，），而超过这一应用的复杂性，是我们所不需要的。
从长远来看，第一层网络不会在所有这些改进上积极竞争，它只是提供了一个稳定的平台，能够让二层创新在其顶部发生。那这是否意味着，分片就是一个坏主意？我们应该让区块链大小和状态维持在小的状态，甚至10年历史的旧式电脑也可以处理每个人的交易？绝对不是这样的，即使执行引擎是部分或完全移至第二层网络的东西，在数据排序和可用性上达成共识仍然是高度通用和必要的。你需要明白的是，在第一层网络没有实现可扩展数据可用性共识（scalable data availability consensus）的情况下，第二层网络的执行引擎会是困难的，请参阅Plasma研究中遇到的困难，这种困难也自然会延伸到各类通用型区块链的身上。例如，如果人们希望将每秒100 MB的数据放到一个需要对可用性达成一致的区块链系统当中，那么，我们就需要在每秒100兆字节数据的可用性问题上达成共识。
此外，第一层网络在减少延迟方面仍然有改进的地方；如果第一层网络很慢，实现极低延迟的唯一策略就是状态通道，而状态通道通常具有很高的资本要求，并且它们很难推广。由于状态通道仅需要一条网络信息，所以其在延迟方面总是优于第一层区块链，但是在状态通道无法正常工作的情况下，第一层区块链仍然可实现比今天更低的延迟。
因此，在另一个极端位置，“区块链基础层可实现绝对最小化，并且不需要使用一个准图灵完备的执行引擎或可扩展性来超越单个节点的容量”，这种观点也是明显错误的；对于基础层来说，其需要一定程度的复杂性以使其足够强大，从而能够在基础层上构建应用，而目前我们并没有达到这一程度。额外的复杂性是需要的，当然我们也应该非常仔细地选择，以确保它是最大限度的通用目的，而不是针对特定的应用或技术（由于用户失去兴趣，或更好替代品的出现，这些应用或技术将在两年内过时）。
而在未来，甚至基础层也将继续进行一些升级，特别是当新技术（例如STARKs达到更高的成熟度）允许它们实现更强大的性能时（尽管开发人员今天可谨慎地使基础层平台，最大限度地兼容这些潜在的改进）。因此，随着时间的推移，尽管二层网络方案将继续在创新中占据越来越大的份额，在基层和二层网络（可扩展性、隐私性以及通用性）改进之间的平衡仍然是需要的。
2018.08.29日更新：Justin Drake向我指出了，为什么一些功能最好在基础层网络上实现：这些功能是公开的，因此不能有效或可靠地使用特定功能使用费，因此，它们最好是由发行人支付的补贴或燃烧的交易费用来支付。其中一个可能的例子，就是安全随机数的生成。