1014 large


toya · 于 发布 · 最后由 toya回复 · 850 次阅读

原文链接: https://www.reddit.com/r/ethereum/comments/58i8e0/update_on_hf_2_and_client_optimizations/

  • Geth的开发者正对客户端进行优化,这次优化会将一张代表账户存储的表直接存储在磁盘上,这会使账户leveldb读取时间从现在的O(log(n))时间减少为O(1)时间。目前的测试结果表明如果完成这个优化,处理账户的速度会增快5倍。这会是对客户端较大的一个改动(不像journaling那么复杂),因此不要期待这个变化明天就会出现,但是它会造成巨大的改变。
  • 一个对内存字典树缓存的相对简单的优化目前达到了提速大约30%的效果。
  • 我们在考虑修剪状态树的更简单的方法,这会使节点无需删除DB即可减少存储大小,因此可以从零开始快速同步。这会间接的减少处理时间。
  • 关于硬分叉的辩论主要围绕是应为实现EIP 158 第2节 还是(1c)(两个同时实现没有价值)展开。两个选项各有各的风险;第二节从EVM内部共识的角度来看更加复杂,而(1c)需要在geth中实现更彻底的重构,因为循环访问所有账户并非最初为所有节点设计的用途之一。
  • 我们在考虑增加重放保护,很可能是通过EIP 155或者一个通过把tx 随机数的上面的几个位元做为链ID的一些简单操作来实现,但是目前没有确定。

  • Geth developers are working on an optimization that will store a direct on-disk table representing account storage, allowing accounts to be accessed in O(1) leveldb reads instead of O(log(n)) leveldb reads as is the case now. Preliminary tests suggest a 5x speedup in processing account reads if this is done. This is a fairly large change to the client (not quite but almost as complex as journaling) so don't expect it out tomorrow, but it will make a large difference.

  • Simpler optimizations on the in-memory trie cache are achieving ~30% speedups.

  • We're looking at simple forms of state tree pruning to allow nodes to reduce their storage size without having to delete the DB and fast sync from scratch. This should increase processing time indirectly.

  • The main debate in the hard fork discussions is whether to implement EIP 158 with section 2 or with (1c) (there is little value in doing both). The two carry different risks; section 2 is more complex from an in-EVM consensus standpoint, whereas (1c) requires more substantial re-architectures in other areas of geth to implement, as iterating through all accounts is not a use case that needed to be supported in all nodes before.

  • We are considering adding replay protection, likely either EIP 155 or a simpler trick involving using the upper bits of the tx nonce as a chain ID, but nothing is yet finalized.