Hacker News Reader

Comment by RL_Quine | Hacker News Reader

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.

View on HN

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.

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

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.

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.

Reply on news.ycombinator.com