Putting Stuff on the Blockchain — for iOS developers — part 2

Robbie Hanson
Storm4
Published in
6 min readOct 2, 2017

In part 1, we gave an overview of the Ethereum landscape, from the perspective of native app developers. And now we’re ready to jump in and start testing some code.

At the end of this post you’ll have a working contract, deployed to a test blockchain. And you’ll be able to issue HTTP calls in order to interact with the contract. So let’s get started.

Installing stuff

First, let’s install Node.js on your Mac. (If you don’t already have it installed.) If you have homebrew installed, this is as easy as:

brew install node@6

And once you’ve got node installed (which comes with NPM), you can install truffle:

npm install -g truffle@beta

Make sure you’re using truffle v4.0 or later, as we’re going to be dependent on some features added in v4. (At the time of writing, “v4.0.0-beta.0" was used.)

Introducing Truffle

Now we’re ready to see some code. We’re going to start with a throwaway project, just to see what this truffle thing is like.

$ mkdir test
$ cd test
$ truffle init

After initializing an empty project with Truffle, you’ll have a basic setup that will enable you to easily write code (in Solidity), and deploy it to an Ethereum network.

Take a moment to look at the files that truffle created for you (all within that ‘test’ directory).

Truffle is a framework that solves a bunch of problems for you:

  • How do I compile my contract code ?
  • How do I deploy my compiled code to the Ethereum network ?
  • What’s the address of my deployed contract ? (Which is required knowledge in order to interact with it.)
  • What about switching between different Ethereum chains (private vs test vs foundation) ?
  • How do I automate all this stuff so the entire process is more akin to clicking the “run” button in Xcode ?

The answer to all those questions is Truffle. You can use truffle to deploy your contract(s), and it will:

  • compile your contracts
  • talk to the local Ethereum node to figure out which chain you’re deploying to
  • deploy your contract(s) onto the blockchain
  • updates an “artifact” file with the information containing the contract’s address (for the specific chain), and the contract’s ABI that was deployed to that address

Feel free to explore this test project. When you’re done, you can delete it.

Solidity

The programming language we’ll use to write the contract is Solidity. Like any programming language, there’s a bunch of stuff you’ll want to learn, so it’s best to browse the docs for a bit.

After you’ve answered any burning questions you might have had, let’s take a look at a full server solution.

Hello Ethereum

Go ahead and clone our test project:

git clone https://bitbucket.org/4thA/helloEthereum.git

Here’s what you’ll find in the project:

- /contract/
You’ll notice this folder was created with `truffle init`,
and contains a familiar layout.
- /contract/contracts/HelloEthereum.sol
This is our simple key-value storage contract.
It allows a value to be set for a key once, and only once.
- /site.js
Our node.js application which runs a web server,
and interacts with the deployed contract.
- /node_modules
All of the dependencies used by ‘site.js’.

Test stages

As with all programming, you’ll want to test your code before you release it. With Ethereum, it’s generally recommended that you do so in stages.

  1. First, you’ll deploy your contract to a “fake” blockchain that’s running on your own machine. This is a mock Ethereum server that isn’t interacting with any other machines, but provides all the API’s a real server would offer. You already have one installed. It’s built into Truffle.
  2. Next, you’ll deploy your contract to one of Ethereum’s test chains. (We’ll use the Kovan test chain.) This means running a real Ethereum node, that’s syncing with the rest of the world. And you’ll need to spend test ETH (not real ETH) in order to issue transactions.
  3. And finally, when you’re ready, you can deploy your contract to a real chain. And you’ll spend real ETH in order to do it.

Let’s run it

Still got that Terminal open ?

$ cd path/to/cloned/helloEthereum
$ cd contracts
$ truffle develop
Running development blockchain at http://localhost:9545/...
Truffle Develop started.
truffle(develop)>

Now you’ve got a “fake” blockchain running on your machine. (This is generally referred to as TestRPC. It’s a separate project, but comes embedded in Truffle v4.) Let’s deploy our contract to it.

truffle(develop)> deploy
Using network ‘develop’.
Running migration: 1_initial_migration.js
Replacing Migrations…
… 0x3e3b39f6f1d2eaf38b3c61fa7b93e692ca676f5630b6077d198b369167b97bdf
Migrations: 0x3ed10fd31b3fbb2c262e6ab074dd3c684b8aa06b
Saving successful migration to network…
… 0x429a40ee574664a48753a33ea0c103fc78c5ca7750961d567d518ff7a31eefda
Saving artifacts…
Running migration: 2_deploy_contracts.js
Replacing HelloEthereum…
… 0x9f2e038a5ec173a01f245d8a0bb0239e6ce552484c0fb8ab3149dae1c6ae5f1b
HelloEthereum: 0x377bbcae5327695b32a1784e0e13bedc8e078c9c
Saving successful migration to network…
… 0x6e25158c01a403d33079db641cb4d46b6245fd2e9196093d9e5984e45d64a866
Saving artifacts…
truffle(develop)>

So what the heck just happened ?

It just deployed 2 contracts for you:

  • Migrations.sol
  • HelloEthereum.sol

It’s a bit confusing at first, but there’s nothing to worry about. If you were creating a big Solidity project, you might end up with several contracts that all communicate with each other. And the Migrations contract is just part of how Truffle manages all your contracts, which of them have been deployed, and to which chain. To show you what I mean, let’s try it again:

truffle(develop)> deploy
Using network ‘develop’.
Network up to date.
truffle(develop)>

This time it didn’t do anything, because it knew it had already deployed all the contracts.

Keep in mind that our TestRPC is completely in-memory. So if we quit, and relaunch, it won’t remember anything. But Truffle will figure it out for us. Let’s see this in action:

truffle(develop)> .exit
$ truffle develop
Running development blockchain at http://localhost:9545/...
Truffle Develop started.
truffle(develop)> deploy
Using network ‘develop’.
Running migration: 1_initial_migration.js
Replacing Migrations…
… 0x3e3b39f6f1d2eaf38b3c61fa7b93e692ca676f5630b6077d198b369167b97bdf
Migrations: 0x3ed10fd31b3fbb2c262e6ab074dd3c684b8aa06b
Saving successful migration to network…
… 0x429a40ee574664a48753a33ea0c103fc78c5ca7750961d567d518ff7a31eefda
Saving artifacts…
Running migration: 2_deploy_contracts.js
Replacing HelloEthereum…
… 0x9f2e038a5ec173a01f245d8a0bb0239e6ce552484c0fb8ab3149dae1c6ae5f1b
HelloEthereum: 0x377bbcae5327695b32a1784e0e13bedc8e078c9c
Saving successful migration to network…
… 0x6e25158c01a403d33079db641cb4d46b6245fd2e9196093d9e5984e45d64a866
Saving artifacts…
truffle(develop)>

What’s nice is that, while TestRPC is completely in-memory, a real blockchain won’t be. But Truffle handles all this stuff for us, and we don’t have to think about it as much.

Inspecting build output

If we look at the output above, Truffle told us which address it deployed our “HelloEthereum.sol” contract to: 0x377bbcae5327695b32a1784e0e13bedc8e078c9c

(When you run this on your own machine, the actual address could be different. Theoretically.)

Truffle also created the following file:

  • /contract/build/contracts/HelloEthereum.json

Go ahead and take a look at this document. There are 2 things to note:

  1. There’s a section called “abi”, which contains a JSON description of our contract’s functions, parameter types, return type, etc.
  2. There’s a section (generally at the very bottom) called “networks” that contains the deployed address. Thus in my version it looks like this:
“networks”: {
“4447”: {
“events”: {},
“links”: {},
“address”: “0x377bbcae5327695b32a1784e0e13bedc8e078c9c”
}
},

Note: `4447` is the networkID of TestRPC. Other networks have different networkID’s. For example:

  • Foundation (mainnet): 1
  • Kovan (testnet): 42

Interacting with our contract

Here’s where we should be at:

  • You have a terminal window open that’s running `truffle develop`, and thus you have a TestRPC client running (on port 9545)
  • You’ve deployed the “HelloEthereum.sol” contract to TestRPC
  • Truffle created the “HelloEthereum.json” file for us

That’s everything we need in order to interact with our contract. Now we’re ready to run the “site.js” file, so open up a new Terminal tab:

$ cd path/to/cloned/helloEthereum
$ node site.js truffle
Server listening on port 8080

And now we can test it (in yet another new Terminal tab):

$ curl -X GET "http://localhost:8080/helloEthereum?key=foo" -w "\n"
{"key":"foo","value":null}

It’s alive ! Let’s try setting a value for the key “foo”:

$ curl -X POST "http://localhost:8080/helloEthereum?key=foo&value=bar" -w "\n"
{"result":true,"key":"foo","value":"bar"}
$ curl -X GET "http://localhost:8080/helloEthereum?key=foo" -w "\n"
{"key":"foo","value":"bar"}

Our contract specifies that a value (for a specific key) can be set once, and only once. So let’s try it again:

$ curl -X POST "http://localhost:8080/helloEthereum?key=foo&value=bar" -w "\n"
{"result":false,"key":"foo","value":"bar"}
$ curl -X POST "http://localhost:8080/helloEthereum?key=duck&value=quack" -w "\n"
{"result":true,"key":"duck","value":"quack"}

Voilà !

You now have a working contract, and some server code that’s capable of interacting with it. Feel free to dive into the “site.js” code to find out how it works.

In part 3 we’ll setup a real Ethereum node, and start testing on the (test) Kovan chain.

--

--