长推:从分布式应用角度聊聊 Web3

原文作者:jolestar

原文来源:Twitter

前面写过两篇 Twitter 分别从 Web2 视角以及 AI 视角分析了 Web3,今天这篇从分布式应用角度聊聊 Web3。这个正好是我前两天在 ETH 上海升级圆桌会上谈到的观点,昨天的 #ETHBeijing Hackathon 圆桌上刚好也有人问,这里详述一下。

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

如下图中,是一个典型的 Web2 三层应用。用户发送请求,业务逻辑校验用户的请求,然后修改状态存储到数据库中。(图片来自 aws 文档)

Web3

这个应用要实现分布式,第一步需要先把用户的每个请求记录到日志里,然后通过一个全局的分布式日志系统同步到其他机房的节点,然后重新执行这个请求。这样这个应用就变成了一个多机房的分布式应用。4/n

Web3当然,上面是一个简化的系统,如果让一个大型的 Web2 的应用支持多机房,并没有这么简单。下图是一个更真实的案例,它是混合了多种分布式方案来构成的一个分布式系统。大家不用关心细节,只需要感受它的复杂度(图片来自zhihu)5/n

Web3

Web2 应用实现分布式的复杂度在于: Web2 应用是围绕着一个“活“数据库构建出来的,很难通过一个统一的入口来记录所有系统状态的修改。 即便是拦截了所有的状态操作,重新执行的时候也很难保证执行的结果是一致的。 6/n1307

如果从应用角度出发,如何利用已有的去中心化基础设施,来解决应用的分布式以及去中心化难题?一个去中心化应用的潜台词是它首先已经是一个分布式应用。

应用要去中心化,首先要保证的是应用的程序可公开获取,应用的数据可公开获取,这样别人才能验证结果。第一个可以通过开源实现,第二个就需要把前面的全局的分布式日志系统换成一个公开的,不可篡改的去中心化日志系统。

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

那如果第三方重新执行交易得到的结果和应用方不一样怎么办?那就需要一套机制,来保证交易状态变化的正确性。这个可以通过欺诈证明的挑战机制或者 ZK 的有效证明,都需要依赖一个可以执行验证程序的可信第三方,正好当前的 Layer1 智能合约可以承担这个职责。

应用中需要构建商业模式,需要不同的资产或者货币支持从哪里来?银行当然无法直接接入去中心化系统,但应用可以很容易和不同的链或者其他应用之间建立结算协议(当然不同结算方式的安全性有差异)。

前面提到的如何保证应用的统一更新机制以及确定性,我们可以完全复用区块链演化出的架构方案: 所有的写操作都必须通过执行交易进行,保证有统一的更新日志。 业务逻辑要保证确定性,需要对传统语言进行裁剪,或者用一种新的智能合约语言进行编写。

基于前面提到的应用角度的思路,Rooch 提供了以下方案:

1. 开发者完全通过 Move 语言编写应用,可以叫做 Fully InContract DApp。之所以选择 Move,一方面是保证业务逻辑的确定性,另外一方面是它的平台无关性。其他的特性可以参看我以前的文章。 https://jolestar.com/why-move-1/

2. 给 Move DApp 提供一个容器,容器托管了和 DA,和其他链的结算,以及仲裁层的交互,实现应用的去中心化,这就是 Rooch 容器。

3. 基于 Rooch 容器运行一个 ETH Layer2 网络,由 Ethereum 保证安全,给应用提供低成本的全局注册,以及仲裁和资产结算服务。详细内容参看 https://jolestar.com/the-modular-evolution-of-rollup-layer2/… 14/n1522

那我们继续沿着这个思路,还能有哪些应用构建的思路: 联邦模型的改进。类似于 mastodon 这样的去中心化 twitter,如果和 L1/L2 结合起来,利用一个全局注册表将用户和节点的关系记录在里面,就可以让用户和节点解除绑定关系。用户如果不满意某个节点的服务,可以发起交易,迁移到别的节点。

去中心化的服务发现。将服务注册到智能合约的全局注册表中,任何人都可以运行节点提供某种协议的服务,应用可以通过服务发现机制自动筛选,而不是强绑定到一个服务提供方,还可以同时有付费协议。比如 ETH 的 RPC 节点服务。

这些方向可以继续发挥,欢迎继续讨论。如果从这个角度思考,构建应用的时候,我们就会着眼于解决应用的问题,应用发展的不同阶段也可以采用不同的方案。比如开始的时候应用可能不是去中心化的,但它用这套方式架构出来,可以保证随时可以切换为去中心化应用。

长期以来,区块链领域主要是基础设施叙事,但基础设施能带来的使用价值是有限的,更多的使用价值需要应用来创造。而随着技术的发展,我们认为基础设施即将准备好,期待一个以应用为中心的 Web3 舞台的开幕。

Web3 系列:

1. Web2 视角的 Web3 https://twitter.com/jolestar/status/1589830650659753986…

2. AI 视角的 Web3 https://twitter.com/jolestar/status/1628605829707608064…

3. 分布式应用视角的 Web3

转载声明:本文 由CoinON抓取收录,观点仅代表作者本人,不代表CoinON资讯立场,CoinON不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。若以此作为投资依据,请自行承担全部责任。

声明:图文来源于网络,如有侵权请联系删除

风险提示:投资有风险,入市需谨慎。本资讯不作为投资理财建议。

(0)
打赏 微信扫一扫 微信扫一扫
上一篇 2023年4月10日 下午3:28
下一篇 2023年4月10日 下午3:28

相关推荐

长推:从分布式应用角度聊聊 Web3

星期一 2023-04-10 15:28:55

前面写过两篇 Twitter 分别从 Web2 视角以及 AI 视角分析了 Web3,今天这篇从分布式应用角度聊聊 Web3。这个正好是我前两天在 ETH 上海升级圆桌会上谈到的观点,昨天的 #ETHBeijing Hackathon 圆桌上刚好也有人问,这里详述一下。

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

如下图中,是一个典型的 Web2 三层应用。用户发送请求,业务逻辑校验用户的请求,然后修改状态存储到数据库中。(图片来自 aws 文档)

Web3

这个应用要实现分布式,第一步需要先把用户的每个请求记录到日志里,然后通过一个全局的分布式日志系统同步到其他机房的节点,然后重新执行这个请求。这样这个应用就变成了一个多机房的分布式应用。4/n

Web3当然,上面是一个简化的系统,如果让一个大型的 Web2 的应用支持多机房,并没有这么简单。下图是一个更真实的案例,它是混合了多种分布式方案来构成的一个分布式系统。大家不用关心细节,只需要感受它的复杂度(图片来自zhihu)5/n

Web3

Web2 应用实现分布式的复杂度在于: Web2 应用是围绕着一个“活“数据库构建出来的,很难通过一个统一的入口来记录所有系统状态的修改。 即便是拦截了所有的状态操作,重新执行的时候也很难保证执行的结果是一致的。 6/n1307

如果从应用角度出发,如何利用已有的去中心化基础设施,来解决应用的分布式以及去中心化难题?一个去中心化应用的潜台词是它首先已经是一个分布式应用。

应用要去中心化,首先要保证的是应用的程序可公开获取,应用的数据可公开获取,这样别人才能验证结果。第一个可以通过开源实现,第二个就需要把前面的全局的分布式日志系统换成一个公开的,不可篡改的去中心化日志系统。

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

那如果第三方重新执行交易得到的结果和应用方不一样怎么办?那就需要一套机制,来保证交易状态变化的正确性。这个可以通过欺诈证明的挑战机制或者 ZK 的有效证明,都需要依赖一个可以执行验证程序的可信第三方,正好当前的 Layer1 智能合约可以承担这个职责。

应用中需要构建商业模式,需要不同的资产或者货币支持从哪里来?银行当然无法直接接入去中心化系统,但应用可以很容易和不同的链或者其他应用之间建立结算协议(当然不同结算方式的安全性有差异)。

前面提到的如何保证应用的统一更新机制以及确定性,我们可以完全复用区块链演化出的架构方案: 所有的写操作都必须通过执行交易进行,保证有统一的更新日志。 业务逻辑要保证确定性,需要对传统语言进行裁剪,或者用一种新的智能合约语言进行编写。

基于前面提到的应用角度的思路,Rooch 提供了以下方案:

1. 开发者完全通过 Move 语言编写应用,可以叫做 Fully InContract DApp。之所以选择 Move,一方面是保证业务逻辑的确定性,另外一方面是它的平台无关性。其他的特性可以参看我以前的文章。 https://jolestar.com/why-move-1/

2. 给 Move DApp 提供一个容器,容器托管了和 DA,和其他链的结算,以及仲裁层的交互,实现应用的去中心化,这就是 Rooch 容器。

3. 基于 Rooch 容器运行一个 ETH Layer2 网络,由 Ethereum 保证安全,给应用提供低成本的全局注册,以及仲裁和资产结算服务。详细内容参看 https://jolestar.com/the-modular-evolution-of-rollup-layer2/… 14/n1522

那我们继续沿着这个思路,还能有哪些应用构建的思路: 联邦模型的改进。类似于 mastodon 这样的去中心化 twitter,如果和 L1/L2 结合起来,利用一个全局注册表将用户和节点的关系记录在里面,就可以让用户和节点解除绑定关系。用户如果不满意某个节点的服务,可以发起交易,迁移到别的节点。

去中心化的服务发现。将服务注册到智能合约的全局注册表中,任何人都可以运行节点提供某种协议的服务,应用可以通过服务发现机制自动筛选,而不是强绑定到一个服务提供方,还可以同时有付费协议。比如 ETH 的 RPC 节点服务。

这些方向可以继续发挥,欢迎继续讨论。如果从这个角度思考,构建应用的时候,我们就会着眼于解决应用的问题,应用发展的不同阶段也可以采用不同的方案。比如开始的时候应用可能不是去中心化的,但它用这套方式架构出来,可以保证随时可以切换为去中心化应用。

长期以来,区块链领域主要是基础设施叙事,但基础设施能带来的使用价值是有限的,更多的使用价值需要应用来创造。而随着技术的发展,我们认为基础设施即将准备好,期待一个以应用为中心的 Web3 舞台的开幕。

Web3 系列:

1. Web2 视角的 Web3 https://twitter.com/jolestar/status/1589830650659753986…

2. AI 视角的 Web3 https://twitter.com/jolestar/status/1628605829707608064…

3. 分布式应用视角的 Web3