在以太坊上开发 Dapp 的瓶颈和门槛有哪些？ | 博文精选
来源 | CSDN 博客
责编 | Carol
出品 | 区块链大本营（blockchain_camp)
去中心化应用程序（Dapp）被广泛认为是可以为像银行业（Di-Fi）和游戏业等领域带来颠覆性创新的。但是，即使是最有创新性的解决方案，如果不能满足消费者的期望，也不会被认可。
消费者需要的是流畅和成熟的用户体验，而实现这个目标对以太坊的 Dapp 开发者来说又是一个重大挑战。
本文将概述典型的 Dapp 架构，并指出当今标准以太坊堆栈的一些固有局限性，正是这些局限性导致开发者难以打造出能有说服力用户体验。接着会介绍下以太坊基础设施领域中的一些能帮助开发者克服这些挑战的创新。
经典的以太坊 Dapp 架构
一般来说，以太坊上的 Dapp 包含三个主要部分：
智能合约，通常以 Solidity 编写，使用 Truffle Suite 等框架构建并部署在以太坊区块链上。
前端代码，用 Java 编写的。
后端——一般是用标准的以太坊区块链节点。前端与后端的通信一般是使用节点提供的 JSON-RPC 或 GraphQL API。
还有各种促进前端与 Eth 节点的通信的库，其中最受欢迎的是 web3.js 和 ethers.js。也还有许多其他语言（Java，Python，Rust…）的 web3 库。
自建后端节点
在以太坊的早期，开发者必须运营自己的以太坊节点。Dapp 发布了以后，他们还必须运营生产级别的节点（或节点集群）。运营区块链节点这项工作繁重，也会对开发者的效率造成负担。
节点服务（NaaS）提供商
上述的这个挑战促成了一些例如 Infura，以及相对新的 Nodesmith、Quiknode、Blockdaemon、Ethernode、Chainstack、Alchemy、CloudFlare 等公司的 “节点服务” 平台的兴起。
这些平台为开发者提供了基于云端的以太坊节点，从而节省了开发者运营节点的精力。用于开发和生产的解决方案。这些平台可为开发者分担基层操作系统和节点软件本身的系统管理，例如补丁和更新。
以太坊节点的固有局限性
即使节点服务能成功地替代开发者担任系统管理员的职责，它无法帮助开发者实现的用户体验去构建更好的 Dapp，这是因为来自节点服务的架构以及以太坊节点支持的 JSON-RPC 和 GraphQL 接口的固有局限性。
主要的局限性包括：
1、观测到的 state 信息不一致
为了扩展到单个节点的容量之上同时提供更高的可靠性，作为服务平台的节点是通过负载平衡器提供对节点池的访问的。
由于这些节点中是都作为以太坊网络中的对等节点自主运行的，因此当信息在通过网络传播的某一个时刻，不同的节点可能处于不同的区块高度上，甚至处于不同的分叉上。这意味着 Dapp 可能收到区块链状态的信息是不一致的，因为它的请求获得的结果是由负载均衡器背后的不同节点提供的。
节点服务平台通常试图通过负载平衡器上的会话粘性来解决此问题，总是会去尝试将指定前端的查询发送到同一个后端节点，但是这种方法在多种情况下会失败：
当前端产生的请求多于单个后端节点能负担的处理量时；
当网络问题导致前端与后端断开连接时，而且必须重新连接；
多个节点服务平台会将不同类型的前端请求（例如，发送交易或搜索链历史记录）路由到针对该查询类型优化的不同后端节点组。
那么由于前端经常访问多个后端节点，而这些后端节点获取的区块链状态与彼此不一致，因此 Dapp 很难处理链重组。向后追溯链历史的时候，Dapp 可能突然发现它想找的父区块不存在了（原因是它现在正在与在不同分叉上的另一个节点交互）。那么 Dapp 开发者就不得不去专门写代码来解决这个问题（方法通常是通过反复地重连，直到它找到一个节点）。这样给 Dapp 增加了不必要的复杂性，并且可能导致呈现给用户的信息有出入。
2、在区块链上搜索信息很慢、有局限性
Dapp 搜索交易或链上历史的能力受限，因为标准以太坊节点不适合支持精确搜索或执行实时数据的筛选式监听。想要以高性能的方式进行操作，我们需要对数百万个区块和交易做大量的索引，但是：
以太坊节点仅索引交易执行发出的日志中的某些字段（要索引的字段必须在部署合约时由开发者标记出来）
以太坊节点不索引内部交易（当智能合约调用另一合约的方法时发生）的数据
开发者不愿意添加额外的索引字段，因为每多一个索引字段每个交易的成本都会相对增加，会给合约的用户带来额外的费用
以太坊节点使用 Bloom 过滤器执行搜索，因此它始终是模糊搜索，并且会产生伪阳性的匹配。精确匹配需要前端进行额外的处理，前端必须获取模糊匹配的整个区块或交易，对其再次检索而找到精确匹配的结果。这不仅需要开发者的精力，而且浪费了前端和节点之间的带宽
可用的搜索语法非常有限——仅支持基本的选择以及简单的替换
获取搜索结果的速度很慢——在大范围的区块中执行搜索可能需要几个小时
JSON-RPC 非常浪费带宽——返回的数据远远超出你所真正所需。GraphQL 接口使用的带宽较少，但不提供串流传输功能（前端必须进行轮询更新）
3、缺乏原子性
在大多数现代环境中，例如关系数据库，交易一般是原子操作，但在以太坊（或其他区块链）上不是。每个交易都会经过一系列状态的转换，在这个过程中可能遇到多种问题或失败。Dapp 必须调用多个 API，查询许多不同的数据源（区块、mempool、网络状态）以便跟踪交易的生命周期，直至其完成。
同样，这个负担就落在了前端代码上，通过重复轮询来弄清楚具体发生了什么，而 Dapp 的用户会因为 Dapp 执行所有这些额外的工作而经历延迟和需要刷新。
4、节点是被动的
以太坊节点是被动的，这意味着它们无法生成事件或回调和调用 Webhooks。所有操作必须由前端来启动，而前端还必须轮询节点以获得更新的信息。以太坊节点的事件串流读取功能太有限，无法满足大多数 Dapp 的需求，并且仅在 JSON-RPC 接口中可用，在 GraphQL 接口上不可用。
重新思考 Dapp 的基础架构
dfuse 提供的是一个更高级别的区块链 API 的平台，与区块链节点提供的原生 API 相比，它们可以更轻松地完成更多的工作。是为了赋予 Dapp 开发者所需的功能，使其能够通过快速、流畅的界面构建现代区块链应用程序，从而提供出色的用户体验的基础上而设计的。
希望能通过平台，解决上述所有限制，打破传统以太坊节点的局限性。
1、有一致性的视图
dfuse 是一个集成的超大规模数据平台，而不是在负载均衡器上的多个以太坊节点合集。dfuse 平台在所有连接上、所有时间点上提供链的 state 信息。要么是看到一个区块（同时侦测到链的分叉和重组），要么根本不去报告该区块（在区块经历迅速重组并传播不远的情况下）。
这样 Dapp 永远不会面对一个不一致的链状态视图，并且可以专注在它的主要功能上，不是去忙着验证区块链的细节。
2、高速、细粒化的搜索
使 Dapp 开发者能够以极细化的颗粒度、非凡的速度和效率来搜索区块链的历史记录，还能通过GraphQL、gRPC 和 Websocket 界面实现实时筛选，串流读取。
完全索引所有的 Log 字段——每个交易在 Log 中发出的所有数据都直接适用于高精度搜索。
完全索引所有内部交易（发送者、接收者、值、方法、输入参数），从而在整个调用的树型结构中全面跟踪合约的操作
索引不会给你的用户带来任何额外的 gas 费用——dfuse 的索引是 dfuse 平台的一项集成功能，不会增加合约执行的资源成本
搜索找到的是完全匹配的结果，而不是模糊搜索的结果。无需编写额外的前端代码来重复检验搜索结果，也不用浪费带宽去批量获取不需要的数据
提供了一种结构化的查询语言，类似于 Kibana 或 GitHub 的查询语言，具有完整的 boolean 操作和直接深入你想找的具体交易或命令的能力
提供出色的性能——可以在不到一秒钟的时间，按照指定的搜索条件，搜索全链历史记录，找到一组完全匹配的项
通过 GraphQL 能提供简洁的响应，但又不牺牲串流功能，两全其美——我们的 GraphQL 界面提供了完整的实时过滤搜索，可为用户有效地提供动态更新
无论以太坊网络上的流量如何，性能都是保持一致的
3、原子操作
提供了一个串流读取端点，该端点了解交易可能进入的所有复杂状态，并在其满足最终性时通知你。无需去费力地通过重复轮询或检查多个数据源去跟踪交易的状态，你只需要把交易推送上去并保持连接即可接收实时状态更新，从而也可以向你的用户提供交易的实时状态。
4、有主动性的后端
一个好的平台会为您提供了一个可以启动事件的主动后端。比如，可以根据你指定的精确标准（通过上述的搜索以及其他功能）调用你所选择的 lambda 函数（或云函数）。这让 Dapp 实现了异步的体系结构，数据更新可以通过多个通信渠道流畅、实时地发布给用户。
5、一个为尖端 Dapp 打造的现代平台
dfuse 为你的 Dapp 提供了一个现代化的基础架构层，即：
快速
可扩展
提供对区块链事件的高精度，细粒化的实时访问
支持主动的 Webhook 形式的回调
支持原子操作
具有业内最高的可靠性
所以，在以太坊上开发 Dapp遇到以上问题时，可以尝试用不同的工具解决问题，只有在经历了产品打磨和用户培养后，才能促使更多精致、实用、成熟的 Dapps 面世。
推荐阅读