分布式应用视角的 Web3

如果从分布式应用的角度看，Web3 最值得讨论的不是 Token，而是它到底提供了一套什么新的分布式基础设施。

在传统分布式应用中，我们一般会依赖 Paxos 或者 Raft 这样的共识基础设施，来解决全局元数据存储、全局锁、服务发现、事件订阅等问题。但我们并不会把所有数据都放进共识系统中。

如下图，是一个典型的 Web2 三层应用：用户发起请求，业务逻辑校验请求，再把状态写入数据库。

如果这个应用要支持多机房分布式部署，一个常见思路是：先把用户请求记录到日志里，再通过一个全局分布式日志系统同步到其他机房节点，然后在其他节点重新执行这个请求。这样，系统才逐渐变成一个真正的分布式应用。

当然，这只是一个简化模型。真实的大型 Web2 应用，通常会混合多种分布式方案，复杂度会高得多。

Web2 应用实现分布式，难点主要在两件事上：

1. Web2 应用通常围绕一个“活数据库”长出来，很难通过统一入口记录所有状态修改。
2. 即便拦截了全部状态操作，重新执行时也很难保证结果绝对一致。

那如果从应用角度出发，如何利用已有的去中心化基础设施去解决这些问题？一个去中心化应用的潜台词，其实是：它首先必须已经是一个分布式应用。

应用要去中心化，至少要保证两件事：

1. 应用程序本身可公开获取。
2. 应用数据可公开获取。

第一点可以通过开源实现，第二点则意味着：原来那个全局分布式日志系统，需要换成一个公开的、不可篡改的去中心化日志系统。

这样一来，任何人都可以通过重新执行账本中的交易日志来得到最新状态。而这个去中心化日志系统，本质上就是 Sequencer 和 DA 要解决的问题：它们一起保证交易顺序以及数据的公开可用。

但如果第三方重新执行交易，得到的结果和应用方不一样怎么办？那就还需要一套机制来保证状态变化的正确性。这个可以通过欺诈证明的挑战机制，或者 ZK 的有效性证明来解决。而无论是哪条路线，都需要一个可以执行验证程序的可信第三方，这正好也是当前 Layer1 智能合约可以承担的职责。

如果顺着这个视角看，Web3 的意义就会更具体一些：它不是简单地在应用上层再加一层 Token，而是在尝试用一套公开、可验证、可重放的方式，把传统分布式系统里那些依赖内部信任和私有协调系统的部分替换掉。

从这个角度理解，很多 Web3 基础设施其实都可以理解成一种新的分布式系统基础设施。它关心的，不只是性能和一致性，还额外关心 Permissionless 和可验证性。