-
Notifications
You must be signed in to change notification settings - Fork 75
Eth2.0 Implementers Call 4 Agenda #8
Comments
Can we discuss tests for ssz? Since, ssz is our serialization format (for now), we should have a set of tests that implementers can use to make sure that their implementation of ssz is correct. |
@Mikerah, I'm interested in this as well and started an issue with some ideas: ethereum/beacon_chain#115 |
@djrtwo This is Raúl from the libp2p team at Protocol Labs. I'm happy to jump on the call to discuss the libp2p daemon we're working on, in case that can be of help to the community. |
Thanks @raulk! We'd love to have you. Adding an item to the agenda |
I am suggesting two topics:
|
Thanks @AlexeyAkhunov. Adding both |
The reason AVL-style trees were not directly used in ethereum originally, aside from the fact that they are even more complex than Patricia trees and were beyond my understanding at the time I was making the spec, is that they do not have the property that every combination of keys and values has a single root hash, which makes all sorts of caching optimizations much more risky, as you have to remember what order to do updates in. Even things like warp sync formats would need to include the extra information. That said, one thing I think we could look into is using AVL trees on top of sparse Merkle trees. The key insight here is that we can use the sparse Merkle tree as the hashing format, as it's by far the simplest and most natural option there is, but then we can use all sorts of constructions for batching sparse Merkle tree nodes together in the DB, bounded-depth trees being one option. The nice thing about this approach is that we don't need to specify it at consensus layer; different clients can batch nodes in different ways. |
@AlexeyAkhunov For wire packets wouldn't it be better to stick with Simple Serialize ? Using RLP would lead to a pretty big performance hit compared to other serialization solutions |
@nisdas The main drawback of Simple Serialise is that it requires schema information for deserialising. that makes de-serialisation less efficient, and precludes a lot of generic tooling, like packet inspectors and rooters |
Yes, this is exactly what I am working on. I quantified that extra information, and it turns out to be 1.5 extra bit per key for "regular" AVL+ tree, and around 0.8 bit per key for what I call "left leaning" (or right leaning if you like) AVL+ tree. I want to do Proof Of Concept on how to store and update those structures efficiently |
I'd like to share a 3d visualization of beacon chain and shard blocks: https://beta.observablehq.com/@cdetrio/shasper-viz-0-4 |
The Merkle trie discussion got me thinking and I have a potentially silly question now. What prevents us from storing the state in a regular hash table governed by some a deterministic algorithm? This would make all look-ups fast, but the obvious problem is how to provide the merkle proofs. One solution would be build a binary Merkle tree over the slots of the hash table (i.e. you hash slot 0 and 1 together; then you combine the result of slots 0-1 and slots 2-3; then this result with the hash of slots 4-8 and so on). Under this scheme, given a current hash table size and a particular key, you'll be able to efficiently verify a compact Merkle proof. Some potential problems and benefits:
This is not a small list of problems, but are there any others? |
Eth2.0 Implementers Call 4 Agenda
Meeting Date/Time: Thursday 2018/9/27 at 14:00 GMT
Meeting Duration 1.5 hours
YouTube Live Stream Link
Agenda
The text was updated successfully, but these errors were encountered: