Modular sequence sender

[arnaubennassar]

This discussion suggest changes to be done in the sequence sender component for it to become more flexible, and enable alt implementations and/or different functionalities

Splitting batch aggregation from sequence sending

The logic for waiting and handling L1 tx sending should be independent from the actual SC implementation:

// This function waits to receive a final proof from a prover. Once it receives
// the proof, it performs these steps in order:
// - send the final proof to L1
// - wait for the synchronizer to catch up
// - clean up the cache of recursive proofs
func (a *Aggregator) sendFinalProof() 

From all the steps performed by this function, the one that should be modularized is send the final proof to L1, actually it's more convinient to assume that L1 will always be Ethereum (or EVM based network), and split this step in two:

• Build the tx: step that should be modularized
• Send the tx: common step

The current implementation modularized should look like this:

package sequencesender

func (s *SequenceSender) tryToSendSequence(ctx context.Context, ticker *time.Ticker) {
	// ...

	// Current implementation:
	sequences, err := s.getSequencesToSend(ctx)

	// Proposed implementation:
	to, data, firstBatchNum, lastBatchNum, err := s.buildSendSequenceTx(ctx, sender)
}

// ------
package sendsequencetxbuilder // sequencsender/sendsequencetxbuilder/sendsequencetxbuilder.go

type SendSequenceTxBuilder struct {
	// state
	// etherman
	// ...
}

type Response struct {
	to *common.Address
	data []byte
	firstBatchNum uint64
	lastBatchNum uint64
}

func New(/*state, etherman, ...*/) SendSequenceTxBuilder

func (s *SendSequenceTxBuilder) BuildSendSequenceTx (ctx, sender) (Response, error) {
	// Implement a combo of what right now is:
	// 1. func (s *SequenceSender) getSequencesToSend(ctx context.Context) ([]types.Sequence, error)
	// 2. BuildSequenceBatchesTxData(sender common.Address, sequences []ethmanTypes.Sequence) (to *common.Address, data []byte, err error)
}

Sequence sender should receive the implementation of buildSendSequenceTx in the constructor.

This way, sequence sender should be agnostic to the underlying smart contracts, instead sendsequencetxbuilder should handle the relation between batch aggregation and SC specific logic. Still the ethtxsender abstraction is preserved for monitoring sending an monitoring L1