CKB联创Jan：什么是L1饥饿问题 Layer2与Layer1该如何设计

编译：雾月&白丁，极客web3

本文为Nervos联创Jan在2019年HBS Blockchain+Crypto Club Conference上的讲话，主题围绕着Layer2与Layer1之间的关系展开，明确提出模块化区块链会是正确的方向，还谈及了区块链数据存储机制的问题。同时Jan也抛出了一个颇为有趣的话题：Layer2的兴起若导致Layer1饥饿，该怎么解决。

作为最早一批支持Layer2与模块化区块链叙事的团队，Nervos的主张在18、19年时颇具前瞻性，彼时的以太坊社区还对分片抱有不切实际的幻想，而高性能单片链的叙事也处于甚嚣尘上的状态，尚未被充分证伪。

但在2024年的今天，回看以太坊Layer2在实践当中暴露出的问题，以及Solana为代表的“高性能公链”在去中心化与免信任问题上的弊端，不得不说Jan在5年前的观点很有先见之明。出于对Layer2本身的兴趣，“极客web3”将Jan的讲座以文字版的形式整理成文，发表于此，欢迎Nervos与以太坊、比特币社区的Layer2爱好者们共同学习与讨论。

以下为Jan的讲座原文。

Layer1和Layer2的定义

这是我对L1和L2（二层网络）的定义，如图。

首先要强调，Nerovs只是一个努力满足去中心化经济需求的区块链网络，并不负责解决“所有问题”。在我们的认知里，Layer1和Layer2的区别，关键在于共识的强弱。L1网络必须具有最广泛的共识，即“全球共识”。通过无需许可的全球共识，世界上任何人都可以参与到L1的共识过程中，最终Layer1可以作为去中心化经济的“锚”。从这个角度来讲，我们可以把L1称为“共识层”。

相比之下，L2网络的共识范围会小一些，其参与者可能仅来自某个国家，或某个行业，甚至是某家公司或机构，亦或是范围很小的社区。L2在共识范围上的牺牲是一种代价，换来了其他方面的进步，比如更高的TPS、更低的延迟和更好的可扩展性等。我们可以把L2称为“协议层”，而L1和L2之间往往通过跨链桥进行连通。

必须要强调，我们构建L2网络，目的并不仅仅是解决区块链的可扩展性问题，而是因为分层架构是让“模块化区块链”最容易落地的途径。所谓模块化区块链，就是将不同类型的问题投放到不同的模块中去解决。

很多人一直在讨论区块链的合规和监管问题，那么我们该如何将比特币或以太坊纳入现有的监管框架中？分层架构也许是解决该问题的一个答案。直接在Layer1层面添加迎合监管要求的业务逻辑，可能会破坏其去中心化和中立性，因此与合规相关的逻辑可以单独在Layer2上实现。

Layer2可以根据特定的法规或标准来定制，比如建立一个基于许可制的小型区块链，或是状态通道网络等东西。这样即实现了合规性，又不会影响到Layer1的去中心化和中立性。

另外，我们还可以通过分层架构解决安全性和用户体验之间的冲突。类比来说，如果你想保证自己的私钥安全，就要牺牲一定的便捷性，而区块链也是如此，如果你想保证区块链的绝对安全，就要牺牲一些东西，比如该链的性能等等。

但如果使用分层架构，我们就可以在L1网络上完全追求安全性，而在L2网络上牺牲少许安全性以换取更好的用户体验。比如我们可以在L2上使用状态通道来优化网络性能，降低延迟。所以说，Layer2的设计无非是安全性和用户体验之间的权衡。

上述内容自然而然地就引出了一个问题：是不是任何一条区块链都可以作为Layer1？

答案是否定的，首先我们必须明确，Layer1网络的去中心化和安全性高于一切，因为我们必须通过去中心化来实现抗审查。追求Layer1的安全，究其根本，是因为L1是整个区块链网络的根，是整个加密经济系统的锚。

在这样的评判标准下，比特币和以太坊无疑是最经典的L1网络，它们拥有极强的共识范围。除这二者之外，大多区块链都不满足L1的标准，共识程度较低。比如说，EOS的共识就不达标，只能充当一个L2网络，更何况它的一些规则只适用于其自身。

当前Layer1网络存在的问题

明确Layer1的定义后，我们要指出，现有的一些L1网络存在三个问题，这些问题即使在比特币和以太坊中，也一定程度上存在：

1.数据存储的公地悲剧问题

我们使用区块链时需要支付一定的费用，但在比特币的经济模型中，手续费结构设计中只考虑了计算成本和网络带宽成本，没有成熟地考虑数据存储成本。

比如用户向链上存储数据只需要支付一次费用，但存储期限却是永久的，所以人们可以滥用存储资源，将任何东西都永久上链，最终网络里的全节点要承担越来越高的存储成本。这带来了一个问题：任何节点运行者想参与进该网络中的成本，都会被最大限度地提升。

假设某区块链的状态/账户数据总计超过1TB，则不是每个人都能轻松同步完整的状态和交易历史。在这种情况下，就算你能同步到完整的状态，也很难再去自行验证对应的交易历史，这会削弱区块链的免信任性，而免信任恰恰是区块链最核心的价值观。

以太坊基金会意识到了上述问题，据此在EIP-103中加入了有关存储租赁制的设计，但是我们认为这不是最优的解决方案。

我们在Nervos中提出了全新的状态模型，称为“Cell”，可以看作是UTXO的一种扩展。在比特币UTXO的状态中，你能储存的只有比特币的余额数值，而Cell中可存储任意类型的数据，并将比特币UTXO的amount和integer value泛化为“Capacity”，用以指定Cell的最大存储容量。

通过这种方式，我们将CKB上原生资产的数量和状态大小绑定在一起。任何一个Cell占据的空间不能超过其容量限制，所以数据总量会保持在一定范围内。

而且我们通过较为合适的代币通胀率来确保状态数据的大小不会对节点运行者造成干扰。任何人都可以参与到CKB网络中，他们可以验证历史数据，也可以验证最终的状态是否有效，这就是CKB针对区块链中存储问题提出的解决方案。

2.Layer1饥饿问题

如果我们在Layer2上进行扩展，并将大量交易活动放到Layer2上进行，势必会导致Layer1上的交易数量下降，Layer1矿工/节点运行者的经济奖励也会相应降低。这样的话，Layer1矿工/节点运行者的积极性会下降，最终导致Layer1的安全性下降。这就是所谓的Layer1饥饿问题。

举个极端的例子，如果我们将所有的交易活动都转到L2，那么作为其根基的L1将不可持续。所以如何才能解决这个问题呢？

对此，我们要区分区块链网络中有哪些种类的用户，简单来说可分为Store of Value Users（SoV user，价值存储用户）和Utility Users（应用型用户）。

仍以CKB为例，SoV Users将原生资产CKB代币作为价值存储的手段，而Utility Users则利用Cell来存储状态。SoV Users对于CKB代币通胀导致的价格稀释是排斥的，而Utility User必须向矿工支付状态存储费用，该费用与数据存储的持续时间和占用空间成正比。

我们会在网络中持续发行新的CKB代币以制造固定的通胀率，并将其付给矿工，这就相当于稀释了Utility Users手中的代币价值（这就是CKB经济模型中三种发行模式之一的“二级发行”，该方式每年固定发行13.44亿枚CKB代币，具体内容可以查看《解读Stable++：RGB++ Layer首个稳定币协议正式启航》）。

该过程中SoV用户的资产同样被稀释，因此我们可以给他们一定的补贴抵消通胀损失（这就是后来的NervosDAO分成）。也就是说，矿工从CKB通胀中获得的收益，实际上只由Utility User来支付。很快我们将发行CKB的代币经济论文，相关问题在其中会详细说明。

基于这样的代币经济学设计，即使CKB链上没有任何交易活动，矿工也能获得报酬，进而我们可以与任何“价值存储层”或Layer2兼容。综上所述，我们通过有意为之的固定通胀，解决Layer1饥饿问题。

3.加密原语的缺乏

用户需要不同的加密原语，以使用不同的加密方式或不同的签名算法，比如Schnorr、BLS等。

想要成为一条Layer1区块链，必须考虑如何与Layer2进行互操作。以太坊社区中有些人提议使用ZK或Plasma的方式实现Layer2，但是如果没有ZK相关的原语，你如何在Layer1上完成验证呢？

另外，Layer1也要考虑与其他Layer1之间的互操作性。仍用以太坊举例，有人要求以太坊团队将Blake2b哈希函数预编译为EVM兼容的操作码。该提案的目的是将Zcash和以太坊进行桥接，以便用户在二者之间交易。上述提案虽然两年前就已经提出，但直到现在还没有实现，究其原因即缺乏对应的加密原语，这对Layer1的发展造成了严重阻碍。

为解决该问题，CKB构建了一个抽象程度很高的虚拟机，即CKB-VM，与比特币虚拟机和EVM截然不同。举个例子，比特币有一个专门的OP_CHECKSIG操作码，用于验证比特币交易中的secp256k1签名。而在CKB-VM中，secp256k1签名并不需要特殊处理，只需用户自定义的脚本或智能合约即可进行验证。

CKB也使用secp256k1作为其默认的签名算法，只不过是运行在 CKB-VM 中，而不是作为硬编码的加密原语。

CKB构建虚拟机的初衷是，在EVM等其他虚拟机中运行加密原语非常慢，所以要改善这种情况。单个secp256k1签名在EVM中的验证耗时大概是9毫秒，而使用相同的算法在CKB-VM计算，耗时仅为1毫秒，这是将近十倍的效率提升。

所以CKB-VM的价值在于，现在用户可以在其中自定义加密原语，且绝大多数可以被CKB-VM兼容，因为CKB-VM采用了RISC-V指令集，任何由GCC（GNU Compiler Collectio，一种广泛使用的编译器集合）编译的语言都可以在CKB上运行。

另外，CKB-VM的高度兼容性也提升了CKB的安全。正如开发者总说的“Don't implement your own version of crypto algorithms, you will always do it wrong”，自行定义加密算法往往会带来不可预见的安全风险。

总结一下，CKB网络使用各种方法，解决了我所提出的L1网络面临的三种问题，这就是CKB为什么可以称为一个合格的Layer1网络的原因。