Ethereum on a iPhone
Getting started with Ethereum apps on iOS
There is no installation package, build by the Ethereum community, ready for the iOS. But in a way it is possible to build something.
Let us start with the Ethereum client architecture to see what we have.
Ethereum is an example of a very fast growing blockchain implementation. Actually, Ethereum has surpassed Bitcoin in amount of nodes in the public network, at this writing moment, see the current number of nodes.
Ethereum is a cryptocurrency. Ether is the currency. Ethereum was created as a clone of the Bitcoin core, having its own blockchain network - a public, distributed ledger. The Ethereum network is called “P2P Wire Protocol Network”.
The most exceptional: Ethereum has a whole programing platform on top of its cryptocurrency, implemented in every client. The programs are called DApps, Decentralized Applications.
People are doing things in Ethereum that are not possible right now in Bitcoin. It has created a new generation of developers which never worked with Bitcoin but are interested in Ethereum. See story from Coinbase.
What is very real, though, is the possibility that Ethereum blows past Bitcoin entirely. See r3cev.com/blog/2016/5/29
Ethereum Client
Every node in the network is called a Ethereum Client — and it has nothing to do with a client-server architecture. There are only “clients” nodes in the Ethereum network.
Where the Bitcoin blockchain distinguish between a full-node, having a full copy of all transactions, and a lightweight node, having only what is needed for a wallet, the Ethereum has only full-nodes. But there is being working on a lightweight node, see what-should-i-install-on-a-mobile-tablet. Meaning, we must wait on the official Light Client for the mobile devices.
While we are waiting on a lightweight solution for iOS and Android, let us dive into the ‘full-node’ client architecture and see what we already have to work with.
The Ethereum Client consists of:
- Network routing, discover and maintain connections to other clients in the P2P Wire Protocol Network.
- The blockchain database, having a copy of all transactions.
- The mining, the work with creating, verifying, publishing and propagating blocks in the blockchain, ensuring consensus on all clients. And get the fee for that work.
- Maintaining the private/public keys pairs, encoded in a keyfile, saved only in that client, the user is using. The keys are the ownership of Ether, and the identity in the contracts.
- The DApps, ‘smart’ contracts, running on the Ethereum Virtual Machine, EVM, having states of the contracts stored together with the states of all accounts, saved on each client. Input/output of the contract’s functions are sent through the transactions on the blockchain. Transactions addressing contracts, are triggering the execution of them on the EVM.
The Ethereum Client is build to interact with network. As user interface, it has the command line interface for the developer. API to the client exists as JSON RPC endpoints exposed on top of HTTP, WebSocket and/or IPC transports.
The Ethereum community has more then 8 implementations of the Ethereum Client, see the list of clients. The most used are cpp-ethereum (C++), go-ethereum (Go) and pyethapp (Python).
The go-ethereum has the executable Geth, you access in the command line interface. The Ethereum Client is started by typing Geth console, and you are given the interactive javascript environment in the command line, in return. Attaching a running client, type Geth attach, and you are given the interactive javascript environment against this client in the command line.
Developing DApss
Contracts are EVM bytecode programs, running on the EVM in the client. To develop contracts, you code them using one of the following language available: Solidity, Serpent or LLL. Solidity is the most common.
For the chosen language, you must install the compiler for the language. It is not included in the client. Then the compiled bytecode can be delivered to the client through the command line. There are more ways to compile the code, see Compiling a contract. If the command line is used, you must give the source code in one line, and first remove end-of-lines. Use remove-line-breaks.
You creates a contract on the blockchain by sending a transaction to an empty address with the EVM bytecode. The whole process using Geth command line is described in Contracts.
Ethereum Mist Wallet
In marts 2016, a new major version of Ethereum, named “Homestead”, was released. This release included the Ethereum Mist Wallet.
This Wallet is one big installation package, containing the go-ethereum client, the Solidity compiler and a whole new UI-application:
Download it from github.com. Install it and open it. Follow the instruction, choose the TEST-NET for development. And let it run syncronizing — downloading blocks — for about 10–20 min. When finished, you create the main account. Then it is recommended to start mining. Find the menu item Start Mining, under Develop. You will, within 30 min., have enough Ether — from TEST-NET — to be able to create your first contract and other transaction, you want to send. It is only in the TEST-NET, it is so easy to mine some Ethers. In the upper right corner you see the amount of Ether, the Wallet contains. You can create another account and send some Ether to that account as well. Then you have two account that can interact with your contracts.
Creating contract is very easy, click on the CONTRACT ikon in the tool bar, then click on Deploy… — and start writing a contract. Examples, you can start with:
The Ethereum Mist Wallet is a great user app for the developer — for using the Ethereum blockchain, writing contracts and deploying them on the blockchain, sending transactions of any kind, watching contracts and showing latest transactions. It has a generic interface to accessing any contract and its functions.
But it is not an end-user application for other than IT-developers.
How to develop UI apps — in general?
When talking about an app, any webapp or mobile app, accessing the Ethereum Client, we are back on the command line and the API, using JSON RPC endpoints exposed on top of HTTP, WebSocket and/or IPC transports.
The interface language is Javascript in the interactive environment on command line. It is also Javascript in the Web3.js, which make life easy in interfacing with the JSON RPC.
Makoto Inoue has made a video tutorial about getting started with webapp interface to the Ethereum Client and using Web3. And he has made a github repo, where he has collected Web3.js with js-libs that it depends on, and a description on how to start Geth and how to make it accessable as a simple webserver.
- Clone the code
git clone https://github.com/makoto/homestead-for-dummies.git- Run geth in testnet mode allowing rpc call from local port 8000
geth --testnet --rpc --rpcaddr "127.0.0.1" --rpcport "8545" --rpcapi "db,eth,net,web3" --rpccorsdomain "http://localhost:8000"- Startup web server at the port you specified at geth — rpccorsdomain. On Mac you can use python that is included in the OS X.
python -m SimpleHTTPServer # defaults to port 8000- Open the page
open http://localhost:8000The JSON RPC accessed through Web3.js is not recommended to be used over public internet, but only used as a local interface.
Ethereum’s examples shows how to use Web3.js in a html/javascript webapp.
Where is the iPhone in this context?
Apple’s native language Swift — nice language — and the older one, Objective-C — before Swift, you had to live with it — share the same runtime environment and are the development platform for all the apps known from Apple Store.
Apple’s iOS7 was the first iOS version to officially support javascript as a mobile development language. It was part of the strategy of supporting the 2 development platforms:
- Native app: Swift/Objective-C platform
- Web app: HTML5/JavaScript platform
And they can both be included in the same app. Using the JavaScriptCore framework you are able to inject javascript from Swift or Objective-C programs within your native apps and get callbacks from the javascript directly into the Swift or Objective-C programs. It can be done in different ways, see the blog: javascriptcore-and-swift. As explained in the blog, the Webkit’s WKWebView is allowed to run javascript at full-speed, using the Safari-engine.
The solution is an app including JavaScriptCore using Web3.js against the Ethereum client, and use Apples native apps for the UI. And the JavaScriptCore framework must be running in a background thread within the app, just like normal internet-access should be handled. So the iPhone is always able to respond to incoming phone-calls or respond to common user interaction on the same app busy running interactions with the Ethereum in background.
The iPhone development setup
The development setup for this is:
This is not how the final solution should be. While we are waiting on the official Light Client to Ethereum, we can actually start developing end-user apps through the development setup, using a Mac as bridge to the Ethereum network.
We can start developing a real DApp having its own UI app designed for its contracts in Ethereum. Develop and deploy the contracts is done using Ethereum Mist Wallet. Developing the rest of it is done using the Xcode on Mac.
The coming Ethereum Light Client
The development setup will make sense, if we assume the following about the coming light client:
- It will contain network routing, discover and maintain connections to other clients in the P2P Wire Protocol Network. The network must be changed to prepare for communication with Light Clients.
- No blockchain database, but holding copy of own transactions, and holding status of own accounts.
- No mining.
- It will contain the private/public keys pairs, encoded in a keyfile, and the maintenance of them — for the users, using the Light Client.
- No contracts, no Ethereum Virtual Machine, but able to send transactions against contracts in the network.
The coming Ethereum Light Client could look like this — in a iPhone context:
Here the Light Client is directly connected to the P2P Wire Protocol Network. Web3.js will be updated to be able to access a Light Client, and the UI + JS-core would hopefully be able continuing without major changes. Hopefully.
