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

With Ethereum, it’s becoming a lot easier to put data on the blockchain. There are a variety of reasons why one might want to do so. For us, at Storm4, it had to do with security.

We wanted a way to prove that a user’s public key has not been tampered with. With Ethereum, this becomes a rather straight-forward task:

• code a contract that allows a user’s public key to be stored once, and ONLY once
• deploy contract to the blockchain (contract/code is now immutable & public)
• server code stores public keys in contract
• client code uses contract to verify public keys (their own, and others)

Of course, the translation between theoretical concept and actual implementation takes some work…

In this series of blog articles, I’m going to walk you through all the steps necessary to get up and running. And while I’m going to be focused on the perspective of native app developers, hopefully there’s some information that others would find useful as well.

Interacting with Ethereum

When interacting with a contract on Ethereum, there are 2 types of function invocations you can make:

• a “call” is any function invocation that is simply reading state data. That is, it isn’t attempting to modify storage within the blockchain. It’s just reading what’s already there.
• a “transaction” is any function invocation that IS modifying blockchain storage. Or that has the potential to do so.

(In Solidity, functions that are ‘calls’ are marked ‘constant’. So one can quickly identify what the situation is for any function in a contract.)

In Ethereum, “calls” are free. You can make “calls” all day long. But “transactions” are not — they cost money. (This is because “calls” can simply be executed by a single Ethereum node. They don’t have to be mined.)

Which means putting data on the blockchain will cost money, payable in ether (the cryptocurrency of Ethereum). From the perspective of a native application developer, this means you have 2 choices:

1. Have the clients (iOS app) put the data directly into the blockchain themselves. Which implies they personally own ETH. And there’s some secure cryptocurrency wallet installed on their system, with an available framework for you to use from within your app. (Or you supply something equivalent directly within your app.)
2. Have your server handle it.

This is the reality of today. Someday in the near future, #1 will be the clear choice. But for now, if you’re not making a DApp, then you’re probably stuck with #2.

But while this isn’t ideal, it’s not necessarily a deal breaker. Remember, the clients can still issue “calls” to an Ethereum node for free. So while it may be (currently) vastly easier to perform the Blockchain writes via your own server, the client is still free to verify your transaction via any public Ethereum node in the world.

Client vs Server

So for the act of writing data to our Ethereum contract (which costs money), we’re going to allow our server to handle it. This means we can handle purchasing ETH ourselves. And we can provide a simple HTTPS API for the native client app to use. But while this is convenient, it also decreases decentralization and therefore trust. Luckily we can combat this problem on the client side.

For the act of reading data from our Ethereum contract (which is free), the clients can directly interact with ANY Ethereum node in the world. In fact, they can interact with multiple Ethereum nodes in order to decrease attack vectors. I bet we could even come up with some kind of round-robin scheme.

Good news & Bad news

How do we interact with a contract on the Blockchain ? How does that work ?

There’s good news, and bad news.

The good news is that Ethereum has defined an RPC protocol that you can use to talk to Ethereum nodes. It also defines how you would go about using this RPC protocol to call a function within a deployed contract.

Here’s the 10,000 foot overview:

When you compile a contract, you get 2 things. One is the compiled code in raw form, that’s ready to be deployed to Ethereum. The other is the contract metadata, which is a JSON document that describes the contract, its functions, the corresponding parameter types & return type, and other such pertinent information.

Now, given this contract JSON, there are libraries that are able to do all the heavy lifting for you. For example, there is an official javascript library called ‘web3’, where you can basically feed it the contract JSON, and then proceed to make calls against your contract. The library automatically handles converting your javascript parameters to the proper contract types, invoking the RPC protocol, parsing the response, and giving you back an easy-to-digest result.

The bad news is that support for this RPC protocol has been absent in Swift/Obj-C. However, there is an exciting new project that is working on it: ethers.objc

And while it provides a ton of value, at the time of this writing, it doesn’t yet handle the contract JSON/ABI stuff…

Recommendations

It’s best to learn to walk before you try to run.

We know what our end goals are for the client and the server. And while there may be some unanswered questions about the client RPC stuff, there’s still a TON of work to be done before then:

• learn how to write a contract in Solidity
• learn how to deploy it & test it
• learn how to interact with it for our server
• learn how to setup the client facing API

Coming Soon

So in the next blog post we’ll dive in, and learn about the development tools to write a contract in Solidity, and deploy it to a test network.