我们该如何设计网络，才能让客户端只需为网络贡献少量数据，就让整个网络具有很大的意义呢？
——PiperMerriam
我们很高兴地宣布，Nimbus将加入以太坊基金会的“门户网络”团队，作为门户网络的启动客户端之一。
一句话总结：“门户网络”是一个开发中的跨客户端项目，为的是重新构想以太坊的轻客户端，并开发出一套可用且实用的轻客户端体验。
直接引用这份规范的表述：
“门户网络”是一个还在开发的项目，为了让资源有限的设备也能轻量地访问协议。
“门户”一词的含义是，这些网络可以观察到协议运行的现状，但对核心的以太坊协议的运行又无关紧要。
门户网络将由一个或多个去中心化的点对点网络组成，这些网络共同提供暴露标准的JSON-RPCAPI所需的数据和功能.
这些网络是经过专门设计的,为了保证参与这些客户端只需付出最小化的网络带宽、CPU、RAM和机械硬盘资源即可加入。
Poly Network攻击者将100万枚DOWS分发给四个地址，并将730万枚FLUX转至新地址:7月6日消息，PeckShield监测显示，Poly Network攻击者已将100万枚DOWS分发给四个地址，并将730万枚FLUX转移到0x6c21开头的新地址，该地址最初由Poly Network攻击者转入0.3枚ETH。[2023/7/6 22:21:05]
“门户网络”一词也用来描述参与这些网络并暴露标准的JSPN-PRCAPI的软件.
特别地，我们的目标是与EF一道，围绕已有的以太坊协议，开发出一组新的以太坊协议，能专门服务于这种获取以太坊数据的新方法。
总体目标是为以太坊提供一个操作模式，能够服务于常见的使用模式，而不是实时追踪完整的状态。
我们正在讨论要开发的是一个用于钱包的完美客户端，一个极轻客户端，可以给网络作贡献，但又不要求同步区块链。
这也没有听起来那么困难。我想象大部分钱包都直接嵌入轻客户端，比如/img/20230515034028297731/1.jpg "/>
门户网络的目标是通过将以太坊协议的整体结构为三个独立的网络：Gossip状态以及历史，来实现这一点；最开始的开发重心是状态网络。
这些网络将与ETH协议共存——但不像ETH协议，它们不必是完全无懈可击的，但它们需要能几乎不间断工作。
愿望是这些新的网络，可以随着时间的推移，与现有的网络更加紧密地结合在一起。举个例子，我们可以设想这样一个世界：全功能客户端可以使用历史门户网络来为节点运营者提供额外的选择，仅存储他们关心的历史而不是整条区块链。状态数据也是如此。
总而言之，这个模块化的架构——其中数据以P2P的模式来分享，而事务和区块则靠gossip来传播——使得轻客户端可以自己选择存储/服务多少状态数据和历史数据。
当他们需要访问本地没有的数据时，他们可以在相关网络提出adhoc请求。
JSONRPC备注
借用Piper的精彩文章“设计可用的轻客户端part1”：大部分钱包，包括我们的，在JSONRPCAPI上都是标准化的.
Status钱包的正确运行需要下列JSONRPC端点:
eth_blockNumber用于跟踪链的顶端
eth_getBalance以及eth_getTransactionCount用于获得账户信息
eth_call用于读取合约信息
eth_estimateGas以及eth_gasPrice用于估计gas费
eth_sendRawTransaction用于发送用户的交易
eth_getTransactionReceipt在交易上链后获取回执
如果我们进一步梳理实现钱包功能的必要组件，我们可以得到如下更底层的需求：
访问账户以及合约存储项，以支持：eth_call、eth_estimateGas、eth_getBalance以及eth_getTransactionCount
访问gossip网络以跟踪链的顶端以及eth_sendRawTransaction
访问链的历史，用于eth_getTransactionReceipt
若可开启对状态、Gossip和历史的轻量级访问，门户网络就打开了可嵌入钱包的轻客户端的大门，它们可以满足这些需求，而且不需要同步区块链，也不必牺牲隐私性和安全性。
这对现状来说是个很大的提升，现在我们不得不依赖于Infura来发起确定的JSONPRC调用并发送交易——无法访问状态，我们就无法服务大部分JSONPRCAPI，也无法发送交易，因为我们无法参与交易gossip。
项目现状
我们已经开始为Nimbus开发一种操作模式，一开始命名为nlpn，但现在重命名为fluffy，会与以太坊1的客户端同时存在、运行。
fluffy将使nimbus-eth1客户端可以作为网络中的一个极轻客户端节点来运行。
初步的工作是开发PortalWire协议，这是一个建立在NodeDiscoveryv5.1协议基础上的次级协议。
我们已经实现了对该协议的基本支持，并且几周以前，我们就已成功实现了与其它客户端的握手，包括ddht客户端和Trin客户端。
下一步
下一步是通过PortalWire协议来传输数据。我们正在处理状态数据。
这需要“桥节点”为门户网络输入状态数据。当前的措施是使用一个Nethermind客户端插件作为定制化JSON-PRCAPI来给愿意充当桥节点的门户节点提供数据。这一工作已经开始。
最终我们的极轻客户端将支持以太坊JSON-PRCAPI的一个子集，所以钱包可以直接集成这种客户端。
资源
Nimbus门户网络客户端可以在我们的nimbus-eth1代码库中找到：https://github.com/status-im/nimbus-eth1/tree/master/fluffy
PortalWire协议已加入nim-eth代码库，作为节点发现协议v5.1的次级协议：https://github.com/status-im/nim-eth
规范：https://github.com/ethereum/stateless-ethereum-specs/
网站：https://www.ethportal.net/
一些有关与ddht和trin的第一次PortalWire协议测试的资料：https://gist.github.com/kdeme/36795f5deae7d02ce1785e9c7d501e53
PiperMerriam撰写的系列博文：Thewindingroadtofunctionallightclients
有关这个主题的一个视频演讲
注：方便的是，所有实现功能性轻客户端所必须的基础设施也会自然延伸到无状态客户端上，所以会跟无状态以太坊有很多交叉。实际上，让无状态客户端能够服务于绝大部分JSON-PRCAPI是门户网络的诸多动机中最核心的一个。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。