我们很高兴地宣布，Nimbus 将加入以太坊基金会的 “门户网络” 团队，作为门户网络的启动客户端之一。 一句话总结：“门户网络”是一个开发中的跨客户端项目，为的是重新构想以太坊的轻客户端，并开发出一套可用且实用的轻客户端体验。 直接引用这份规范的表述：
特别地，我们的目标是与 EF 一道，围绕已有的以太坊协议，开发出一组新的以太坊协议，能专门服务于这种获取以太坊数据的新方法。 总体目标是为以太坊提供一个操作模式，能够服务于常见的使用模式，而不是实时追踪完整的状态（当前的客户端就是这么做的）。 我们正在讨论要开发的是一个用于钱包的完美客户端，一个极轻客户端，可以给网络作贡献，但又不要求同步区块链（也即是可以在离线之后重启即用，安装之后立即可用）。
因此，我们的一个最终目标是，将这种客户端直接敲入到 Status app 中。 它有潜力能提升我们用户的安全性和隐私性（我们也不再需要依赖 Infura 了），同时提高以太坊的可靠性，因为更多用户可以为网络的健康作贡献。 背景 门户网络根植于开发者 Piper Merriam 以及 Trinity 团队的初始目标：在现有的网络上开发一个轻量级的客户端。它的诞生是因为他们意识到了，现有的网络对于他们所设想的客户端类型来说不够灵活。 用 Piper 的话来说：
动机（轻客户端视角） 现有的 DevP2P LES 网络在设计上采用了 客户端/服务器 架构，轻客户端作为客户端，而全节点作为服务器端（到今天为止，“轻客户端” 这个术语指的都是现有 DevP2P LES 网络的一个客户端）。 因为这种架构把所有的负载都交给全节点来承担，而全节点的运营成本已经很高了，所以节点运营者就不愿意打开这个功能。 所以，虽然当前的网络设计很好地实现了其初始目标，但从轻客户端的视角来看，它是严重的失败。 我们如何解决这个问题呢？就像 Piper 的 Trinity 团队发现的那样，现实表明这个问题没有简单的解决方案。现有的网络不够灵活，无法做出高效的轻客户端设计。 修复这个问题需要我们回到一张白纸，重新设计协议的核心。 设计 一个轻客户端友好的网络，必须设计得节点只需付出少量存储空间、少许工作量，就能参与网络并为网络做贡献，而不是要求每个节点都必须承担很高的负载（即：在内存里保存区块链的完整历史）。 换句话来说，这样一个网络必须允许轻客户端在实际上为网络做出贡献，使得每当有额外的客户端加入网络，都会增强网络的容量。 具体来说，这意味着要提出一种网络设计，可以减少你的偶发请求的数据的验证开销，并降低在网络中传递消息的基本开销。
门户网络的目标是通过将以太坊协议的整体结构为三个独立的网络：Gossip（事务和区块）状态以及历史，来实现这一点；最开始的开发重心是状态网络。
这些网络将与 ETH 协议共存 —— 但不像 ETH 协议，它们不必是完全无懈可击的，但它们需要能几乎不间断工作。
愿望是这些新的网络，可以随着时间的推移，与现有的网络更加紧密地结合在一起。举个例子，我们可以设想这样一个世界：全功能客户端可以使用历史门户网络来为节点运营者提供额外的选择，仅存储他们关心的历史（可能也就 200 MB）而不是整条区块链（大于 200 GB）。状态数据也是如此。 总而言之，这个模块化的架构 —— 其中数据（状态和区块链历史）以 P2P 的模式来分享，而事务和区块则靠 gossip 来传播 —— 使得轻客户端可以自己选择 存储/服务 多少状态数据和历史数据。 当他们需要访问本地没有的数据时，他们可以在相关网络提出 ad hoc 请求（以一种类似于 BitTorrent 的方式，一个DHT用来发现这些被请求的数据）。 JSON RPC 备注 借用 Piper 的精彩文章 “设计可用的轻客户端 part 1”（中文译本）：大部分钱包，包括我们的，在JSON RPCAPI 上都是标准化的. Status 钱包的正确运行需要下列JSON RPC端点: 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 网络（Gossip）以跟踪链的顶端以及eth_sendRawTransaction访问链的历史（历史），用于eth_getTransactionReceipt 若可开启对状态、Gossip 和历史的轻量级访问，门户网络就打开了可嵌入钱包的轻客户端的大门，它们可以满足这些需求，而且不需要同步区块链，也不必牺牲隐私性和安全性。 这对现状来说是个很大的提升，现在我们不得不依赖于 Infura 来发起确定的 JSON PRC 调用（例如eth_gasPrice）并发送交易 —— 无法访问状态，我们就无法服务大部分 JSON PRC API，也无法发送交易，因为我们无法参与交易 gossip。 项目现状 fluffy将使nimbus-eth1客户端可以作为网络中的一个极轻客户端节点来运行。 初步的工作是开发Portal Wire 协议，这是一个建立在 Node Discovery v5.1 协议基础上的次级协议。 我们已经实现了对该协议的基本支持，并且几周以前，我们就已成功实现了与其它客户端的握手，包括ddht 客户端（一个用 Python 编写的门户网络客户端原型）和 Trin 客户端。 下一步 这需要 “桥节点” 为门户网络输入状态数据。当前的措施是使用一个 Nethermind 客户端插件作为定制化JSON-PRCAPI 来给愿意充当桥节点的门户节点提供数据。这一工作已经开始（规范草案在此）。 最终我们的极轻客户端将支持以太坊JSON-PRCAPI 的一个子集，所以钱包可以直接集成这种客户端。 资源 Nimbus 门户网络客户端（nlpn）可以在我们的 nimbus-eth1 代码库中找到：https://github.com/status-im/nimbus-eth1/tree/master/fluffyPortal Wire 协议已加入nim-eth代码库，作为节点发现协议 v5.1 的次级协议：https://github.com/status-im/nim-eth规范：https://github.com/ethereum/stateless-ethereum-specs/网站：https://www.ethportal.net/一些有关与 ddht 和 trin 的第一次 Portal Wire 协议测试的资料：https://gist.github.com/kdeme/36795f5deae7d02ce1785e9c7d501e53Piper Merriam 撰写的系列博文：The winding road to functional light clients有关这个主题的一个视频演讲注：方便的是，所有实现功能性轻客户端所必须的基础设施也会自然延伸到无状态客户端上，所以会跟无状态以太坊有很多交叉。实际上，让无状态客户端能够服务于绝大部分JSON-PRCAPI 是门户网络的诸多动机中最核心的一个。加入我们 如果你想为门户网络的设计和实现作贡献，请加入Ethereum R&D discord的#portal-network频道，有许多讨论正在进行中。还有一个每周的会议，安排在 UTC 时间每周二的下午 3 点，会讨论最新的开发进度和开放问题。如果你想加入 Nimbus 的开发中，我们欢迎你加入我们的 discord。 本文中的所有图片都应归功于Piper Merriam，都是从他的精彩演讲“民主化以太坊/以太坊核心协议：整体分解” 中取出来的。 原文链接: https://our.status.im/nimbus-fluffly/ 作者:0xmiel 翻译:阿剑—- 编译者/作者：EthFans 玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。 |
引介 | Fluffy 客户端：以太坊的极轻客户端
2021-07-02 EthFans 来源：区块链网络
LOADING...
相关阅读：
- Mike Novogratz – 以太坊可以超越比特币成为顶级加密货币2021-07-02
- Aztec 和 Ren 为比特币带来更多隐私2021-07-02
- AMA(译文)：Nerve跨链桥助力区块链项目入驻OKExChain生态2021-07-02
- 常用比特币地址数量下降超过 60%，创下六周新低。2021-07-02
- 中币行情看点：GalaxyDigitalCEO：以太坊有一天可能会超越比特币2021-07-02