本文主要介绍了作者计划构建一个高性能的SSZ(Simple Serialize) Rust实现,并通过基准测试套件,在真实的区块链数据上对不同的SSZ实现进行比较。目标是优化以太坊协议中的序列化过程,提高编码/解码的效率,并探索锁步编码和哈希等方法以进一步提升性能。同时,作者还计划构建一个SSZ基准测试套件,用于评估各种SSZ实现的性能,并以图表的方式直观地展示它们的性能差异。
构建一个基准测试套件,以便在真实的区块链数据上相互比较 ssz 的实现,并致力于一个高性能的 SSZ 的 Rust 实现。
序列化是在以太坊协议的生命周期中会发生多次的事情。 客户端使用它来本地存储数据,并通过网络传输数据结构(如区块、交易和共识对象)。 需要一个标准格式来共享以多种不同语言实现的客户端之间的数据,因为数据结构可能具有不同的内存表示形式。
最佳序列化至关重要,因为没有它,你的系统会随着时间的推移在编码/解码延迟方面付出无形的代价。 我想构建一个超级优化的实现来量化可以节省多少时间。 此外,我认为社区可以从拥有更好的工具来比较和测试许多 ssz 实现中受益。
首先,我想开发一个新的 ssz 的 Rust 实现,希望它比 ssz15 和 ethereum-ssz 性能更高。 我将进行一些基准测试和诊断测试,以缩小当前实现中可能存在的瓶颈,并在存在瓶颈时对其进行优化。 之后,我想尝试使用 SIMD 加速编码/解码,并尝试我所谓的“lockstep 编码和哈希”。 希望这些能带来显着的加速。
以太坊上序列化对象的端到端流程的一部分还包括一个后续步骤,即对序列化输出进行 Merkle 化(即哈希成树)。 目前,有一些库可以分别进行相当快速的编码/解码和快速的树哈希。 我有一种预感,通过将这两个步骤作为一个整体来考虑,可能会获得额外的好处,我想探索一个考虑这种情况的实现。
Keccak256 属于一类称为 Sponge 哈希函数的哈希函数。 这些 Sponge 函数的工作原理是:具有一个吸收阶段,其中任意长度的输入被分成 r 大小的块,并与某个状态 S 进行异或。最后,一旦所有输入块都被消耗掉,状态 S 将被挤压成所需长度的输出。
我想尝试在输入被编码时吸收它,每当准备好要被吸收时,就传入 r 大小的块。
这样我们就可以一次性完成编码和哈希! 即使稍微加快一点速度也很有意义,因为我们可以预期在协议的生命周期内多次执行此操作。
其次,我想构建一个 ssz 基准测试套件,以准确评估各种 ssz 实现的性能,并以可视方式展示它们彼此之间的性能。 我想添加漂亮的图表和有用的报告,以及差异火焰图,以比较在编码/解码步骤中,哪些包落后于其他包。
在第一阶段,我将花时间运行测试并对当前 ssz 实现的生态系统进行基准测试。 这是一个缓慢的开始方式,但应该是值得的,并且可以消除优化我自己的实现中的许多猜测。 我将设置一个工作流程,用于:
BeaconBlock
和 BeaconState
数据,以及一个基准测试套件将从我开始简化我的方法时进行的频繁测试中产生。 因此,我不会从一开始就专注于构建这个套件,而是尝试首先找到优化,然后“生产化”我的基准测试流程。
在此阶段,我将开始在各种 ssz crate(主要是 lighthouse 的)中寻找性能错误。 我希望做出有意义的贡献并提交一些 PR。 此阶段将说明,对于优化 Rust ssz crate 来说,向上游推送更改是否绰绰有余,或者重新设计是否可以在此处实现相当大的改进。
我将开始开发我优化的 ssz 实现,或者生产化基准测试套件。
优化优化的 ssz 实现和基准测试套件。
目前还不清楚差异火焰图如何用于比较不同的实现,即使它们实现了相同的 traits。
矢量化某些操作可能会使库难以维护和升级。
任何同步 Lockstep 编码和哈希的工具都可能会带来一些开销,从而消耗掉任何潜在的收益。
没有。
我还没有,但我想请 Potuz 或 Lighthouse 的某个人来指导我。
EF 协议 Wiki 升级以太坊:SSZ ssz15 Lighthouse rust ssz crate gohashtree 所有 ssz 实现
- 原文链接: github.com/eth-protocol-...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!