Do a comparison between execution clients based on Bedrock specifications

[InoMurko]

Do a comparison between execution clients based on Bedrock specifications

[InoMurko]

wip
I've been reading the docs and from what I can tell, the important features of the client that need to be supported is ETH2 ready, because of the support of API calls:

engine_forkchoiceUpdatedV1
engine_newpayloadv1
engine_getpayloadv1

Looking at Besu, Nethermind and Erigon - they're all ETH2 ready.

Next, P2P networking is strictly optional

DiscV5
eth/66

The last protocol implementation is eth/67 (https://eips.ethereum.org/EIPS/eip-4938#backwards-compatibility) but all still (only go-eth at the time of writting supports eth/67, erigon follows) support eth/66. And the changes are added so that they're backwards compatible.

[InoMurko]

As said, what would be useful is to see how we can compile erigon (or others) to mips: https://github.com/ethereum/go-ethereum/pull/23800/files

[wsdt]

Some things:

Nethermind:

• .NET Core (at least enables us to run the client in Docker containers as well as on Non-Windows OS (with .NET Framework, we would have needed specific versions, Docker EE, etc.), went through that pain a few years ago.

• C# in general much easier to learn, but since that the team is already used to Go, that wouldn't make much sense imho as it is a new ecosystem anyway.

Erigon:

• Go, from a purely economical perspective that alone is a strong argument for it, since the internal team already worked with Geth, and is used to Golang.

• Way more stars, etc on GH, seems to be more mature (way more commits), also less open issues, etc. than Nethermind.

---

Bedrock requirements:

• Erigon:

Simply based on GH issues by searching for post-merge/PoS: Looks already very good even without looking for the specific API calls mentioned in the Bedrock docs.

And based on their docs, they support these API methods as well:
https://github.com/ledgerwatch/erigon/blob/devel/cmd/rpcdaemon/README.md

For me personally this would be a no-brainer, but I definitely don't have all the information, since I don't know our infrastructure that well as you all do.

Happy for feedback, hope it helps.

[wsdt]

@InoMurko Could it make sense, to actually use the exact same Geth version Bedrock will be using to have a smooth as possible Bedrock migration and to migrate to another client after we successfully migrated to Bedrock? Or do you think, that this is fairly easy and comes without that many additional risks / potential delays?

Could be a (slightly) higher workload, but it could make things smoother, more stable, more secure and give us a faster time to market to not loose market share to Optimism or other Optimistic roll-ups at Bedrock launch. But yeah since client changes are close to non-existent seemingly, it could make sense to actually switch the client right away, happy for feedback!

[wsdt]

Erigon:
Building go project with GOARCH=mips should work (for my understanding we just need to add it in their release Makefile.
https://zchee.github.io/golang-wiki/GoMips/

Erigon itself has no documentation on that, but I requested Discord community access and opened a discussion on their GH.

They currently don't provide any binaries in general, so we need to build it ourselves anyway.
erigontech/erigon#4153

But I think compiling for Mips shouldn't be an issue (need to actually try this) since we are talking about a Go project here, and Go seems to support Mips out-of-the-box (plus that Geth built for Mips as well and just discontinued to do so, since xgo stopped supporting it).

Just asked in the Erigon Discord community: Got the confirmation that the Mips binary is even compiled automatically.

Happy for feedback.

[InoMurko]

Just asked in the Erigon Discord community: Got the confirmation that the Mips binary is even compiled automatically.

Where is that being done?

[wsdt]

you mean the compilation?

[InoMurko]

Aha, because you mentioned automatically, I thought it's done somewhere in their CICD.

[wsdt]

No they don't have any official binaries:
erigontech/erigon#4153

[InoMurko]

@wsdt can you fork Erigon, and make a circleci integration that compiles it to mips32?

[wsdt]

sure!

[wsdt]

@InoMurko just had a chat with Michael yesterday, he is also working on it. Just to keep you posted, that we both have a look at it.

[wsdt]

@mmontour1306 @InoMurko Just got the confirmation, that Erigon might NEVER support 32x architectures at all.

The issues Michael and me encountered, seem to be bugs/issues with libraries they are using. Would mips64 also be an option @InoMurko ?

Raspberry works with Erigon, so according to them mips64 might/should work. Need to try today.

[wsdt]

@InoMurko mips64 returns the exact same error messages for me, just asked in the Discord again.

Another question, why don't we simply use their Docker image?

[InoMurko]

FYI:
https://github.com/ethereum-optimism/minigeth/blob/c2b6152b4afb05e07514ad892304c117b2f72134/fetching-preimages.md

When run in prefetch mode, minigeth's role is to retrieve all the (hash -> preimage) mappings that are necessary to run the MIPS version of minigeth.

So the minigeth is a subset of geth:

As per cannon readme, minigeth is:

The pieces of geth needed to verify a block

See `../sync_minigeth.sh`, most of this is just geth and we can copy many of the files

The database has been abstracted in the `oracle/`, this does not use leveldb

Running on PC, it fetches all the required pieces of state from RPC.

Running on MIPS, it uses the oracle MMIO interface to get state based on hash.

So the question is - any idea which pieces prevent mips32?

[mmontour1306]

The Go language itself seems to have good support for a MIPS target, but it gets more difficult when you are trying to wrap a C library as is done with the cryptographic secp256k1 library. I have not been able to make that work while cross-compiling from my main desktop. I'm presently trying a native build of erigon inside my MIPS VM (last attempt ran out of disk space). It's slow and very memory-limited so I am not sure how far it will get.

64-bit might be an option, but the ultimate goal is to support a very stripped-down instruction set which can be implemented in an on-chain smart contract. That's probably easier with 32-bit registers.

[wsdt]

Really seems to be an issue also for both mips{32 and 64}

[InoMurko]

Really seems to be an issue also for both mips{32 and 64}

Is Erigon2 a rewrite or the same repo? What are the changes?

[wsdt]

Really seems to be an issue also for both mips{32 and 64}

Is Erigon2 a rewrite or the same repo? What are the changes?

https://erigon.substack.com/p/erigon-2-three-upgrades?s=r

Found this :-)

[InoMurko]

Let's see where Erigon brings us.