zkevm-pool-manager replacement

[vcastellm]

Background

Currently we're using a zkevm-pool-manager as a man in the middle process to rely transactions to the sequencer (relayer).

The zkevm-pool-manager was introduced in the stack with the following responsabilities:

1. Provide a central place to control and blocklist certain transactions
2. Allow to upgrade and restart the sequencer without stopping the mempool
3. Store an historic of the sent transactions in case the necessity to replay them

But these responsibilities have changed:

1. We control transactions using ACLs
2. Already achieving this due to the use of cdk-node
3. Storage will happen locally on the cdk-node storage

These are the following reasons to replace the current component:

• It's not documented, there's no info on the README.
• Code is a liability and it requires maintenance.
• We're forcing users to use the CDK in specific cloud providers or to have knowledge on complex and advanced DB operations.
• I'ts an "alien" component in the stack, as it's using Postgres storage and not the common storage in CDK, and it's an independent binary that should be run and configured independently, complicating operations.

Goals & Non-goals

• Define a path to abandon zkevm-pool-manager moving the logic to the cdk
• Do not define a distributed mempool

Proposal

The proposed first step is to move the zkevm-pool-manager code to the cdk repo and run it in the same CDK process.

Rename the component to relayer for a more acurate name of its purpose.

Second step is to refactor the Postgres storage with local SQLite storage as the other CDK components.

The throughput and the scalability of this component can be quite high for the majority of use cases, see https://wafris.org/blog/rearchitecting-for-sqlite

According to the current implementation transactions are never removed from the DB https://github.com/0xPolygon/zkevm-pool-manager/blob/9a725dcb2d66210fbdc8716c08257a0de7cae7c5/db/pooldb.go so it's also needed to implement the removal of transactions from the local DB periodically with a new config param.

Next steps

Remove the EVM specific mempool and replace it with a native cdk mempool

[rachit77]

Perhaps we should also discuss in detail the transaction eviction mechanism and the key factors that need to be considered, as the current pool-manager does not remove a transaction once it is stored.