Smart Contract: QA Role for Decentralized Platform
- 1. Hire the top 3% of freelance talent Smart contract: QA Role for Decentralized Platform
- 2. imgimgimg | 2 $whoami Marco Andrade ● I'm from Brazil ● I have visited 18 countries (3 continents) ● QA Automation Engineer and Scrum Master at Toptal ● Toptal's Community leader at Belo Horizonte
- 4. | 4 This is a Smart Contract
- 5. | 5 Blockchain: What is it Blockchain is a secure, shared, distributed ledger
- 6. | 6 Blockchain: What is it?
- 7. | 7 Here's a bright idea: let's put code into the blockchain! Some "accounts" have code attached to them, they become "contracts". The code can: Smart Contract ● Decide what happens to the coins sent to it ● Create new transactions ● Query blockchain data ● Generate events ● Call other smart contracts ● ... or do anything else since is Turing-complete
- 8. | 8 Use of Smart contracts
- 9. | 9 Requirements for a payment system Decentralized, anonymous system for exchanging money/information: ● All transactions should be made over the Internet ● No central authority that will process transactions ● Users should be anonymous and identified only by their virtual identity ● A single user can have as many virtual identities as he or she likes ● Value supply (new virtual bills) must be added in a controlled way
- 10. | 10 QA Role
- 11. | 11 QA Role In 2017, it’s estimated that $500 million has been lost due to bad code, and around half of that figure involved Ethereum.
- 12. | 12 QA Role Very much the same: ● Build tests based on requirements. ● Automate and execute them. ● Provide risk assessment of the software to the team at any given point of the development cycle.
- 13. | 13 QA Role
- 14. | 14 Key points ● Immutable data ● Data visibility ● Learn different tools ● Ensure code is covered by tests ● Grow a quality culture inside your company ● Have a critical thinking
- 15. | 15 Smart contract No internal state. Stateless Has internal state (is mutable), therefore need special care for security and correctness. Stateful
- 16. | 16 Smart contract Business logic Triggered by the events Using digital signatures to identify who sent the messages Putting the programs, messages, and signatures on a Blockchain Executing every program for every message on every node.
- 17. | 17 Tools
- 18. | 18 Bug examples: King of the Ether Throne
- 19. | 19 Bug examples: King of the Ether Throne It is little mistakes like these which can cause a lot of havoc if not corrected in time.
- 20. | 20 Bug examples: King of the Ether Throne When it comes to smart contract coding, attention to detail is of paramount importance to avoid smart contract vulnerabilities.
- 21. | 21 Bug examples: batchOverflow
- 22. | 22 Bug examples: batchOverflow
- 23. | 23 Bug examples: batchOverflow It is little mistakes like these which can cause a lot of havoc if not corrected in time. When it comes to smart contract coding, attention to detail is of paramount importance to avoid smart contract vulnerabilities.
- 25. | 25 Challenge of many standards and protocols
- 26. | 26 Challenge of many standards and protocols As with any rapidly developing field, there has been a chorus of calls for standardization. Items that could be targets for further standardization: ● Basic data models for Blockchain (Blocks, Events, and State Machine) ● Consensus algorithms (Proof of Work, Stellar Consensus, Hashgraph) ● Storage algorithms (Merkle Trees, MerklePatriciaTries, Linked Lists) ● Signature algorithms (JOSE Web Signing, Linked Data Signatures, Chainpoint) ● Web-based access protocols (Cre-ate, Read, Add, Get Status, Query)
- 27. | 27 Hard fork, soft fork, chain split and replay attack Introduce a limitation on what is valid. New versions of software simply stop producing some forms of transactions / blocks, etc. which were previously valid. Soft fork Introduces new features which old versions of software do not support or recognise as valid. Forward- incompatible. Hard fork Old software continues to accept data created by new versions - the data will simply lack certain features. Old version of software will discard data created by new versions - often because it has features it doesn't know how to handle.
- 28. | 28 Hard fork, soft fork, chain split and replay attack Chain split is a scenario where there are two or more competing versions of the blockchain that share the same history up to the point that their rulesets diverge. Chain split It is possible for both a soft fork and a hard fork to cause a chain split.
- 29. | 29 Hard fork, soft fork, chain split and replay attack If you own some amount on the ledger before the split, you will have the same amount on both ledgers after the split. What if you want to spend money on one ledger and not on the other? Replay attack
- 30. | 30 Common security concerns 1. Wallet compromise / password stealing / social engineering*. This one is most common by far. 2. Politics. In case of Bitcoin, influential people have continually steered the course of development to their personal benefit. 3. 51% attack. The way distributed consensus works, the majority wins. So if 51% of all miners decide to run an executable with a certain set of rules, they control the blockchain. 4. Transaction selectivity attacks. Miners (esp. if colluding) basically have the power to pick which transactions go into blocks, and (sometimes more importantly) when.
- 31. Hire the top 3% of freelance talent http://bit.ly/HireToptal http://bit.ly/DevToptal LinkedIn: bit.ly/MarcoQA marco.felizardo@toptal.com Muito obrigado! Thank you! Questions? QA Automation Engineer