你的 dApp 存在漏洞 - 原因如下

RPC（远程过程调用）节点是区块链基础设施的关键组件。它们处理去中心化不可变账本和前端应用程序之间的通信。这些中介基础设施充当信使，促进区块链上构建的节点和服务之间的请求和响应。

RPC 节点就像美国邮政服务 (USPS)，它促进信息从 dApp 到区块链的移动和返回。就像你依靠邮政服务将邮件从一个地方送到另一个地方一样，dApp 也依赖 RPC 节点来访问区块链。如果没有这些节点，去中心化应用程序将难以运行。

在过去 10 年中，RPC 节点取得了长足的发展，但基础设施的中心化也带来了隐藏的漏洞。本文旨在探讨 RPC 节点的作用、中心化的危险以及可以保护您的 dApp 免受漏洞攻击的替代方案。

RPC 基础设施的演变

远程过程调用的想法可以追溯到 20 世纪 70 年代，当时计算机科学家正在寻求不同机器之间进行通信的方法，以使分布式计算机对开发人员透明。

20 世纪 80 年代，第一个 RPC 由 Sun Microsystem 公司开发，称为网络文件系统。Sun Microsystem 公司开发了开放网络计算 RPC 协议，该协议已成为网络上不同程序之间通信的标准。

然而，在 1990 年代初期，微软开发并实现了其版本的 RPC，以实现基于 Windows 的系统上的进程间通信。在 2000 年代初期，引入了使用 JSON 进行数据编码的 JSON RPC。由于易于传输标准化数据，它在开发人员和程序员中声名狼藉。

在过去的十几年里，dApp 已经成为区块链行业的重要组成部分，而 RPC 已经成为完成迷宫所需的完美基础设施。

为什么？

1. 它能够像本地函数调用一样在另一台计算机上进行远程函数调用，这对于区块链架构来说是完美的。
2. 它的无状态性和轻量级性为区块链提供了支持，并且在带宽和计算受限的情况下很有帮助。

由于这些优点，RPC 很快就得到了广泛的应用。RPC 的提出是为了使用不同语言编写的应用程序能够连接和通信。RPC 背后的基本思想是将远程函数调用当作本地函数调用一样在另一台计算机或服务器上进行。

多年来，RPC 主要有三种类型（集中式、分散式和自托管式），每种类型都有其独特之处。

中心化 RPC 节点的危险

集中式 RPC 节点是由单个实体管理和控制的节点。这些集中式节点的模型类似于 AWS（Amazon Web Services）、Microsoft Azure 和 Google Cloud Protocol（GCP）等 Web2 云托管服务。

尽管这些中心化的 web3 RPC 提供商为去中心化应用程序维护节点基础设施，但深入研究系统后，就会发现它们非常中心化。讽刺的是，这些 web3 基础设施提供商还依赖 web2 云托管服务器基础设施来维护其服务。

因此，当这些云提供商出现故障时，本应去中心化的 web3 服务也会出现停机。以下是中心化 RPC 节点的示例：Alchemy、Infura、Quicknode 等。

让我们来看看集中式 RPC 节点对 web3 基础设施造成的危险。

1. 单点故障：单点故障总是会影响系统可靠性。由单个实体控制的单个服务器或服务器网络将引入一个关键点，这可能会导致 dApp 失败。

   
   

   

   
   

   如果数据路由的服务器发生故障，区块链和 dApp 之间的链接就会中断，系统就会出现故障。单点故障会影响系统的可靠性，尤其是在 DeFi 平台等金融相关应用中。

2. 可扩展性问题：集中式 RPC 节点在流量高峰时可能成为瓶颈，从而限制 dApp 的可扩展性。当网络因依赖单个节点而拥堵时，会影响 dApp 的效率并增加延迟，进而影响用户。

   
   

   因为它是一个集中式系统，所以增加 dApp 的可扩展性是不可能的。

3. 安全风险和漏洞：集中式或专用节点容易受到漏洞攻击，很容易成为不法分子的攻击目标。数据可能被泄露和操纵，并最终影响 dApp 中的决策。

   
   

   此外，还可以轻松实施对提供商的协同攻击，最终暴露 Dapp 的用户。政府机构可以强迫单个实体关闭应用程序。

   
   

   以下是一个例子：

   
   

   2022 年，MetaMask 据称阻止了委内瑞拉和伊朗 IP 地址的用户在区块链上进行交易。

   
   

   这是因为 web3 钱包使用了集中式 RPC（Infura）才成为可能。

集中式 RPC 节点故障和漏洞案例研究

中心化 RPC 看似安全，但实际上并非如此。如果您对此心存疑虑，不妨看看过去中心化 RPC 失败的一些案例研究。

Infura 案例

Infura是 web3 中首批区块链后端基础设施即服务 (IaaS) 提供商之一，由共识提供。据称该基础设施的正常运行时间为 99.9%，可供 16 个区块链 EVM 使用。

直到 2020 年，Infura 一直被视为英雄，作为 dApp 开发的前沿之一，引领加密货币/区块链的大规模采用。

2020 年 11 月 11 日，由于影响 Infura 运行的 GEth 版本的错误，Infura 服务中断。

这里的主要问题是 Infura 系统瘫痪，所有 Infura 基础设施用户都无法连接到区块链。服务器因错误而中断，去中心化网络背后的中心化风险暴露无遗。

Metamask 是面向消费者的最大以太坊钱包，拥有数百万活跃用户，但遭遇了中断。这一切都是因为他们依赖中心化 RPC 提供商 Infura。

网络升级期间的集中化问题

在网络升级/硬分叉期间，人们通常会担心服务故障，尤其是对于依赖中心化基础设施提供商的 dAapp。这些问题包括：

单点故障，可能扰乱活动并导致停机。

以下是一些过去的例子：

• 在2019 年以太坊伊斯坦布尔硬分叉期间，许多中心化 RPC 提供商都经历了宕机。其中一些宕机是由于网络升级造成的。DeFi 应用无法处理交易，导致用户陷入困境。

  
  

• 在Polygon Heimdall 升级期间，RPC 服务提供商面临连接问题，无法与区块链网络同步。用户几个小时内无法访问 DeFi dApp，因此交易延迟或失败。

2021 年 Solana RPC 过载

Solana在 2021 年经历了多次中断。其中一次臭名昭著的中断是由于高峰期中心化 RPC 服务过载造成的。由于公共节点不堪重负，用户几个小时都无法与 Solana 区块链交互，网络面临长达数小时的全面服务中断。

这些 Facepalm 案例和无数其他案例揭示了 RPC 提供商对区块链实用性的重要性。虽然许多 dApp 仍在使用中心化提供商（可能是出于无知或粗心），但多年来一直存在替代方案。

在接下来的部分中，我们将带您了解其他替代方案以及它们如何成为区块链开发的绝佳选择。

去中心化你的 DApp：中心化 RPC 节点的最佳替代方案

自托管 RPC 节点

顾名思义，自托管 RPC 节点是您在自己的硬件或云基础架构上托管或管理的节点。您可以托管自己的 RPC 节点，而不必依赖第三方 RPC 提供商。您可以直接访问区块链网络、验证交易、直接查询区块链数据以及与 dApp 交互。

自托管 RPC 节点的优势包括：

1. 自主/控制：运行节点意味着您可以完全控制节点的配置。您可以自定义软件以满足您的需求，自行应用更新并管理安全性。

2. 可靠性：您不必担心第三方集中节点常见的服务中断或由于提供商问题而导致的故障。

3. 直接网络访问：在您的基础设施上运行节点意味着您要对他们的服务负责，并且您可以低延迟地访问区块链网络。

虽然自托管节点看起来比中心化替代方案更可靠，但它们也有缺点。缺点如下：

1. 高资源要求。托管 RPC 节点需要大量磁盘空间来存储区块链历史记录。运行 RPC 节点所需的存储、带宽和处理能力可能非常大。

   
   

   此外，你需要不断与区块链同步，这会消耗大量带宽，这可能会让人难以承受。所需的处理能力也可能非常强大，尤其是在高流量情况下处理信息时。

   
   

2. 管理成本高昂：设置自托管节点似乎是一个更好的选择，但事实并非如此。硬件成本、运营成本和机会成本可能非常高昂。

   
   

   电力、互联网带宽和云服务费（如果您使用云基础设施）等运营成本可能非常高昂。要成功运行节点，您需要一个专门的专家团队随时待命解决任何问题，否则您可能会面临几个小时的停电风险。

3. 复杂的设置和维护：您需要对区块链技术、服务器管理和安全最佳实践有深入的了解。定期维护以避免软件更新、安全补丁和硬件升级等中断，以保持节点正常运行。

4. 可扩展性有限且不支持多链：与具有处理此问题的模型的第三方提供商不同，要与多个区块链进行交互，您需要为每个区块链托管节点，这可能会耗费大量资源且不可持续。

   
   

   自托管节点提供独立性、对区块链交互的强大控制和隐私。它们需要大量资源、技术专业知识和维护，即使是最强大的区块链开发团队也可能无法做到这一点。

去中心化 RPC 节点

去中心化 RPC 是允许 dApp 以去中心化方式与区块链通信的区块链服务器。去中心化 RPC 提供商将其基础设施分布在多个节点上。这减少了单点故障，增强了网络稳定性和可扩展性，并降低了延迟。

与其他节点相比，去中心化 RPC 节点的优势包括

1. 分布式网络：节点提供商的分布式网络正在处理请求、响应查询并与区块链交互。

2. 操作无需信任：不信任单个提供商。请求分布在多个提供商之间，确保没有任何一方可以完全控制数据或所提出的请求。

3. 抗审查性：由于 RPC 节点不位于同一管辖区，因此实体/机构无法轻易审查、阻止或限制对区块链的访问。如果 RPC 基础设施由于某个管辖区的政策而关闭，则 dApp 的请求可以路由到来自不同管辖区的其他 RPC 节点。

4. 容错性：RPC 服务的去中心化模型使其能够抵御中断。如果某个节点发生故障，另一个节点将替代该服务。这减少了停机时间并确保了一致的可用性。

挑战包括：

1. 延迟：如果设置不当，分散式 RPC 服务可能会引入延迟，因为它可能会通过多个节点进行路由。RPC 节点的分散性很容易变得冗余，因此，数据可能会通过多个服务器进行路由，从而增加延迟。

2. 安全性：由于节点由不同的实体管理，因此节点的安全性可能不相同。

3. 节点之间的共识：确保数据的一致性和可靠性可能具有挑战性。需要建立机制来检测和缓解恶意/故障节点。

去中心化 RPC 节点的示例包括：

dRPC、Pocket 网络和 Ankr

避免 dApp 开发中的中心化风险的最佳实践

1. 节点提供商的多样化

通过选择 dRPC 等去中心化 RPC 节点提供商，您可以避免中心化风险。去中心化 RPC 提供商拥有系统来确保节点按负载均衡器、节点提供商监控和对优秀参与者的激励等必需功能运行。

例如，dRPC 为您提供了仪表板，用于监控节点基础设施的多样化。即使您无法直接控制使用的节点及其分散程度，仪表板也可以让您了解节点的分散程度。

从上图可以看出，该连接在四个不同的 RPC 节点提供商（ Besked、drpc-free、drpc-public-multiregion、p2p-validator-optimism-free ）之间是去中心化的。去中心化指数为 0.563，显示了去中心化程度的累计数字，“一”表示最去中心化，“零”表示最中心化。

2. 监控和管理节点健康

开发人员应该能够监控其 dApp 使用的 RPC 节点。这确保了 dApp 的可靠性。即使您可能无法控制 RPC 提供商如何管理其系统，但像 dRPC 这样的去中心化 RPC 提供商都有系统来监控 RPC 节点提供商。

dRPC 的 SaaS 仪表板可让您访问全面的分析功能，以监控 dApp 与基础架构的交互方式。例如，在 dRPC 仪表板中，您可以监控 dApp 在选定日期内发出的请求总数、监控 RPC 节点去中心化以及基于 API 密钥的请求分布。您甚至可以从仪表板访问监控错误日志。

除了 dRPC 分析仪表板之外，dRPC 还有一个后端机制来监控节点提供商并防止它们失控。在此处阅读有关这些后端机制的更多信息。

结论

RPC 节点在促进去中心化应用程序与区块链之间的通信方面发挥着重要作用。然而，RPC 的中心化会给您的 dApp 和整个区块链网络带来重大风险。如上文案例研究中的先前故障所示，依赖中心化 RPC 提供商会带来单点故障的风险，并可能导致 web3 服务的关键服务中断。

开发人员并非没有替代方案。自托管和去中心化 RPC 提供了可靠的解决方案，可帮助构建弹性应用程序。通过采用dRPC等去中心化 RPC，开发人员可以降低中心化风险并构建功能强大、弹性强、抗审查且安全的应用程序。