• 追踪区块链的最新区块

• 查看账户余额和 nonce

• 读取合约信息（如代币余额）

• 估算交易的 gas limit

• 发送交易

• 监控需要打包的待处理交易

大多数钱包都采用标准化的 JSON-RPC API。根据上述需求转化成的 JSON-RPC 端点如下所示：

• eth_blockNumber 用来追踪链首块

• eth_getBalance 和 eth_getTransactionCount 用来查看账户信息

• eth_call 用来读取合约信息

• eth_estimateGas 用来估算 gas limit

• eth_sendRawTransaction 用来发送交易

• eth_getTransactionReceipt 表示交易已经被挖出

如果我们更深入分析该功能的必备条件，就会得到更低一级的需求：

• 访问账户和合约存储以支持 eth_call、eth_estimateGas、eth_getBalance 和 eth_getTransactionCount

• 访问 gossip 网络来追踪链首块和 eth_sendRawTransaction

• 访问链上历史记录来获得 eth_getTransactionReceipt

因此，如果我们可以满足这些需求，就可以构建一个适合轻量级钱包的客户端，不需要同步，也无需牺牲隐私性和安全性。

如今的以太坊网络

目前，以太坊客户端可以在以太坊协议和 LES DevP2P 协议之间进行选择。

LES 协议采用服务器 / 客户端模型。在该模型中，数据会根据要求从服务器流向客户端。该协议不允许客户端通过任何有意义的方式返回数据，这点可以从协议状态看出。根据我的经验来看，LES 协议中的服务器和客户端在数量上严重失衡。运行服务器的成本很高，现有服务器的数量不足。这就导致 LES 变得不可靠，而且经常会变得完全不可用。

以太坊协议则另有缺陷。该协议很好地达到了目的，确保网络中所有的节点都尽可能地复制了完整的历史记录和状态数据。这对客户端的要求很高。网络中的每个节点都必须保存完整的历史记录和状态。没有保存这些数据的节点不太可能保持健康的点对点连接，可能会在无法满足对等节点的数据要求时断开连接。

在本系列文章中，我们想要解构以太坊协议这一 「庞然大物」。该协议包含了我们理想的客户端类型的所必备的一切功能。它的设计适合全节点和矿工，但是不适合我们所概述的轻量级客户端。

解构以太坊协议

让我们将目光转向以太坊协议……

我们需要解决这个问题。在与以太坊协议交互时，人们可选择的方式有限，而且高度依赖中心化提供商。当前的网络状态就预示了未来可能发生的情况。 (责任编辑：admin)