Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 20:04

    JustinDrake on proposer-fix

    cleanups to get_seed 1) Put `d… (compare)

  • 20:04
    JustinDrake synchronize #1413
  • 20:00
    JustinDrake edited #1413
  • 19:59
    JustinDrake edited #1413
  • 19:58
    djrtwo closed #1371
  • 19:58
    djrtwo commented #1371
  • 19:57
    djrtwo review_requested #1413
  • 19:57
    djrtwo edited #1413
  • 19:57
    djrtwo synchronize #1413
  • 19:55
    djrtwo edited #1413
  • 19:53
    djrtwo edited #1413
  • 19:52
    djrtwo edited #1413
  • 19:50
    djrtwo edited #1413
  • 19:50
    djrtwo edited #1413
  • 19:48
    djrtwo opened #1413
  • 19:47

    djrtwo on proposer-fix

    typo Add domain_type to get_seed (compare)

  • 19:30

    JustinDrake on proposers

    Remove light client infrastruct… Fix lint issues Starting on phase 1 misc beacon… and 82 more (compare)

  • 19:30
    JustinDrake synchronize #1371
  • 14:55
    djrtwo edited #1411
  • 14:54
    djrtwo review_requested #1411
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<terence> Preston and I have the following concern:
<terence> We don't use attestations that are in the blocks for fork choice
<terence> It's likely that an attestation could be missing in its gossip domain but later showed up inside a block
<terence> Given that, we are thinking to track which attestation is procssed, and if there's an attestation showed up in the block which we haven't seen before, we'll apply fork choice for that
<prestonvanloon> yeah exactly, if we learn of an attestation we haven't seen before through a new block, why would we ignore this data for fork choice? Adding more information expands our view of the world and it doesn't make sense to ignore data because it's already been processed in a block
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<telegram bridge> cem_ozer (in reply to @terence)
<telegram bridge> Are you sure that’s correct? I believed that we applied any attestation that we receive over the wire, which is not a duplicate, to the fork choice
<terence> "attestation that receive over the wire" meaning it can be the attestations when we unpack the block?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<telegram bridge> cem_ozer
I think so
<telegram bridge> cem_ozer
It shouldnt matter where you receive the attestation as long as you know its valid imo
<terence> makes sense to me
<terence> I dont think we have this in the spec today
<djrtwo> Yeah, whether gossiped directly or inside a block or received hand delivered by snailmail to your server, you should incorporate the attestation into your fork choice. I suppose on_attestation should include a note that said attestations can come from any source
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<telegram bridge> cem_ozer (in reply to @djrtwo)
<telegram bridge> “hand delivered by snailmail to your server” 😂😂😂
<terence> As long as it's well aggregated. I'd take them 😆
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<prestonvanloon> thanks for clarifying
growl360
@growl360
Just to clarify but after sharding and POS, how will the original chain be deployed onto Eth 2.0? Will Ethereum start from fresh, slice up Eth 1.0 into the different shards or will it be added as a new shard onto Eth 2.0?
If the original chain isn't added to Eth 2.0, wouldn't that wreck havoc for tokens, legacy accounts and smart contracts?
Mamy Ratsimbazafy
@mratsim
The Nimbus team is in planes, I'm about to take off as well. I've put our updates in the agenda
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<djrtwo> Eth2 call in 80 minutes. Will share details shortly
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<djrtwo> call in 10
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<telegram bridge> shahankhatch
Wooo
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<GregTheGreek> wow
<GregTheGreek> that was lightning fast
<tooetoo> maybe were getting better at em?
This message was deleted
growl360
@growl360
qinDokey
Pooja Ranjan
@poojaranjan
Notes for Meeting 25
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<arnetheduck> re attestations, we process any incoming attestations the same, regardless of their provenance (block, gossip) - notably, the ones in the block seem good to have during startup when the pool is not yet seeded from gossip since we don't sync attestations
<arnetheduck> ^ @terence
<terence> that makes sense, I'm updating our beacon node to do the same. It does feel better to have the attestations in the block during start up (initial sync) to be accounted for fork choice
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<arnetheduck> we apply the same logic to blocks actually: doesn't matter where they come from (gossip, sync): they all go into a slush area until they've been linked to a parent and validated. at some point (we're at the gut-feeling stage still, so no well-researched algorithm, but happy to listen to ideas) it would be interesting to compare notes on strategies for managing these yet-to-be-validated blocks - though I suspect it's fine that we don't all do it the same way
<arnetheduck> and same for attestations: they only count if they've been validated, but we keep unvalidated attestations around "for a while" in case we manage to validate their parent block
<arnetheduck> (and consequently the attestation itself)
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

<Mikhail Kalinin [mkalinin]> We do it nearly same. Both attestations from blocks and gossip are counted by fork choice after they've been validated, it means that blocks should have parent and state root should match when block is applied to the state of previous slot which effectively the same as block inserted to the chain.

Although, fork choice spec doesn't do full attestation verification, it only runs checks against those parts which have meaning to finality, we think that only attestations that are valid enough to be included on chain should go to the fork choice.

Chris Lin
@ChrisLinn
hi all. is there any formal doc/spec/paper describing eth2.0 sharding
Mamy Ratsimbazafy
@mratsim
eth2.0-specs
Chris Lin
@ChrisLinn
Mamy Ratsimbazafy
@mratsim
the spec is currently focused on implementation. The design parts are disseminated in ethresear.ch and also the eth2.0-specs issues/PR
ideally a companion repo/document should be written that explains why the implementation is done this way but it does not exist.
For formal spec, the team that wrote KEVM is doing an impelmentation of the beacon chain in K at the moment
Chris Lin
@ChrisLinn
so there's no formal/published one i can refer to
thx
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<djrtwo> The phase 0 and phase 1 specs listed here come together as the spec but do not contain the rationale behind the design
Vitalik maintains this design rationale doc in conjunction -- https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view
I made this doc to help bring people up to speed on the phase 0 spec but it is not polished and incomplete on some sections -- https://notes.ethereum.org/@djrtwo/Bkn3zpwxB?type=view
<Samuel Furter> this Casper FFG paper from vitalik can be helpful as well: https://vitalik.ca/files/casper_note.html
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<telegram bridge> vbuterin
Here's the "paper" version of that:
<telegram bridge> vbuterin
https://arxiv.org/abs/1710.09437