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.
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?
@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?
What is the motivation behind the proposed SNARK-based protocol for verifying the Ethereum Beacon chain’s Casper FFG consensus proofs, and how does it offer a more secure and trustworthy alternative to the sync committee?