[vbuterin]

Lots of things "don't need" to be written in python, but they're written in python anyway. I expect a lot of blockchain institutional use cases will take a similar route: sure, theoretically they could use some standardized federated solution, but in practice blockchain tx fees will become low enough through layer-2s to be negligible and that's where all the infrastructure to help users verify what's going on, and use those verifications in other applications, will be built. NFTs are already an incredibly easy to use and verify type of certificate; their biggest weakness is that (because of limitations in technology that are completely temporary and will disappear soon) transaction fees are too high.

Like... why _not_ dump Merkle roots on-chain?

[70rd]

> Lots of things "don't need" to be written in python, but they're written in python anyway.

This is a weak argument. Many things shouldn't be written in python, because it would the wrong tool for the job. Networking libraries that require bare metal performance, high assurance systems that are easier to write in strongly typed languages.

Block chains solve untrusted writing in the presence of byzantine faults. Not all applications require this. Most don't.

> Like... why _not_ dump Merkle roots on-chain?

Because the data isn't merkelized?

[captn3m0]

Choosing the wrong language doesn’t usually come with multiple order of magnitude differential in energy costs. Or changing the security guarantees being offered - that’s usually at the application layer.

As an example, you’re open to Sybil attacks, and ongoing costs of mining. You need to understand the economics behind the chain you chose to make sure it doesn’t die, and hand off the key management to land owners.

When we have a simpler solution that doesn’t burn the planet, and is easily understood by everyone - as engineers it is our responsibility to have a really compelling reason to ignore it. I don’t see it here.