该项目旨在解决当前以太坊Execution Layer的JSON RPC API (JRA) 标准化不足的问题,通过创建一个REST API规范和一个JRA包装器的参考实现来改进。项目包括迭代JRA,发现Execution客户端的特性,制定REST API规范,并提供通用Execution客户端基础设施访问。最终目标是实现可预测和标准化的REST API,并提供相关的测试套件和EIP。
JSON-RPC 也能做到,对吧。
主副本位于:https://github.com/tsujp/suisu/blob/master/epf/project_proposal.md
当前的 JSON RPC API (以下简称:JRA)受到不完善的标准化和每个执行节点的临时扩展的影响,导致难以使用且紧密耦合的应用程序。如果 Ethereum 的目标是一个分布式且与实现无关的协议,那么当前的 JRA 虽然取得了巨大的进步,但目前未能满足这一要求。
对 JRA 进行进一步的标准化改进(例如 EIP-1474)可能 会缓解这些问题,但鉴于 Beacon 链实现了 REST API,这代表了一个很好的机会,可以通过 REST API 规范和参考 JRA 包装器实现来解决当前执行 JRA 的不足。这两个组件将(提议)扩展执行 API 协议。
该项目需要 3 个主要领域:
该项目的性质要求这 3 个领域同时且迭代地进行,因此需要 在这些项目领域之间进行仔细的组织和同步。这可以被认为是一个循环,项目时间线包括尽可能多的循环迭代。
在主项目循环之前,将对 JRA 的各个领域进行 T 恤尺寸估算,并对要转换为 REST 规范的方法进行大致的攻击顺序。
一般循环过程是:
选择 JRA 的子集来开发 REST 规范。最初,这将是最简单的明确选择,直到所有 3 个领域都建立起来,届时将根据预先的估计计划进行临时选择。
为(1)开发 REST 规范,并特别记下 JRA 或 REST 规范中任何预测的未来后果和/或受影响的项目。
为(2)实现参考 API 表面;为此选择的堆栈是 Varnish 的 VCL 配置,如果需要(或代替),则使用 Zig 编写的 API。
使用执行客户端后端为(3)实现测试,即调用在测试网和主网上运行的实际执行客户端(任何事务性端点都将仅限于测试网)。
最初,规范将与参考实现(计划用于 Varnish 的 VCL 配置)同步开发,因为进入 REST 规范的第一个 JRA 方法将是最简单的。
通过在 REST 中指定并包装更简单的 JRA 方法,将启动一个自动测试套件,以确认参考实现满足其自身规范的能力。这将包括来自生态系统提供商、测试网等的各种执行客户端后端,以针对其进行 JRA 调用。
第 1 周和第 2 周涉及试验包装复杂性以及可以实现的 REST 端点,包括任何更改。这有助于制定一个粗略的 地图,说明要处理的内容以及处理的顺序。
第 3 周专门用于开发测试工具,因为开发的主要手段是迭代地实现所选的 REST 规范并立即且持续地测试该实现;因此需要一个测试工具。
对于项目的其余部分:
可能 @Amit0617。
@lightclient
组合并缩写两个词(不注意语法)并进行罗马化以方便拼写,得到:쉬수 (Suisu)。
- 原文链接: github.com/eth-protocol-...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!