{"content":{"title":"Portal Network：优化以太坊数据存储","body":">- 原文链接：https://blog.nimbus.team/fluffy-and-the-portal-network-enhancing-ethereums-decentralization/\r\n>- 译者：[AI翻译官](https://learnblockchain.cn/people/19584)，校对：[翻译小组](https://learnblockchain.cn/people/412)\r\n>- 本文永久链接：[learnblockchain.cn/article…](https://learnblockchain.cn/article/9177)\r\n    \r\n[Portal 网络](https://github.com/ethereum/portal-network-specs) 是一个专门为存储以太坊数据而设计的内容特定分布式存储网络。与 [Codex](https://codex.storage/)、IPFS 或 Swarm 等通用分布式存储网络不同，Portal 网络可以针对其处理的特定类型数据进行优化，从而改善数据访问和验证过程。这种特性使得网络中的节点对其存储的内容有既得利益，能够实现类似于 BitTorrent 系统的中的针锋相对非货币激励。\r\n\r\n### 我们为什么需要 Portal 网络？\r\n\r\n以太坊社区早已认识到在扩展和优化性能的同时，维护一个去中心化和无权限的网络所面临的挑战。正如 Vitalik Buterin 在他的 [博客文章](https://vitalik.eth.limo/general/2024/05/17/decentralization.html) “改善以太坊网络的无权限性和去中心化的近期和中期未来” 中强调的那样，EIP-4444、Verkle 树和去中心化存储等近期进展对网络的演变至关重要。\r\n\r\n今天，运行一个完整的以太坊节点需要大量的存储和技术专长。例如，一个典型的节点可能占用超过 2 TB 的磁盘空间，而维护一个归档节点可能需要超过 10 TB 的磁盘空间，这使得许多用户难以实现。随着区块链的发展，完整节点的存储需求持续增长。\r\n\r\nEIP-4444 提议通过不再要求节点存储和提供超过一年的历史链数据来减轻以太坊节点的存储负担。然而，这带来了另一个挑战。提案 EIP-4444 的一个主要担忧是，移除节点存储旧历史的要求后，确保在需要时历史数据的可用性。Portal 网络通过在点对点网络中分布存储来解决这个问题，确保数据的强大冗余和可访问性。这种方法减轻了依赖少数大型参与者存储历史数据所带来的中心化风险。\r\n\r\n### Portal 网络及其子网络\r\n\r\n![](https://img.learnblockchain.cn/attachments/migrate/1725198325970)\r\n> 图 1：Portal 作为以太坊网络的一部分\r\n\r\nPortal 网络由多个子网络组成，每个子网络针对特定类型的以太坊数据进行了优化：\r\n\r\n*   **历史网络：** 提供对链数据的访问，如区块头、区块体和收据。\r\n*   **信标网络：** 提供信标轻客户端数据，包括引导、更新和最终性更新，促进共识轻客户端同步。\r\n*   **状态网络：** 提供对当前和历史状态数据的访问，充当分布式归档节点。\r\n\r\n正在开发的未来子网络包括 verkle-state 网络、规范索引网络和交易八卦网络等。Portal 网络的模块化设计使得定义新的内容类型和密钥、验证数据以及将新内容桥接到网络中相对容易。\r\n\r\n### Nimbus Portal 网络客户端 - （项目：Fluffy）\r\n\r\nFluffy 是一个用 Nim 编写的 Portal 网络客户端实现。它作为以太坊轻客户端，使用 Portal 网络作为其数据后端，实现了执行 JSON-RPC API。Fluffy 可以作为一个独立客户端运行，访问 Portal 网络和执行 JSON-RPC API，或者可以作为库集成到另一个客户端中。\r\n\r\n### 第一个用例：EIP-4444\r\n\r\nPortal 网络的第一个主要用例是支持 EIP-4444 的实施，并解决管理链历史的担忧。通过集成“Portal 客户端”，节点可以将这些归档数据注入到 Portal 网络节点中，保持对历史数据的访问，而无需在本地存储。  \r\n对于 EIP-4444，可以采取初步的双层方法：使用种子文件进行批量数据下载，使用 Portal 网络进行单独访问。这确保了高效的数据分发和对特定历史数据的轻松访问。\r\n\r\n图 1 说明了共识客户端（CL）、执行客户端（EL）和 Portal 网络客户端如何协同工作，以实现降低以太坊节点资源需求的目标。\r\n\r\n**关键亮点：**\r\n\r\n*   当执行客户端收到请求以获取某个区块时，如果该区块在其本地存储中不可用，执行客户端可以向 Portal 节点请求该区块，Portal 节点将从 Portal 网络中获取它。\r\n*   执行客户端（EL）可以通过 [Portal JSON-RPC API](https://playground.open-rpc.org/?schemaUrl=https://raw.githubusercontent.com/ethereum/portal-network-specs/assembled-spec/jsonrpc/openrpc.json&uiSchema%5BappBar%5D%5Bui:splitView%5D=false&uiSchema%5BappBar%5D%5Bui:input%5D=false&uiSchema%5BappBar%5D%5Bui:examplesDropdown%5D=false) 与现有的独立 Portal 客户端协作，或者执行客户端可以集成一个 Portal 节点（即一个二进制文件），以提高两者之间的性能和交互。\r\n*   执行客户端（EL）还可以将历史数据（例如，在修剪时）注入到 Portal 网络中，以降低或消除当前对 Portal 数据桥的需求。\r\n*   将来，如果网络中的大多数节点能够直接查询 Portal 网络以获取历史区块，执行客户端可能不再需要接收和处理所有当前 EL 网络查询。\r\n\r\n### 我在哪里可以了解更多关于 Nimbus Portal 网络客户端的信息？\r\n\r\nNimbus Portal 网络客户端是该网络的第一个客户端实现之一。\r\n\r\n深入了解 [Github Repo](https://github.com/status-im/nimbus-eth1/blob/master/fluffy/README.md)，从 [Docs](https://fluffy.guide/) 开始，或加入 Nimbus [Discord](https://discord.gg/EP8DZnXu9y) 讨论我们关于 Portal 网络客户端的更多努力。\r\n\r\n> 我是 [AI 翻译官](https://learnblockchain.cn/people/19584)，为大家转译优秀英文文章，如有翻译不通的地方，在[这里](https://github.com/lbc-team/Pioneer/blob/master/translations/9177.md)修改，还请包涵～"},"author":{"user":"https://learnblockchain.cn/people/22488","address":null},"history":null,"timestamp":1725326728,"version":1}