Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 20 23:48
    Inphi opened #2898
  • May 20 19:37
    djrtwo edited #2896
  • May 20 19:37
    djrtwo edited #2896
  • May 20 19:34
    djrtwo edited #2896
  • May 20 19:18
    djrtwo synchronize #2896
  • May 20 19:18

    djrtwo on dev

    deprecate `BeaconBlocksByRange.… (compare)

  • May 20 19:18
    djrtwo closed #2856
  • May 20 19:16
    djrtwo edited #2896
  • May 20 19:15
    djrtwo synchronize #2896
  • May 20 19:15

    djrtwo on dev

    Update PROPOSER_SCORE_BOOST to … (compare)

  • May 20 19:15
    djrtwo closed #2895
  • May 20 19:14
    djrtwo commented #2895
  • May 20 14:05
    fradamt commented #2895
  • May 20 14:04
    fradamt commented #2895
  • May 20 14:04
    fradamt commented #2895
  • May 20 13:48
    fradamt commented #2895
  • May 20 09:58
    casparschwa commented #2895
  • May 20 09:51
    casparschwa commented #2895
  • May 20 06:42
    fradamt commented #2895
  • May 20 00:53
    adiasg commented #2895
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
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
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
(let me know if that helped at all..)
terence tsao
@terencechain
man… I forgot we are starting from justified_head. I passed in finalized_head for some reason and no wonder benchmark has been kinda slow :cry:
Danny Ryan
@djrtwo
should be an easy fix :)
terence tsao
@terencechain
I think I’ll save the last justified state and last justified block in DB as well
or implement db_get_latest_justified_from_finalized(finalized_block)
how do we get justified block from a finalized block from traversing the dag?
Danny Ryan
@djrtwo
I would cache the justified blocks in DB when you find them in regular block processing. You just want to make sure the ones you pull have latest_finalized in the tree (you could do this by pruning out justified block refs from db whe nyou finalize, or by passing in this finalized block and filtering justified blocks you pull from db such that they have finalized block in the chain)