Building the Foundations for a Scalable Ethereum Community

28 August 2016 | on governance, ethereum, policy

Note to reader: This article also appeared on Coindesk on August 28, 2016. In this (long!) piece I recap the aftermath of the DAO hack, consider arguments for and against implementing a governance structure over the Ethereum network, and suggest some practical ways to move forward.

Recent events have forced ethereum's community to the forefront. On 17th June, a critical security vulnerability in an ethereum application called The DAO was used to drain millions of dollars worth of ether into accounts controlled by an anonymous attacker. After a period of deliberation, a majority of core developers, miners and other members of ethereum's community decided that the best path forward was to hard fork the network to "undo" the hack and return the stolen funds.

The community's power to revise ethereum's transaction history has surprised many outside observers who were told that blockchains are, as a rule, immutable.

To the broader market, the inner-workings of the deliberative process that led to this outcome are at best opaque. The decision proved controversial within the community as well, with a vocal minority taking the position that ethereum has betrayed its core principles and choosing instead to support the un-forked network, with the result being that there are now two blockchains that share ethereum as a common ancestor.

"The community" is often in the background of our conversations about ethereum. In any discussion of ethereum's ability to provide settlement finality, it's a necessary caveat: in two pieces from earlier this year, both Tim Swanson and Vitalik Buterin articulate that, ultimately, it is the community's economic consensus which determines which chain is legitimate. More broadly, any conversation about ethereum’s future potential relies on the implicit promise that there will continue to be a productive community of talented developers working to maintain and support the project.

But for the most part, the community is treated as a black box. We know it is important, we believe that it works, but we rarely look too deeply at what makes it so. When our community functions as we expect, we congratulate ourselves, as we did when we successfully hard forked into Homestead. When someone else's community struggles, as bitcoin has with the divisive block size debate, we point to it as a sign of inevitable moral failing.

There have already been suggestions for how the ethereum community could better manage future situations like the DAO hard fork. But too often these require creating formal rules or governance structures which are impractical in a decentralized community.

Rather, our solution should begin by looking at what works today, what doesn’t, and by finding practical ways to make incremental improvements.

This isn’t just an academic issue. The community wields tremendous power over its blockchain. Convincing the world to build its future on ethereum requires proving that our community will exercise that power in a responsible way. Even more, it requires proving that our community will continue to be effective and responsible as the platform scales into something far larger than it is today.

The community's role

The DAO hard fork is a useful practical illustration of how the community exercises power over its blockchain.

The ethereum community is the group of people, institutions, companies and other organizations that together support and maintain the ethereum blockchain. This includes the core developers who work on the ethereum protocol itself, the miners who own and operate the nodes that constitute the ethereum network, the larger ecosystem of developers and entrepreneurs who are building applications on the platform, researchers who make critical contributions to the development of the platform, ordinary token-holders or users of ethereum applications, and others.

In response to the DAO hack, core ethereum developers proposed a hard fork that would return the stolen funds. Essentially, the miners whose nodes constitute the ethereum network would all agree to adopt a new version of the ethereum software that would remove the offending transactions.

This change requires a "hard fork" because it breaks backwards compatibility – the entire network must agree on the state of the blockchain to continue.

However, a minority can reject the changes introduced by a hard fork and continue with their own chain – they have the power of "exit". This is what happened after the DAO hard fork – a minority of miners decided to continue on without accepting the changes, and became their own minority blockchain. In a narrow sense, the ethereum blockchain's immutability has not been compromised by the hard fork. The "original" chain, without any of the edits introduced by the hard fork, still exists in the form of ethereum classic.

However, the minority has no guarantee that the broader community will devote resources or attention to their blockchain. This is significant because the community gives ethereum part of its value: the expectation that, over time, the protocol will be upgraded and a large ecosystem of applications will be developed, increasing the utility of the platform. The ethereum community understands this intuitively, which is why a few days afterwards both sides of the fork were competing to tally up which companies, people or researchers were working on their preferred chain.

These nuances of blockchain immutability are not widely understood. Data you store on a blockchain – including tokens, or code – has a strong probability of remaining immutable. But preserving that immutability might require you to choose a minority chain, in which case you have no guarantee that your preferred chain will continue to attract the attention of the broader community. And if the value of your tokens or the utility of your code depends on that community, the minority chain may not be much use to you.

This extends beyond immutability. Hard forks are not typically changes to the history of transactions – more often, they are protocol upgrades or new features that change how the blockchain functions. For example, a change to increase the maximum block size in bitcoin. More generally then, we might say that you have a guarantee against any change that could be introduced through a hard fork only if you can accept being in the minority in some cases.

Forming a minority chain is not always possible. If I am the only person that wants to reject a hard fork, I could certainly operate the lone remaining node of the unchanged blockchain, but my chain would not be viable. In practice, a minority chain needs some minimum amount of support to attract a community of developers or convince an exchange to list its tokens. So, we need to add another caveat: you have a guarantee against changes introduced through hard forks only if you can form a sufficiently large minority to continue a viable chain.

(Lastly, it's worth noting that the parameters of hard forks might change significantly in the future, which would alter the dynamics I describe above).


The community matters. Core developers have influence over which concrete proposals are brought to the community, and are trusted by miners to provide technical guidance. Miners have control over which hard forks are accepted by the majority of the network. A larger community of developers, companies and others determine which post-fork chain attracts the most talent and resources. The ability of any individual to reject a change introduced through a hard fork depends on convincing a viable minority of the community to come along with them.

None of these decisions are made in a vacuum. They require the community as a whole to be able to identify novel problems, surface relevant expertise, propose effective solutions and thoroughly consider the benefits and costs of those solutions. Ideological beliefs and financial incentives shape the decisions of all community members to different degrees. Disputes and personal conflicts can, if not resolved, damage the decision-making process and inhibit cooperation.

We can't separate the technical components of the ethereum blockchain from the human community that supports it. This isn’t just some nice sentiment. This is mission-critical wetware on which ethereum’s future depends. A community can be better or worse, cooperative or siloed, productive or toxic. A blockchain whose community loses key expertise and is unable to debate solutions without devolving into personal conflict may be a perfectly adequate piece of technology, but it is a terrible blockchain. What guarantee do we have that this will never happen to us?

Defining the community

Within the ethereum community, we often delude ourselves into thinking that blockchains are beyond these concerns. There is a tendency to believe that because the community is decentralized, it is immune to the challenges of other human organizations. Part of this is due to the lack of easy analogs: blockchains are not companies, they’re not governments and they’re not quite like other open-source projects either.

It’s difficult to point to a model for what our community ought to be. Blockchain communities are novel things with no easy analogs. But they are still made of people, and subject to the same flaws and strengths as any human organization. Even decentralized communities can consciously try and change or improve themselves. Members of the community are free to adopt shared norms, ethical standards, and processes that make the group as a whole more effective at achieving a shared goal.

The ethereum community’s capacity for critical self-analysis and improvement isn’t just a theoretical concern. So far, the community has functioned well enough. But will the same decision making processes used today be as effective when the community is 100 times as large? When the economic value at stake approaches the size of a small country? When the political and financial pressures on key community members are far greater?

Over the next few years, we will attempt to scale the platform. How will we scale the community to match if we don’t understand what makes it work today?

Inspiring confidence

Outside observers of blockchain communities often make a different mistake.

Those with backgrounds in finance or law often grok immediately that public blockchains depend on a community. But when they look at it, they see an opaque mass of pseudonymous techno-anarchists engaging in messy arguments on Reddit and twitter and dozens of chat rooms. They conclude that there is no way this community could serve as a foundation for a global value transfer platform.

This is where the issue of "the community" intersects with another common topic in the conversation around ethereum – whether, and how, public blockchains should be directly integrated into existing legal structures. If you believe that the community alone can never provide sufficient confidence, then the obvious conclusion is to try and use legal or regulatory tools we already understand to accomplish the same end. For example, by treating core developers and miners as fiduciaries.

This is wrong, too – or at least premature. It is generally true that people tend to overestimate the stability of regulated centralized institutions and underestimate what can be achieved by decentralized systems. It's probably too early to say that the decentralized community around ethereum could never convince the market that they are capable of maintaining the ethereum blockchain in the long-term.

For now, it’s an open question. But if advocates of public blockchains believe that the community shouldn’t be subject to onerous regulation, then the community needs to find other ways to provide assurances to the outside world.

Improving, decentralized

The ethereum community needs ways to improve itself over time, to adapt to new challenges and provide greater confidence in its decision-making processes as the platform grows.

Some people want to use very heavy tools to accomplish this. Either by trying to fit the ethereum community into existing legal and regulatory structures, as mentioned above, or by having the community adopt rigid governance systems of some kind that will constrain future decision making.

Ethereum's decentralized nature makes these solutions impractical. Using existing legal tools in individual jurisdictions are more likely to cause entrepreneurs to flee that jurisdiction than they are to strengthen confidence in the community. Trying to convince the community to adopt some type of hierarchical, formal governance structure is likewise difficult: it’s seen to compromise the decentralization of the platform, a key ideological value shared by large segments of the community. Maybe some version of these “hard” tools could work someday, but for now they're non-starters.

If decentralized communities like ethereum are environments where formal processes are weak, maybe we shouldn’t start there. Maybe the right way to approach decentralized community governance is to try and develop very strong shared social norms and standards of behaviour, enforced not through some central mechanism, but through rough social consensus.

Formal processes are not the only way to improve a community's governance. Communities can also differ by the norms of behaviour they freely choose to adopt. A norm is simply an informal rule shared by a community of people. While not strictly enforced, norms play an important role in shaping how any community behaves. This is commonly understood in other contexts. For instance, every successful startup knows that their culture – their shared norms – is critically important.

We can already observe norms developing within the ethereum community. For instance, it’s become common for anyone writing about specific blockchain projects to disclose whether they are invested in it, either to remove the appearance of a conflict of interest or to signal their commitment to the project (I own less than $2,000 worth of ETH). Our community has a strong norm in support of identifying and widely criticising anything that even smells like a scam.

The advantage of relying on informal rules like norms is that it lets us take the processes used today and make incremental improvements. Even though it may be messy to outside observers, the community does “work” and has proven itself capable of responding to threats to some extent.

We aren't going to redesign the community into a system of committees governed by a constitution (at least not anytime soon). But we can take the community we have and try and articulate basic improvements where they are needed, argue about them, and build social consensus around them.

A thorough analysis of the ethereum community is beyond the scope of this essay. But drawing on the events of the last few months, here are three general areas that might be worth considering in more detail:

1. Reducing information asymmetry through transparency and pro-active disclosure

Some members of the ethereum community have access to more information than others. Core ethereum developers who are well-connected in the community and involved in critical projects, for instance, have more knowledge, insight and access than the average token holder. This is an example of information asymmetry, a type of problem that motivates disclosure and transparency efforts in many other contexts. In public markets, for example, companies are required by law to provide necessary financial and other information to their shareholders.

We might ask a similar question: What level of transparency should the community expect from its key members? We can already observe a strong pro-transparency norm. Shortly after the DAO hack, for example, a transcript of a conversation between core community members was released that allowed the broader community an unfiltered view into the early moments of the decision making process that shaped the initial response.

But our approach to transparency and disclosure is inconsistent at best. Many industry observers need to understand the deliberative process that led to the DAO hard fork in order to predict how the community might act in similar future situations. The public resources available to them – mostly news articles and blog posts – are insufficient and incomplete. Larger institutions rely on personal contacts from within the community to explain what happened, and why. If we want the broader market to trust the community, there should be better public channels for communicating decisions and the processes that led to them.

Information asymmetry is related to another problem: real or perceived conflicts of interest. Those who have access to information by virtue of their position in the community could profit from that information through speculation. Relatedly, those with particular influence in the community could use that influence to support outcomes that benefit them financially.

During the DAO hard fork debate, there was a recurring allegation that’s social ties to core ethereum developers motivated those developers to support the fork. Though this has been adamantly denied, the fact that it was a credible allegation at all damaged the legitimacy of the process.

Are there circumstances in which prominent community members should declare a conflict of interest and recuse themselves from the discussion? If so, what are they?

2. Community engagement

When important decisions are being made in the ethereum community, do we have an obligation to ensure that the furthest reaches of the community – say, passive token holders – are aware of what is going on and how it might affect them? Today, this might seem unnecessary – anyone who owns ETH probably does so because they are invested in this project and are already following the discussion to some extent. But it's not clear how engaged the wider community is in such issues – prior to the DAO hard fork, a coin-vote held to gauge support had a turnout of only 5%.

In the near future, this problem will grow. Eventually, we should hope that many people that own ETH or rely on the platform will not have to care about the internal politics at the centre of the community. But these people would still be materially affected by the community’s decisions. It would probably be easier for them to trust the platform as a whole if they had confidence that, if a big decision is at hand, they will be notified.

This isn’t a unique problem for blockchains. A similar situation exists for public companies, whose shareholders need to be notified of important decisions or votes that require their attention. In most jurisdictions, there are regulations that require corporations to notify their shareholders (and the public markets in general) of important votes, and an entire industry built on helping shareholders make decisions on how to vote.

We can imagine that an analogous system of notification and voting could be accessed through the wallets and exchanges that token-holder use to manage their blockchain assets. In the case of a situation like the DAO hard fork, this could give the community as a whole far better information about the preferences of token-holders.

3. Resolving conflict

Occasionally, disagreements will turn into disputes. These can become toxic and damaging to the community as a whole. We've already seen in the bitcoin block size debate how a bitter conflict between individual people can spill out into public and have a negative impact on the platform as a whole. During the DAO hack and its aftermath, personal attacks and other drama distracted and demoralized the community.

Ethereum developer Vlad Zamfir wrote on Twitter recently that the most important thing he learned from the DAO hard fork was the importance of good manners. This isn’t just some nice idea – this is an essential norm for a community that wants to retain and attract talent.

This is something that other open-source communities have learned the hard way. In 2014, Linus Torvalds said that the thing he most wishes he had done differently over the previous 23 years was treat people better:

"From a technical standpoint, no single decision has ever been that important... The problems tend to be around alienating users or developers and I'm pretty good at that. I use strong language. But again there's not a single instance I'd like to fix. There's a metric shitload of those."

Ethereum’s community prides itself on being collaborative and polite, a widely shared norm that is due in no small part to Vitalik's example. How do we ensure that it stays this way?


Talking about the community in these terms seems odd. Sometimes it feels like an overly serious argument between moderators of a niche online forum, and other times like a disconcertingly vague conversation about securities laws.

But this makes a kind of sense. On the one hand, this is an odd internet subculture made up of people with a shared geeky passion. On the other hand, it is a community that supports and ultimately controls what could become a tremendously important piece of global infrastructure. If that happens, understanding the dynamics of our quirky community might someday be as important to global commerce as understanding the internal politics of the Federal Reserve.

If ethereum succeeds, the community will have to grow and adapt over time. But because the community sits in this uneasy middle-ground, it’s hard to articulate how it could grow or adapt. Doing nothing and hoping for the best is a mistake. Doing too much – by suggesting formal, hierarchical governance – is a poor fit in a decentralized community.

An easier place to start is to realize that there’s a middle way: formal structures aren’t the only mechanism for improvement. We have to take the community as it is – the one that works now – and build on it, by adopting norms and behaviours where needed. It’s something we do already – but it’s time to start being more intentional about building a scalable community.

How Close Are Smart Contracts to Impacting Real-World Law?

11 April 2016 | on smart-contracts, ethereum

Note to reader: This article also appeared on Coindesk on April 11, 2016. In this piece I introduce the basic concept of a smart contract and explain why blockchains are an ideal technology to implement them.

Over the last year, the concept of a "smart contract" has received renewed attention in legal and business circles.

Advancements in blockchain technology have led some to believe that smart contracts could soon offer alternatives to traditional commercial and financial agreements, with dire results for the legal and financial sectors. While this enthusiasm may be premature, the legal profession nonetheless remains mostly unaware of this important emerging technology and the long-term implications for their profession.

In this context, "smart contract" refers specifically to the use of computer code to articulate, verify and execute an agreement between parties. Whereas a typical contract is drafted using natural language, the terms of smart contracts are expressed in code, similar to a programming language like javascript or HTML.

The contract is then "executed" by a computer – given the conditions of the agreement, and a set of defined inputs, the smart contract enforces its own terms.

Readers familiar with blockchain technology will know that the term "smart contract" is often used in a more general sense to refer to any script or program that operates on a blockchain. However for the purposes of this article, we focus on the narrower meaning described above: using code in place of traditional contractual agreements between parties.

Point of origin

The term "smart contract" was first popularized by computer scientist Nick Szabo in his 1997 paper "The Idea of Smart Contracts". The vending machine, he described, is the simplest form of a "smart contract" – a mechanical device designed to transfer ownership of a good (a candy bar) when provided with a certain defined input ($1.50). Because the machine itself "controls" the property – by being physically sealed – it is able to enforce the terms of the "contract".

Extending the concept, Szabo suggested that computer code could be used in place of mechanical devices to facilitate far more complex transactions of digital property. Rather than transfer ownership of a candy bar, a smart contract could transfer ownership of real estate, shares or intellectual property. The program would define what "inputs" were necessary for the contract to execute – things like payment, votes of board members or any other condition that can be expressed by code.

Consider a basic options contract. A call options contract entitles the holder to buy a given security at a defined price. In our example, Alice buys our "smart options contract" from Bob. The contract entitles Alice to purchase 100 shares of Acme Inc from Bob at a defined price of $50 per share. The contract has an expiry date, after which Alice is no longer entitled to buy the share at the defined "strike price".

Expressed in pseudo-code, a simple "smart options contract" might look like this:

contract Option  
  strikePrice = $50
  holder = Alice
  seller = Bob
  asset = 100 shares of Acme Inc.
  expiryDate = June 1st, 2016

function exercise ( ) {  
  If Message Sender = holder, and
  If Current Date < expiryDate, then
    holder send($5,000) to seller, and
    seller send(asset) to holder

In the first section, the smart options contract defines the relevant terms – the underlying asset, the strike price, the identities of each party and the expiry date. Then, a function we’ve named "exercise" enables the holder to trigger the purchase of shares at the strike price at any moment before the expiry date.

The function first checks to see if the entity triggering it (the "Message Sender") is the holder, and then checks to see that the contract is still within the expiry date.

If both are true, then the contract immediately executes by transferring cash from the holder to the seller, and the assets from the seller to the holder, according to the contract’s terms.

Two challenges

Until recently, smart contracts were little more than theory. In general, there were two fundamental challenges that needed to be addressed before smart contracts could be used in the real world.

First: How would a smart contract actually control real assets so that it could enforce an agreement? A vending machine, to return to Szabo's example, controls property by physically securing it inside of itself. But how could code do the same? In our options contract above, the "exercise" function transfers money and assets between the two parties. How can a computer program control real-world assets like cash and shares?

Second: What computer would be trusted to "execute" those terms in a way that both parties could rely upon? Parties must not only agree on the code of their contract, but also the computer which interprets and executes that code. A shared standard, at the minimum, would have to exist, and be used in a way that was verifiable by each party – ideally, without requiring the parties to physically inspect the computer in question.

In the last few years, solutions to both of these problems have come into sight. Emerging research and development surrounding blockchain technology may provide a basis to make smart contracts a reality in the near future.

The first use of blockchain technology was the digital currency bitcoin, made famous by its mysterious creator and sudden price increase in late 2013. In the last few years, its underlying "blockchain" has been intensely studied and adapted to expand its use beyond simple digital currencies. Startups, open-source communities and large financial institutions alike are improving and expanding the technology with the aim of one day using it to facilitate exchange of fully digital assets.

A blockchain is an authoritative database. It is a database that, by virtue of the way it is maintained and updated, has very high trust properties. Blockchains are not controlled by a single party. There is no single company, organization or person that has ultimate control over a blockchain. Rather, a blockchain is maintained, updated, and secured by a network of participating computers. Each computer keeps a full copy of the blockchain database, and each copy is kept in synchronization with the others by a system of cryptographically-enforced rules called a consensus algorithm.

Crucially, blockchains are append-only databases, meaning that once information is validly added, it can never be removed. Each update to the blockchain is secured by a cryptographic process known as a hash function, which allows the network to detect and reject any attempt to distribute an edited copy of the database. In this way, blockchains form the foundation for the recording and transfer of fully digital assets.

Because the blockchain is always kept in synchronization, there is only ever one true record of ownership – essential to prevent anyone trying to double-spend their assets by sending it to multiple parties at the same time, a problem that plagued previous attempts to create digital assets. Because it is impossible to edit a blockchain once it has been properly updated, parties have mathematically-enforced confidence that the record of their ownership will persist into the future.

Emerging solutions

While the technology is still in early stages, many now believe that if blockchains can create a secure platform for the trade of digital assets, they may also solve the two fundamental challenges facing smart contracts.

First, smart contracts require a way for computer code to control real assets. By enabling fully digitized assets, blockchains make it possible for code to exercise control over property. On a blockchain, control over an asset means controlling a cryptographic key that corresponds to the asset in question, rather than any physical object.

Thus in our example above, the options contract could itself have control of the underlying assets, rather than an escrow agent. When the "exercise" function is called, the operation of the code would transfer the assets without requiring any human assistance.

Second, smart contracts need a "trusted computer" that would execute the terms of the contract. This is the blockchain itself. The blockchains that are being developed today are not only databases, but distributed computers that can execute code as well as record ownership of assets.

Our “smart option” example would itself be uploaded and stored on a blockchain, and would be executed by the blockchain when instructed to do so.

The same properties that make blockchains ideal to record ownership of assets also make them ideal for executing smart contracts. Once the code of the contract is uploaded and recorded onto the blockchain, the parties can have confidence that the contract cannot be altered, and that it will perform as expected.

Current work

Blockchain smart contracts may not be as far away as we expect. Banks, exchanges, and other financial institutions are actively developing blockchain technologies that will enable them to store and trade real assets over blockchain systems. Nasdaq, in partnership with blockchain startup Chain, has developed and begun testing a private-market equity trading platform.

A next-generation open-source blockchain called Ethereum aims to be the foundation for a new industry of non-traditional decentralized commerce. A consortium of 43 banks, working with blockchain firm R3, have begun work on a shared industry platform based on blockchain technology specifically designed to facilitate financial agreements. Within a few years, financial markets may be trading fully-digital assets across blockchain networks, with the terms of those trades enforced by code.

The impact will not be limited to financial contracts, although these are the most obvious use cases. As techniques are developed that enable other types of property to be recorded and transacted on a blockchain, the possible applications for smart contracts will multiply.

If they ever become widely used, smart contracts could alter the nature of corporate and commercial transactions. The advantages of software that have revolutionized so many industries – automation, predictability and speed – could finally be brought to bear on segments of the legal industry.

Representing contractual terms in code, rather than natural language, could bring clarity and predictability to agreements. A smart contract could be tested against any set of inputs – in other words, against any set of material facts which it takes as inputs - allowing lawyers on either side of a deal to know precisely how the contract would execute in every computationally-possible outcome.

In our simple Smart Option example above, each of Alice and Bob could "dry run" the contract in a simulated environment, where every possible input is tested. While this is unnecessary in such a simple example, imagine a contract with thousands of inputs, and hundreds of nested if-then statements – as is common in many complex financial agreements.

These, too, could be tested against every possible input defined in the code. Analogous to how software developers “debug” their own code by testing it in every possible circumstance, lawyers could test contracts, giving each side of a deal a clearer understanding of their risk – and perhaps requiring fewer billable hours.

Alternatives, not replacement

Of course, smart contracts will never fully replace natural-language law. Many types of agreements can never be fully expressed in code or executed by a computer – for instance, those that involve human performance rather than the exchange of dematerialized assets.

Even fully self-executing contracts will ultimately need to make reference to legal terms and concepts that will define each party’s rights if their relationship leads to litigation. Rather, the emergence of smart contracts will lead to a re-evaluation of common practice, as lawyers and clients alike discover which types of agreements and terms are best suited to code, which should be left to natural language, and how to combine each to achieve the best of both worlds.

For now, smart contracts are still science fiction. But for the first time we have a technology that could be used to bring them into commercial use. While that day may still be years away, legal professionals would be wise to consider how these innovations could impact their business.