Moonbeam's Architecture in a Post-Merge World

Ecosystem
1

Moonbeam collators currently run a single client that is responsible for running the EVM in the runtime, and consuming shared security from Polkadot on the client side. This architecture is reminiscent of Ethereum’s in the PoW days. Incidentally Moonbeam was born in those days.

Now that Ethereum’s merge is complete, the Ethereum ecosystem has standardized around the Engine API (execution-apis/src/engine at 869b7f062830ba51a7fd8a51dfa4678c6d36b6ec · ethereum/execution-apis · GitHub) and every node is actually a consensus client and an execution client. This creates an excellent opportunity to start using more genuine Ethereum software while simultaneously reducing their own developer load.

Here’s the idea:

Forget all the pallet-evm, frontier, re-implemented-rpc api stuff. Instead maximally embrace the Engine API that is now standard in the Ethereum community. This allows collators to run any real execution layer client they want like geth or reth or wetf. The moonbeam devs no longer have to maintain the whole frontier stack. Their goal now is reduced to utilizing Polkadot’s consensus rather than the beacon chain’s. That is, the devs would implement the consensus side of the engine api. Instead of running a “normal” eth-ecosystem consensus layer client, like Lighthouse or prysm, collators now run the moonbeam consensus client which talks to Polkadot relay chain.

Bonus points for implementation: The consensus client is a fork of the polkadot node itself with an added service running that implements the consensus side of the Engine Api. While the old cumulus-based architecture embeds a relay chain node in the collator, the new approach embeds an Engine api in the relay chain node.

As a side bonus, this is a good chance to move away from the existing “nimbus consensus” engine that I wrote, because that name is now taken by an actual ethereum consensus client (GitHub - status-im/nimbus-eth2: Nim implementation of the Ethereum Beacon Chain) that is much better known.

3 Likes
2

Interesting–maybe this post would be appropriate for the Moonbeam Community Forum?

1 Like
3

Reading this before my morning coffee. But on the high level this sounds like an excellent idea because it would increase compatibility while decreasing technical depth significantly.

Once a PoC is available it would be interesting to compare it’s economics against other scaling solutions (esp. ZK).

Another good side effect I sense is that this makes it easier to grasp the concept for people unfamiliar with the Polkadot architecture.

1 Like
4

@JoshOrndorff on a second thought, how would things like custom pre-compiles integrate?

I mean even if this turns out infeasible for moonbeam, I think it is worth to think it further. Because these days to me this seems to be the practical way of doing fully Ethereum compatible rollups on Polkadot.

5

Was this done on purpose and not more out of desperation?

Polkadot consensus is based on re-execution. So, while you are right and on the parachain side you could probably use the ETH clients via the execution api, this will not work on the relay chain. And no, we will not ship any ETH client with the relay chain :wink:

1 Like