feat: rpc client support op-node finality

[joanestebanr]

Description

The goal is that aggsender use last finalized block as finality but currently the RPC of L2 is not able to respon to last finalized block. This information is provided by op node using call optimism_syncStatus.

Add a way to choose the kind of L2 RPC client:

• basic: directly a RPC client
• op: it when you ask for last finalized block do a call to a op_node using rpc method: optimism_syncStatus to get it

Configuration

• Remove old L2URL configuration fields:

  • ❌ AggOracle.EVMSender.URLRPCL2
  • ❌ AggSender.URLRPCL2

• The simplied version of configuration remains the same: setting L2URL it's enough:

  • The L2URL is the legacy configuration parameter
  • It is inserted in another variable called L2RPC: L2RPC = "{ Mode= \"basic\", URL= \"{{L2URL}}\" }"
  • This variable is set in Common.L2RPC

[Common]
NetworkID = 1
IsValidiumMode = {{IsValidiumMode}}
ContractVersions = "{{ContractVersions}}"
L2RPC = {{L2RPC}}

• The full configuration have some changes:
  • The L2 client is defined in: Common.L2RPC that is a struct that can be:
    • • basic: L2RPC = { Mode= "basic", URL= "http://localhost:8123" }
    • • op: L2RPC = { Mode= "op", URL= "http://localhost:1111" , OpNodeURL ="http://localhost:2222" }

By default is:

L2RPC = "{ Mode= \"basic\", URL= \"{{L2URL}}\" }"

[vcastellm]

Removing URLRPCL2 and replacing with L2RPC is great and makes sense, but I feel that the "Mode" adds unnecessary complexity and it's kind of not abstracting what is necessary.

We need to abstract the "FinalizedL2Block" call, in a way that the underlaying implementation is not aware of the node.

Wouldn't it be more easy to just have an interface that declares HeaderByNumber and instantiate either a normal eth client or an op-node client depending on the case?

[vcastellm]

What happens here when an op mode is used in the L2RPC config? isn't the ethRealClient nil and not configured?

[joanestebanr]

the opnode is only used to get the finalized block, the rest of calls are send to the regular eth client

[joanestebanr]

Removing URLRPCL2 and replacing with L2RPC is great and makes sense, but I feel that the "Mode" adds unnecessary complexity and it's kind of not abstracting what is necessary.

We need to abstract the "FinalizedL2Block" call, in a way that the underlaying implementation is not aware of the node.

Wouldn't it be more easy to just have an interface that declares HeaderByNumber and instantiate either a normal eth client or an op-node client depending on the case?

The implementation is to simplify impact in code. The current client can be use by any component that receive a ethClient. So if would fix, not just aggsender issue, also the rest of syncer,etc... So, from my point of view, it's the best abstration possible because it's transparent to rest of code.

The mode is to decide which kind of eth client is required. a 'basic' it's the legacy one, just a call to the RPC configured. But in mode op you need to do a call to op-node to get the latest finalized block but the rest of calls are execute by the regular eth client. Setting explicity recude the possibility of miss configuration

[goran-ethernal]

LGTM

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[vcastellm]

LGTM