Generally we've described this sort of research as "review resistant", rather than being secure in some classical sense. How Ethereum and other cryptocurrencies actually work is often eagerly explained but completely unfathomable on closer inspection. Concerns raised are fixed with additional complexity repeatedly until the reviewer grows weary of attempting to piece it together. Consequently there's sufficient conflicting descriptions that I don't think anybody has any hope of successfully understanding the system as a whole, much less being able to come to conclusions about its security.

How can this argument be made in good faith? The spec is open source, all the clients are open source.

Furthermore, it's implemented and running. You could argue that someone in particular has made a poor or incomplete explanation of how it works but not that they way it works is unfathomable or being patched as your speak. It's already implemented, go look at the code if you don't want to believe what anyone says.

If the spec is open source, how can you say all the clients are open source? Or do you simply mean there are open source clients one can inspect and use?

There is a specification of the protocol, which is open source: https://github.com/ethereum/consensus-specs

And there are over 5 interoperable, independent and open source implementations of said specification:

- https://github.com/sigp/lighthouse/

- https://github.com/ChainSafe/lodestar

- https://github.com/status-im/nimbus-eth2

- https://github.com/prysmaticlabs/prysm

- https://github.com/ConsenSys/teku

- https://github.com/sifraitech/grandine

...

That's a gross misrepresentation of how it works in the real-world.

Do you believe the same about cryptography? Since you can't understand it, and few really understand the full system, algorithms and functions, it must be "review resistant" rather than actually safe to use?

Cryptography has mathematical proofs of the underlying math that are rigorous. There are constraints such as breaking if a proof of an attack against the discrete log were to emerge or other constraints related to p=np.

The implementations are also very close to formally verified if not fully formally verified.

Nothing is perfect but cryptographic code has to be pretty bulletproof or a lot of systems would get owned. The descriptions of how to verify cryptographic systems are academically and professionally rigorous especially compared to eth.

Caveat: sometimes the underlying systems that cryptographic implementations utilize change degrading their guarantees. There have been times where the compiler will get updated and cause what was a branchless process to branch which could lead to information leaks against a dedicated attacker. Thankfully such examples are rare in the literature.

> The implementations are also very close to formally verified if not fully formally verified.

So is Eth2, see "Formal Verification of the Ethereum 2.0 Beacon Chain" by Franck Cassez, Joanne Fuller, Aditya Asgaonkar, paper (https://arxiv.org/abs/2110.12909) and source code (https://github.com/ConsenSys/eth2.0-dafny). More efforts to formally verify Eth2 is ongoing as well, by different entities.

> Nothing is perfect but cryptographic code has to be pretty bulletproof or a lot of systems would get owned

Same with Ethereum. The chance of having a major impact with a vulnerability is even higher I'd argue, as you can easily extract currency you can trade for USD, and the entire network is inter-connected, so finding targets to exploit becomes even easier.

Point still stands that cryptography goes over a lot of peoples head, but you don't hear those people complaining that because they don't understand it, no one does.

I mean, I think this really depends on how you define ethereum. I think we all agree that there hasn’t been an effective attack against the consensus mechanism in a while (we could argue the original dao was sort of a successful attack against all of eth due to the hard fork).

This is kinda where I’ve gotten to on this: consensus is pretty much safe. Smart contracting is very hard to do safely.

This is not unlike the guarantees in general computation. The metal is pretty safe. The further you get away from the metal, the more layers of abstraction you’re relying on functioning predictably.

To be clear, I’m not arguing with you and appreciate your point about formal verification of eth.

I respectfully disagree. While some cryptographic primitives are surely based on some sound math, building cryptographic systems is very hard, and when built, they ane not generally proven to be correct. Some attacks involve influencing source of randomness, whereas proofs simply assume random unguessable numbers, for example. You correctly mention unintended degradation, that is another pretty serious concern, but even when built first, most systems are incorrect, faulty and unsafe.

Proving systems to be correct in computer science is far from settled matter.

I would say that it really depends on how you think about "the system."

If the hardware is in-scope for the system, you're generally out of luck at having provable guarantees unless you're willing to operate a foundry and courier your own products.

I think it comes down to threat modeling. You have some threshold where it's unreasonable for someone to attack a system for less than $X spend. Right now on iOS I think that's on the order of $500k-$1m usd.

There is a perfectly good mathematics-research-level question that was review resistant for a long time: the fabled solution to the ABC Conjecture, and that is still a controversial topic since the author still claims his work is, in fact, a solution despite reviews.

I wager Ethereum would be much the same if a researcher came around to say "This is actually wrong." It would be happily ignored by the authors.

I personally would be suspicious of a distributed cryptographic algorithm that can include malicious actors.

The spec is open and documented pretty clearly.[1]

[1] https://notes.ethereum.org/@vbuterin/Sys3GLJbD#Misc

Considering that Eth2 also have about 7 clients that work today (with more being worked on), the specification is clearly understandable by at least 7 different entities, further eroding the argument that Eth2 specification is so complicated no one actually understands it.

Most of the linked spec is pseudocode - actually it looks like valid python code. So to be fair I highly doubt you'd need any understanding of what it's actually doing to successfully implement that spec. Just like I still have no clue how Quaternions work, yet I've implemented them multiple times.

How much would one need to pay you to test your hypothesis?

That is you try to implement a standard complaint new Eth2 implementation from scratch ( and possible record yourself while doing so.

That's just a random function description. The main thing here is how is seed calculated and analysis of whether it seed is safe from network partition, DDoS, malicious attack, nodes being offline, forks etc.

Also clearly documented and open to researchers to examine. The full code for the various Eth2 clients is open source.

[1] https://eth2book.info/altair/part2/building_blocks/randomnes...

[2] https://eth2.incessant.ink/book/06__building-blocks/02__rand...

All popular Ethereum clients are open-source.

If you really want to know how it works, go read the code.

But isn't that a great description of our current banking system as it is today? Not everyone knows everything, somehow it works, complex, etc. However, still so woefully insecure.

"I don't get it so it must be false" that's what you sound like right now

Spoken like somebody who doesn't read Buterin.

Article author here.

Great questions, should have explored the randomness beacon more. Ethereum uses [RANDAO](https://github.com/randao/randao), which is a distributed commit-reveal scheme where participants in the generation post a hash of their data on the commit portion and then at a later timestamp reveal the data preimage, and get slashed if they do not reveal a correct preimage. Then all participant data is aggregated together. This means if there is at least one honest participant the generation will be random.

A supermajority (2/3rds) of validators is required to finalize a block, in case of a 50-50 network partition blocks would stop being finalized and attestation rewards would stop. Non-participating validators would slowly leak stake through the inactivity leak until online validators once again had a supermajority. This is the "self-healing" mechanism that allows both safety and liveness.

According to Eth docs:

> One validator is randomly selected to be a block proposer in every slot. This validator is responsible for creating a new block and sending it out to other nodes on the network. Also in every slot, a committee of validators is randomly chosen, whose votes are used to determine the validity of the block being proposed.

The annotated code for this can be found in [2].

[1] https://github.com/ethereum/annotated-spec/blob/master/phase...

[2] https://notes.ethereum.org/@vbuterin/Sys3GLJbD#Misc

Maybe I am stupid, but at least to me its not obvious how one would randomly select a member in a decentralized way, assuming some actors are malicious?

There are tons of different ways of doing so, with their own set of pros/cons. I'm not familiar with exactly how Eth2 does it, but I suppose your curiosity is a general one, not specific to Eth2, so here is how it works for Algorand as an example using VRFs (Verifiable Random Function):

> The VRF takes a secret key and a value and produces a pseudorandom output, with a proof that anyone can use to verify the result. The VRF functions similar to a lottery and is used to choose leaders to propose a block and committee members to vote on a block. This VRF output, when executed for an account, is used to sample from a binomial distribution to emulate a call for every Algo in a user’s account. The more Algos in an account, the better chance the account has of winning – it’s as if every Algo in an account gets its own lottery. This method ensures that a user does not gain any advantage by creating multiple accounts.

https://www.algorand.com/Algorand%20Protocol.pdf

The search term you're looking for is "decentralized leader election", searching for that on Google or Google Scholar gives you bunch of results ranging from random musings to academic papers.

I tried to search for it, but can't find any concrete example assuming malicious nodes. There are many edge cases to cover here like who gets to set the secret key or any parameter. What if nodes get offline. What about things like DDoSing the node.

For Algorand, the answer is in the very paper I linked:

> If the network does stall, either from network outages or malicious behavior, the nodes go into recovery mode, waiting for recover messages. Individual nodes will send these messages to signal to the network that it should either continue processing the last known block proposal or to propose a new block. When a quorum of votes is received for either one of these messages, the system will revert to normal operation. In the case of malicious behavior, the protocol may select a new leader. In the case of network outage, the current block will continue to be processed or a new block might be proposed.

For other blockchains, the answer will depend on their implementation. It's likely you're gonna have to understand the underlying protocol before you can understand the potential threats, and consequently how the protocol addresses those threats. So for other blockchains, your best bet to understand what happens in the case of malicious nodes, is to understand the whitepaper describing the protocol.

It is probably better to describe it as pseudo-random. See here: [1]

[1] https://eth2.incessant.ink/book/06__building-blocks/02__rand...

The procedure Ethereum uses to generate randomness is called RANDAO. You can see an explanation here:

https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-ch...

I'd love to see this explained too, like in simple words.

One simple algorithm, just to convince you that this is possible, would be as follows:

* All of the members generate a key-pair, and introduce themselves to each other with their public key as their identity.

* After a certain time interval, all members individually pick their own random number, and publish just the hash of it, thereby "pre-committing" to it (signing it with their private key).

* Once all the hashes are known, the members reveal the random numbers that were the inputs (and the other members check that they hash to the pre-committed values).

* The members then XOR all the random numbers together (and then maybe hash the result) to produce a single final random number.

* That random number is reduced modulo the number of members, producing a number which is then used as an index into the list of members (sorted by public key).

There are edge cases with malicious or badly connected nodes potentially dropping out at each stage, so this requires a bootstrapped consensus system that can agree on which nodes are bad and punish them financially.

Would recommend reading Ben Edgington's annotated spec: https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-ch...

It's not entirely up to date (none of the annotated specs are) but out of the three annotated specs I'm aware of, it's the one that is most focused on explaining how things work. Vitalik's annotation (linked in another comment) places a particular focus on the reason specific constants where chosen.

As for the source of randomness, they mention it briefly in the appendix:

> RANDAO: the random number generation scheme used to select block proposers, sort validators into committees, etc

Spec and implementation: https://github.com/randao/randao

Heres my understanding of it: committee assignment is random, as in baked into the protocol, similar to how a validator is selected for a block (i.e. randomly).

While only one validator creates the block, others create attestations which I understand as duplicate work done to check the chosen validators produced block.

If an entire country goes down, those validators fall out of the active set and assuming some majority is still active they'll produce and verify blocks.

Incorrect state is rejected by the majority, and the minority is punished (slashing their stake).

Full disclosure, I'm not an expert - just an enthusiast interested in these protocols. Would love for someone more knowledgeable to correct my mistakes. I'm also not arguing for or against anything here.

> Incorrect state is rejected by the majority, and the minority is punished (slashing their stake).

That's wrong. Also the state of those validators that are separated from the larger network is not wrong it's just not the same as what the majority considers the state.

They will be on a forked chain of the network. But for being on a fork, no validator is slashed. They will only lose out on the rewards they would have gotten on the majority chain.

Validators are only slashed if they try to vote for the same slot/blockheight on different forks of the chain.

Ah, thanks. How does the forked chain reconcile with the rest of the network once the networks sync back up?

I think that depends on how long the validators were cut off from the majority of validators.

Ethereum's POS has a concept called finality which means that under certain conditions the blockchain gets checkpoints that can't ever be reverted. Somewhat simplified but the the blocks are finalized if 2/3rd of the validators validated the last 64 blocks. So, normally after about 13 minutes you can be sure if the transactions are set in stone or not.

If the cut off validators are reunited after not too long, they won't have been able to finalize any blocks and then they will just throw away the part of the chain they have been building since they were separated from the majority. As far as I understand it that's quite similar to a reorg on a POW blockchain.

The other case, if they've been separated for a very long time, the situation is a bit different. If you don't follow your duties as a validator, you get penalized. A little of your staked ETH is burned. Note, that's not the same as slashing (which is much harsher) and if your staked ETH balance falls below 16 ETH, you're kicked off the list of validators. This is so that active validators will be able to reach again a 2/3rd majority after a while and be able to finalize blocks. If this happens to our cut off validators, even if they get access to the other validators data again, they can't reorg the blockchain as their blocks have been finalized.

In this case, the admins need to manually reset the data so the validators can rejoin the correct chain. This is a known issue which POW networks don't have. There you can always rely on the chain that has the most work done. But the work is cheap and fast in POS networks so you sometimes need to get external info and verify it by hand.