ethereum/sharding

https://tinyurl.com/eth2-handbook

Gregory Markou

@GregTheGreek

does anyone have a link to that massive diagram of the eth2 architecture?

terence tsao

@terencechain

this guy?

https://github.com/protolambda/beacon-schematic/blob/master/beacon_chain.svg

Gregory Markou

@GregTheGreek

ahh of course it was @protolambda 's doc

thanks @terenc3t

Diederik Loerakker

@protolambda

Lol, it's already a bit outdated. Will update it at some point. Not sure if I have time this weekend, dropped some things to go to Taipei for a few days, incl a meetup :)

Danny Ryan

@djrtwo

sneak peak of some sample state tests conforming to v0.5.0
https://gist.github.com/djrtwo/cd8250fee2d851895977627403e91401

tests follow this format ethereum/eth2.0-test-generators#21

Paul Hauner

@paulhauner

woo!

Jacek Sieka

@arnetheduck

nice! I like that it includes chain constants as well - I sometimes think these could be part of the wire handshake when connecting to a node as well. fwiw I had some trouble getting the bls lib accept all 0's as a point so we start our fake keys at 1 :)

(basically, when faking keys, we start the private key at one and derive pubkey from that, in the few tests we have)

Danny Ryan

@djrtwo

nice. These all have verify_signatures: false so shouldn’t be an issue, but we need a scheme for key pairs when we want to verify sigs in tests. so good to know to start a privkey = 1

Jacek Sieka

@arnetheduck

another practical hack: we store the priv key in withdrawal_credentials, so we don't need any "extra" data to access the it :)

Danny Ryan

@djrtwo

oh cool! I like that

Nishant Das

@nisdas

@djrtwo Hey when performing the handshake between two nodes should we enforce that the deposit contract address be required in the hello message ? i know it isn't part of the chain info but two nodes pointing to different deposit contract addresses should not be communicating with each other

Jacek Sieka

@arnetheduck

yeah. it's very practical, we should have that for the real network as well, will allow you to prove your withdrawal credentials from anywhere in the world, no extra hardware or annoying things to remember, the blockchain will store them in the cloud.

Danny Ryan

@djrtwo

@nisdas The configuration including the deposit contract is implicit in chain/network id.

yeah. it's very practical, we should have that for the real network as well, will allow you to prove your withdrawal credentials from anywhere in the world, no extra hardware or annoying things to remember, the blockchain will store them in the cloud.

😭🤣

eth2.0 call in ~11.5 hours
Reminder, although parts of the world have going through a time change, this call is still at 2pm UTC

terence tsao

@terencechain

Yay. 1 more hour of sleep for me

Gregory Markou

@GregTheGreek

wait no

what time is it at ?

nvm

Jacek Sieka

@arnetheduck

what's the most recent casper reference btw? or rather, that is closest to the spec?

Danny Ryan

@djrtwo

The mini spec on ethresearch. There are some academics doing a formal paper from the mini spec that we're working with. Expect this to be near complete within the month

https://ethresear.ch/t/beacon-chain-casper-mini-spec/2760

Jacek Sieka

@arnetheduck

:bow:

Danny Ryan

@djrtwo

The mini spec incorrectly does not make note of this tuple business (block, epoch), but this is covered in the wip paper

Paul Hauner

@paulhauner

@arnetheduck our keys are generated in the same fashion as yours

int_to_bytes46(i + 1)

Mikerah

@Mikerah

Where the zoom link at?

I just realized daylight saving changed these calls to 10 am EST

my bad.

Mamy Ratsimbazafy

@mratsim

You have 1 more hour

Gregory Markou

@GregTheGreek

So exciting

Danny Ryan

@djrtwo

eth2 call in 15 minutes:
agenda: ethereum/eth2.0-pm#33
stream: https://www.youtube.com/watch?v=zeceWlmxseY
youtube chatbox: https://www.youtube.com/live_chat?is_popout=1&v=zeceWlmxseY
zoom call: https://zoom.us/j/242800004

Mamy Ratsimbazafy

@mratsim

My EthCC slides on tests and simulation:

EthCC - Eth2 tests and Implementation.pdf

Talk: https://www.youtube.com/watch?v=6c4mQg5L6Rs

I also really encourage you to watch and get the slides from Justin: https://docs.google.com/presentation/d/1YdrJPGRLTK2FQLy9zS-8DRHFtPbVBwX1EhrDzXnULTY/edit#slide=id.g501dd075f4_0_497

https://www.youtube.com/watch?v=83DGZPJoyPQ

Jacek Sieka

@arnetheduck

@paulhauner I'm curious about those parallelization efforts.. intuitively, I feel a bit that it would be nice not to have to parallelize the beacon node processing itself perhaps, and rather use the cores for shards - naively this seems like it would decrease the amount of cross-core traffic etc, but I'm curious to hear more about the reasoning here?

Mamy Ratsimbazafy

@mratsim

I think state handling and the network part make sense to be on 2 different threads with one telling the other “request some blocks” and the other telling “oh by the way I received this block and those attestations”.

Paul Hauner

@paulhauner

@arnetheduck concurrency is very easy for us in these scenarios, we can just turn it on and off with a fairly minimal overhead. My thinking is that we have it avilable if you want it.

Mamy Ratsimbazafy

@mratsim

“concurrency is not parallelism”™

;)

Paul Hauner

@paulhauner

haha sorry!

you got me

We'll also run a separate thread for networking, like @mratsim said. It's a bit early for us to know what the final shape will be, but now we know how processing runs when it has access to multiple cores.

Hey @djrtwo, I was playing with your state tests and I can't natively deser this state because the public keys are invalid. As you know, we store pubkeys decompressed so part of our deser involves decompressing them.

I propose we use real pubkeys, generated from deterministic keypairs.

E.g.,

secret_key = int_to_bytes48(validator_index + 1)

(We add 1 because generating all all-zero pubkey seems to produce an invalid pubkey)

This also permits actual signature verification.

Where communities thrive

People

Repo info

Activity