现在我们已经对以太坊的局限性及其对 DeFi 的影响有了全面的了解。当然，所有天王级的团队都在开发解决方案，对吧？

一个 Layer-1，两种愿景

现在有很多厉害的团队在开发不同的可扩展性解决方案。解决方案主要有两个方向，「Layer-1」 和 「Layer-2」。Layer-1 的方案致力于打造一个更可扩展的区块链来取代当前的以太坊，Layer-2 方案则是尝试在当前以太坊的基础上接入更可扩展的基础设施。我们这里就谈 Layer-1，Layer-2 方案留给下一篇文章。

我们从最明显的一个方案开始：提高当前以太坊区块链的性能。也就是 「Eth1.x」 同仁在做的事。单论以太坊客户端的性能提升，就有很多工作可以做。不过，Eth1.x 还没有得到他们应得的支持力度，所以进展缓慢。想要对这个方向的性能提升可达到的程度有个基本概念，只需了解一下 Solana 就好，Solana 实现了以太坊的 1000 倍吞吐量，而且还有空间可以提高；缺点在于需要很高级的硬件才能运行全节点。

大部分其他解决方案都有三点共同之处：（1）使用 WebAssembly 作为虚拟机；（2）最小化状态的架构；以及最重要的，（3）分片。当前的以太坊是串行执行所有交易的。事实上，让交易能排成一个队列可以说是区块链的全部意义所在。但这种模式的缺点就在于，难以并行执行交易，所以我们无法通过投入直接更多资源来解决扩展问题。那么把区块链分割成多个松散互联的领域，一个线程就叫一个 「分片」，就能实现并行化处理。在一个分片内部，事务仍然是串行发生的，但不同分片的事务是移步发生的。这就使得所有分片能并行运行，以分片数量为倍数扩大网络的吞吐量。我们用来分割网络的领域也不需要与分片一一对应，可以把多个领域分配给同一个分片（线程），甚至可以移动它们做负载均衡。看 Near Protocol 的 「夜影」 协议白皮书可更深入地了解分片的大体。

具体如何将区块链分割成多个领域，下一代的区块链各有想法。可以认为，这是一条从细粒度（许多细小领域）到粗粒度（少数几个大型领域）的光谱。

两个项目分别代表这条光谱的两端。DFinity 在细粒度这一端，每一个 「actor」 都有自己的细小领域，而且每个 actor 之间的交互都是异步的。粒度稍大的的 Near Protocol，其中每个合约都有自己的领域。粗粒度一端的是 PolkaDot，一个领域就是一整个分片，更具体一点应该叫做一条 「平行链」。从一个 dApp 开发者的视角来看，断言 Ethereum 2.0 位于哪个位置还为时尚早。ETH1 EE （执行环境）应该是粗粒度型的，其边界恰好与一个分片的边界一致，就是当前的以太坊所化成的一个分片（也就是 Eth1 在 Eth2 实现后的未来）。一个专门的 Eth2EE 可能会选择一个更细粒度的方案。细粒度方案的长处在于它们是透明的；可以将所有的跨合约调用一视同仁，无论这些调用是否跨越了分片边界。这就能反过来允许我们通过在分片间移动合约来实现负载均衡。

缺点在于，跨越领域的事务就不再是原子化的了，它们会变成 并行的，甚至是部分 不可逆 的。在 DFinity 和 Near 中，这一点表现为跨合约的交易变成 async 状态，并返回一个承诺：你需要 await（等待）。在一场 await 期间，所有到时已经发生的交易都会被提交到链上。然后其他人的交易可以堆积在上面。到这时你就无法回滚已经发生的事情了。当 await 最终解决的时候，它会从合约调用中返回 「成功」 或者 「失败」。有许多提案尝试避免这一点、找回某种形式的跨分片原子性，但都有自己的缺点。看起来，拥抱非原子性会是自然结果。

但对 DeFi 应用来说，一个异步的 transferFrom 调用会带来相当大的挑战。设想一个两方之间的简单交换，Alice 和 Bob 希望交换 Eth 和 Dai。基本合约看起来会像这样：

但现在我们需要能处理错误。如果第一笔交易失败，我们可以简单地终止交易。但如果第一步交易成功而第二笔交易失败，我们要能返还给 Alice 一个 ETH。问题在于，Bob 可能已经在我们处理错误之前就花掉了这笔钱。解决这个问题的一个办法是使用一个 escrow：

很好，现在就不会有人丢币了。但现在 Bob 就对 Alice 的出价有了一个免费的排他性期权（free exclusive option）。虽然现在 Alice 的钱保管在托管方手里，但这些钱既不能接受其他人的交易请求，也不能保证跟 Bob 的交易一定会成功。你可以用惩罚恶意行为来解决这个问题，但是你很难确定合理的惩罚力度，因为不同 DeFi 交易的价值差别非常大。你也可以要求所有市场参与者从一开始就把钱都放在同一个储蓄合约（托管方）里，但这样就重新使得状态集中化、取消了分片的意义。

另一个需要注意的事情是，这些并发问题可能非常棘手。在现实的交易所中，订单的填充状态（fill-state）需要不断更新，这就使得写一遍的更加复杂。如果说困扰以太坊 1.0 的可重入漏洞（reentrancy bug）是蝴蝶，可能引起巨大的后果，那并发问题就是床上的臭虫（bug），无孔不入。并发漏洞是不确定的，而且在测试中可能根本看不出来。就像我们在上面的简单的交换的例子中看到的，开发者需要从头重新思考整个架构，就像床上的臭虫，清除它们的唯一办法就是把一切都推倒，从头重建。

交易所是 DeFi 世界其余部分的基石，而且显然是个川流不息的连续过程。我们已经看过了订单簿类型的交易所面临怎样的挑战。自动化做市商（Automated market maker）交易所还简单点，因为参与者已经将资金都存储在托管方（合约）处，但在这种情境下，储备起来的余额本身就阻碍了并行化处理。即使在更快的传统交易所里，结算活动最终也是在一个撮合引擎里面按顺序处理的，不会用到并发，（但比较好的是传统交易所还可以有冗余）。想深入了解传统交易所是如何运作的，可观看 Brian Nigito 的演讲。 (责任编辑：admin1)