<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
<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?
<telegram bridge> cem_ozer
It shouldnt matter where you receive the attestation as long as you know its valid imo
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
<telegram bridge> “hand delivered by snailmail to your server” 😂😂😂
<terence> As long as it's well aggregated. I'd take them 😆
If the original chain isn't added to Eth 2.0, wouldn't that wreck havoc for tokens, legacy accounts and smart contracts?
<djrtwo> youtube stream: https://youtu.be/pEdqjXO6euY
chatbox: https://studio.youtube.com/live_chat?is_popout=1&v=pEdqjXO6euY
agenda: ethereum/eth2.0-pm#85
zoom: https://zoom.us/j/219868180
chatbox: https://studio.youtube.com/live_chat?is_popout=1&v=pEdqjXO6euY
agenda: ethereum/eth2.0-pm#85
zoom: https://zoom.us/j/219868180
<GregTheGreek> that was lightning fast
<tooetoo> maybe were getting better at em?
This message was deleted
<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
<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)
<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.
sorry but to me
https://github.com/ethereum/wiki/wiki/Sharding-FAQ is not formal enough
and https://github.com/ethereum/eth2.0-specs/blob/dev/specs/core/1_shard-data-chains.md
doesn't describe the whole design
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
thx
<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
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
<telegram bridge> vbuterin
https://arxiv.org/abs/1710.09437
https://arxiv.org/abs/1710.09437