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.
Actually, let me rephrase this. For better or worse, Solidity is a shipping product now, so you're constrained in your ability to make breaking changes. However, its status as the "official" blessed EVM language can be changed without breaking compatibility. So I guess a better question is, are you planning to replace Solidity with a language that has more emphasis on safety in its design (even if it's called Solidity 2.0 or whatever... clearly it would have to significantly break backwards compatibility).
Now, I know that most feedback that you hear is to just take an existing functional language. But after looking at Solidity and EVM specs, I also see why this is not necessarily feasible. And, as one of your contributors has pointed out in this thread, functional style can often be too high-level to keep track of the underlying opcodes and their gas cost.
But even sticking with the imperative approach, I think it's clear that there's a lot that could be changed, starting with adopting some key principles like "explicit is better than implicit", "don't pick a default unless it's absolutely safe" etc. Looking at the design of Solidity, it's clear to me that the primary inspiration was JS with a dash of C++. The one thing that's common to both is that they allow and encourage "clever" code. Perhaps looking at Ada, Eiffel, and even COBOL for inspiration would be more appropriate for this niche.
In any case, if you're interested in specific suggestions on how to redesign, I do have some thoughts, and would be happy to share them.
There is an EIP that is slated to land in the upcoming hardfork that adds an EVM opcode for effectively "const" call that is enforced by the runtime:
https://github.com/ethereum/EIPs/pull/214/files
There are also proposals out for a number of the issues you have mentioned. I believe that people _do_ want to make Solidity into a better language for safe code authoring, but some things require EVM changes which requires a hard fork, and other things simply require time (discussion and engineering). The impression I get is that at this point there _are_ some voices of reason involved in the Solidity language process, but it will take time before those voices can enact all of the changes listed here.
Also, keep in mind that when Ethereum launched it did so like any scrappy startup, with an MVP that was "good enough" to move things forward. Now that Ethereum is a leading contender in the blockchain race it is starting to have to pay for some of those early decisions.
> 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)
ENS is a great example of a centralised system plus its only about eth based names, no application other than just a method by to collect money by the platform for offering services that are only about the platform and work in the platform.
ENS is implemented as a set of smart contracts with some multisig management. Are you arguing that this is centralized? Also, money that is collected by the ENS contracts is only held as a deposit.
Yes, I am arguing it is centralised. Read about the centralised root signature system that is the way to add new TLDs to the system.
Also this is worse than the current system we have in the world because it wastes more energy in doing so!
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 is only ethereum-platform based naming for anything like your address etc.
The "etc" is important here, because it refers to richer resources such as content hashes. With this, you could load the entire "frontend" for a website from a decentralized datasource, e.g. Swarm. Meanwhile, the backend could be the Ethereum blockchain/smart contract methods.
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.
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.
Ehh... I have quite similar issues with the Ethereum crowd. Nobody understands in which situations they need distributed consensus on some state, and what the other available solutions to various similar problems are. Blockchains solve a very niche (but previously difficult-to-solve!) problem, and given that they literally cost money to use, it's good to use other tools to solve problems when you can.
Sorry, I didn't qualify "always feasible" well enough. What I meant was, I want it to be feasible to reason about the halting states of every single smart-contract that will ever interact with my code. Not just the ones that I write, but also the ones that are reachable from my smart contract's call graph, and the ones that call into my smart contract.
If I can do this, then I can feasibly reason about how my code will react to other peoples' inputs (e.g. I can prove the absence of DAO-like re-entrance bugs). The fact that Ethereum allows smart contracts to be written in undecidable languages means that this is not feasible in practice.
Because in practice, I'm trying to reason about the consequences of submitting a given transaction. A transaction can invoke many smart contracts in addition to mine. It's not enough for my code to be correct; every piece of code the transaction causes to run has to be correct as well.
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".
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.
> 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.
I also have to reason about the transactions that invoke other smart contracts that, through one or more subsequent calls, will call into mine. These transactions are inputs to my smart contract as well. Recall that the DAO was hacked by an "attacker" contract that called into it, for example.
> 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 formal specification and verification were practical, we'd be doing it in every programming domain. Normally, few people bother since (1) it takes a lot of work, and (2) the consequences of bugs are small in most domains, especially compared to the consequences of not shipping code on time. If you have not tried to formally specify and verify the correctness of a non-trivial program before, I encourage you to try it before recommending that strategy (especially if that recommendation includes telling developers to rewrite other peoples' code).
Since smart contracts have other peoples' money attached to them, the developers' first priority must be user safety. Ethereum does not appear to take this seriously, since (1) its default programming languages are not designed to be amenable to formal verification, and (2) smart contracts are allowed to call into one another.
I would much rather program on a blockchain that kept smart contracts completely isolated from one another, and required me to submit a machine-checked proof that the user's money (1) will be sent to an address of the user's choice automatically no more than X blocks after the deposit, and (2) cannot leave the smart contract at an earlier time without a one-time-use signature from the user. If a smart contract cannot be proven to do both of these things, then the blockchain should prevent it from running.
I agree "smart contract" is a poor term, but they're way more than "conditional payment" - you can do a lot of things with them that have nothing to do with paying money.
> And my point was that if you look at ETH/ETC, the market is saying that they feel more comfortable with a known, trusted authority (i.e. small group of developers with trademarks and a conference schedule) than they do with true democratized first principles of immutable code.
But the fork wasn't a referendum on the governance model of Ethereum. If you picked ETC, you get your liberterian utopia - but you also get a chain where someone made off with 10% of the Ether supply.
Pre-fork ETH owners didn't necessarily have to pick one over the other. Miners had to allocate their resources between the two chains (but could split their bets, and some did so). Pre-fork ETH owners ended up with both chains in a kind of 2-for-1 special.
Every market transaction since then has been a referendum on which model the market prefers. Ultimately, the market price dictates a LOT of down-stream behaviors, e.g. some miners will switch back and forth between ETH and ETC (and other alt-coins) based on hourly yield.
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.
