At the highest level the Deloitte executive briefings provide an excellent overview of implications of the idea of blockchains, bitcoin itself and other clones. There are many of them, here is one: [ ]. Here are several others: . To see the incredibly rapid change in the industry look here; [ ].

Ethereum itself… Ethereum and Bitcoin are examples of blockchain based applications. Ethereum is more flexible in that it can run user defined contracts. There are many tutorials on getting up to speed on Ethereum [ ]. Another great overview is this one : . Here’s another overview as well [ ]. Truffle has a good campfire story going over the history from scratch as well [ ].

Blockchains… A blockchain is an idea of having a shared public database which is maintained by all parties around the world. All parties keep a copy of all data. There are various techniques to synchronize the database state and to prevent bad actors from writing arbitrary state to the database. Many different organizations are looking at ways to make blockchains scale better since there are currently some scaling issues with respect to number of transactions that can happen per hour and with respect to storage (it can be expensive to store the entire blockchain and it may become necessary to just store fragments or hashes of a blockchain). There are many separate blockchains running concurrently in the world today. [ ]. A blockchain acts as a public ledger of transactions in the case of both Ethereum and Bitcoin. There are many people trying to do a better job because of criticisms of the computational costs. See: [ ] . Also see: [ ]. As well: [ ]. However many of these so called improvements are not open source and are themselves unproven. Others are critical of attempts to reduce the costs of blockchain: [ ]. Here’s another critique of ethereum [ ].

History… It’s worth reading the original paper here which kick-started a lot of this revolution: [ ]. Briefly here is some of the early history (of which many contributors are still active today):

Wallets and accounts… Using the ethereum network you first make a private/public key pair which exists on the blockchain and which can hold some amount of ether. A wallet is a smart contract — often managing the flow of money. Note that bitcoin and ethereum are totally separate universes and they each implement things like currency differently [ see ].

Communities… Ethereum has several communities that are worth joining especially if you are looking for people to talk to or developers. There are also many apps and many contracts that are visible. The practice is to make ethereum source code public for verifiability — many projects are hosted on github. Also see [ ]. Of course forums such as should be known to all readers.

Existing apps… there are many ethereum apps coming out. Right now one promising one is Filecoin. There are many others. One collection of ethereum apps is here [ ].

ICO’s… There are many ICO’s as well — see for an example of one family of related projects. There are turnkey ICO launching services now such as . And there are teams that will build your ICO for you. See also [ ].

User facing UX dev tools… There are a variety of user facing applications for interfacing both with existing Ethereum apps and for creating your own. Like any database, the ethereum blockchain is not natively visible to the web, so some kind of wrapper is needed. Look at Metamask or Mist for examples here. For our purposes Meteor is a nice way to wrap up an ethereum app with a user interface [ ].

Core development tools… For actual development and programming of ethereum apps Truffle looks like the clear winner — it is basically a collection of tools not unlike a makefile or build system — see [ ] . There are also excellent tutorials [ ].

Programming theory..

Programming best practices...

Programming ethereum core principles…

Designing your app in Ethereum requires thinking about the contracts or agreements that exist between the parties. There are multiple separate layers of consideration. There are the core contracts defining the app (and any ether that is involved). There are dApp wrappers so users can interact with it on the web. And there is also likely a crowd-sale contract for handling your ICO if you have one, or however it is that you choose to distribute any tokens that represent access to the service you’re providing. You don’t need to use a token based approach at all of course.

Setting up an ethereum testbed…

It’s easy to do it privately, but I wanted to do a full blown test with other developers and visible to casual users; basically what could become a website. My approach was I spun up an instance of Ubuntu 17.10 on Google Cloud — giving it extra disk space since often disks are too small. There are several ways to set this up such that you have geth running with some initial amount of ethereum in your account (although mining is easy on your own instance as well). See [ ]. Here’s what I did:

  1. Sshed into that box, elevated to root and installed nodejs, npm, truffle and ethereum — here are reasonable instructions for the last [ ] — I used ‘apt install ethereum-unstable’ for 17.10.
  2. I wanted to setup my own ethereum instance with some default ether in it to play with. Using testrpc looks useful but I’d like to play more with geth. It’s slightly annoying to configure so I made a small script to do it:
  • rm -R -f ~/.ethereum_private
  • mkdir ~/.ethereum_private
  • address1=$(geth — datadir ~/.ethereum_private — password <(echo whatawonderfulday)
  • account new | sed ‘s/Address: {//’ | sed ‘s/}//’)
  • echo “Made account $address1”cat > genesis.json <<- EOM
    { “config”: { “chainId”: 15, “homesteadBlock”: 0, “eip155Block”: 0, “eip158Block”: 0 }, “difficulty”: “400”, “gasLimit”: “2100000”, “alloc”: { “$address1”: { “balance”: “30000” } } }
  • geth — datadir ~/.ethereum_private init ./genesis.json
  • geth — datadir ~/.ethereum_private — password <(echo whatawonderfulday) — unlock 0 — fast — cache 512 — ipcpath ~/geth.ipc — rpc — rpcport “8545” — rpcaddr “” — rpccorsdomain “*” — port “30303” — rpcapi “personal,db,eth,net,web3” — mine console

Note that for metamask you may have to do the following magic incantation and wave a dead chicken over RPC with this [ ].

At this point (from the console) it’s easy to check your balance:

  • eth.getBalance(eth.accounts[0])

And if you setup your firewall rules ( or if you’re on EC2 etc do whatever is the right thing there — and expose port 8545 (to tcp4 not tcp6) — then you can do a remote curl query easily enough as well:

  • curl -X POST — data ‘{“jsonrpc”:”2.0",”method”:”web3_clientVersion”,”params”:[],”id”:67}’ -H “Content-Type: application/json”

Or you can use geth to attach to geth…

Using testrpc instead…

  • Metamask has a mnemonic incantation it can use…
  • testrpc -a -m “candy maple cake sugar pudding cream honey rich smooth crumble sweet treat” — gasLimit 1111115141592

Using Truffle Examples…

Building and pushing and poking at Contracts…

  • Still — a few handy incantations that can be run from the truffle console or as a raw piece of nodejs code on a server
  • Truffle really is the easiest best way to build and manage contracts. I tend to end up using truffle migrate — reset out of paranoia.
  • Truffle console operations to talk to a truffle visible contract is excellent.
  • let accounts =0;
  • web3.eth.getAccounts(function(err,res) { accounts = res; });
  • let myresult = 0;
  • MyContract.deployed().then(instance => instance.mySpecialMethod(accounts[0])).then(result => myresult= result)
  • Some people may not be familiar with es6 notation — older notation is also totally fine:
  • MyContract.deployed().then(instance => instance.mySpecialMethod(accounts[0],{from:account[0]})).then(function(result) { myresult= result })
  • I personally had some kind of strange bug in this truffle handler : node_modules/truffle-contract/contract.js
  • I circumvented it by hacking at Async to make it synchronous:
  • Provider.prototype.sendAsync = function() { return this.provider.send.apply(this.provider, arguments); };
  • There is a secret parameter that can be passed to a contract method that does any actual work such as changing state on the blockchain—hardly documented but nothing works without it — see {from:account[0]} .
  • See this note: We passed an object as the third parameter to sendCoin. Note that the sendCoin function in our Solidity contract doesn’t have a third parameter. What you see above is a special object that can always be passed as the last parameter to a function that lets you edit specific details about the transaction. Here, we set the from address ensuring this transaction came from account_one. [ ]

The existing examples do work if they’re very carefully babysat. They’re a bit glitchy — don’t refresh, sensitive to state initialization, there are upper and lower gas limits that make it hard to test on anywhere that isn’t the testnet, require browser plugins (metamask) and CORS settings on the server to permit metamask to work… and it all feels fragile…. but it does seem possible to build web apps that can do transactions over the ethereum network.

Trying to think through how people actually will in the future interact with these services. It’s a bit of a different model than what I think we’re used to. Today the commitment to make a purchase is a somewhat heavy transaction. Users enter their credit card or paypal and the browser isn’t really thought of as a wallet per se — but rather just a kind of kiosk or gateway. I’m imagining the future of web based purchases or transactions that require a signature to be more like metamask — where some kind of identity or signing authority is attached to your browser and you use it often to certify transactions.

Once you’ve wrapped your head around the basics — the question becomes more what are the kinds of services that can be built around these ideas. And in fact basic token exchanges, acting as a way to fund projects early, while giving liquidity to participants, looks like a totally reasonable way to do all this.

SFO Hacker Dad Artist Canuck @mozilla formerly at @parcinc @meedan @makerlab