Clear Paper
Note: In the spirit of open collaboration, I’m keeping a public lab notebook of my work as a Clinical Informatics Fella at UCSF. Whether you cite or steal this, remember to build cool things that help people live healthier lives.
Educational objectives
There are a number of excellent technically focused blog posts on Ethereum out there. If you are interested in building Ethereum applications, I recommend making your way through these technical references (see end of article). This article is intended for non-technical readers interested in understanding, on a high level, the real-world implications of Ethereum’s application paradigm. More specifically, you should be able to answer these questions after reading this article:
- What is Ethereum and how does it work?
- Should I use Ethereum for my project?
- What are the pros & cons of Ethereum?
Welcome to Hell
Let’s pretend you have a crazy boss (let’s call her Mary) who’s set on making your life difficult. You and Mary meet every month to check in and make sure you’re both on track. Mary takes out her notebook and takes notes while you share with her what’s going well and what’s not going as well. Because you’re an honest (and somewhat naive) person who hasn’t yet encountered someone like Mary, you start using these meetings as opportunities to speak openly, give and receive feedback, finding comfort in the fact that Mary’s faithfully keeping a record — a ledger — of your conversations. A month passes, and then two months, and Mary’s insanity pervades the workplace. With each subsequent meeting with Mary, she seems to glare at you with wider crazy-eyes, clench her teeth until they sound like they’re about to crack, and stabs her pen ever harder into her notebook while she keeps records of your discussions.
Three months into your job, you’re fed up with her madness and decide to resign (fortunately, you’re not a medical resident or other indentured servant and have the freedom to do so). Mary leads you to a quiet corner, throws a death stare at you, and growls: “If you resign, I will personally make sure you never find a job ever again.” By this point, the stench of bodies in Mary’s closet is overwhelming, and you email Mary to give 30-day notice. Then all hell breaks loose.
In following month, Mary copies you on several emails to her bosses. One of the emails accuses you of harassing her assistant (whom you’ve never interacted with). Another email warns you of several missed deadlines (for projects which never existed). Some emails state that no one has been able to reach you by email or phone (you’ve answered every call and email in the most timely fashion). You’re neither the first nor last of Mary’s victims, and you quickly learn that she’s more than a psychopath, she’s also written the book on psychological manipulation, deception, and torture. She’s creating a fictitious paper trail by sending contrived emails and writing a book of alternative facts, which her complicit assistant is co-authoring.
How can you shed light on Mary’s evil tactics and show others that her ledger is as legitimate as an acid trip? Because you’re a clever hacker, you decide to use Ethereum to shed light on a rancid situation.
A Distributed Ledger
Pretend the Ethereum “blockchain” is a magic notebook that serves as a ledger. This notebook can appear in anyone’s hands, and every copy of this notebook is identical. This magic notebook is so smart it can understand your commands and write on its own pages. When one of its pages is written on, the other notebooks vote whether to accept the new page. If they do accept the new page, this change is reflected in every magic notebook. These magic notebooks follow you into meetings with Mary and record their own version of “the truth.” Each page in this notebook is analogous to a “block” in a “blockchain.”
So you buy yourself a magic notebook and bring it to your next meeting with Mary. As usual, she’s preparing her own notebook of alternative facts. Her assistant, Karen, also shows up to the meeting with her own notebook of alternatively alternative facts. So there you are, in Mary’s office with Mary and Karen, everyone clutching their notebooks.
You: "I quit." (magic notebook hears this and writes it on page 1) Mary: "Good riddance." (magic notebook hears this and writes it on page 2) You: "Before I leave, you still owe me a paycheck." (magic notebook hears this and writes it on page 3) Karen: "You picked up the paycheck last week. We owe you nothing." (magic notebook hears this and writes it on page 4) You: "No you didn't. I've been asking you for that paycheck for weeks."(magic notebook hears this and writes it on page 5)
Realizing this is going no where, you walk out of Mary’s office carrying your magic notebook.
You next see Mary and Karen in court: you’re suing them for unpaid wages, and you bring along your magic notebook to set the facts right. When the judge asks you when you announced that you’re quitting, your magic notebook recites what’s written on page one: your statement (“I quit”) along with a timestamp. Mary and Karen jump to their feet and hold up copies of their own notebooks. However, the judge did her research on this new magic notebook, which is reputed to be the best ledger in the history of mankind because it doesn’t rest in any one person’s or organization’s hands. The truth doesn’t rest in Mary or Karen’s notebooks or email inboxes (or in either of their minds); the truth — the Ethereum ledger — is the account provided by the magic notebook, which is in everyone’s hands and is guaranteed to contain the same text on every page .
It’s worth repeating emphatically here that the Ethereum blockchain is a distributed ledger.
Realizing the signifiance of this jargon-laden statement, you decide to go further than just shedding light on Mary’s career of lies and deception. You’re going to make Mary pay for all of the people she’s abused and manipulated over the years, and you’re going to do it with Ethereum. As you study this article and read more about how Ethereum works, you realize that the magic notebook is more than just a record of events. The notebook can execute logic (in the form of “contracts”) and store/modify/delete data. This is one big difference between Bitcoin and Ethereum. A Turing-complete system, such as Ethereum, can execute logic; unlike Bitcoin, the Ethereum Virtual Machine (EVM) is a stack machine. You can write contracts that transfer money and include basic logic to allow others to interact with your contract in a transparent manner. Anyone interested in examining a contract can do so.
If you had heard of Ethereum before you started working for Mary, you could have written a contract that states something like:
MARY SENDS MAGIC NOTEBOOK $100,000 EVERY MONTH EVERY 2 WEEKS, MAGIC NOTEBOOK SENDS ALL EMPLOYEES $5,000 IF AN EMPLOYEE RESIGNS: MAGIC NOTEBOOK SENDS THEM A FINAL PAYCHECK MAGIC NOTEBOOK REMOVES THEM FROM LIST OF EMPLOYEES
Unlike a traditional contract, Ethereum contracts:
- are transparent and can be examined by anyone
- are trustless, meaning they execute faithfully and automatically
- do not need lawyers or courts for interpretation
As your knowledge of Ethereum grows, you realize that you would have been better off writing your employment contract on the Ethereum blockchain rather than relying on Mary and her team of corporate attorneys. Had your contract been written on the Ethereum blockchain, you wouldn’t have had to rely on Mary’s sanity or lack thereof to get paid. The codified contract would execute autonomously, can be reviewed by you or anyone else, and does not need middlewomen/middlemen to interpret or execute (Auf Wiedersehen lawyers, HR staff, administrators, etc). In case Mary was still delusional enough to argue with the Ethereum ledger, the magic notebook would quickly provide proof of payment (or lack thereof) and the conditions under which the logic was executed. The logic on the Ethereum blockchain is transparent.
The current paradigm of hosting applications on a private server is analogous to doing business with Mary and Karen. The logic is centralized and opaque. I trust most applications about as much as I trust Mary and Karen. The average application is hosted on one or a cluster of privately owned and operated servers, and most applications are not open source (and even if they are open source, the average user doesn’t have the means to perform checksums and make sure they’re running the code they think they are). If the server crashes or the application behaves in unexpected ways, well, hard luck fella. Why would anyone trust the software equivalent of Mary & Karen when they could trust a decentralized ledger running autonomously executing logic?
Without getting too bogged down in details, I include this simple example of an Ethereum contract that creates a simple voting mechanism.
pragma solidity ^0.4.0;
contract Ballot {
struct Voter {
uint weight;
bool voted;
uint8 vote;
address delegate;
}
struct Proposal {
uint voteCount;
}
address chairperson;
mapping(address => Voter) voters;
Proposal[] proposals;
/// Create a new ballot with $(_numProposals) different proposals.
function Ballot(uint8 _numProposals) {
chairperson = msg.sender;
voters[chairperson].weight = 1;
proposals.length = _numProposals;
}
/// Give $(voter) the right to vote on this ballot.
/// May only be called by $(chairperson).
function giveRightToVote(address voter) {
if (msg.sender != chairperson || voters[voter].voted) return;
voters[voter].weight = 1;
}
/// Delegate your vote to the voter $(to).
function delegate(address to) {
Voter sender = voters[msg.sender]; // assigns reference
if (sender.voted) return;
while (voters[to].delegate != address(0) && voters[to].delegate != msg.sender)
to = voters[to].delegate;
if (to == msg.sender) return;
sender.voted = true;
sender.delegate = to;
Voter delegate = voters[to];
if (delegate.voted)
proposals[delegate.vote].voteCount += sender.weight;
else
delegate.weight += sender.weight;
}
/// Give a single vote to proposal $(proposal).
function vote(uint8 proposal) {
Voter sender = voters[msg.sender];
if (sender.voted || proposal >= proposals.length) return;
sender.voted = true;
sender.vote = proposal;
proposals[proposal].voteCount += sender.weight;
}
function winningProposal() constant returns (uint8 winningProposal) {
uint256 winningVoteCount = 0;
for (uint8 proposal = 0; proposal < proposals.length; proposal++)
if (proposals[proposal].voteCount > winningVoteCount) {
winningVoteCount = proposals[proposal].voteCount;
winningProposal = proposal;
}
}
}
[Source: https://solidity.readthedocs.io/en/develop/solidity-by-example.html%5D
Why develop on Ethereum?
Now that you know how Ethereum works, you have the luxury of living to witness one of the most interesting, exciting, and important developments in computing, and you too can design and develop applications on the Ethereum blockchain. Why not write an employment contract on the Ethereum blockchain that gives you and your peers a democratic way of removing problematic elements in the workplace? Or an employment contract that distributes an organizations profits more equitably and transparently? But before you can decide whether it makes sense to ditch a virtual server running your standard Python/Ruby/NodeJS/PHP/[fill in the blank] stack in favor of Ethereum, you should note a few more pros and cons of Ethereum:
Unlike the Bitcoin protocol, which is a distributed ledger of transactions based on monetary (Bitcoin) inputs and unspent transactional outputs, Ethereum is account-based. This is getting into technical details that may not interest the intended audience of this post, but it should be noted that in Ethereum there are account addresses identify users as well as individual contracts written to the Ethereum blockchain. Like Bitcoin, the Ethereum protocol is based on a cryptocurrency called Ether, which is used to fund all transactions on the Ethereum blockchain (more on this below). And just like an address that you can use to send and receive Bitcoin and Ether payments, your Ethereum contracts also have addresses which function as handles to allow users to interact with your code and identify it on the Ethereum blockchain.
Basic anatomy of an Ethereum contract
An Ethereum contract consists of the code you write and the state of the contract (i.e. the data associated with the contract). As described in the Solidity documentation, the magic happens in between the curly brackets, the body of a contract:
contract requestFile {
// stuff happens here ...
}
The “stuff” consists of state variables, functions, function modifiers, and events, which will look familiar to you if you’re fluent in one of many programming languages that use these paradigms.
State variables are permanently stored in contract storage and include types such as integers (int and uint), booleans (bool), addresses (address, address.balance, address.transfer), fixed and dynamically-sized byte arrays (bytes, string), string literals, enums, structs, and mappings (similar, but not identical to, hash tables). The EVM uses standard logical operators, including comparison operators, bit operators, and index access. See the reference above for more details.
How large is a contract storage area? Vitalik Buterin answers this here. Bottom line: 2^261 bytes. That means that you’ll never really be limited by size, but rather, by the cost of conducting transactions on the Ethereum blockchain (see “Economics of Ethereum contracts” below).
Functions work similarly to other programming languages and take the form of:
function audit() returns (address addr) {
// stuff happens here...
}
As described in the Solidity documentation, functions can be called internally or externally and have different levels of visibility, like in programming languages such as C++, Java and Python.
Function modifiers “amend the semantics of functions in a declarative way.” I’ll skip the technical details here.
Events are basically functions that use the EVM’s logging mechanism. If you’ve developed Android apps, you’ve probably used something similar.
If you’re itching to deploy a real contract to the Ethereum blockchain, check out my earlier tutorial.
Economics of Ethereum contracts
On a macro scale, Ethereum is a giant computer powered by every machine running the full Ethereum client. Just like every step and breath we take costs energy, so too does every computation performed by your computer require a finite amount of electrical energy. The Ethereum network is no different. The energy required to keep adding blocks to the blockchain, transfer Ether, and execute contracts is provided in the form of “gas” (an Ethereum subunit). Unlike a local machine such as your laptop, and unlike a virtual server (which runs on a real machine too), Ethereum contracts are interpreted by the Ethereum Virtual Machine, the stack machine that converts Solidity code into instructions to interact with the Ethereum blockchain. Unlike the Bitcoin protocol, in which each transaction has a predictable cost to the network, the cost of transactions on the Ethereum blockchain depends on bandwidth consumed, computational power, and the size of data that’s being manipulated. Each transaction specifies how much gas it is willing to consume and a gas price. In the event of unused gas, the sender receives gas_rem * gas_price, and the miner of the block receives a reward of (startgas-gas_rem) * gas_price. Id est, there is a cost of conduction transactions, and miners, are rewarded financially for using their own computational power to create new blocks on the blockchain and keep the ledger going.
The economics of current application development profoundly shape how software is developed and used. Many consumer-facing applications are available for a cost on app stores or can be downloaded for a fee; many other consumer-facing applications are supported by adverts, in-app purchases, and subscription fees. Ethereum’s transactional economics were designed to safeguard against malicious agents, and understanding the Ethereum blockchain economy is important to understanding how applications on the Ethereum blockchain will function. This is illustrated in the “Security considerations” section below.
There are some good websites with details on Ethereum economics, including Ethereum’s Design Rationale and Ethereum Gas Economics.
Security considerations
What better way to learn good security practices on the Ethereum blockchain than to confront the most malicious of actors, your former wicked boss? While you’ve been writing Ethereum applications, Mary learned a thing or two about this Ether thingy and wrote their own contract to hinder the Ethereum network and suck your account dry of Ether. Let’s say that Mary tricks her next hapless victim into executing an Ethereum contract that does the following:
contract youGotPunked {
function newEmployee(address dest, uint employeeId) {
while(true) { };
}
}
Mary is tricking her next batch of employees who aren’t savvy enough to study the contract into calling an infinite loop. If you’ve ever written an infinite loop on your machine, you know you can hang your machine by wasting all of your machine’s computing resources on executing a loop that does nothing forever. Mary’s new employees call the contract, which then runs forever, wasting computing resources across the Ethereum network. Because each transaction (such as calling the above contract) costs gas, Mary can’t use this old trick to lock up the Ethereum network.
Mary goes back to the drawing board and comes up with another contract (this example is also provided in the Solidity documentation):
contract TxAttackWallet { address owner; function TxAttackWallet() { owner = msg.sender; } function() { TxUserWallet(msg.sender).transferTo(owner, msg.sender.balance); } }
When Mary’s hapless new employees call this contract, it empties all of their funds (msg.sender.balance) into Mary’s account (address owner). People have used their understanding of Ethereum’s blockchain and simple tactics such as this account emptying trick to transfer hundreds of millions of dollars worth of Ether in unexpected ways. Bottom line: there is no such thing as a perfectly secure system. The amount of energy expended in securing a system should be proportional to what’s at stake. Ethereum is no more or less inherently secure than Google or Microsoft’s applications.
Ethereum in healthcare
I’m drawn to an Ethereum-based electronic health record for the same reasons I wouldn’t want anything to do with Mary and Karen. The next generation of EHRs on a blockchain should:
- be secure, with fail-proof access control
- be infallible, with mechanisms to deter malicious attacks on the network
- be distributed, so that patients, providers, and researchers can benefit from responsible use data
- be distributed, so that inter-operability is a given
- be distributed, so that data is never lost (while preserving consensus)
- be transparent, so that there’s an audit trail of who is accessing what
- be transparent, so that there’s an audit trail of all transactions on the blockchain
- be transparent, allowing health services to be rendered in the most cost-effective way possible
- be autonomous, allowing health services to be rendered without costly third-parties who currently monopolize health data
Now enough White, Yellow, Mauve and Clear Papers. Let’s see some code!
Acknowledgements
“It’s only work if you’d rather be doing something else” (JM Barrie). I couldn’t think of a better way to spend my time, thanks to this opportunity to be a Clinical Informatics Fella at UCSF Medical Center. I’m grateful to UCSF’s Department of Hospital Medicine, my mentor, Dr. David Avrin, and my colleagues Dr. Michael Wang and Dr. Steven Chen, for their support and feedback.
References
- https://solidity.readthedocs.io/en/develop/solidity-by-example.html
- https://remix.ethereum.org
- http://ethdocs.org/en/latest/
- https://github.com/ethereum/wiki/wiki/Design-Rationale
- https://en.wikipedia.org/wiki/Bloom_filter
- https://ethereum.github.io/yellowpaper/paper.pdf
- http://whatthefuckisethereum.com/#nerd
Minimally invasive software 