“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 capitalism1, 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?
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 service2, 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.
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:
Taken at face value, all of these promises are pretty cool. What about some of the myths?
With that summarized, let me now explain how I came to learn all of this from personal experience…
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:
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:
Debtor: Brother A Debtee: Brother B Amount: 1000 (USD in cents) Description: New Lamp
DebtRequestedevent, containing the new debt request smart contract.
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.
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.
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).
These are the words of the crypto-anarchists, not necessarily my own opinions. ↩
It was even better in the beginning when Square allowed you to send money over email! ↩
Some advancements have been made in this area with Monero, but I don’t really know anything about it. ↩
For example, running the computers yourself will cost more simply because you need to buy and maintain more computers. Amazon’s Aurora service is also more expensive than, say, EC2, because it is a niche service that also costs more for them to run. ↩