簡介
Portal Network（門戶網絡）旨在讓資源較為有限的設備通過輕量級的方式訪問協議。顧名思義， 所謂的“門戶”，就是指這些網絡只能提供協議的 視圖，但是對於以太坊核心協議的運行來說並不重要。
Portal Network 將由一個或多個去中心化的點對點網絡組成，這些網絡共同提供標準JSON-RPC API 所需的數據和功能。這些網絡經過專門設計，確保客戶端只需使用最少的帶寬、CPU、RAM 和硬盤資源即可參與進來。
Portal Client（門戶客戶端）指的是參與這些網絡並暴露標準JSON-RPC API 端口的軟件。
動機
Portal Network 旨在實現兩個相互關聯的目標。
無狀態客戶端
以太坊核心協議正在朝著“無狀態” 區塊驗證模型的方向發展。在這個模型下，客戶端使用見證數據（witness）就可以完全驗證區塊的執行。這樣一來，客戶端將不再需要保存任何以太坊“狀態”數據。對於以太坊核心協議來說，這種客戶端具有很大的價值，有助於推動Eth1 和Eth2 更好地合併。
如需進一步了解為什麼無狀態對於Eth1/Eth2 合併如此重要，建議閱讀：https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html
容易被忽略的是，如果沒有額外的基礎設施，這種“無狀態” 客戶端幾乎做不了其它事情。具體來說，它無法為絕大多數JSON-RPC API 提供服務。 Portal Network 恰好能填補這一空缺，讓無狀態客戶端也能公開支持Web 3.0 生態的外部API。
可擴展型輕量級客戶端
“輕客戶端” 通常指現有的DevP2P LES 網絡的客戶端。這個網絡採用客戶端/服務器架構設計。 LES 網絡的總容量由網絡中的“服務器” 數量決定。為便於網絡擴展，“服務器” 容量必須增加。也就是說，在任何時候，一旦網絡負載超過網絡總容量，就會導致全網服務降級。因此，LES 網絡在接近滿負荷運行時是不可靠的。
Portal Network 旨在從網絡設計的角度解決這一問題，讓每個新加入該網絡的客戶端都能增加網絡的容量。隨著越來越多節點加入該網絡，網絡會變得更加健壯和強大。
擴展閱讀：https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/ (中文譯本）視頻講解：https://www.youtube.com/watch?v=MZxqRs_tLNs
網絡功能
狀態：賬戶和合約存儲項
狀態網絡有助於按需檢索以太坊狀態數據。
節點能夠選擇它們想要存儲和分享的狀態，網絡應該提供一種方法來辨別應該向哪些節點查詢所需的狀態數據。這樣一來，無論多小的節點都可以為維護網絡的健壯性貢獻一份力量。
網絡的運行依賴於接收新狀態以及根據新區塊更新狀態。充當狀態提供者的全功能“橋” 節點負責從主網搬運這些數據到門戶網絡上。因此，即使只有少量橋節點，網絡也能保持健康。
從網絡中查詢和讀取數據的速度應該滿足人為錢包操作（如估算交易所需的gas 費或從合約中讀取狀態）的需求。
鏈歷史：區塊頭、區塊和收據
為了驗證從Portal Network 求得的數據，門戶客戶端要能獲取區塊頭並驗證它們是否存在於主鏈上。客戶端可以使用經過驗證的區塊頭進一步驗證區塊、叔塊、交易、收據和狀態節點。
普通客戶端將下載每個區塊頭來構建一條主鏈。對於“無狀態” 客戶端來說，這是不合理的。 “雙批默克爾日誌累加器（double-batched merkle log accumulator）” 機制可以讓門戶客戶端免於下載屬於主鏈的每個區塊頭。
當門戶客戶端請求某個區塊頭時，一起返回的還有兩個累加器證明。只要客戶端（通過gossip 網絡）保存鏈頭的最新視圖，就可以使用累加器證明來驗證區塊頭是否包含在合法的鏈上。然後，客戶端就可以使用區塊頭來驗證從Portal Network 檢索到的其它數據。
Portal Network 的設計模擬了以下以太坊協議消息，支持通過 block_hash 檢索以下數據。
以太坊協議Portal NetworkGetBlockHeaders -> BlockHeadersblock_hash -> 區塊頭和包含證明GetBlockBodies -> BlockBodiesblock_hash -> 區塊體GetReceipts -> Receiptsblock_hash -> 區塊收據
主鏈索引：按哈希值檢索交易和按編號檢索區塊
為了服務 eth_getTransactionByHash 和 eth_getBlockByNumber JSON-RPC API 端點，客戶端在同步整條鏈的時候通常會創建本地索引。 Portal Network 需要模仿這些索引。具體做法是，為交易和區塊生成唯一的映射，然後再將它們發佈到Portal Network 上。
由於有效交易也有可能存在於特定區塊之外，我們需要一種機制來證明交易包含在特定區塊內。同樣地，有效區塊也有可能是叔塊，但是沒有證明能表明它們包含在主鏈上。因此，還需要一種機制來驗證某個區塊是否位於主鏈上的某個區塊高度（而不是一個叔塊），以及一筆交易是否包含在某個合法區塊內。
以下映射存儲在Portal Network 上，與累加器一起發揮合法索引的功能。
主鏈區塊索引：block_number -> (block_hash) 。獲取與block_hash 相關的區塊頭並利用累加器驗證該區塊頭中的 block_hash 是否對應某個block_number。
主鏈交易索引：tx_hash -> (block_hash, tx_index)。獲取與block_hash相關的區塊頭，並利用累加器驗證該區塊頭。然後，獲取與該區塊頭相關的區塊體，並驗證 tx_hash 是否與交易樹中通過 tx_index 找到的交易匹配。
交易發送：合作式交易gossip 傳播
交易gossip 網絡旨在確保礦工能夠獲取所有新交易，以便將它們打包進區塊中。
無狀態客戶端要能基於其所擁有的資源聲明它們想要處理的交易量在所有未被打包上鍊的有效交易（即交易池）中的佔比，而且只能從其它節點那裡獲得這些交易。
無狀態交易驗證包括驗證賬戶的餘額和nonce，因此網絡在傳播每筆交易時需要附上賬戶證明。
網絡規範
基於DiscoveryV5 的uTP狀態網絡新狀態數據的可擴展gossip 傳播：https://ethresear.ch/t/scalable-gossip-for-state-network/8958/4 （中文譯本）鏈歷史網絡暫無規範之前的研究：https://notes.ethereum.org/oUJE4ZX2Q6eMOgEMiQPkpQ?view之前用Python 寫的概念證明：https://github.com/ethereum/ddht/tree/341e84e9163338556cd48dd2fcfda9eedec3eb45這個概念證明並不代表最後的目標。它融合了目前還無法在實際實現中應用的機制，尤其是“廣告” 系統（已經被證明是巨大瓶頸）和SSZ 默克爾根系統（原本用來解決大數據傳輸問題，現在我們打算使用uTP來代替它）。交易gossip 傳播：暫無規範之前的研究：https://ethresear.ch/t/scalable-transaction-gossip/8660
原文鏈接:
https://github.com/ethereum/stateless-ethereum-specs/blob/master/portal-network.md
作者: namrapatel
翻譯&校對:
閔敏& 阿劍
APP 
