ethereum/sharding

https://tinyurl.com/eth2-handbook

Jacek Sieka

@arnetheduck

sure, for 13h.. is that number related to anything?

I wonder if we could compress it so it doesn't update when there's no finalization.. but I guess that would require some nasty book keeping instead

Danny Ryan

@djrtwo

Concretely, it provides direct access to 8192 blocks to contracts and beyond that the contract has to use the historic_roots and a proof to make claims

Jacek Sieka

@arnetheduck

er, not finaliation.. when there's no block

Danny Ryan

@djrtwo

the 13 hour is a compromise between easy access vs increased state size

Jacek Sieka

@arnetheduck

ah, and historic roots are unlimited..

Danny Ryan

@djrtwo

yeah, and grow very slowly.. :)

Jacek Sieka

@arnetheduck

could one make the argument that they should be purged at the weak subjectivity limit?

ie, I think of the weak subjectivity mostly as agreeing socially on a new genesis

Danny Ryan

@djrtwo

the historic roots?

Jacek Sieka

@arnetheduck

yeah

Danny Ryan

@djrtwo

also note that weak subjectivity period is dynamic depending upon the size of the vset due to the way validators ahve to queue to exit (thus boudning the % the v set can change)

I can rerun the calculation but the historic roots grows much slower than anything to be worried about (yeah, famous last words)

Jacek Sieka

@arnetheduck

taking screenshot

Danny Ryan

@djrtwo

😆

I think its 21KB / year..

and allows contracts to make claims about historic blocks and state in perpetuity

Diederik Loerakker

@protolambda

The 4M validator 1.0 second shuffle may be "fast", but we may be able to do better still. Idea (+ link to writeup) here; ethereum/eth2.0-specs#747

Wei Tang

@sorpaas

Regarding ssz: https://github.com/ethereum/eth2.0-specs/blob/dev/specs/simple-serialize.md#tuples-containers-lists
If I have a container who has fixed size of item, but one of the item is variable length. Is the outer container considered fixed length or variable length? And does it need the byte length prefix?

Paul Hauner

@paulhauner

Thanks to whoever added the v0.4.0 tag for consistency with the other tags :)

Diederik Loerakker

@protolambda

https://github.com/protolambda/zrnt

Danny Ryan

@djrtwo

If value is variable-length (i.e. embeds a list):

This means that you recursively need to check a type for any variable length list. If found, need to prefix length

Wei Tang

@sorpaas

@djrtwo That means the prefix length will be added multiple times, right? If I have something like A { a: B { b: C { c: vec<u8> } } } then for a serialization of A we'll find 4 prefix length?

Wei Tang

@sorpaas

But py-ssz says container is always length prefixed? https://github.com/ethereum/py-ssz/blob/2a4f436778a50ec2c66fb792676d34dae4e6849a/ssz/sedes/container.py#L35

tvanepps

@tvanepps

@djrtwo @hwwhww @vbuterin @arnetheduck @JustinDrake

where can I find the reasoning in the spec / ethresearch (technical / game theoretic) as to why the ETH can only be transferred 1 way from 1.0 to 2.0? (now including Beacon address transfers). Does it have anything to do with the 1.0 burner address generating a reciept for the new 2.0 address? can this receipt not be invalidated?

Danny Ryan

@djrtwo

The more we encumber the 1.0 consensus with 2.0, the more we tie the development and fork processes which would likely slow down the shipping/iterating on 2.0. It is not technically infeasible. It would require 2.0 light clients to be run by all 1.0 clients and some changes to the 1.0 consensus rules allowing for a similar burn/receipt method in the opposite direction. If we were to create fungibility, the path would be (1) release 2.0 beacon chain, (2) once stable beacon chain and light clients exist then require 1.0 clients to be light clients of 2.0 and finalize 1.0 with 2.0 and expose beacon chain state root to 1.0 (3) add additional consensus rules to 1.0 and 2.0 to handle the reminting on 1.0 with proof of burn on 2.0.

I think it would be detrimental to 2.0 development to demand fungibility out the gate. Over time as light clients are released and we begin to finalize 1.0 with 2.0 if the community wants fungibility, then we can assess proposals then.

@sorpaas What you’re seeing on the dev branch is some recent updates that have not been released yet and have not been integrated into py-ssz. These recent changes are reflected here https://github.com/ethereum/research/blob/master/spec_pythonizer/minimal_ssz.py

Yes, it would mean you have to add length prefix multiple times for these variable length containers

tvanepps

@tvanepps

@djrtwo awesome this answers it perfectly. I thought it might have something to do with the receipt. a lot of people were wondering about this, will be sure to spread

Danny Ryan

@djrtwo

Right, we can’t prove things about the beacon chain within the 1.0 chain until we force 1.0 clients to agree on the current state of the beacon chain (thus the light client requirement)

That’s why it logically falls after finalizing 1.0 if the community really wants it

Danny Ryan

@djrtwo

eth2 call this Thursday
agenda: ethereum/eth2.0-pm#31

Note, the call is still at 2pm UTC, but due to the recent time change in the US, this might fall at a different local time than it did previously. Please be mindful of this :)

Jacek Sieka

@arnetheduck

looking at lmd ghost in spec, it starts searching at a justified block. would it be right to say then that it can never switch to a different branch of the tree starting at the latest finalized block?

Danny Ryan

@djrtwo

a new justified block can be on a different branch than the previous justified block but must be in the same tree starting at finalized as the root

This is the source of potential “flip flop” attacks that have been discussed in the past

Jacek Sieka

@arnetheduck

yeah, but the lmdghost itself stays on one branch?

Danny Ryan

@djrtwo

ah, right. in just one run

you recursively walk up the tree finding a single branch to a head. Once you walk up and add something to your branch you never pull it back out in a subsequent iteration

In the scope of one run of LMD Ghost on a given tree and set of attestations

Jacek Sieka

@arnetheduck

so basically, when you receive a random block and start applying it to your latest finalized state, you might end up starting your search on a different branch, but that's it

Danny Ryan

@djrtwo

a different tree/set of attestations with the same finalized base might have you go up a different branch

Jacek Sieka

@arnetheduck

or in other words, any block you receive might change your view of what the justified state is

Danny Ryan

@djrtwo

yes, a new block might change your view of what the latest justified block is

Jacek Sieka

@arnetheduck

but if it changes what your finalized state is (for example if you were to apply it to some earlier finalized block you have), it's an invalid block and should be discarded..

Danny Ryan

@djrtwo

Let justified_head be the descendant of finalized_head with the highest epoch that has been justified for at least 1 epoch

Note here that it must be seen as justified for at least 1 epoch

if the new block is not in the tree starting at the latest finalized block, then you should discard it before even checking if it changed your finality

Jacek Sieka

@arnetheduck

trying to sort how many states we need to keep in memory here.. there are 3 reasonable candidates at least:

latest_finalized is the minimal thing you need because you'll be using this to check validity of blocks and replaying
latest_justified seems kind of useful - optimistically, this is what you'll use most of the time when selecting a new head
latest_seen again optimistically, most blocks will validate by applying to this one

it also seems that we maybe should be able to use latest_seen as latest_justified - this works iff the ghost choice is not affected by non-justifying block updates.. but is it?

Danny Ryan

@djrtwo

The latest justified state is what you need. DB accesses to get all the stuff you need would look something like:

finalized_block = db_get_latest_finalized()
justified_block, justified_state = db_get_latest_justified_from_finalized(finalized_block)
block_tree = db_get_block_tree_from_root(justified_block)
latest_attestations = db_get_latest_attestations(justified_state.validator_registry)
lmd_ghost((latest_attestations, block_tree), justified_state, justified_block)

The only thing you need from state is the validator set which is fixed from latest_finalized

but you can grab it from latest_justified (because it would not have changed since finality)

You have to pull yourself out of thinking about a single state when running the fork choice. It is against a block tree and a validator set’s latest attestations

Where communities thrive

People

Repo info

Activity