This is incorrect, the verifier only needs to know the epoch boundaries
If you need the events in <B1…B33>, you’ll need B33 to become the source of the attestations. Which makes B65 the target. Voting will be done in the beacon chain blocks <B65…B96>.
So 2 epochs + the time it takes to reach supermajority attestations in the 3rd epoch.
Point taken about epoch boundaries…
Re: 2 epochs, I thought that’s what I said previously.
I think it is best we take this discussion out to DM and if need be a zoom call. My telegram handle is @raghavendra1980
Hi @seunlanlege, thanks for your research.
Could you explain "If all signature verifications pass, the verifier updates the bitlist for all the signers seen so far by computing S=S ∨ b " ?
The verifier can be made aware of attestations as they’re produced on the beacon chain. This way they maintain an “accumulator” bitlist of validator signatures they’ve seen so far.
Thank, it’s clear now.
On KZG commitments - do other commitments schemas with the same functionality exist? I mean, why KZG, could it be some alternatives?
Can be done with any commitment scheme, as long as it is additively homomorphic
@seunlanlege if i’m not mistaken, you suggest to count 2/3 of validators, but real consensus counts 2/3 of effective balances sum. Does it require to have another one list/commitment of balances and balances changes?
The effective stake for any validator is 32ETH, they need to bond a minimum of that amount to be activated, whether you count stake or validators, results would be the same.
I believe, validator leaves active validators set when it’s balance less than 16 eth. Until then, its vote accounted by get_total_balance() which sums all the effective balances.
@seunlanlege could you explain what for verifier makes B = B xor D?
What is the case when prover sends bitlist with pubkeys of disabled validators, which are already known by verifier as disabled?
xor removes the disabled validators in the bitlist, causing the SNARK to no longer verify.