Ethernaut: wargame to learn about smart contract security
ethernaut.zeppelin.solutions
ethernaut.zeppelin.solutions
https://consensys.github.io/smart-contract-best-practices/
Disclaimer: I contributed to the first link.
Also, I wrote this a while back for any experienced engineers that want to learn Solidity:
https://medium.com/@preethikasireddy/how-does-ethereum-work-...
Take a look at their github and how the overwhelming majority of users can't run a full node (If you can't run a full node, you rely on an intermediary, you are not decentralized).
I'm not sure if the "marketing team behind a decentralized project" is still doing it but they used to be continuing to market ethereum as an immutable blockchain which is patently false due to their roll back of the DAO.
Ethereum's inclusion of state root commitments in its data structure also means ultra-secure light clients - that provide much greater security than Bitcoin's SPV clients - are possible.
What you're claiming amounts to blatant FUD.
The Ethereum Foundation is just the centralized marketing and governance organization that also lobbied the SEC not to classify it as a security because of how decentralized it is.
I don't often comment here, but I simply can't understand why an human being would come to the internet and hatefully attack things it doesn't like with straight made-up facts. I mean, I know this is so common, I just don't get why. This kind of thing makes me sad about humanity as a whole. Why can't we be nice to each other?
This is not true. SPV nodes blindly follow the longest chain and are at the mercy of miners. Running a full node guarantees you that all the protocol rules are being followed to the letter, while an SPV node cannot verify chain validity rules (like the 21M coin limit) and could be fooled to accept payments with money made out of thin air.
> Ethereum is that it had a hard fork to revert a millionaire hack caused by a bug in early stages of the project; whereas something not too different also happened to Bitcoin
The Bitcoin developers fixed a bug in the Bitcoin protocol. The Ethereum developers bailed-out a buggy smart contract written by a third-party, where the bug had nothing to do with the Ethereum protocol itself. I don't think the two are comparable.
Something that would've been comparable is the Bitcoin developers doing a chain-rollback to save the funds lost by MtGox. Which of course would be a horrible idea.
Also, when that happened in 2010, Bitcoin was a pet project valued at $0.08, with a total market cap of ~$250k. Ethereum was nearly a two-billion dollars project when they bailed out the DAO!
You're defining "bug" to fit your purposes. It wasn't "just a faulty contract". The entire protocol had a reentrancy situation that wasn't intended by any of its developers nor expected by any of its users, and that went against the expected semantics of its official programming language; it was a protocol bug, for any sensible definition. I don't see anyone neutral arguing it wasn't.
If you argue The DAO hacker had the right for the Ether he got because "that's what the code said", you could also claim the Bitcoin address had the right to claim his billions BTC, because that's what the code said back then. He only followed protocol rules and got all his money taken away by the hard fork.
Well, FWIW, I've never heard _anyone_, neutral or not, claiming the DAO hack was a bug in the Ethereum protocol before now...
And that's because, well, it very clearly isn't. hackingdistributed has a good overview[0] of the coding bug in the DAO that enabled the hack which I recommended you to read.
Looking at this another way, this could've been avoided by the DAO developers if they developed the smart contract more carefully. And the exact kind of bug that lead to the hack was still possible on Ethereum following the bail-out hardfork. So how can one claim the hardfork fixed a protocol bug?
> If you argue The DAO hacker had the right for the Ether
I didn't say that. I only argued about the differences between fixing a protocol bug and bailing-out companies that build on top of the protocol.
[0] http://hackingdistributed.com/2016/06/18/analysis-of-the-dao...
By comparison, Parity's wallet bugs were just a result of carelessness, and independent audits probably would have discovered them. Consequently, the community strongly pushed back when Parity tried to get a fork for the second one.
If I understand it, it isn't fixable without affecting every existing contract, so, the best fix was to patch the problems it caused, patch Solidity, introduce safer opcodes that avoid it, and invest heavier on security, which is exactly what was done (just see how much the EF is spending on security-related grants...)
Just to be clear: the Bitcoin developers do recommend you run a full node. It is the only way to independently validate the entire chain.
Practically, you don't need to independently validate the blockchain. You can rely on dozens of blockchain explorers to do that. You do however need to be able to write your own transactions to the blockchain to have any degree of control over your own funds. The 1 MB limit effectively prioritizes the former over the latter, which is something that was never part of Bitcoin's original roadmap, or what Satoshi would have recommended:
There's no purpose in asking a user to run a full node to write to a blockchain. A user/client runs a node to verify they've been paid. If you're trusting someone else to tell you you've been paid, you have centralization. The entire purpose of bitcoin is to receive payments without a trusted, third-party intermediary. Only the people who can run nodes can tell they've been paid.
This is a totally illogical statement.
You can't get paid if you can't write to the blockchain. How are you going to spend what you're paid if you can't afford to write to the blockchain?
>>If you're trusting someone else to tell you you've been paid, you have centralization.
I've already addressed this: the risks associated with relying on a dozen blockchain explorers to validate the blockchain are nothing compared to the risks of relying on someone else to hold the private key that controls your funds.
What they're all going to lie about what transactions are happening on the blockchain? It's open source, public domain data. There's no limit to the number of sources you can poll until you get a confident estimate of the true state of your transaction. Consequently, the feasibility of such a deception being pulled off is astronomically low.
In other words, you're advocating throttling write-access to the point that the Bitcoin-Core blockchain is not able to provide practical utility to the vast majority of the human population, to ward off a total non-risk.
Reference: https://bitcoin.electronrelocation.com
In the future we expect fees to increase (as they must for security purposes), but the idea that someone that can afford to run a full node will not be able to afford to insert a transaction does not hold up under basic scrutiny.
That's irrelevant. The only reason you can get away with a low fee on the Bitcoin Core blockchain at the moment is that it's not operating at capacity. As soon as adoption picks up again, fees will start to climb - they have to because capacity is constrained. At any globally significant level of usage, fees will be astronomical.
Remember, as recently as December 2017, BTC's average transaction fee reached $30.
>> but the idea that someone that can afford to run a full node will not be able to afford to insert a transaction does not hold up under basic scrutiny.
That's absurd. 1 MB of space in each block allows for a maximum of 604,800 transactions being written to the blockchain a day. There is no way that fees for writing to the blockchain wouldn't skyrocket, far out of reach of ordinary users, at any significant level of adoption.
It’s not an association free name