解读SCP：跳出Rollup定式的去信任化基础设施范式

作者：雾月，极客Web3

导语：本文将前瞻性地介绍一种看起来有点特立独行的Web3基础设施设计范式——存储共识范式SCP(Storage-based Consensus Paradigm)，这种产品设计模式虽然在理论上，与以太坊Rollup等主流模块化区块链方案存在较大差异，但在落地简易度以及与Web2平台衔接的难易度上，可行性却很高，因为他从一开始就不打算像Rollup那样把自己限制在一个狭窄的实现路径上，想要以一种更宽泛、更开放的框架，将Web2平台与Web3设施融合起来，可以说是一个脑洞大开、颇具想象力的做法。

正文：让我们设想一种公链扩容方案，具有下列特性：

• 拥有媲美传统Web2应用或交易所的速度，远超任何公链、L2、rollup、侧链等。

• 没有Gas费，使用成本几乎为0。

• 资金安全性高，远超中心化设施如交易所等，逊于Rollup但大于等于侧链。

• 与Web2相同的用户体验，无需对区块链的公私钥、钱包、基础设施等有任何认知。

这样的方案确实令人非常兴奋：一方面它在扩容上基本已经做到了极致；另一方面在Web3的mass adoption上也奠定了很坚实的基础，基本消除了Web2与Web3使用体验的鸿沟。

不过，我们似乎想不到多少方案能做到如此完备，因为主流讨论与实践确实太少。

我们在上面用扩容这个大家非常熟悉的议题作为引子，实际上SCP并不仅限于扩容使用，其设计灵感确实来源于比特币、以太坊等公链的扩容方案与社区讨论。而它的愿景和实际应用是构建新一代的去信任化基础设施，甚至是非区块链结构的运算平台。

SCP基础组件和工作原理

一般而言，SCP也像以太坊和Celestia社区所说的“模块化区块链”一样，具有数据可用性层、执行层、共识层、结算层等模块划分。

• 数据可用性层：由一条被广泛认可且久经考验的公链来承担，或存储类设施作为数据可用性层，如以太坊、Arweave、Celestia等。

• 执行层：一台服务器，用于接收用户交易并执行，同时将用户签名后的交易数据批量提交到DA层，与Rollup的排序器相似。但执行层并不一定要有区块链式的链表结构，它可以完全是Web2数据库+计算系统，但整个计算系统必须开源，具备透明度。

• 共识层：由一群节点组成，它们拉取执行层提交到DA层上的数据，并用与执行层相同的算法，对这些数据进行运算，确认执行层的结果输出是否正确，并可以作为执行层的防灾冗余。用户也可以读取共识层各节点返回的数据，确保执行层没有欺诈行为。

• 结算层：由一群节点与其他链上的合约或地址组成，用于处理用户充值进入SCP，或提现离开SCP的行为，有点类似于跨链桥的运作模式。结算层节点通过多签合约或基于TSS的地址，控制充值地址的提现功能。充值时用户向所在链的指定地址充入资产，提现时则发送请求，结算层节点读取到数据后，通过多签或TSS对资产放行。结算层的安全程度，取决于采用的跨链机制。

SCP的实践框架

我们可以通过如下框架，来理解SCP范式。一个满足SCP框架的产品，可以具备如充值、转账、提现、swap等主要功能，在此基础上还可以进一步扩展。下图是一个此类产品的原理图：

• 该项目的DA层使用了永久存储设施Arweave，即图中的大圆圈。

• 协调者Coordinator，即执行层。用户将交易提交至协调者，协调者执行运算并展现运算结果，然后将用户的原始输入数据批量提交至DA层。

• 检测者Detector，从Arweave上拉取协调者提交的交易原始数据，使用与协调者一致的算法，对数据和结果进行验证。检测者的客户端同样也是开源的，任何人都可以运行。

• 守望者Watchmen，掌管了提现系统多签的一组检测者。会根据交易数据对提现请求进行验证和放行。另外守望者也负责签署提案。

我们可以看到整套系统，他们达成的共识是全部位于链下的，这即存储共识范式的核心——它抛弃了区块链式的节点共识系统，让执行层摆脱繁重的共识交流和确认过程，只需要做好一台服务器的工作即可，从而达到近乎不受限制的TPS和经济性。这一点和Rollup非常类似，但SCP走向了和Rollup不同的道路，将其从一个扩容专属的用例，尝试转向为一种Web2到Web3的新的过渡模式。

上面提及的协调者是一台服务器，但这并不意味着协调者可以为所欲为。和Rollup的排序器道理类似，在将用户提交的原始数据批量地在Arweave上提交后，任何人都可以运行检测者程序对其进行验证，并和协调者返回的状态进行对比。某种程度上，这和铭文类应用的思路如出一辙。

在这种架构下，一个中心化的服务器、数据库并不构成根本的挑战。这也是SCP范式另一点，将“中心化”和“单一实体”这两个概念绑定解耦了——一个去信任化的体系里，可以有中心化组件，甚至可以是一个核心部件，但这并不影响整体上的去信任化。

我们可以喊出这样一个口号——“下一代去信任化基础设施不是非要依赖于共识协议，但应当是开源的系统与P2P节点网络”。

人们发明和使用区块链的初衷是去信任化、账本一致、不可伪造、可溯源等等老生常谈的基本面，这在比特币白皮书里有明确阐述。但在以太坊之后，不论是旧公链的扩容方案，还是Rollup或模块化区块链，大家都形成了思维定式：我们做的东西必须是一条区块链（由节点的共识协议组成），或者是Rollup这种看起来是一条链的方案（只是有区块链的数据结构，但节点没有直接的共识消息互换）。

但现在来看，基于SCP的框架下，即使不是区块链，也可以实现去信任化、账本一致、不可伪造、可溯源等等一系列需求，当然前提是要有更明确的实现细节。

执行层

执行层是在整个系统中是至关重要的，它承担了整个系统的运算过程，也决定了系统上可以运行怎样的应用。

无限可能的执行环境

理论上执行层中的执行环境可以做成任何形态，可能性是无穷无尽的，具体取决于项目方如何定位自己的项目：

• 交易所。基于SCP可以构建公开、透明的、高TPS的交易所，该交易所既可以有CEX迅速、0成本的特点，又保持了DEX的去中心化。CEX和DEX的分野在这里就变得模糊起来。

• 支付网络。类似于支付宝、PayPal等。

• 支持加载程序/合约的虚拟机/区块链。任意开发者可以部署任意的应用程序在其上，和其他程序共享所有用户的数据并根据用户的指令进行操作。

SCP这种支持任意执行环境的设计模式，有其独特的好处：不必再依赖于某些存在历史包袱的组件，尤其是像以太坊社区独创的“账户抽象”概念，对SCP来讲天生就不需要。

而在SCP架构下，本身就不存在账户抽象的概念——你可以随意采用Web2标准账户和区块链账户等。从这个角度讲，许多成熟的Web2用例不需要重新思考和构建，就可以直接用于SCP上。这一点或许是SCP相比于Rollup的益处。

透明与非对称性

上面提到了账户系统，敏感的读者应该已经发现，SCP虽然可以利用Web2的账户体系，但原封不动地使用似乎也有问题。

因为这整个系统，是完全透明的！直接使用用户对服务器的交互模型，会出现严重问题，导致整个系统毫无安全性可言。我们先回顾下传统的服务器-用户模型是如何工作的：

1.账号注册：用户在应用程序的注册页面输入用户名和密码。为保护用户的密码，服务器收到后会通过哈希函数来处理密码。为增加哈希的复杂性并抵御彩虹表攻击，通常会为每个用户的密码连接一个随机生成的字符串（称为“盐”），一起哈希处理。用户名、盐、哈希被明文存储在服务提供商的数据库中，并不对外公开。但即使如此，也需要做加盐和安全处理，一防内鬼，二防攻击。

2.用户登录：用户在登录表单上输入他们的用户名和密码。系统比对处理后的密码哈希值和数据库中存储的哈希值。如果两个哈希值匹配，表明用户提供了正确的密码，登录进程继续。

3.操作认证：登录验证通过后，系统会为用户创建一个会话。通常情况下，会话信息被存储在服务器上，并且服务器发送一个标识（例如cookie或token）给用户的浏览器或应用。用户在接下来的操作中不再需要重复输入用户名和密码：浏览器或应用会保存cookie标识，并在每个请求中附带标识，表明自己获得了cookie关联的服务器的许可。

我们再回顾下典型的Web3的区块链-用户交互体系：

1.账户注册：实际上没有账户注册这一过程，也没有用户名-密码体系。账户（地址）不需要注册，天然存在，谁掌握其私钥谁控制该账户。私钥由钱包在本地随机生成，也不涉及联网过程。

2.用户登录：区块链的使用并不需要登录，大部分dApp没有登录这个过程，而是连接钱包。有的dApp在连接钱包后,会要求用户进行签名验证，确保用户真的持有私钥，而不是仅仅是向前端传了个钱包地址。

3.操作认证：用户直接向节点提交签名后的数据，节点验证后会向整个区块链网络广播该交易，满足区块链网络共识后用户的操作即被确认。

两种模式的差异是由对称和非对称导致的。在服务器-用户架构中，双方掌握相同的秘密。在区块链-用户架构中，只有用户掌握秘密。

SCP的执行层虽然可以不是区块链，但所有的数据又需要同步到公开可见的DA层，因此SCP所使用的登录、操作的验证方式必须是非对称的。但又因为不想有让用户保管私钥、使用钱包等影响大规模采用的累赘动作和较差体验，在SCP上构建的应用使用传统的ID密码或者OAuth三方认证登录的需求也很强，那么如何结合二者呢？

由于非对称密码学和零知识证明对具有不对称性，我设想了两种可能的方案：

• 如果想使用ID-密码体系，可以将这个保存密码的模块不做进SCP中，这样其他人也就不可见。SCP执行层内部依然使用区块链的公私钥账户和操作逻辑，没有注册，没有登录等。用户的ID实际上会对应一个私钥。这个私钥当然不能保存在项目方，比较可行的方案是使用2-3的MPC来解决中心化存储的问题，同时又不让用户有使用私钥的累赘。

• 当依赖OAuth登录时，可以利用JWT（Json Web Token）可以作为身份认证的方式。这个方式会比上面的显得稍微中心化一些，因为它本质上需要依靠Web2大厂提供的第三方登录服务作为身份认证。

  第一次使用第三方登录时，将JWT中表征用户身份和服务商身份的字段注册在系统内。在用户的后续操作中，将操作指令作为public input，而JWT整体作为一个secret witness，用ZKP验证每一笔用户的交易。

  每个JWT有过期时限，用户下次登录时也会申请新的JWT，所以无需永久保管。另外这个系统内还需要依赖JWK，这里可以理解为大厂为验证JWK提供的公钥。那么JWK去中心化地如何输入到系统内，日后应对私钥轮替的方法等，也值得探讨。

不论使用哪种方式，都比传统方式的开发和运算的成本都要高一些，但这也是去中心化所付出的必要代价。当然，项目方如果并不认为做到极致的去中心化是必要的，或者在开发的不同阶段有不同的milestone，没有这些设计也是可以的，因为去中心化不是非黑即白，而是存在中间的灰色区域。

隐私性

上面提到的透明的问题，不仅对用户的交互范式造成影响，也会对用户数据造成影响。用户的数据都是直接暴露的。虽然在区块链中不是问题，但这在某些应用中是不太能接收的，所以开发者也可以构建隐私交易系统。

收费

执行层如何收费是另一个值得关注的点。因为向DA层提交数据也需要成本，包括自身服务器的运行等。传统区块链向用户收取gas费的第一个核心目的是避免用户刷大量重复的交易来破坏交易网络，第二个才是根据gas来排序交易。Web2没有类似的担忧，所以只有洪水、DDoS这些基本的概念。

执行层可以自定义各种的收费策略，比如完全免费或部分收费，也可以从其他的行为如MEV（在排序器中已经非常成熟），市场活动等进行获利。

抗审查性

执行层不具备抗审查性，理论上可以无限制地拒绝用户的交易。在Rollup中抗审查性可以由L1合约的强制归集功能来保证，而侧链或公链是完整的分布式区块链网络，也难以进行审查。

目前并没有明确的方案来解决抗审查问题，是SCP范式的一个问题。

共识层

该层是由松散的节点组成，这些节点并不主动构成网络，因此不是严格意义的有共识的一层，而仅仅是用来向外界（如用户）确认当前执行层状态的。

例如，如果你对这些节点的运行状态有所怀疑，可以下载其检测者客户端，其中会运行与协调者相同的程序代码。

不过这和Rollup类似，由于数据是批量提交的，执行层给用户返回的状态总是比DA层上的更新的。这里面就涉及一个预确认的问题：

执行层给用户的是预确认、软最终性的结果，因为还没有提交到DA层；

而共识层给用户提供的是硬最终性。用户对此可能不是特别在意，不过对于跨链桥等应用，必须遵循硬最终性。比如，交易所的充提现系统是不会相信Rollup序列器在链下广播的数据的，必须要等这些数据上以太坊后，才认可。

除了能用来确认结果以外，共识层还有一点很重要的作用，就是作为执行层的防灾冗余。如果执行层永久罢工、严重作恶，这个时候理论上任意的共识层都可以接手执行层的工作，接收用户的请求。如果发生如此严重的情况，社区应该会选择出稳定可靠的节点来作为执行层的服务器。

结算层

由于SCP并不是Rollup，所以无法做到像Rollup的提现结算层那样，不需要人工介入、完全基于密码学和智能合约代码的去信任化提现。SCP跨链桥的安全程度是与侧链或第三方见证人跨链桥相同的，需要依赖有权限的多签管理者为资产放行，我们称为见证人模式。

将见证人桥做的尽可能去中心化，是很多跨链桥研究的议题。篇幅所限这里就不具体展开了。一个设计良好的SCP平台，在实践中也必须有信誉良好的去中心化桥的多签合作方。

有人可能会问SCP为什么不使用有智能合约的链作为DA层？这样可以做出给予合约，完全免信任的结算层。

长远来看，只要克服一些技术困难，如果将DA层放到以太坊等有合约的DA层上，并能构建出相应的用于验证的合约，SCP也可以获得与Rollup相同的结算安全性，而不需要使用多签。

但实践中这未必是最优选择：

1.以太坊并不专门用于数据保存，相对于纯粹的数据存储公链来说价格太高。而对于SCP范式来讲，足够低的或者固定的存储成本是至关重要的。只有这样才可能支撑的起Web2级别的吞吐量。

2.证明系统非常难以开发，因为SCP中不光可以模拟EVM，而可以实现任何逻辑。而我们看大像Optimism这种团队目前其欺诈证明仍然没有上线，以及zkEVM的开发难度，就可以想象在以太坊上想实现各式各样的系统的证明，是难度极高的一件事。

所以Rollup这个方案只在特定的情况下，才有更优秀的实践可行性，如果你打算实现一种更宽泛、更开放，摆脱EVM体系转而融入更多的Web2 feature，则以太坊Rollup的思路并不合适。

SCP并不是某种公链的扩容方案，而是一种更大的Web3计算平台架构，所以显然不需要走以太坊Layer2的思路。

一张图对比SCP与其他范式