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

Robbie Hanson
Storm4
Published in
6 min readOct 11, 2017

In part 1 we gave an overview of the Ethereum landscape, from the perspective of native app developers.

In part 2 we deployed a contract to a private network, and learned how to interact with it from our server.

In this post we’re going to deploy to an Ethereum public test network, and learn how to publicly verify the source code of our contract.

Installing Ethereum server

The Ethereum server of choice for most people is Parity. We can install it easily using homebrew:

$ brew install parity

Now let’s configure it before we run it.

$ nano "~/Library/Application Support/io.parity.ethereum/config.toml"

And then add the following content to that file:

# More information on configuration:
# https://github.com/paritytech/parity/wiki/Configuring-Parity
[parity]
# Kovan Test Network
chain = "kovan"

There are a lot of configuration options available to you. In addition to the documentation, parity has a config file generator that’s quite handy.

Now, we’re ready to run it:

$ parity

Some important stuff you might want to know about parity:

  • You can find out how much disk space the Ethereum blockchain data is using (on your machine) by looking in `~/Library/Application Support/io.parity.ethereum/`. On my machine, the Kovan network is currently taking up 4.54 GB.
  • The parity server has something called warp sync (enabled by default) that downloads snapshots of historical data. This means your server will be up-and-running in a matter of minutes after starting it for the first time. So if you’ve heard horror stories about Bitcoin nodes needing multiple days to sync the Blockchain… you won’t have to worry about that here.
  • The parity server has a pruning feature (enabled by default) that “prunes” old transaction data. This confused me at first, but here’s what it means: Every contract has a “current state”. That is, the current values of all instance variables. “Pruning” means the server will keep the “current state” of all contracts, but will delete old states once they get old enough. For most use cases, this is actually preferred.

Parity UI

With your parity server running, open up your browser, and go to: http://127.0.0.1:8180

Then follow the instructions to create an account.

Note: You’re NOT creating an account with a 3rd party company here. You’re just creating an Ethereum account, which effectively means you’re generating a public/private key pair. And parity is walking you through the process of associating a password with the account, and backing up your key.

Getting some test Ether

Ether for the test network (Kovan in this case) is free. But you have to jump through some hoops to get it. Which is actually a good thing.

The previous test network (Ropsten) suffered spam attacks by some bad actors. From what I understand, these people were able to sustain their spamming due to the fact that they could get very large amounts of Ether for the testnet rather easily.

Thus, the Kovan testnet introduces the concept of the “Faucet”. There are multiple ways in which to get test Ether from the faucet, as described here.

I used the “Github Gist” solution. It took all of 60 seconds, and I had plenty of Ether in my account.

Deploying to Kovan

At this point you should have:

  • Parity server running in Terminal (on Kovan)
  • An account with some test Ether in it
  • Your web browser open to the partiy UI
  • And `truffle develop` is NOT running. (From part 2, we know this would mean TestRPC is running. Which isn’t what we want here. We want to interact with our parity server now.)

Now, open up another terminal and type:

$ truffle deploy
Using network ‘development’.
Running migration: 1_initial_migration.js
Deploying Migrations…

You’ll see it “freeze” here, which is because you’re attempting to spend Ether. So, by default, Parity needs you to manually authorize the transaction.

Check your web browser, and you should see the partiy UI page prompting you to enter the account password. Go ahead and authorize it.

It will prompt you for authorization a total of 4 times. (Corresponding to each of the 4 transactions the ‘truffle deploy’ process will initiate.) And after it’s done, you’ll notice all 4 transactions appear under the account details (in the parity UI).

Congratulations! Your contract is now deployed to the public Kovan test network.

Time to test it out.

Transactions on Kovan

Similar to part 2, we can run the `site.js` file to get a web server which will communicate with the Ethereum server. (In this case Parity, instead of TestRPC.)

$ node site.js
Server listening on port 8080

Note: We did NOT include the `truffle` flag this time. This is important, because truffle’s TestRPC server runs on a different port. Thus the `truffle` flag is being used to switch between the standard Ethereum RPC port, and the one truffle uses.

Communicating with our web server is the same as in part 2:

$ curl -X GET "http://localhost:8080/helloEthereum?key=foo" -w "\n"
{"key":"foo","value":null}
$ 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"}

Just as when deploying your contract, in order to actually spend Ether, you’ll need to approve the transaction within the parity UI. So the `POST` operation will freeze until you complete this step.

This makes sense as a default setup. But for an automated server process, we’ll need to find a way around this problem. So let’s do that now.

Unlocking parity account

As we did earlier, we need to configure parity:

$ nano "~/Library/Application Support/io.parity.ethereum/config.toml"

And then update your config file to look something like this:

# More information on configuration:
# https://github.com/paritytech/parity/wiki/Configuring-Parity
[parity]
# Kovan Test Network
chain = "kovan"
[account]
# Send tranasactions without password.
unlock = ["0x0020DA1DD324C8E5C06dBeEe8897F7AB51F8A3aB"]
password = ["/some/path/to/parity/passwords.txt"]

Just change it to use your own account address, and some path that makes sense on your system. Note: parity seems to struggle with password paths that have whitespace in them. So watch out for that.

The only thing you need to put in the password file is the password. Once you’ve done that you can shutdown the existing parity server (if it’s still running), and then re-run it like this:

$ parity — force-ui

(Without the ` — force-ui` option, parity won’t let us access the UI anymore. This is a security precaution due to the fact that you’ve unlocked an account.)

And know you’ll be able to spend Ether without being prompted everytime:

$ 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"}

Etherscan.io

All of the transactions on the Ethereum blockchain are public. And a great resource to view activity is Etherscan.io.

For example, here’s the HelloEthereum contract that I deployed to Kovan: https://kovan.etherscan.io/address/0x8967ce624d822e583b5c8835ad6a89ec332b71ab

You can see when the contract was created (Oct-05–2017 03:51:31 PM +UTC), as well as all the associated transactions since then. But what’s especially valuable is that you can actually READ the contract source code, and download the contract ABI. And the contract ABI is the only thing you need to interact with the contract in code. In fact, this is what `site.js` ultimately uses to invoke methods on the HelloEthereum contract.

Thus anybody would be able to interact with this contract now. Not only that, but they can be guaranteed (due to how the contract was written, and the fact that the contract is immutable) that `foo` will always return `bar`, and that `duck` will always return `quack`.

After you publish a contract, you can also publish the source code. You can do that [here](https://kovan.etherscan.io/verifyContract2). The default settings will work for truffle (optimization enabled, with 200 runs). The only thing you’ll need to know is which compiler was used:

$ cd /usr/local/lib/node_modules/truffle
$ npm list | grep solc
└─┬ solc@0.4.15

--

--