从无服务器到 Web3

1.jpeg

无服务器应用开发团队,例如「知晓云」无服务器应用开发团队,一直享受着无需管理服务器节点、内存和带宽分配等较低层次资源的管理优势。随着 dApp和区块链的兴起,dApp开发者也正在用类似的模式使用区块链网络提供

无服务器应用开发团队,例如「知晓云」无服务器应用开发团队,一直享受着无需管理服务器节点、内存和带宽分配等较低层次资源的管理优势。随着 dApp 和区块链的兴起,dApp 开发者也正在用类似的模式使用区块链网络提供的 API,而无需担心底层计算资源。本文探索区块链和无服务器应用开发的相似和不同,试图为无服务器应用开发团队进入 web3 产品开发提供启发。

两者的异同

表面上看,区块链和无服务器计算资源的组织和服务模型似乎没有什么相似之处。 Serverless 是无状态的,区块链是有状态的;无服务器的数据处理是临时的,区块链的数据是持久的;无服务器处理依赖于应用程序开发人员和无服务器提供商之间的信任; 区块链旨在通过无信任模型获得信任;无服务器的扩展成本较低,而区块链的扩展成本较高,因为要在去中心化、安全性和性能之间进行权衡。

仔细观察,无服务器和区块链有很多相似之处。例如,两者都是为事件驱动和高度分布式的应用程序设计的。它们都将客户端代码作为函数处理——在服务器级别之上的抽象层中运行。它们在应用程序状态持久性方面相互补充。无服务器通常不保留应用程序状态,或为此目的依赖单独的数据库服务器。区块链可以用作验证交易的状态机。

dApp 同时依赖链上和链下处理

区块链处理模型与无服务器处理有很大不同。大多数无服务器平台不仅支持多种语言,而且无服务器处理的目标是一次性处理。

在并发基础上,处理相同的事务与无服务器处理理念是对立的。然而,在区块链平台中,这种并发的相同处理模型是一个关键特性——确保和维护区块链作为交易历史和当前状态的经过验证和可信的来源。

鉴于区块链处理的封闭性,没有必要——也没有任何入口方式——为执行智能合约而对链上交易进行无服务器处理。然而,处理链下交易的需求巨大——尤其是在配置交易、帮助完善交易和解决交易后的工作流方面。

为什么会有这样的链下交易需求?原因是:

链上处理能力严重受限

链上数据存储受到严重限制

因此,对于复杂和/或数据量大的交易,需要进行链下数据处理。

dApp 同时依赖链上和链下数据发挥价值

为了使依赖于区块链的有效 dApp 发挥其有限的功能,需要将链上交易逻辑保持在最低限度,以实现有效的交易吞吐量。使用区块链的成本机制,即为区块链处理交易和运营网络提供奖励的机制——也将 dApp 的交易成本施加在区块链上。

如果没有为交易处理收取的「gas」费用,交易方将在区块链网络上吃免费大餐。此外,它们的计算需求可能会压垮区块链网络的总容量——非常类似于对传统网站的 DDoS 攻击。

为了达到每笔交易的最佳性能、低成本和一致性,区块链应用需要同时满足链上和链下业务逻辑的计算要求。这也适用于处理链上和链下数据。因此,有效的区块链设计意味着仅使用区块链网络进行最少量的数据处理和数据存储,以完善和保存交易。

区块链和无服务器在数据处理方面也可以互为补充。由于 dApp 依赖链上和链下处理,它们之间的分离意味着应用程序的链下部分必须能够配置交易并管理任何后处理需求。请记住,区块链提供了受信任的交易日志——但使用该交易的各方确实需要在链上这样做。

在链上存储数据的限制也对无服务器处理有影响。任何支持交易的数据都需要作为交易的一部分进行数字化保存和链接——就像在区块链中记录为已签署的实际智能合约一样。正在开发的服务,以及某些公链上,同时执行此功能的技术已出现,目前称为「Data Oracle」。例如,BandChain 是一种高性能的公链,它允许任何人对传统网络上可用的 API 和服务提出请求。它建立在 Cosmos SDK 之上,并利用 Tendermint 的拜占庭容错共识算法来立即确定。在获得足够数量的区块验证者的确认后,特别是达到了最终确定性。对于私有区块链(或联盟区块链)网络,无服务器处理的潜在候选者包括准备数据、验证数据和访问数据后处理。

链上处理与链下处理之间的差异很大程度上取决于使用同一应用程序的不同用户角色/方之间的信任级别。链上处理被设计为无需信任——这意味着各方不必为了执行交易而相互信任。由一方在无服务器环境中执行的境外处理适用于以下情况:1) 没有交易受到影响,2) 两方或多方相互信任以放弃任何类型的共识算法,或 3) 有共识算法用于验证链下处理的结果。这就是 Data Oracle 作为公链的新附加功能发挥作用的地方。

事件驱动架构的普及是催化剂

区块链和无服务器处理是两个截然不同的独立技术创新,但它们有许多共同点。虽然无服务器旨在实现无状态,但区块链提供了一种公开且独立可验证的方式来维护业务和事务的状态。

随着越来越多的软件应用设计模式演变为事件驱动架构,对独立可验证事务状态的需求将会增加——无服务器和区块链将更有可能一起使用。这种组合的用例在私有和/或公链中尤其适用,在这些区块链中,信任级别更高,外部组件和服务的使用者更能容忍。

以 BandChain 为例,它充当智能合约平台、dApp 和各种数据提供者之间运行的中间层。如下图所示,只有事件驱动的架构才能将基于区块链和无服务器构建的应用程序粘合在一起。在这种情况下,Data Oracle 的工作是 1) 处理来自 dApp 的数据请求,2) 从相应的提供者那里查询数据,以及 3) 将结果报告给应用程序。

Data Oracle 工作原理示例

展望未来,无服务器和区块链应用模式之间的差异和相似之处表明,当应用程序或 dApp 建立在两者之上时,两者是可以互为补充并实现两全其美的。 dApps 尤其受益于事件驱动和 Data Oracle 设计范式,而这正是 web2 和 web3 世界得以融合和整合的地方。以这种方式构建 dApp 也是开发者的优先选择,因为无服务器应用开发团队可以更专注构建同时融合链上和链下数据、更专注业务逻辑,从而更多资源投入到高价值业务的开发。

(作者:Chance,封面摄影:Danny Meneses)

产品图.jpg

赞 (0)
上一篇 2024年11月23日 00:05
下一篇 2024年11月23日 00:05