-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: new attestations calculation algorithm #270
base: develop
Are you sure you want to change the base?
Conversation
Implement a prototype of the new algorithm for attestation calculation to support the new attestation data format introduced in the EIP-7549 that will be added to the next Pectra hardfork.
As attestations for slots in all epochs except the current epoch and the previous epoch are already handled during previous app cycles, we now exclude these attestations from processing. So, the logic of attestation processing is kept the same as it was before. Also, update the `@lodestar/types` lib to support Pectra hardfork types.
Add backward compatibility of the attestation calculation algorithm with pre-Pectra forks. So, the app should work normally on the chain before Pectra and after Pectra without any changes in app code or in configs. Now information about fork epochs is fetched from the CL node instead of setting it in the env variables or hard-coding these epochs for known chains.
UPD Add backward compatibility of the attestation calculation algorithm with pre-Pectra forks. So, the app should work normally on the chain before Pectra and after Pectra without any changes in app code or in configs. Now information about fork epochs is fetched from the CL node instead of setting it in the env variables or hard-coding these epochs for known chains. |
dencun: spec.DENEB_FORK_EPOCH != null ? parseInt(spec.DENEB_FORK_EPOCH, 10) : Number.MAX_SAFE_INTEGER, | ||
pectra: spec.ELECTRA_FORK_EPOCH != null ? parseInt(spec.ELECTRA_FORK_EPOCH, 10) : Number.MAX_SAFE_INTEGER, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would be better to have deneb
and electra
to be consistent with response here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I agree. I've renamed forks in all application symbols.
|
||
const forkEpochs = await this.clClient.getForkEpochs(); | ||
const isDencunFork = epoch >= forkEpochs.dencun; | ||
const isPectraFork = epoch >= forkEpochs.pectra; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be smth like this:
const attestedSlotInEpoch = attestation.includedInBlock // slotsPerEpoch;
const isPectraBlock = attestedSlotInEpoch >= forkEpochs.pectra;
Also isDencunFork
should be re-reviewed. Here might be a bug
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're correct, that's a good finding, thank you. I've fixed this in the code.
As the `AttestationService` fetches attestation for the epoch that is processed on the current EVM cycle and for the epoch that was processed on the previous cycle, an epoch in the `this.processedEpoch` does not correctly reflect the epoch of the attestation that is currently processed. So, the logic of how fork is determined worked incorrectly for some attestations. Now this bug is fixed and the fork is now determined using the slot of each particular attestation.
Rename "dencun" to "deneb" and "pectra" to "electra" in all symbols.
Move common code in the attestation calculation logic to a separate `processAttestationCommittee` method.
Round down an epoch number in the attestation processing algorithm.
Implement a prototype of the new algorithm for attestation calculation to support the new attestation data format introduced in the EIP-7549 that will be added to the next Pectra hardfork.
Some useful links that illustrate new data format and calculation rules
Open questions:
What to do if the
committee
in theprocessAttestation
method isnull
? In the previous version of this algorithm, it just skipped that attestation and went ahead. But in the new version of the algorithm, if a committee doesn't exist in thecommittees
data structure if the algorithm skips this committee, it will mean that all attestations aggregated by this committee will be skipped.