He will briefly cover infrastructure of the Ethereum platform, smart contract execution principles including the "gas economics". High-level programming language for smart contracts Solidity will be presented with practical examples. In the conclusion we will speak about common problems that could be solved in our society using smart contracts, and why it is worth to learn smart contract programming now. Anatoly is a Senior Software Developer at C.T.Co, Co-founder at AssistUnion, Board Member of Latvian Blockchain Association. He is a TSI ex-lecturer with more than a decade experience in teaching functional and logic programming and compiler design. Anatoly is a crypto-currency and blockchain enthusiast since 2011

1. Smart Contract Programming
Anatoly Ressin
anatoly@assistunion.com
Senior Software Developer at C.T.Co
board member of Latvian Blockchain Association
co-founder at AssistUnion

2. …an idea
• Bitcoin script language allows
some sophisticated calculations
(verifying conditions) though it
is not Turing-Complete…
• Blockchain system with
embedded Turing-Complete
language would allow to verify
any [computable] condition!
Vitalik Buterin
2013

3. Why do we need custom logic
on blockchain?
• Auctions;
• Lotteries;
• Voting;
• Different kinds of ledgers (tax-statements, land-books…)
• Obligations and rights management;
• Custom crypto-currencies connected to arbitrary
business-processes;
• … [try to imagine more - maybe it’ll be your fresh startup]

4. Most important papers
• Ethereum White paper (by Vitalik Buterin)
• Ethereum Yellow paper (by Gavin Wood)
• formal description of the semantics

5. Accounts
• External — controlled by Private/Public keys
• Public address + Private Key
• Balance
• Contract — controlled by code. Contract has:
• Public address
• Code
• Persistent storage [mapping (256bit => 256bit)]
• Balance

6. Ethereum Virtual Machine
0: PUSH1
1: 0
2: CALLDATALOAD
3: SLOAD
4: NOT
5: PUSH1
6: 9
7: JUMPI [!]
8: STOP
9: JUMPDEST [!]
0: PUSH1
11: 32
12: CALLDATALOAD
13: PUSH1
14: 0
15: CALLDATALOAD
16: SSTORE
• Stack based
• Has it’s own
• STACK
• MEMORY
• Has access to the
• message data
• contract storage & balance
• block & transaction contexts

7. Classical problem
• Undecidability
• Time: how many steps are needed to complete
an execution (and whether it completes at all?)
• Space: how many memory it would consume for
the execution.

8. Gas Economics
• Gas is a unit for measuring execution complexity.
• Every OpCode costs well-defined amount of Gas.
• To initiate a transaction, you need to specify
• gas: Amount of Gas you allow to spend for execution;
• gasPrice: how many ethers (wei) you are agree to pay
per 1 gas unit;
• Miners are free to to include transactions into blocks if
gasPrice combined with gas amount is profitable for
them.

9. Meet Solidity
• Object Oriented (Multiple inheritance with
linearization)
• JavaScript inspired
• Statically Typed
• Targets to EVM
by Gavin Wood (!)

10. Example: Mortal.sol
contract mortal {
address owner;
function mortal() {
owner = msg.sender;
}
function kill() {
if (msg.sender == owner) {
selfdestruct(owner);
}
}
} greeter.sol
source code example

11. globals: block, msg, tx
• block.blockhash(uint blockNumber) returns (bytes32): hash of the given block - only works for 256 most
recent blocks excluding current
• block.coinbase (address): current block miner’s address
• block.difficulty (uint): current block difficulty
• block.gaslimit (uint): current block gaslimit
• block.number (uint): current block number
• block.timestamp (uint): current block timestamp
• msg.data (bytes): complete calldata
• msg.gas (uint): remaining gas
• msg.sender (address): sender of the message (current call)
• msg.sig (bytes4): first four bytes of the calldata (i.e. function identifier)
• msg.value (uint): number of wei sent with the message
• now (uint): current block timestamp (alias for block.timestamp)
• tx.gasprice (uint): gas price of the transaction
• tx.origin (address): sender of the transaction (full call chain)

12. Basic data types
• address: account identifier, similar to a 160-bit hash type.
• bool: two-state value.
• uint: 256-bit unsigned integer, operable with bitwise and
unsigned arithmetic operations.
• int: 256-bit signed integer, operable with bitwise and signed
arithmetic operations.
• hash: 256-bit, 32-byte data chunk, indexable into bytes and
operable with bitwise operations.
• string32: zero-terminated ASCII string of maximum length 32-
bytes (256-bit).

13. Structs, Arrays, Mappings
struct RGBWallet {
uint redCoins;
uint greenCoins;
uint blueCoins;
}
RGBWallet myWallet;
uint[] arr = new uint[10];
mapping (address => RGBWallet) wallets;

14. Reference type location
modifiers
• memory
• storage
• calldata
function (uint[8] memory args) {
…
}
Affects how assignments are performed
(copy if needed to change location)

15. Function modifiers
function-modifiers.sol
source code example

16. Security considerations
• Avoid sending money from the contract. Allow
users to withdraw it!
• Preferred execution flow on inter-contract
communication:
1. Check preconditions;
2. Modify state;
3. Only then call other contracts.

17. Simple Auction
simple-auction.sol
source code example

18. And many-many more…
• Full Solidity language labs;
• ERC20: token standard;
• Different kinds of Voting Schemes;
• DAO;
• Contract verification;
• Web3 and DApps

19. Thank you!
Your questions…
If you are interested in a full Solidity course — drop
me a line: anatoly@assistunion.com

20. Useful sources
• https://github.com/ethereum/wiki/wiki/White-
Paper
• http://solidity.readthedocs.io/
• https://ethereumbuilders.gitbooks.io/guide/
content/en/solidity_tutorials.html
• https://drive.google.com/file/d/
0ByMtMw2hul0EN3NCaVFHSFdxRzA/view