设计灵活性:Web3 开发的新巅峰

去中心化应用程序(dApps)位于 Web3 运动的前沿,提供了更开放和以用户为中心的互联网体验。然而,开发这些应用程序并非没有挑战。在阻碍 Web3 开发者前进的一长串问题中(安全性、可扩展性、用户体验、激励等),还有一个挑战一直难以把握,讨论得较少:设计灵活性。

DApp 开发的当前状态

在今天的传统软件世界中,开发者拥有丰富的工具和库,用于构建用户友好的应用程序。对于今天的 Web2 开发者来说,选项众多,简而言之,他们的设计选择是灵活的。

与之形成鲜明对比的是,在 Web3 中,技术的限制通常会限制开发者。这在建立在以太坊上并在以太坊虚拟机(EVM)中执行的应用程序中最为明显。每个智能合约交互(即每个交易)都通过 EVM 运行,更新网络的状态。在 EVM 上的每个交易都会产生燃气费;交易越复杂,费用就越高。以太坊的区块空间有限,因此当燃气费上升和区块空间有限相冲突时,会出现竞争环境。

在网络需求高峰期,竞争加剧。Web3 用户和 dApps 发现自己陷入竞标战中,争夺能够更早处理他们的交易,并被迫支付高额费用才能实现。

然而,这种动态不仅仅转化为高昂的成本。它从根本上影响了 dApps 最初的设计方式。开发者常常被迫将燃气优化置于软件功能之上。其结果是一个开发领域,创新受到压制,设计选择不是为了用户体验,而是为了弥补底层基础设施的限制。

今天的 L2 燃气解决方案

燃气费用和可扩展性对于 Web3 的成功至关重要,而今天的许多 Layer 2 项目旨在找到解决方案。通过在链下执行交易,Layer 2 承诺减少了区块空间的激烈竞争。然而,尽管这些网络缓解了一些燃气战争的压力,它们并没有完全解决核心问题:设计的灵活性。

即使使用 L2 解决方案,dApps 仍然受到 EVM 的限制。燃气和区块空间之间的竞争竞标动态是共享 EVM 空间固有的,而大多数这些 L2 仍然是如此。即使这些压力在今天的 L2 rollup 解决方案中得到减轻,开发者仍然不得不进行设计妥协。

寻找更好的开发环境

对更多设计自由度的追求已经引导项目探索了 EVM 的替代方案,例如 EVM+ 和 WASM。这些替代方案允许开发者使用更传统的编程语言(如 Rust 和 Python)编写智能合约。

传统编程语言的真正优势在于它们庞大的开源库。这些库是在全球开发者的数十年输入下构建的,提供了对复杂问题的预写、经过实战验证的解决方案。开发者使用这些库来更快速、更高效地构建应用程序。这些 Web2 库依赖于提供内存管理、系统硬件、安全性等的操作系统。

然而,由于当前 L2 共享环境的计算限制,EVM 的替代方案无法支持操作系统。这意味着即使使用这些“开发者友好”的 EVM 替代方案,dApp 开发者仍然无法受益于大多数开源库。没有这些资源,即使是基本的开发任务仍然繁琐且低效。

找到实现设计灵活性的正确途径

因此,实现设计灵活性的巅峰需要几种不同的创新相互交汇。首先,需要解决区块空间和燃气成本的竞争,以便开发者可以专注于为用户创建完美的 dApp,而不是针对燃气优化的完美 dApp。一旦开发者从共享环境转移到特定于应用程序的环境,问题就变成了:“利用这些大幅提升的计算能力可以做什么?”

现在,他们将拥有资源来使用熟悉的编程语言的完整实现,而不是受限版本或 Web3 本地语言。这些语言需要与庞大的开源库一起提供,这些库受益于全球开发者的“大脑力量”。

所有这些交叉点的需求需要一种根本上新的方法来实现设计灵活性。设计灵活性不是一项“好有的”特性。它是更多 Web3 应用程序超越好奇,开始对我们在线操作方式进行明显可扩展变化的必要条件。全球社区需要不断创新,以建设我们所有人构想的 Web3 未来。