Hacker News new | ask | show | jobs
by thinkmassive 1889 days ago
bitcoind is the most used implementation by far, but there are others that work fine, like btcd

The more significant difference seems to be Ethereum is far more complicated (a Rube Goldberg machine, as critics like to say) and has trouble coordinating hard forks.

A hard fork of Bitcoin is considered a different network, so it’s no longer an issue.
1 comments
derefr 1889 days ago
The real problem with Ethereum client code, is that almost everyone just starting to work on it — and even some people who've been at it for a while — are under the mistaken belief that Ethereum itself is a 100% formalized system, because the Yellow Paper formalizes the behavior of the EVM. They think that as long as their EVM follows the spec, they can't possibly accidentally calcluate a wrong state and end up out-of-consensus with the network.

However, there are (many!) stateful things that happen during Ethereum block-ingestion that occur outside of contract bytecode execution (i.e. not modelled by the EVM abstract-machine.) So even if you implement your EVM "to spec", there's this whole surrounding edifice of block-processing code that has no spec, that everyone's just guessing and "following the leader" on.

IMHO Ethereum badly needs a "Yellow Paper 2" that takes a step back and formalizes the whole block validation+execution flow. On top of that, there could be a C FFI spec for implementations of a "block processor" to follow, with type declarations for the ADTs such a library would consume/produce — making them into, essentially, plugin libraries (where any Ethereum node implementation could plug in any Ethereum block processor engine implementation.) Think "web browser" vs. "rendering engine" (where the "scripting engine" — i.e. the EVM — is just one part of the "rendering engine.")

If such a formal block-processor plugin interface existed, an Ethereum "node" could then just consist of the storage engine, the consensus engine's policy layer (while needing to rely on standardized consensus machinery existing within the block-processor), the P2P protocols, and the RPC backend. I.e., infrastructure code.

Powerfully, this would mean that networks that are essentially forks of Ethereum or which embed an Ethereum node in their network architecture (i.e. everything listed on https://chainid.network/) could all just link in an up-to-date upstream block-processor engine — rather than drifting away from it just because they've necessarily forked the storage+consensus+p2p+rpc code.

link