导语：本文将前瞻性地介绍一种看起来有点特立独行的Web3基础设施设计范式——存储共识范式SCP( )，这种产品设计模式虽然在理论上，与以太坊等主流模块化区块链方案存在较大差异，但在落地简易度以及与Web2平台衔接的难易度上，可行性却很高，因为他从一开始就不打算像那样把自己限制在一个狭窄的实现路径上，想要以一种更宽泛、更开放的框架，将Web2平台与Web3设施融合起来，可以说是一个脑洞大开、颇具想象力的做法。
正文： 让我们设想一种公链扩容方案，具有下列特性：
- 拥有媲美传统Web2应用或交易所的速度，远超任何公链、L2、rollup、侧链等。
- 没有Gas费，使用成本几乎为0。
- 资金安全性高，远超中心化设施如交易所等，逊于Rollup但大于等于侧链。
- 与Web2相同的用户体验，无需对区块链的公私钥、钱包、基础设施等有任何认知。
这样的方案确实令人非常兴奋：一方面它在扩容上基本已经做到了极致；另一方面在Web3的mass 上也奠定了很坚实的基础，基本消除了Web2与Web3使用体验的鸿沟。
不过，我们似乎想不到多少方案能做到如此完备，因为主流讨论与实践确实太少。
我们在上面用扩容这个大家非常熟悉的议题作为引子，实际上 SCP并不仅限于扩容使用， 其设计灵感确实来源于比特币、以太坊等公链的扩容方案与社区讨论。而 它的愿景和实际应用是构建新一代的去信任化基础设施，甚至是非区块链结构的运算平台。
SCP基础组件和工作原理
一般而言， SCP也像以太坊和Celestia社区所说的“模块化区块链”一样， 具有数据可用性层、执行层、共识层、结算层等模块划分。
- 数据可用性层： 由一条被广泛认可且久经考验的公链来承担，或存储类设施作为数据可用性层，如以太坊、Arweave、Celestia等。
- 执行层： 一台服务器，用于接收用户交易并执行，同时将用户签名后的交易数据批量提交到DA层，与Rollup的排序器相似。但执行层并不一定要有区块链式的链表结构，它可以完全是Web2数据库+计算系统，但整个计算系统必须开源，具备透明度。
- 共识层： 由一群节点组成，它们拉取执行层提交到DA层上的数据，并用与执行层相同的算法，对这些数据进行运算，确认执行层的结果输出是否正确，并可以作为执行层的防灾冗余。用户也可以读取共识层各节点返回的数据，确保执行层没有欺诈行为。
- 结算层： 由一群节点与其他链上的合约或地址组成，用于处理用户充值进入SCP，或提现离开SCP的行为，有点类似于跨链桥的运作模式。结算层节点通过多签合约或基于TSS的地址，控制充值地址的提现功能。充值时用户向所在链的指定地址充入资产，提现时则发送请求，结算层节点读取到数据后，通过多签或TSS对资产放行。结算层的安全程度，取决于采用的跨链机制。
SCP的实践框架
我们可以通过如下框架，来理解SCP范式。一个满足SCP框架的产品，可以具备如充值、转账、提现、swap等主要功能，在此基础上还可以进一步扩展。下图是一个此类产品的原理图：
该项目的DA层使用了永久存储设施，即图中的大圆圈。协调者，即执行层。用户将交易提交至协调者，协调者执行运算并展现运算结果，然后将用户的原始输入数据批量提交至DA层。检测者，从上拉取协调者提交的交易原始数据，使用与协调者一致的算法，对数据和结果进行验证。检测者的客户端同样也是开源的，任何人都可以运行。守望者，掌管了提现系统多签的一组检测者。会根据交易数据对提现请求进行验证和放行。另外守望者也负责签署提案。
我们可以看到整套系统，他们达成的共识是全部位于链下的，这即存储共识范式的核心——它抛弃了区块链式的节点共识系统，让执行层摆脱繁重的共识交流和确认过程，只需要做好一台服务器的工作即可，从而达到近乎不受限制的TPS和经济性。这一点和非常类似，但SCP走向了和不同的道路，将其从一个扩容专属的用例，尝试转向为一种Web2到Web3的新的过渡模式。上面提及的协调者是一台服务器，但这并不意味着协调者可以为所欲为。和的排序器道理类似，在将用户提交的原始数据批量地在上提交后，任何人都可以运行检测者程序对其进行验证，并和协调者返回的状态进行对比。某种程度上，这和铭文类应用的思路如出一辙。在这种架构下，一个中心化的服务器、数据库并不构成根本的挑战。这也是SCP范式另一点，将“中心化”和“单一实体”这两个概念绑定解耦了——一个去信任化的体系里，可以有中心化组件，甚至可以是一个核心部件，但这并不影响整体上的去信任化。
我们可以喊出这样一个口号——“ 下一代去信任化基础设施不是非要依赖于共识协议，但应当是开源的系统与P2P节点网络 ”。人们发明和使用区块链的初衷是去信任化、账本一致、不可伪造、可溯源等等老生常谈的基本面，这在比特币白皮书里有明确阐述。 但在以太坊之后， 不论是旧公链的扩容方案，还是Rollup或模块化区块链， 大家都形成了思维定式：我们做的东西必须是一条区块链 （由节点的共识协议组成），或者是Rollup这种看起来是一条链的方案（只是有区块链的数据结构，但节点没有直接的共识消息互换）。但现在来看，基于SCP的框架下，即使不是区块链，也可以实现去信任化、账本一致、不可伪造、可溯源等等一系列需求，当然前提是要有更明确的实现细节。
执行层
执行层是在整个系统中是至关重要的，它承担了整个系统的运算过程，也决定了系统上可以运行怎样的应用。
无限可能的执行环境
理论上执行层中的执行环境可以做成任何形态，可能性是无穷无尽的，具体取决于项目方如何定位自己的项目：
- 交易所。基于SCP可以构建公开、透明的、高TPS的交易所，该交易所既可以有CEX迅速、0成本的特点，又保持了DEX的去中心化。CEX和DEX的分野在这里就变得模糊起来。
- 支付网络。类似于支付宝、PayPal等。
- 支持加载程序/合约的虚拟机/区块链。任意开发者可以部署任意的应用程序在其上，和其他程序共享所有用户的数据并根据用户的指令进行操作。
SCP这种支持任意执行环境的设计模式，有其独特的好处：不必再依赖于某些存在历史包袱的组件，尤其是像以太坊社区独创的“账户抽象”概念，对SCP来讲天生就不需要。而在SCP架构下，本身就不存在账户抽象的概念——你可以随意采用Web2标准账户和区块链账户等。从这个角度讲，许多成熟的Web2用例不需要重新思考和构建，就可以直接用于SCP上。这一点或许是SCP相比于的益处。
透明与非对称性
上面提到了账户系统，敏感的读者应该已经发现，SCP虽然可以利用Web2的账户体系，但原封不动地使用似乎也有问题。因为这整个系统，是完全透明的！直接使用用户对服务器的交互模型，会出现严重问题，导致整个系统毫无安全性可言。我们先回顾下传统的服务器-用户模型是如何工作的：
1.账号注册：用户在应用程序的注册页面输入用户名和密码。为保护用户的密码，服务器收到后会通过哈希函数来处理密码。为增加哈希的复杂性并抵御彩虹表攻击，通常会为每个用户的密码连接一个随机生成的字符串（称为“盐”），一起哈希处理。用户名、盐、哈希被明文存储在服务提供商的数据库中，并不对外公开。但即使如此，也需要做加盐和安全处理，一防内鬼，二防攻击。
2.用户登录：用户在登录表单上输入他们的用户名和密码。系统比对处理后的密码哈希值和数据库中存储的哈希值。如果两个哈希值匹配，表明用户提供了正确的密码，登录进程继续。
3.操作认证：登录验证通过后，系统会为用户创建一个会话。通常情况下，会话信息被存储在服务器上，并且服务器发送一个标识（例如或token）给用户的浏览器或应用。用户在接下来的操作中不再需要重复输入用户名和密码：浏览器或应用会保存标识，并在每个请求中附带标识，表明自己获得了关联的服务器的许可。
我们再回顾下典型的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范式的一个问题。
共识层
该层是由松散的节点组成，这些节点并不主动构成网络，因此不是严格意义的有共识的一层，而仅仅是用来向外界（如用户）确认当前执行层状态的。例如，如果你对这些节点的运行状态有所怀疑，可以下载其检测者客户端，其中会运行与协调者相同的程序代码。不过这和类似，由于数据是批量提交的，执行层给用户返回的状态总是比DA层上的更新的。这里面就涉及一个预确认的问题：执行层给用户的是预确认、软最终性的结果，因为还没有提交到DA层；而共识层给用户提供的是硬最终性。用户对此可能不是特别在意，不过对于跨链桥等应用，必须遵循硬最终性。比如，交易所的充提现系统是不会相信序列器在链下广播的数据的，必须要等这些数据上以太坊后，才认可。除了能用来确认结果以外，共识层还有一点很重要的作用，就是作为执行层的防灾冗余。如果执行层永久**、严重作恶，这个时候理论上任意的共识层都可以接手执行层的工作，接收用户的请求。如果发生如此严重的情况，社区应该会选择出稳定可靠的节点来作为执行层的服务器。
结算层
由于SCP并不是Rollup，所以无法做到像Rollup的提现结算层那样，不需要人工介入、完全基于密码学和智能合约代码的去信任化提现。 SCP跨链桥的安全程度是与侧链或第三方见证人跨链桥相同的， 需要依赖有权限的多签管理者为资产放行，我们称为见证人模式。
将见证人桥做的尽可能去中心化，是很多跨链桥研究的议题。篇幅所限这里就不具体展开了。一个设计良好的SCP平台，在实践中也必须有信誉良好的去中心化桥的多签合作方。 有人可能会问SCP为什么不使用有智能合约的链作为DA层？ 这样可以做出给予合约，完全免信任的结算层。长远来看，只要克服一些技术困难，如果将DA层放到以太坊等有合约的DA层上，并能构建出相应的用于验证的合约，SCP也可以获得与Rollup相同的结算安全性，而不需要使用多签。
但实践中这未必是最优选择：
1.以太坊并不专门用于数据保存，相对于纯粹的数据存储公链来说价格太高。而对于SCP范式来讲，足够低的或者固定的存储成本是至关重要的。只有这样才可能支撑的起Web2级别的吞吐量。
2. 证明系统非常难以开发，因为SCP中不光可以模拟EVM，而可以实现任何逻辑。 而我们看大像Optimism这种团队目前其欺诈证明仍然没有上线，以及zkEVM的开发难度，就可以想象在以太坊上想实现各式各样的系统的证明，是难度极高的一件事。
所以这个方案只在特定的情况下，才有更优秀的实践可行性，如果你打算实现一种更宽泛、更开放，摆脱EVM体系转而融入更多的Web2 ，则以太坊的思路并不合适。SCP并不是某种公链的扩容方案，而是一种更大的Web3计算平台架构，所以显然不需要走以太坊的思路。
一张图对比SCP与其他范式
