-
Notifications
You must be signed in to change notification settings - Fork 952
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Miscellaneous beacon chain changes—take 2 #218
Comments
I'm not certain [2] is as clean a simplification has advertised. Attestations still need to be added to |
Right. The merging is purely in the beacon blocks.
That's one reason, and [5] addresses that in a better way (IMO). |
I would say the right implementation of [2] would be to remove the concept of "specials" entirely, and instead explicitly have lists of attestations, deposits, voluntary exits, attester slashing messages, etc etc. This would also remove the weird de-facto dynamic typing of the list 😄 |
Generally agreed @vbuterin. |
this is for upgrades outside of forks? for forks, the fork versioning should be enough, but if we want to do this generally, it would be nice to do more generally than just |
Here's an explicit proposal for the ancestor hashes / accumulator @JustinDrake. Add two lists into the state:
Question: how is this concretely different from a DBMA? Is the difference that we should be building up a plain binary Merkle tree of hashes rather than power-of-2 hashes in the state, to make the witnesses at that point 32 bytes per tree level? |
Two differences:
(With 6-second slots, and after 32 years, Two advantages of DBMAs:
One disadvantage with DBMAs is that the permanent witness takes |
checked off number 7 in favor of #286 closing.. great work! |
(See #128 for take 1.)
slot
to the state. See Add slot number tostate
and make state transition function per slot #212.MAX_ATTESTATIONS_PER_BLOCK
logic can be encapsulated in the per-kind caps.) Also cleanly separates beacon block "headers" and "bodies".ancestor_hashes
is 1kB and consists of redundant data that clients can build for themselves. Smaller blocks, simpler consensus logic. Potentially putancestor_hashes
in the state. Addparent_root
to blocks in its place.SSZTreeHash
for everything. For objects it's much cleaner. For one-level-deep fixed size objects it's equivalent tohash
.The text was updated successfully, but these errors were encountered: