简介
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 
