djrtwo on dev
deprecate `BeaconBlocksByRange.… (compare)
djrtwo on dev
Update PROPOSER_SCORE_BOOST to … (compare)
@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?
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.
devbranch 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
eth2 call this Thursday
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 :)
trying to sort how many states we need to keep in memory here.. there are 3 reasonable candidates at least:
latest_finalizedis the minimal thing you need because you'll be using this to check validity of blocks and replaying
latest_justifiedseems kind of useful - optimistically, this is what you'll use most of the time when selecting a new head
latest_seenagain optimistically, most blocks will validate by applying to this one
it also seems that we maybe should be able to use
latest_justified - this works iff the ghost choice is not affected by non-justifying block updates.. but is it?
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)