I've just completed "Ethereum and Solidity: The Complete Developer's Guide"
. It's really a great course about Solidity/Ethereum smart contract development which enables the learner not just to write their own smart contract on the Ethereum blockchain, but also how to test it (manually and automated) and how to integrate it into a web application.
The course starts with an introduction of Blockchain technology and specially Ethereum. You learn how Blockchains work in general and which role accounts, private and public keys, as well as what ether, wei and transactions mean for Ethereum. Then the course goes "hands on" and you learn how you can connect your browser to the Ethereum network using MetaMask
. The introduction ends with an explanation of smart contracts and a small example for an Ethereum smart contract written in Solidity, which is then deployed and executed on one of the Ethereum test networks using Remix
, an online IDE for Solidity.
Following chapters are about setting up a local development, build and test environment using NodeJS, Mocha, Web3
and the Truffle framework with Ganache
suite. This development framework is then used to implement a Lottery DAPP (decentralized app) using Solidity.
By the way, all code of the course is available on Github
What Could be Improved?
Speaking about the latter, I fully understand why the author Stephen Grider took React into the game and I agree, it made sense. It also made sense to include this React introduction (which by the way give the impression that this other course is also great). But yet, I had to drop half a point off the maximum rating because by my perception, React+SemanticUI took too much place in the other chapters, after all. I would rather have seen some more detail about what to pay attention for on the Solidity side, some examples:
- what can be done with Solidity and what not (in comparision to "normal" programming environments
- tips and tricks for saving gas cost on the EVM (e.g. tradeoff between storage and operations)
- what to do and what to avoid in Solidity in comparison to off-chain programming (e.g. how to avoid loops by moving code to originating transactions)
- how data on the blockchain is actually stored and later accessed by the EVM (that would just be an extra bonus, I really have to research about that)
Maybe these topics for an advanced course?
Other Critical Voices
Some more criticism I've read about in this courses reviews on Udemy were: "too much testing" and "too slow paced".
And speaking about "too slow paced": Yes, it was slow paced and therefore easy to follow. Udemy has a cool feature, though, speeding up the video playback up to the factor of 2. And that's what I did in vast parts of this course, mostly ran it at factor 1.5 to 1.75. On the other hand, I stopped it while I coded along or tried out things.
I rated this course with 4.5/5 points - and I never gave a 5/5. Overall that was one of the best courses I've ever taken, thanks to Stephen Grider!
What I've learned
Maybe the most important part of learning was realizing how careful one has to be when writing smart contracts. Once they are out on the blockchain, no defect can be fixed anymore. Yes, you can destroy or disable your contract, if you've thought about it before deploying, but you have to consider what happens with the account balances, you really might lose money.
And as in each transaction, each operation costs real money (in ether), it's interesting to see how different you have to design your code. For example, to avoid loops like hell - at least in transactions. Or to move code, which you normally would run in subsequent transactions, to the originating transaction, for the benefit of moving the cost to the originator of the initial transaction instead of making subsequent transactions more and more expensive. This was not deeply discussed in the course, though.
Also I learned quite some Solidity programming and which limitations it has due to where and how it's executed. But I doubt I could become a fan of Solidity, it looks too inconsistent for me, e.g. modifiers for instance variables are placed between the type and the name, for functions it's between the parameter lists and the return value. Also the effect which the modifiers "storage" and "memory" work, is a bit strange.
What Comes Next for Me
The main example from the course gave me a good kickoff for some idea I'd been full with for a while: A crowdfunding platform for features of free open source software (see this Tweet
of mine) where arbitrary people can contribute funding, arbitrary developers can pull the work items and, after a review of the work results, the funders can veto the approval of the payout with the weight of their funding. More is about to come later ...
Critical Points Regarding Blockchain Technology
I must point out two more critical issues, though not about the course but about Blockchains in general: Their electricity consumption and high volatility.
The hunger for electricity comes from mining new "coins" using Proof of Work
which is also crucial for the security. Proof-of-Work is is used by Bitcoin as well as Ethereum.
Ethereum has not yet solved this problem, but they are at least thinking about it and is moving towards a hybrid approach by partly employing Proof-of-Stake
[added on 2018-02-19 17:41 UTC+1]
The high volatility is also a problem for many applications. One problem is that in many tax systems (as in Germany) you needed to pay earnings tax each time to pay with a cryptocurrency which increased in price since you bought it. Another problem is that any asset which goes up fast, can also go down fast. Some applications, like crowdfunding or even more loans, need at least some reliability about the value of the asset. Among current cryptocurrencies, I see no solution for this problem yet.