feat: agg-sender

[goran-ethernal]

Description

This PR implements the Aggsender component which is tasked of sending certificates to the agglayer using the interop_sendCeritificate rpc endpoint.

Config

Next code is an example of the Aggsender configuration:

[AggSender]
DBPath = "/tmp/aggsender" // path of the SQLite DB for the aggsender
AggLayerURL = "http://zkevm-agglayer" // URL to the agglayer
AggsenderPrivateKey = {Path = "/pk/sequencer.keystore", Password = "testonly"} // Aggsender private key that will sign the certificates before sending them to the agglayer
BlockGetInterval = "2s" // Interval for getting L1 blocks
URLRPCL2="http://test-aggoracle-l2:8545" // L2 node RPC URL
CheckSettledInterval = "2s" // Interval in which aggsender will check if sent certificates are settled
SaveCertificatesToFiles = false // indicates if sent certificates should be save to json files (for debugging purposes)

Required components (services)

The aggsender utilizes next components in the cdk repo to build a certificate:

1. L1 client to get L1 blocks - certificates are settled on agglayer one by CDK in a single L1 epoch (configured by the EpochSize in the config), so we need to know how many L1 blocks have passed so we can send another certificate.
2. L2 client - to get the last block on the L2. This is needed to know to which block we get claims and bridges on L2 to send them in a certificate.
3. L2 bridge syncer - to get bridges, claims and blocks on L2, needed for a certificate.
4. L1 info tree syncer - to build inclusion proofs.
5. Agglayer client - needed to send certificates to the agglayer, and check if sent certificates were settled on the agglayer.

DB

Aggsender saves sent certificates in its local SQLite db. It has one table called certificate_info in which it saves this data:

type CertificateInfo struct {
	Height           uint64                     `meddler:"height"`
	CertificateID    common.Hash                `meddler:"certificate_id"`
	NewLocalExitRoot common.Hash                `meddler:"new_local_exit_root"`
	FromBlock        uint64                     `meddler:"from_block"`
	ToBlock          uint64                     `meddler:"to_block"`
	Status           agglayer.CertificateStatus `meddler:"status"`
}

Height - is a simple counter of this cdk's certificates. We can look at it as a nonce. It gets incremented by sending and settling certificates.
CertificateID - certificates Hash.
NewLocalExitRoot - new local exit root posted through the certificate (gotten from l2 bridge syncer).
FromBlock - block from which we got bridges and claims on L2.
ToBlock - block to which we got bridges and claims on L2.
Status - certificate status on agglayer. It can be Pending (pending to be settled), Settled, or InError (if some error happens on certificate settling).

Flow

[vcastellm]

This is being kept hidden by the GithubUI but it's important #22 (comment)

[arnaubennassar]

plz revert the changes done in #140 before merging

[joanestebanr]

plz revert the changes done in #140 before merging

If we revert this PR we are going to have a bug if somebody calls bridgeAsset of Bridge Contract with param forceUpdateGlobalExitRoot=false.
I suggest:

• Keep this code until we have a better solution (think in that as a workarround) until contracts are updated as you suggest
• If we decide to delete this code we can implement a less efficient solution:
  • add a check to the synced Bridge and if have forceUpdateGlobalExitRoot=false prevent syncing this and keep in a 'waiting assets' lists on DB until appears a new bridgeAsset with forceUpdateGlobalExitRoot=true that then we can include the 'waiting assets list' .This suppose that in that in some moment there are going to be this call because the call updateGlobalExitRoot(), that is supported in feat: allow bridgeAsset with forceUpdateGlobalExitRoot=false #140 solution, is not going to allow to include this 'waiting asssets'.
  • Implement a polling pattern over the field LastUpdatedDepositCount that is a less efficent solution that the one on PR feat: allow bridgeAsset with forceUpdateGlobalExitRoot=false #140
• Don't implement any solution to the bug and just detect it showing an error and stopping syncing: it require an extra call because the flag is in calldata and we are not retreiving it, so the previous solution is better. Also require an extra call but then it works

We have to decide this point, reverting without any other solution (so introduce a bug) i think that is not acceptable.

[vcastellm]

add a check to the synced Bridge and if have forceUpdateGlobalExitRoot=false prevent syncing this and keep in a 'waiting assets' lists on DB until appears a new bridgeAsset with forceUpdateGlobalExitRoot=true that then we can include the 'waiting assets list' .This suppose that in that in some moment there are going to be this call because the call updateGlobalExitRoot(), that is supported in #140 solution, is not going to allow to include this 'waiting asssets'.

I like this solution, isn't this how it's supposed to work?

[vcastellm]

[sonarcloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
80.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

The PR have been reverted