Skip to content
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

Open
wants to merge 8 commits into
base: develop
Choose a base branch
from

Conversation

AlexanderLukin
Copy link
Contributor

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 the processAttestation method is null? 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 the committees data structure if the algorithm skips this committee, it will mean that all attestations aggregated by this committee will be skipped.

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.
@AlexanderLukin
Copy link
Contributor Author

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.

@AlexanderLukin AlexanderLukin marked this pull request as ready for review February 6, 2025 09:16
Comment on lines 93 to 94
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,
Copy link
Contributor

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

Copy link
Contributor Author

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;
Copy link
Contributor

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

Copy link
Contributor Author

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.

src/duty/attestation/attestation.service.ts Outdated Show resolved Hide resolved
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants