免责声明：本文旨在传递更多市场信息，不构成任何投资建议。文章仅代表作者观点，不代表火星财经官方立场。
边肖：记得要集中注意力。
来源：区块链大本营
来源| CSDN博客
编辑|卡罗尔
出品|区块链大本营(区块链_营地)
去中心化应用(Dapp)被广泛认为会给银行(Di-Fi)和游戏行业等领域带来颠覆性创新。然而，即使是最创新的解决方案，如果不能满足消费者的期望，也不会得到认可。
消费者需要流畅、成熟的用户体验，实现这一目标是以太坊Dapp开发者面临的一大挑战。
本文将概述典型的Dapp架构，并指出当今标准以太坊堆栈的一些固有限制，这些限制使开发人员难以创建令人信服的用户体验。然后我们将介绍以太坊基础设施领域的一些创新，可以帮助开发者克服这些挑战。
经典的以太坊 Dapp 架构
一般来说，以太坊上的Dapp包含三个主要部分：
智能合约通常用Solidity编写，使用Truffle Suite等框架在以太坊区块链上构建和部署。
前端代码，用Java写的。
后端-通常，使用标准以太坊区块链节点。前端和后端之间的通信通常使用节点提供的JSON-RPC或GraphQL API。
还有各种方便前端和Eth节点通信的库，其中web3.js和ethers.js最受欢迎。还有很多其他语言的web3库(Java，Python，Rust…)。
自建后端节点
以太坊早期，开发者要运营自己的以太坊节点。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 面世。
