---
title: "波特爾網路"
description: "波特爾網路概覽：一個開發中的網路，旨在支援低資源客戶端。"
lang: zh-tw
---

[以太坊](/)是一個由執行以太坊客戶端軟體的電腦所組成的網路。這些電腦中的每一台都被稱為「節點」。客戶端軟體允許節點在以太坊網路上傳送和接收資料，並根據以太坊協定規則驗證資料。節點在其磁碟儲存空間中保留大量歷史資料，並在從網路上的其他節點接收到稱為區塊的新資訊封包時將其加入。這對於始終檢查節點是否具有與網路其餘部分一致的資訊是必要的。這意味著執行節點可能要求大量的磁碟空間。某些節點操作也可能要求大量的 RAM。

為了解決這個磁碟儲存問題，開發了「輕節點」，它們向全節點請求資訊，而不是自己儲存所有資訊。然而，這意味著輕節點無法獨立驗證資訊，而是信任另一個節點。這也意味著全節點被要求承擔額外的工作來為這些輕節點提供服務。

波特爾網路是以太坊的一種新網路設計，旨在透過在網路上以小區塊共享必要的資料，解決「輕節點」的資料可用性問題，而無需信任全節點或對其施加額外壓力。

更多關於[節點與客戶端](/developers/docs/nodes-and-clients/)的資訊

## 為什麼我們需要波特爾網路 {#why-do-we-need-portal-network}

以太坊節點儲存其自己的以太坊區塊鏈完整或部分副本。此本機副本用於驗證交易並確保節點遵循正確的鏈。這種本機儲存的資料允許節點獨立驗證傳入的資料是否有效且正確，而無需信任任何其他實體。

區塊鏈的本機副本以及相關的狀態和收據資料佔用了節點硬碟上的大量空間。例如，建議使用 2TB 硬碟來執行與共識客戶端配對的 [Geth](https://geth.ethereum.org) 節點。使用快照同步 (snap sync) 時，僅儲存相對較新的一組區塊的鏈資料，Geth 通常佔用約 650GB 的磁碟空間，但每週增長約 14GB（您可以定期將節點修剪回 650GB）。

這意味著執行節點可能會很昂貴，因為必須將大量磁碟空間專用於以太坊。以太坊路線圖上有幾個解決此問題的方案，包括[歷史記錄過期](/roadmap/statelessness/#history-expiry)、[狀態過期](/roadmap/statelessness/#state-expiry)和[無狀態性](/roadmap/statelessness/)。然而，這些方案可能還需要幾年時間才能實作。還有一些[輕節點](/developers/docs/nodes-and-clients/light-clients/)不儲存自己的鏈資料副本，它們向全節點請求所需的資料。然而，這意味著輕節點必須信任全節點提供誠實的資料，同時也給必須提供輕節點所需資料的全節點帶來壓力。

波特爾網路旨在為輕節點提供另一種獲取資料的方式，該方式不要求信任全節點，也不會顯著增加全節點必須完成的工作。實現這一目標的方法是為以太坊節點引入一種在網路上共享資料的新方式。

## 波特爾網路如何運作？ {#how-does-portal-network-work}

以太坊節點有嚴格的協定來定義它們如何相互通訊。執行客戶端使用一組稱為 [devp2p](/developers/docs/networking-layer/#devp2p) 的子協定進行通訊，而共識客戶端則使用稱為 [libp2p](/developers/docs/networking-layer/#libp2p) 的不同子協定堆疊。這些協定定義了可以在節點之間傳遞的資料類型。

![devP2P and libP2P](portal-network-devp2p-libp2p.png)

節點也可以透過 [JSON-RPC API](/developers/docs/apis/json-rpc/) 提供特定資料，這也是應用程式和錢包與以太坊節點兌換資訊的方式。然而，這些都不是為輕客戶端提供資料的理想協定。

輕客戶端目前無法透過 devp2p 或 libp2p 請求特定的鏈資料，因為這些協定僅設計用於實現鏈同步以及區塊和交易的八卦傳播 (gossiping)。輕客戶端不想下載這些資訊，因為這會使它們不再「輕量」。

JSON-RPC API 也不是輕客戶端資料請求的理想選擇，因為它依賴於連接到可以提供資料的特定全節點或中心化 RPC 提供者。這意味著輕客戶端必須信任該特定節點/提供者是誠實的，而且全節點可能必須處理來自許多輕客戶端的大量請求，從而增加了它們的頻寬需求。

波特爾網路的重點是重新思考整個設計，專門為輕量化而建置，跳脫現有以太坊客戶端的設計限制。

波特爾網路的核心理念是汲取目前網路堆疊的精華，透過使用 [DHT](https://en.wikipedia.org/wiki/Distributed_hash_table)（類似於 Bittorrent）的輕量級 devp2p 風格點對點去中心化網路，來提供輕客戶端所需的資訊，例如歷史資料和目前鏈頭的身份。

這個想法是將以太坊總歷史資料的一小部分和一些特定的節點職責加入到每個節點中。然後，透過尋找儲存所請求特定資料的節點並從中擷取資料來處理請求。

這顛覆了輕節點尋找單一節點並要求它們過濾和提供大量資料的常規模式；相反地，它們會快速過濾一個由各自處理少量資料的節點所組成的大型網路。

目標是允許由輕量級波特爾客戶端組成的去中心化網路能夠：

- 追蹤鏈頭
- 同步近期和歷史鏈資料
- 擷取狀態資料
- 廣播交易
- 使用 [EVM](/developers/docs/evm/) 執行交易

這種網路設計的好處是：

- 減少對中心化提供者的依賴
- 減少網際網路頻寬使用量
- 最小化或零同步
- 資源受限的裝置（\<1 GB RAM，\<100 MB 磁碟空間，1 個 CPU）也能存取

下表顯示了波特爾網路可以提供的現有客戶端功能，讓使用者能夠在資源非常有限的裝置上存取這些功能。

### 波特爾網路 {#the-portal-networks}

| 信標輕客戶端 | 狀態網路 | 交易八卦傳播 | 歷史網路 | 規範交易索引 |
| ------------------- | ---------------------------- | ------------------- | --------------- | -------------------  |
| 信標鏈輕量級 | 帳戶與合約儲存 | 輕量級記憶體池 | 標頭 | TxHash > 雜湊，索引 |
| 協定資料 | | | 區塊主體 | |
| | | | 收據 | |

## 預設的客戶端多樣性 {#client-diversity-as-default}

波特爾網路開發人員也做出了設計選擇，從第一天起就建置四個獨立的波特爾網路客戶端。

波特爾網路客戶端包括：

- [Trin](https://github.com/ethereum/trin)：以 Rust 撰寫
- [Fluffy](https://fluffy.guide)：以 Nim 撰寫
- [Ultralight](https://github.com/ethereumjs/ultralight)：以 TypeScript 撰寫
- [Shisui](https://github.com/zen-eth/shisui)：以 Go 撰寫

擁有多個獨立的客戶端實作增強了以太坊網路的韌性與去中心化。

如果一個客戶端遇到問題或漏洞，其他客戶端可以繼續順利運作，從而防止單點故障。此外，多樣化的客戶端實作促進了創新和競爭，推動了改進並降低了生態系統內的單一文化風險。

## 進一步閱讀 {#further-reading}

- [波特爾網路（Piper Merriam 在波哥大 Devcon 的演講）](https://www.youtube.com/watch?v=0stc9jnQLXA)。
- [波特爾網路 Discord](https://discord.gg/CFFnmE7Hbs)
- [波特爾網路網站](https://www.ethportal.net/)