分散应用程序（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 界面使用的带宽较少，但不提供串流传输功能(前端必须轮询更新)
缺乏原子性
在大多数现代环境中，如关系数据库，交易通常是原子操作，但不是在以太坊（或其他区块链）。每笔交易都经历了一系列的状态转换，可能会遇到各种问题或失败。Dapp 必须调用多个 API，查询许多不同的数据源(块，mempool、为了跟踪交易的生命周期，直到它完成。
同样，负担落在前端代码上，通过重复轮询找出具体发生了什么 Dapp 因为 Dapp 所有这些额外的工作都需要延迟和刷新。
4.节点是被动的
以太坊节点是被动的，这意味着它们不能产生事件或回调和调用 Webhooks。所有操作必须由前端启动，前端必须轮流查询节点以获取更新信息。以太坊节点的事件串行读取功能太有限，无法满足大多数需求 Dapp 而且只有 JSON-RPC 可用于接口，在 GraphQL 不能在接口上使用。
重新思考 Dapp 的基础架构
dfuse 区块链提供了更高层次的区块链 API 提供区块链节点的原始平台 API 相比之下，他们可以更容易地完成更多的工作。 Dapp 开发者所需的功能是在提供优秀用户体验的基础上，通过快速流畅的界面构建现代区块链应用。
希望通过平台解决上述所有限制，打破传统以太坊节点的局限性。
一、视图一致
dfuse 它是一个集成的超大规模数据平台，而不是多个以太坊节点在负载个以太坊节点。dfuse 平台在所有连接和时间点提供链 state 信息。要么看到一个块(同时检测链的分叉和重组)，要么根本不报告块(当块快速重组并传播不远时)。
这样 Dapp 永远不要面对不一致的链状态视图，可以专注于它的主要功能，而不是忙于验证区块链的细节。
2.高速细粒化搜索
使 Dapp 开发者可以以极细化的粒度、非凡的速度和效率搜索区块链的历史记录，也可以通过GraphQL、gRPC 和 Websocket 实时筛选界面，串流读取。
-
全部索引 Log 字段-每笔交易都在 Log 所有数据都直接适用于高精度搜索。
-
完全索引所有内部交易(发送人、接收人、值、方法、输入参数)，全面跟踪整个调用树结构中合同的操作
-
索引不会给你的用户带来任何额外的 gas 费用——dfuse 的索引是 dfuse 平台的集成功能不会增加合同执行的资源成本
-
搜索找到的是完全匹配的结果，而不是模糊的结果。不需要编写额外的前端代码来重复检查搜索结果，也不需要浪费带宽来批量获取不必要的数据
-
类似于结构化的查询语言 Kibana 或 GitHub 查询语言完整 boolean 操作并直接深入您想要找到的具体交易或命令的能力
-
提供优秀的性能——根据指定的搜索条件，在不到一秒钟内搜索整个链的历史记录，找到一组完全匹配的项目
-
通过 GraphQL 能提供简洁的响应，但又不牺牲串流功能，两全其美——我们的 GraphQL 界面提供完整的实时过滤搜索，为用户提供动态更新
-
无论以太坊网络上的流量如何，性能都是一致的
3、原子操作
提供一个串流读取端点，了解交易可能进入的所有复杂状态，并在满足最终要求时通知您。您只需推送交易并保持连接即可接收实时状态更新，无需通过重复轮询或检查多个数据源来跟踪交易状态。
4.主动后端
一个好的平台将为您提供一个可以启动事件的主动后端。例如，您可以根据您指定的准确标准（通过上述搜索和其他功能）调用您选择的标准 lambda 函数(或云函数)。 Dapp 实现异步系统结构，数据更新可通过多个通信渠道流畅实时发布给用户。
一个是尖端 Dapp 现代平台
dfuse 为你的 Dapp 它提供了一个现代的基础设施层，即：
-
快速
-
可扩展
-
为区块链事件提供高精度、细粒化的实时访问
-
支持主动的 Webhook 形式的回调
-
支持原子操作
因此，在以太坊开发 Dapp只有在遇到上述问题时，才能尝试用不同的工具来解决问题，产品抛光和用户培训后，可以促进更精致、实用、成熟 Dapps 面世。
文章来源：区块链大本营
免责声明:版权归原作者所有。如有内容、版权等问题，本网站应在24小时内删除
