An accomplice to the Consensys "Smart Contract Best Practices", but with less security and more engineering focus. WIP.
Copyright 2018 Liam Zebedee and contributors.
While Solidity on the outside looks like JS, functions like C, its semantics are quite unique and different. It is birthed as a "smart contract" programming language, however you can better understand its strange decisions by the constraints imposed by running atop the Ethereum blockchain:
- storage is very expensive
- money/value is data
- computation is transactioned, state is rationed
You can see this in many ways:
- basic operations on data types are difficult/missing: iteration on maps, non-existent keys are 0x0 (even for structs their fields are all 0x0)
- returning structs from external methods is impossible - rather, it returns tuples for now due to the ABI version
- types are generally much more plentiful in number, but lower-level in nature (bytes32, bytes64, uint256)
- contracts cannot respond natively to "timed events" - they must be interacted with via calls, or by decentralized services such as the Ethereum Alarm Clock
- all interactions are based on the primitive of messages, contract instantiations are sending eth to an address (which is in itself the hash of the contract), everything functions as an address (wallets and contracts alike)
- since protocol messages are padded, features such as dynamic arrays do not work in places you expect
- upgradeability is not built-in
- no ubiquitous package management yet
I've decided to write a guide of the knowledge base I've been building up - for those who understand code, who know the fundamentals of blockchain, but don't want to trawl through 200 poorly-written half-answered StackExchange questions and blog posts.
I've tried to organise this guide into various topics that commonly crop up in the software engineering practice of building smart contracts.
- Data modelling: the common patterns of separating concerns (i.e. MVC)
- Interaction modelling:
- Testing: the simplest patterns for writing unit and integration tests for smart contract systems / dApps.
- Solidity semantics: common gotcha's/suprises in the semantics of Solidity
- Self-study: read the codebases of larger projects, and run example contracts created by others to get tactile understanding of the language
Take a further read of https://github.com/fravoll/solidity-patterns