Monorepo, VM: Polygon Support Analysis L2 (Level II: VM Execution)

[holgerd77]

Part of #1675

I did a lot of digging this morning to get a somewhat deeper understanding about what it's need to e.g. support block execution on the Polygon network as currently tested out by @cbrzn in #1689.

I think I got a somewhat clearer picture now, and this confirmed a bit my suspicion that this will need to be broken down into various preparatory sub-tasks to get closer here. Cesar, I guess we can actually stop the work on #1689 for now and concentrate on these subtasks, having something like #1689 to work is likely still 2-3+ months away. I will open up some new smaller issues during the week or comment on existing ones.

Polygon Overview

So, to Polygon:

Consensus

The Polygon sidechain uses a consensus mechanism called Bor (if I understand correctly the "Heimdall" stuff (see docs) is more for submitting updates from the "Bor chain" to the Ethereum main chain, so happening on another layer).

The Bor consensus is loosely inspired (building upon?) the Clique PoA consensus (which we have implemented). I guess we likely do not want to implement (?).

Action Items:

1. I guess what we want to take as an action item from this is that we want to get more robust on unknown consensus engines, so that we follow up on our stack (up to VM (client?)) what happens if a specific consensus engine defined in Common is not implemented. It might be already enough here to add some new test cases on this here and there, not sure. We mainly want to have a clear behavior (so that this works when block (consensus) validation is disabled, and gives a clear main error message when block validation is enabled.

2. For the L2 world encapsulating the consensus mechanism in Block and eventually Blockchain will be a big win and we therefore likely want to revive Block: Encapsulate Consensus Mechanism #1044 for the breaking releases. This will make it easier to swap out consensus, deactivate, eventually implement some fake consensus engines which somewhat mimic the original ones in a simple way but are easier to implement (so that consensus can at least somewhat simulated in a dev environment).

Genesis / State

There seems to be various system contracts on the Polygon chain (this is actually similar on the Optimism chain):

Action items:

1. We recently (I guess along the Merge work) have added the possibility to also add code + storage in genesis.json files in the Client (like the Pithos testnet genesis.json), we likely want to expand here to offer this functionality in Common as well (or eventually : replace the Client integration functionality), so that we can easier initiate a proper genesis state in these kind of situations e.g. for the VM.

2. If we want to support a scenario as made up in Cesar's PR VM, Block: Execute block on Layer 2 (Polygon Network) #1689 (running a Polygon block on the VM) this will likely be a lot easier to realize with a custom Ether-backed state manager which RPC-calls into a Polygon RPC endpoint to get the recent account and state data. We should take the occasion and consider an implementation along (after) the StateManager extraction (see Create standalone StateManager package #1599).

Gas Fee Mechanism

Polygon is using its MATIC token as the native gas token on the network. TBH it is not clear to me yet what this means for us on the implementation side.

---

Meta-reminder: All this is not necessarily only about Polygon but optimally about identifying improvment areas in our library set which will hopefully useful for various (EVM-based) L2 solutions. 🙂

[cbrzn]

Amazing, thanks for this :-D

Do you think it would make sense to close #1689 ?

[holgerd77]

Do you think it would make sense to close #1689 ?

Yes, I would think so for now. Eventually we can come back to that work - or some adoption of that - later down the road.