Introduction With the rise of based crypto currencies, smart contracts have become increasingly more popular. blockchain Crypto startups are utilizing smart contracts to create intelligent agreements that can be executed in a “ ” environment. Smart contracts take out the middleman and execute on contract terms automatically, based on rules put in place. Although smart contracts harbor a lot of promise, we have seen a worrying history of hacked smart contracts, where hundreds of millions of dollars worth of crypto currencies have been lost or stolen. trustless My growing interest in crypto currencies and blockchain based has led me to research and investigate these hacks, to gain a better understanding of technology how they were hacked. , where we will dive deep into the most infamous hacks. This article is part 1 of a 3 part series We will study how strokes of genius, or subtle mistakes caused earthquakes in the crypto world. Aside: This article is based on the amazing lecture of at I highly recommend watching this talk, and all other materials on the channel. Leonid Beder Blockchain Academy — How to Not Destroy Millions. Kin Ecosystem Foundation Youtube Smart Contracts A smart contract is a set of promises, specified in digital form, including protocols within which the parties perform on these promises — Nick Szabo, 1996 Let’s break down this definition term by term. Contract An example of a common contract is a . sales contract The seller to deliver the goods in exchange for the buyer. promises The buyer to pay the desired price. promises Digital form means that the contract has to be programmed in machine readable code. We want the contract to be Digital form deterministic in nature, thus providing the same outcome based on the same input, every single time. Protocols For example, say the parties agree that the purchased good is to be paid in Bitcoin. The obvious protocol of choice would then be the Bitcoin protocol. Smart this just sounds cool. Popular implementation of smart contract programming languages Ethereum Implements a nearly Turing-complete language on its blockchain, a prominent smart contract framework. We say nearly Turing-complete b/c in order to be completely Turing complete we need unlimited computational power. Bitcoin Implements a Turing-incomplete scripting language that allows the creation of limited smart contracts, such as: multisignature accounts payment channels escrows time locks atomic cross-chain trading oracles Solidity by Example Solidity is an OOP language for writing smart contracts (mostly?) on Ethereum. We’ll start with a simple example of a smart contract named Greeter, which will: Initialize with a greeting message (eg., “Hello World!”) Provide a method to read/query the greeting message. Provide a method to write/modify the greeting message. For these examples we will use the official online Remix IDE found @ https://remix.ethereum.org It is best practice at the moment to specify explicitly which version of solidity we are using, because we don’t know which bugs can be introduced in future releases. Solidity has a similar syntax to JS. We are defining a contract named Additionally, we have a public state variable of type string called greeting and two methods (constructor and setGreeting). Greeter. Fundamentals: Execution Model Every smart contracts needs to be compiled to byte code before it can be deployed to the network. Deployment means being stored on the Ethereum network. This can be a production, test or private network. Every transaction or message call in Ethereum is executed by the Etherum Virtual Machine (EVM) on every Ethereum node. (miner or just a full node). Since is running on the EVM, and is executed simultaneously by in the network — there should a mechanism to used by each contract. The mechanism that limits resources in Ethereum is gas. every smart contract every single operation every node limit the resources Every operation executed has a deterministic (yet sometimes hard to predict) cost measured in units of gas. It’s hard to determine gas costs because conditional control flows can change which operations get executed in run time. Image the following program if (condition is true) { // do something super simple which is very cheap in gas terms } else { // do something really complicated which will be very expensive! } Every gas unit consumed by a transaction must be paid for in Ether, based on a gas/Ether price which is set by the sender of the transaction. Each sender determines what he’s willing to pay. The idea is the more important or urgent it is to you, the more you’d be willing to spend. Transactions have also a on how much gas the transaction can consumer gas limit parameter that is an upper bound Why is the gas limit parameter needed? We have an upper bound b/c it isn’t always clear how much the execution of a transaction will cost, and we want to cap how much Ether we spend on it! Let’s upload the contract to the Remix IDE, create and deploy it. Remix can work against main net and test nets. It’s really convenient to work against an Ethereum simulation. When using the simulation we can pretend to have millions of Ether, and not wait on Ethereum transactions to be processed which make development a lot faster. Running smart contracts via Remix is completely free, so I recommend you give it a try at home :) Once the contract is deployed we see it in the Deployed Contracts section in the box (see the arrow!). Notice that we can easily change the constructor argument and redeploy to the network. Fundamentals: Special Variables and Functions There are special variables and functions which always exist in the global namespace. Here are the ones we’ll discuss today (Ethereum address): sender of the message (current call). Thsi belongs to the original caller of the transaction. This can either be a users account or the address of another smart contract. The Ethereum security model guarantees that msg.sender cannot be faked. msg.sender (unit): number of wei sent with the message. wei is the smallest unit of Ether (think cents to dollars.) So this specifies how much ether we are sending with the function for buying, transacting, etc... msg.value Fundamentals: Function and State Variables Visibility In Solidity, there are four types of visibilities: For functions: : can be called externally from other accounts / contracts. It is important to note that we cannot call this code from our script. We would need to create an additional transaction which would invoke this externally. This is very good for methods that need to be publicly accessible but you want to avoid using them in your own code. external (default) can be called by everyone. public : : can only be called internally from our smart contract or a smart contract that inherits from our smart contract. internal can only be called internally and only from the contract itself. private: For state variables: : can be accessed by everyone. Solidity automatically generates a getter for a public variable. public (default): can only be accessed internally and only from the contract itself. internal : can only be accessed internally and only from the contract itself. private Fundamentals: Function Modifiers Modifiers can be used to modify the behavior of functions. This lets us add functionality before, after or even around the invocation of the function. (Logging for example) Modifiers are very similar to before/after/around/hooks in other programming languages. For example, let’s augment our Greeter smart contract to: Have an owner (in our case, the deployer of the smart contract) Make sure that only the owner can further modify the greeting We’re going to see this pattern a lot, in the coming examples as well as in the wild. Additionally, let’s add a condition that says only the owner can change the greeting. It is important to note that require is a predicate in Solidity. If its evaluation returns false, then an exception is thrown, and all changes done in contract are completely rolled back. The underscore is equivalent to a yield. This basically means execute in this place the remaining code of the function. Fundamentals: Fallback Function A smart contract can have exactly one unnamed function. This function is invoked when a call to the contract is made and none of the other functions match the given function identifier. A common use for fallback functions is when Ether is being transferred to the contract. This triggers the invocation of the fallback function. So, in order to set up an account to be able to receive Ether the bare minimum (in most cases) is setting this function up. Fundamentals: Payable Modifier In order to receive Ether, . This is to protect us from accidentally sending ether to a contract that doesn’t expect it. every function must be marked as payable When sending Ether as part of a function call, the function must be marked as payable. When sending Ether directly to a contract, its fallback function must be marked as payable. If no such function exists, the contract receive Ether through regular transactions. cannot Events Example This is a fancy way to do some logging in Ethereum. Aside: We have a function called that logs returns and event. This could be useful for the case of having an off-chain client that reads the loggings and manages all the donations. Donate We have a function called which is (we added the payable modifier). We also have a function called which is , so sending Ether should fail in this case (payable modifier is missing). donate payable troll not payable Let’s deploy this contract to Remix so that we can verify the results of sending money via each of these methods. In the gif above we can see that invoking the method results in a transaction where a value of 5 wei is transferred, and when we invoke the method no money is transferred. donate troll Let’s Destroy Some Ether We can see in Reward that we have a mapping between We use an owner concept here so our owner can call the method, deciding that a specific address is supposed to get some amount of a magic token. Additionally, we have the method which is publicly accessible by everyone. This method gives you the reward that belongs to your address, and then emit an event for the reward. address and a uint. setReward claimReward Can anyone spot a problem with this? Notice that when we declare the mapping, it is a map from rewards address to unsigned integer. We are subtracting here without checking that the necessary funds are available! So any scenario where we reach a negative value in rewards will result in an underflow. Aside: A , will change what should be a negative value to an extremely large positive one. Check out the link, for a further explanation on how underflows work. n underflow Consider the following example. A reward claim of 500 units is made. Now, our hacker will try and claim 1000. In theory, this shouldn’t work because we only have 500 left. After running this transaction will have an infinite amount of coins! the claimer Bugs: Overflow / Underflow Solidity can handle up to 256 bit numbers is when a number gets incremented above its maximum value. So adding 1 to 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF results in 0. Overflow is the inverse case, when the number is unsigned, decrementing will underflow the number. This will work the other way around, where subtracting 1 from 0x00000000000000000000 results in 0xFFFFFFFFFFFFFFFFFFFFF. Underflow Mitigation #1: Test for Correctness Test for correctness before performing any operation. A quick fix for this is to implement a check to verify that the claim is smaller than the current account balance. Mitigation #2: SafeMath Always use the (de-facto) standard library. SafeMath Find nice, relatively stable, smart contracts in . OpenZeppelin’s Github repo What the library does is implement mathematical operations in a safe way, such that if an overflow occurs it rolls back the transaction. Assert is very similar to revert it rolls back bad transaction. In the example below we have imported SafeMath, injected it for use on , and therefore the library will revert any transactions that cause an underflow on line 30. unit256 Setting Function Visibility Can you spot an error in the Charity contract? Let’s break it down. We have a payable fallback function and a withdrawal function where the owner can withdraw his funds. You can imagine that at some point the owner may want to withdraw his funds so he can do something with them. Now, let’s take a look at the method. It’s using the owner paradigm. It has no privacy. Anyone can change the owner, thus transferring the funds to himself / herself. setOwner In Solidity functions are public by default! Hack Scenario: Alice deposits 1000 wei for this example. Bob tries to withdraw with but fails because he is not the owner of the charity. Now, Bob calls into setOwner, changing the owner to himself. Bob takes all the funds. All this because someone forgot to define visibility! Mitigation #3: Always Define Visibility! Always define visibility Limit function visibility when possible Conclusion This has been a primer on the Solidity language, and we have examined some of the simple, dangerous mistakes that can be made during smart contract development. The next post in this series will dive into infamous, genius and nuanced hacks, that have so far in the past several years. drained hundreds of millions of dollars worth of crypto If you’re looking for resources to ramp up on the blockchain world, I highly recommend (again) checking out the , as it has a wonderful inventory of high quality, technical discussions and lectures. Huge thanks to for building this lecture and teaching it at Blockchain Academy! Kin Ecosystem Youtube channel Leonid Beder If this post was helpful, please subscribe and click the clap 👏 button below to show your support! ⬇⬇ You can follow me on , and . Instagram Linkedin Medium
