nicksdjohnson

Thanks!

This one is incredible! I've minted it so nobody else can grab it. If you have an Ethereum account, let me know your address so I can transfer it to you.

1T is a huge overcompensation. If you take Ethereum's estimated daily carbon output and divide it by its daily gas units (the unit by which computation is measured) and assign responsiblity that way, minting an Amulet consumes about 20KG CO2 emissions. Transferring one, about half that.

Speaking as an Ethereum core developer here - I see a lot of misdirected criticism and misunderstandings of Ethereum and the platform in the wider tech community. That said, your criticisms here are absolutely spot on; these are definite issues with Solidity as a smart contract programming language.

The only small correction I would make concerns this:

> Functions can mutate state by default. Both are overridable by explicit specifiers, much like C++ "const", but you have to remember to do so. Even then, the current implementation doesn't enforce this for functions.

When interacting with Ethereum you can do two things: send a transaction, or call a function against your local copy of the blockchain. The former is mutating, costs ether (in gas fees) and requires the transaction to be included in a block. The latter is entirely local, cost-free, and any mutations to state are ignored.

The 'constant' modifier in Solidity serves only to tag the resulting ABI of a function so that calls to it from common interfaces default to local calls instead of sending transactions. It's not intended to enforce that calls to that contract are read-only, only to indicate to callers that it should be called locally instead of creating a transaction for it.

Okay, I'll bite. What's 'centralised' about Ethereuem, without twisting the word beyond all recognition?

You seem to have very (some would say ridiculously) high standards for 'decentralised'.

If the root multisig was deleted, would it be 'decentralised' in your book?

> It claims it is a decentralised naming system, though looking deeper you will find it is just clever marketing and underneath is it is only ethereum-platform based naming for anything like your address etc. will only work in eth browsers, not all etc. which I have already mentioned in my OP.

It doesn't claim to be DNS. DNS is not the only naming system.

What's centralised about ENS?

Also, it can be used to resolve any resource you want - although you're shifting the goalposts, since that wasn't originally a requirement.

> There is not one single dapp that is decentralised and working.

Sure there is. ENS, for one example. Plenty of gambling apps for another (I don't find them particularly _compelling_, but they are there and they do work)

Censorship resistance isn't the main thing that blockchains enable; trustlessness is. If you host them on your own SQL database, people have to trust that you're acting honestly.

In all seriousness, you should lurk in the Ethereum subreddit instead.

We have our share of cheerleaders who take the black and white "this good, that bad" position without evidence, but they're not dominant, and we have a far larger proportion of developers who are interested in building cool technology and are able to look objectively at the problems involved.

But you can reason about what any possible transaction can do by reasoning about all possible inputs to your code; you don't need to know anything about how other contracts were written, since even if they are formally provable, they could send you literally any input.

Edit: Rereading your earlier comment, I understand now - you're talking about other contracts your code calls, not vice-versa. In that case, I'd point out that you're totally free to either write those contracts yourself if they're not already provably secure, or write your own code such that it's formally proved to work regardless of what those contracts do.

If you want to know what a given transaction will do, you can simply run it locally; no need for formal analysis. Formal analysis is useful for proving properties about your program like "the total balance will always equal the sum of the accounts" and "transfers never increase the sender's balance".

I don't think I follow - why would you need to reason about your callers' internal states in order to prove properties about your own contract?

But that's completely beside the point: the point is that you can't have the libertarian-utopia-chain without also getting the hacker-got-away-with-his-loot chain.