“The Blockchain” has become a real buzzword in computing these days, but often without a coherent justification. I think it’s because there are a lot of venture capitalists and entrepreneurs who are trying to remain really tuned in to the “next big thing” in technology. I personally cringe every time I hear business people talking about “the blockchain”, because it was never supposed to a tool to make money, or even be a part of business at all. It was always a hacker thing, meant to subvert businesses in many ways.

Distributed and trust-less computing was frequently discussed on the cipherpunks Usenet newsgroups in the 1990’s. Borne from the early excitement of the Internet, imagining newfound possibilities for an already established decentralized network of computers, our hacker grandparents envisioned a literal “crypto-anarchy”. The Blockchain was never explicitly tied to currency in its inception. Currency, a thing that is controlled by governments, inhibits free market capitalism¹, and empowers individuals was simply the killer application for it, especially to the crypto-anarchists.

It’s interesting that the concept of a blockchain or even a cryptocurrency hadn’t even been conceived in Tim May’s original email (linked above), it was only the ideology. It wasn’t until Wei Dai’s textfile about b-money did the idea of applying cryptography towards currency come about.

A community is defined by the cooperation of its participants, and efficient cooperation requires a medium of exchange (money) and a way to enforce contracts. Traditionally these services have been provided by the government or government sponsored institutions and only to legal entities. In this article I describe a protocol by which these services can be provided to and by untraceable entities.

I think the most interesting thing about this textfile was the fact that Dai had also envisioned smart contracts. Smart contracts are the second killer application for the blockchain, in my opinion, but a far more difficult problem to solve.

Of course, all of this ultimately culminated in the anonymous hacker Satoshi Nakamoto’s paper about Bitcoin, and the rest is history. So why then did this idea–originating from hackers, some even anonymous to this day–grow so many leeches promising a completely new wave of technology startups?

My “Killer App”

I was very excited by an opportunity to learn more about all of this stuff when coming up with an idea to track finances with my brother, who is also currently my roommate. Previously, my brother and I had shared various household expenses by sending each other money over Square Cash. While I still think Square Cash is a wonderful service², at some point we tallied up all of the transactions we had sent over the period of multiple years and discovered that our sums were nearly identical! This means that in the end, if we hadn’t sent each other money at all, we still would’ve been mostly square. Since we try to share the burden of household expenses anyway, this was not entirely surprising.

After making this discovery, we thought it would be cool to develop a very simple piece of software that just kept track of these expenses rather than transfer any money. Although my brother and I trust each other (for the most part), we thought it would be far more interesting if we assumed we couldn’t trust each other at all, and developed an Ethereum Smart Contract built on the blockchain instead of running something on a server that one of us would have to own and operate.

In short, developing this application on the blockchain instead of using a centralized server was extraordinarily difficult, and at one point even became unaffordable. Before going into details with that, let me switch back to talking about some of the promises and myths of the blockchain in general.

Promises

There are a lot of hollow promises for blockchain technology, mostly from business people who don’t completely understand it themselves. If you’ve ever heard of a company who promised a “revolution in e-commerce” using the blockchain, this would be one of those. I won’t even mention the myriad of “get rich quick” schemes here.

However, there are a lot of actual features of the blockchain that could be appealing to application developers. Notably:

• A decentralized database. Centralized stores of data, particularly for data that would be perilous to lose, is a centralized point of failure. Application developers who would like to make guarantees about database integrity could count on the fact that their data is distributed among a large set of nodes across the globe.
• Users have the ability to audit smart contract code. Although the developer is responsible for the development of the original code for a smart contract, if the source code of the contract was somehow published, users of the smart contract could actually guarantee that the contract they’re interacting with is the same as the one they personally audited by comparing the compiled bytecode stored in an actual blockchain transaction. Since the contract cannot be changed after the fact³, users can also have confidence that as long as they interact with a contract at a particular address, that guarantee will also not suddenly change in the future.
• The data stored on the blockchain is tamper-proof. Since the contents (inputs) of a transaction cannot be changed after it has been mined into the blockchain, the users of a contract can guarantee that rows in this decentralized database will not suddenly disappear or change without their authority.
• Transactions are not forgeable. Thanks to the promises of asymmetric key cryptography.

Taken at face value, all of these promises are pretty cool. What about some of the myths?

Myths

• Interactions with the Blockchain are anonymous. In order for a decentralized network like this to function, all interactions with smart contracts must be published and made widely available. Interactions with the blockchain can be anonymous if users are extremely careful with their keys, but this is not often practical or even feasible⁴.
• Applications on the Blockchain can be made easy to use by normal people. This, in my opinion, is also not practical or feasible for the same reason why PGP (email encryption) never took off. I will discuss more about this later in this post.
• The blockchain is “unhackable.” While certainly nice to have in a world where data breaches are becoming evermore common, this is also not guaranteed by the blockchain by itself. The Ethereum DAO hack is an excellent counterexample of this.
• The blockchain is a major cost-saving technology. Quite the opposite, in fact. The cost to run a distributed database is significantly higher regardless of how it is done⁵.

With that summarized, let me now explain how I came to learn all of this from personal experience…

Octahedron

We called our application “Octahedron”, named after the shape of the Ethereum logo. It is implemented in two separate parts. The first part is the client, which we decided would be an iOS application (but could be anything), and the second part is the smart contract itself. The smart contract can be considered the “server” in a typical client-server abstraction, but of course since it’s distributed, there is no code that runs on one particular server.

We drafted out some of the features that we wanted before writing either the client or the smart contract, mostly coming from what we’re used to from Square Cash:

• The ability to “request money” from another person
• The ability to either approve or deny that request
• An easy to access balance between each of us, represented as a positive number (I am owed money) or negative number (I owe money)
• A historical record of previous requests

The Smart Contract

Implementing these features using a smart contract ended up being extremely interesting given the constraints. For example, smart contracts have very limited storage, and the more “space” you use in your contract the more you have to pay. Also, contracts can’t necessarily store arbitrary rows of data inside of them like you can with a SQL database, for example.

The design of the smart contract ended up being two separate code implementations. A request for money owed is a smart contract itself. The smart contract contains all the metadata about the request, such as the amount of money requested, the debtor and debtee’s wallet addresses, and a short description of the request. These are called “debt requests”, and they’re not created by the users themselves, but instead by the “main contract”.

The main contract is another contract implementation who effectively provides an API for creating debt requests, and keeps track of the balance between us. Therefore, the only storage the main contract has is a running balance, which is simply the amount of money “sent” by me minus the amount of money “sent” by my brother. Sent is in quotes here, because no money is actually sent (not even cryptocurrency), only debt is sent.

A typical use case might be as follows:

1. Brother A pays $20 for a new lamp for the living room.
2. Brother A sends a debt request to Brother B for $10. A contract interaction transaction with the main contract is posted to the Ethereum blockchain with all of the metadata needed:

Debtor: Brother A
Debtee: Brother B
Amount: 1000 (USD in cents)
Description: New Lamp

3. The main contract emits a DebtRequested event, containing the new debt request smart contract.
4. Brother A sends a link to the debt request smart contract somehow, usually via the transaction hash or the address to the smart contract itself, to Brother B.
5. Upon inspection of the metadata for the debt request contract, Brother B approves the debt request by “fulfilling” it.
6. When fulfilling the debt request, the balance is updated in the main contract and the state of the debt request moves from “created” to “fulfilled”.

Notice that an important feature about the way this works is that the balance is not updated until the debt request is fulfilled. The debt request contract also has code in it to check and make sure that the request is only being fulfilled by the debtor, which is easily guaranteed based on the private key used to sign the transaction. Pretty cool.

The Client

When interacting with smart contracts on Ethereum, clients typically talk directly to an Ethereum node by sending HTTP requests to it using some kind of protocol. The standard protocol for talking to Ethereum nodes is called JSON-RPC, because the data for the RPC calls is encoded using JSON.

Wait a minute, I thought there was no central server? Why do you have to send HTTP requests to a server at all? This is the first huge caveat for developing applications on the blockchain.

In order for Ethereum nodes to be able to post transactions to the blockchain, they need to have access to a non-trivial amount of history. In our example, a node will need access to the smart contract bytecode, as well as all previous transactions with the blockchain. And because each transaction with our smart contract references previous blocks in the chain, we need to store a lot more than just interactions with our smart contract.

The amount of storage necessary to facilitate this is on the order of hundreds of gigabytes for the main Ethereum network, and growing larger by the day. Since our clients are our iPhones, this would mean both of our iPhones would need to store a hundred gigabytes of transaction history just to be able to post a transaction. Not only that, they must be completely up to date with the latest transactions.

That is obviously not feasible, so this task must be delegated to some kind of server that is dedicated to this particular task. The good news is that despite the fact that a request must be sent to a single server, this server can be any server that is also an Ethereum node, for which there are thousands, and it’s relatively easy to run one yourself if you have a machine that has a decently sized hard drive and some spare CPU resources.

The other good thing about this is that all cryptographic procedures (i.e., signing the transaction) are done on the client (our iPhones) before the RPC request is even sent. So this means the server never needs to know our private keys, and we can keep those securely stored locally on our devices, say in the system’s Keychain.

Earlier in this post I made the claim that “applications on the Blockchain can be made easy to use by normal people”, and perhaps the reason for this is obvious now. For the same reasons that PGP never took off, in order for users of blockchain applications to take full advantage of the technology, they would need full control over their private keys and trust would need to be placed on the client to guarantee that the keys are not just sent to some centralized server.

This is the key point: almost any effort in attempt to make any of this more user friendly entirely defeats the purpose of using a decentralized blockchain. The two primary efforts I’m referring to are centralization and the outsourcing of key management. Centralization is debatably good for security, although I’m not sure I agree. And the outsourcing of key management could be mitigated with better, easy to use security hardware like Apple’s security enclave, or YubiKey.

Conclusion

This project was very fun to work on, and just like any programming paradigm, the only way to really learn about it is to dive right in to a project. It ended up being so much more difficult than I expected, which is very illuminating in face of all the marketing hype. I’m still extremely enthusiastic about the blockchain’s value for hacker projects like this one, but I do not think it will end up being the next business idea at all. I never really took that seriously anyway.

Also, from an educational perspective, I’ve added Ethereum development to my list of programming paradigms that drastically changed the way I think about programming. Other paradigms on this list include graphics shaders, functional programming, and hardware description languages (like VHDL or Verilog).

You can check out the source code for my contract here. My brother also wrote a great post about our project here.