One of the most popular topics in the digital consensus space (a new term for cryptocurrency 2.0 that I’m beta-testing) is the concept of decentralized autonomous entities. There are now a number of groups rapidly getting involved in the space, including Bitshares (also known as Invictus Innovations) developing “decentralized autonomous companies”, BitAngels’ David Johnston with decentralized applications, our own concept of decentralized autonomous corporations which has since transformed into the much more general and not necessarily financial “decentralized autonomous organizations” (DAOs); all in all, it is safe to say that “DAOism” is well on its way to becoming a quasi-cyber-religion. However, one of the hidden problems lurking beneath the space is a rather blatant one: no one even knows what all of these invididual terms mean. What exactly is a decentralized organization, what is the difference between an organization and an application, and what even makes something autonomous in the first place? Many of us have been frustrated by the lack of coherent terminology here; as Bitshares’ Daniel Larimer points out, “everyone thinks a DAC is just a way of IPOing your centralized company.” The intent of this article will be to delve into some of these concepts, and see if we can come up with at least the beginnings of a coherent understanding of what all of these things actually are.

Smart contracts

A smart contract is the simplest form of decentralized automation, and is most easily and accurately defined as follows: a smart contract is a mechanism involving digital assets and two or more parties, where some or all of the parties put assets in and assets are automatically redistributed among those parties according to a formula based on certain data that is not known at the time the contract is initiated.

One example of a smart contract would be an employment agreement: A wants to pay $500 to B to build a website. The contract would work as follows: A puts $500 into the contract, and the funds are locked up. When B finishes the website, B can send a message to the contract asking to unlock the funds. If A agrees, the funds are released. If B decides not to finish the website, B can quit by sending a message to relinquish the funds. If B claims that he finished the website, but A does not agree, then after a 7-day waiting period it’s up to judge J to provide a verdict in A or B’s favor.

The key property of a smart contract is simple: there is only a fixed number of parties. The parties do not all have to be known at initialization-time; a sell order, where A offers to sell 50 units of asset A to anyone who can provide 10 units of asset B, is also a smart contract. Smart contracts can run on forever; hedging contracts and escrow contracts are good examples there. However, smart contracts that run on forever should still have a fixed number of parties (eg. an entire decentralized exchange is not a smart contract), and contracts that are not intended to exist forever are smart contracts because existing for a finite time necessarily implies the involvement of a finite number of parties.

Note that there is one gray area here: contracts which are finite on one side, but infinite on the other side. For example, if I want to hedge the value of my digital assets, I might want to create a contract where anyone can freely enter and leave. Hence, the other side of the contract, the parties that are speculating on the asset at 2x leverage, has an unbounded number of parties, but my side of the contract does not. Here, I propose the following divide: if the side with a bounded number of parties is the side that intends to receive a specific service (ie. is a consumer), then it is a smart contract; however, if the side with a bounded number of parties is just in it for profit (ie. is a producer), then it is not.

Autonomous Agents

Autonomous agents are on the other side of the automation spectrum; in an autonomous agent, there is no necessary specific human involvement at all; that is to say, while some degree of human effort might be necessary to build the hardware that the agent runs on, there is no need for any humans to exist that are aware of the agent’s existence. One example of an autonomous agent that already exists today would be a computer virus; the virus survives by replicating itself from machine to machine without deliberate human action, and exists almost as a biological organism. A more benign entity would be a decentralized self-replicating cloud computing service; such a system would start off running an automated business on one virtual private server, and then once its profits increase it would rent other servers and install its own software on them, adding them to its network.

A full autonomous agent, or a full artificial intelligence, is the dream of science fiction; such an entity would be able to adjust to arbitrary changes in circumstances, and even expand to manufacture the hardware needed for its own sustainability in theory. Between that, and single purpose agents like computer viruses, is a large range of possibilities, on a scale which can alternatively be described as intelligence or versatility. For example, the self-replicating cloud service, in its simplest form, would only be able to rent servers from a specific set of providers (eg. Amazon, Microtronix and Namecheap). A more complex version, however, should be able to figure out how to rent a server from any provider given only a link to its website, and then use any search engine to locate new websites (and, of course, new search engines in case Google fails). The next level from there would involve upgrading its own software, perhaps using evolutionary algorithms, or being able to adapt to new paradigms of server rental (eg. make offers for ordinary users to install its software and earn funds with their desktops), and then the penultimate step consists of being able to discover and enter new industries (the ultimate step, of course, is generalizing completely into a full AI).

Autonomous agents are some of the hardest things to create, because in order to be successful they need to be able to navigate in an environment that is not just complicated and rapidly changing, but also hostile. If a web hosting provider wants to be unscrupulous, they might specifically locate all instances of the service, and then replace them with nodes that cheat in some fashion; an autonomous agent must be able to detect such cheating and remove or at least neutralize cheating nodes from the system.

Decentralized Applications

A decentralized application is similar to a smart contract, but different in two key ways. First of all, a decentralized application has an unbounded number of participants on all sides of the market. Second, a decentralized application need not be necessarily financial. Because of this second requirement, decentralized applications are actually some of the easiest things to write (or at least, were the easiest before generalized digital consensus platforms came along). For example, BitTorrent qualifies as a decentralized application, as do Popcorn Time, BitMessage, Tor and Maidsafe (note that Maidsafe is also itself a platform for other decentralized applications).

Generally, decentralized applications fall into two classes, likely with a substantial gray area between the two. The first class is a fully anonymous decentralized application. Here, it does not matter who the nodes are; every participant is essentially anonymous and the system is made up of a series of instant atomic interactions. BitTorrent and BitMessage are examples of this. The second class is a reputation-based decentralized application, where the system (or at least nodes in the system) keep track of nodes, and nodes maintain status inside of the application with a mechanism that is purely maintained for the purpose of ensuring trust. Status should not be transferable or have de-facto monetary value. Maidsafe is an example of this. Of course, purity is impossible – even a BitTorrent-like system needs to have peers maintain reputation-like statistics of other peers for anti-DDoS purposes; however, the role that these statistics play is purely in the background and very limited in scope.

An interesting gray area between decentralized applications and “something else” is applications like Bitcoin and Namecoin; these differ from traditional applications because they create ecosystems and there is a concept of virtual property that has value inside the context of this ecosystem, in Bitcoin’s case bitcoins and in Namecoin’s case namecoins and domain names. As we’ll see below, my classification of decentralized autonomous organizations touches on such concepts, and it is not quite clear exactly where they sit.

Decentralized Organizations

In general, a human organization can be defined as combination of two things: a set of property, and a protocol for a set of individuals, which may or may not be divided into certain classes with different conditions for entering or leaving the set, to interact with each other including rules for under what circumstances the individuals may use certain parts of the property. For example, consider a simple corporation running a chain of stores. The corporation has three classes of members: investors, employees and customers. The membership rule for investors is that of a fixed-size (or optionally quorum-adjustable size) slice of virtual property; you buy some virtual property to get in, and you become an investor until you sell your shares. Employees need to be hired by either investors or other employees specifically authorized by investors (or other employees authorized by other employees authorized by investors, and so on recursively) to participate, and can also be fired in the same way, and customers are an open-membership system where anyone can freely interact with the store in the obvious officially sanctioned way for any time. Suppliers, in this model, are equivalent to employees. A nonprofit charity has a somewhat different structure, involving donors and members (charity recipients may or may not be considered members; the alternative view sees the positive increments in the recipients’ welfare as being the charity’s “product”).

The idea of a decentralized organization takes the same concept of an organization, and decentralizes it. Instead of a hierarchical structure managed by a set of humans interacting in person and controlling property via the legal system, a decentralized organization involves a set of humans interacting with each other according to a protocol specified in code, and enforced on the blockchain. A DO may or may not make use of the legal system for some protection of its physical property, but even there such usage is secondary. For example, one can take the shareholder-owned corporation above, and transplant it entirely on the blockchain; a long-running blockchain-based contract maintains a record of each individual’s holdings of their shares, and on-blockchain voting would allow the shareholders to select the positions of the board of directors and the employees. Smart property systems can also be integrated into the blockchain directly, potentially allowing DOs to control vehicles, safety deposit boxes and buildings.

Decentralized Autonomous Organizations

Here, we get into what is perhaps the holy grail, the thing that has the murkiest definition of all: decentralized autonomous organizations, and their corporate subclass, decentralized autonomous corporations (or, more recently, “companies”). The ideal of a decentralized autonomous organization is easy to describe: it is an entity that lives on the internet and exists autonomously, but also heavily relies on hiring individuals to perform certain tasks that the automaton itself cannot do.

Given the above, the important part of the definition is actually to focus on what a DAO is not, and what is not a DAO and is instead either a DO, a DA or an automated agent/AI. First of all, let’s consider DAs. The main difference between a DA and a DAO is that a DAO has internal capital; that is, a DAO contains some kind of internal property that is valuable in some way, and it has the ability to use that property as a mechanism for rewarding certain activities. BitTorrent has no internal property, and Bitcloud/Maidsafe-like systems have reputation but that reputation is not a saleable asset. Bitcoin and Namecoin, on the other hand, do. However, plain old DOs also have internal capital, as do autonomous agents.

Second, we can look at DOs. The obvious difference between a DO and a DAO, and the one inherent in the language, is the word “autonomous”; that is, in a DO the humans are the ones making the decisions, and a DAO is something that, in some fashion, makes decisions for itself. This is a surprisingly tricky distinction to define because, as dictatorships are always keen to point out, there is really no difference between a certain set of actors making decisions directly and that set of actors controlling all of the information through which decisions are made. In Bitcoin, a 51% attack between a small number of mining pools can make the blockchain reverse transactions, and in a hypothetical decentralized autonomous corporation the providers of the data inputs can all collude to make the DAC think that sending all of its money to1FxkfJQLJTXpW6QmxGT6oF43ZH959ns8Cq constitutes paying for a million nodes’ worth of computing power for ten years. However, there is obviously a meaningful distinction between the two, and so we do need to define it.

My own effort at defining the difference is as follows. DOs and DAOs are both vulnerable to collusion attacks, where (in the best case) a majority or (in worse cases) a significant percentage of a certain type of members collude to specifically direct the D*O’s activity. However, the difference is this: in a DAO collusion attacks are treated as a bug, whereas in a DO they are a feature. In a democracy, for example, the whole point is that a plurality of members choose what they like best and that solution gets executed; in Bitcoin’s on the other hand, the “default” behavior that happens when everyone acts according to individual interest without any desire for a specific outcome is the intent, and a 51% attack to favor a specific blockchain is an aberration. This appeal to social consensus is similar to the definition of a government: if a local gang starts charging a property tax to all shopowners, it may even get away with it in certain parts of the world, but no significant portion of the population will treat it as legitimate, whereas if a government starts doing the same the public response will be tilted in the other direction.

Bitcoin is an interesting case here. In general, it seems to be much closer to a DAO than a DO. However, there was one incident in 2013 where the reality proved to be rather different. What happened was that an exceptional block was (at least we hope) accidentally produced, which was treated as valid according to the BitcoinQt 0.8 clients, but invalid according to the rules of BitcoinQt 0.7. The blockchain forked, with some nodes following the blockchain after this exceptional block (we’ll call this chain B1), and the other nodes that saw that block as invalid working on a separate blockchain (which we’ll call B2). Most mining pools had upgraded to BitcoinQt 0.8, so they followed B1, but most users were still on 0.7 and so followed B2. The mining pool operators came together on IRC chat, and agreed to switch their pools to mining on B2, since that outcome would be simpler for users because it would not require them to upgrade, and after six hours the B2 chain overtook B1 as a result of this deliberate action, and B1 fell away. Thus, in this case, there was a deliberate 51% attack which was seen by the community as legitimate, making Bitcoin a DO rather than a DAO. In most cases, however, this does not happen, so the best way to classify Bitcoin would be as a DAO with an imperfection in its implementation of autonomy.

However, others are not content to classify Bitcoin as a DAO, because it is not really smart enough. Bitcoin does not think, it does not go out and “hire” people with the exception of the mining protocol, and it follows simple rules the upgrading process for which is more DO-like than DAO-like. People with this view would see a DAO as something that has a large degree of autonomous intelligence of its own. However, the issue with this view is that there must be a distinction made between a DAO and an AA/AI. The distinction here is arguably this: an AI is completely autonomous, whereas a DAO still requires heavy involvement from humans specifically interacting according to a protocol defined by the DAO in order to operate. We can classify DAOs, DOs (and plain old Os), AIs and a fourth category, plain old robots, according to a good old quadrant chart, with another quadrant chart to classify entities that do not have internal capital thus altogether making a cube:

DAOs == automation at the center, humans at the edges. Thus, on the whole, it makes most sense to see Bitcoin and Namecoin as DAOs, albeit ones that barely cross the threshold from the DA mark. The other important distinction is internal capital; a DAO without internal capital is a DA and an organization without internal capital is a forum; the G8, for example, would qualify as a forum. DCs in the graph above are “decentralized communities”; an example of that might be something like a decentralized Reddit, where there is a decentralized platform, but there is also a community around that platform, and it is somewhat ambiguous whether the community or the protocol is truly “in charge”.

Decentralized Autonomous Corporations

Decentralized autonomous corporations/companies are a smaller topic, because they are basically a subclass of DAOs, but they are worth mentioning. Since the main exponent of DAC as terminology is Daniel Larimer, we will borrow as a definition the point that he himself consistently promotes: a DAC pays dividends. That is, there is a concept of shares in a DAC which are purchaseable and tradeable in some fashion, and those shares potentially entitle their holders to continual receipts based on the DAC’s success. A DAO is non-profit; though you can make money in a DAO, the way to do that is by participating in its ecosystem and not by providing investment into the DAO itself. Obviously, this distinction is a murky one; all DAOs contain internal capital that can be owned, and the value of that internal capital can easily go up as the DAO becomes more powerful/popular, so a large portion of DAOs are inevitably going to be DAC-like to some extent.

Thus, the distinction is more of a fluid one and hinges on emphasis: to what extent are dividends the main point, and to what extent is it about earning tokens by participation? Also, to what extent does the concept of a “share” exist as opposed to simple virtual property? For example, a membership on a nonprofit board is not really a share, because membership frequently gets granted and confiscated at will, something which would be unacceptable for something classified as investable property, and a bitcoin is not a share because a bitcoin does not entitle you to any claim on profits or decision-making ability inside the system, whereas a share in a corporation definitely is a share. In the end, perhaps the distinction might ultimately be the surprisingly obscure point of whether or not the profit mechanism and the consensus mechanism are the same thing.

The above definitions are still not close to complete; there will likely be gray areas and holes in them, and exactly what kind of automation a DO must have before it becomes a DAO is a very hard question to answer. Additionally, there is also the question of how all of these things should be built. An AI, for example, should likely exist as a network of private servers, each one running often proprietary local code, whereas a DO should be fully open source and blockchain-based. Between those two extremes, there is a large number of different paradigms to pursue. How much of the intelligence should be in the core code? Should genetic algorithms be used for updating code, or should it be futarchy or some voting or vetting mechanism based on individuals? Should membership be corporate-style, with sellable and transferable shares, or nonprofit-style, where members can vote other members in and out? Should blockchains be proof of work, proof of stake, or reputation-based? Should DAOs try to maintain balances in other currencies, or should they only reward behavior by issuing their own internal token? These are all hard problems and we have only just begun scratching the surface of them.

What is Ethereum, the Project?

The Ethereum Project is an open source, community-driven effort designed to create a next-generation distributed application platform intended to be maximally flexible and powerful in the possibilities that it enables.

What is Ethereum, the Platform?

The Ethereum Platform combines a generalized peer-to-peer networking platform with next-generation blockchain architecture to deliver a decentralized consensus-based (decentcon), full-stack platform for developing, offering and using distributed application services. A consumer-facing application, called the EtherBrowser, integrates the front and back ends to create an environment in which anyone can easily and rapidly build highly secure, scalable and interoperable decentralized applications.

Like the BitTorrent content sharing system, Ethereum network nodes will run on thousands of computers around the world and, short of shutting down the Internet, its operations cannot be halted. This is because peer-to-peer systems generally involve a very large number of independent actors (people or organizations) each running the peer node software on one or more computers. In the Bitcoin system, these nodes are called “miners.”

Like Bitcoin, in Ethereum, the nodes on the network serve as miners whose purpose is to process and validate the transactions and computations on the system and quickly achieve a consensus regarding what happened on the system and when. This consensus is what provides the network with its security. The larger the number of nodes there are and the more work these nodes have to do to exercise a vote regarding what transpired on the network, the greater is the sense that this shared consensus view of the history of the system is a canonical and irrepudiable representation. In Ethereum, miners receive a reward for doing the work required to inform and enable their vote and they are also paid for providing resources to the network in the form of bandwidth, storage and computational processing.

Bitcoin is a system for securely transmitting and storing value. As such, it can serve as the financial bedrock of the emerging global decentcon economy. A conservative, prudent, development roadmap for Bitcoin will make it easier to use and further secure the protocol against quirks and edge cases that might be exploited in the future (though it has thus far proven to be remarkably solid at the protocol level). In contrast, as a platform for hosting distributed or decentralized applications (ÐApps — spelled with the capital letter “eth” and pronounced “dapps” or “eth-apps” by the cognoscenti :-) ) and services, Ethereum must be agile and forward moving. In Q4 of 2014, the Ethereum team will deliver a feature-rich system that will be fully functional and will possess a rich user interface and deliver a compelling user experience for both end users and businesses building ÐApps and offering services on the platform. But technology moves fast, so Ethereum will require an upgrade roadmap and continual development.

What is Ether, the Cryptofuel?

Just as the Bitcoin system has a token, called a bitcoin (lower case) that serves as the medium of exchange, Ethereum has ether (ETH) which serves as a unit of exchange to some degree, but more importantly, it serves as a fuel that powers applications on the Ethereum system.

The engineers of the Ethereum Project are building a computational device or appliance, in the form of a software program, that anyone can download and run on their computer, smart phone, or on dedicated, fast hardware. In order to operate this software appliance a certain type of token is required as fuel in appropriate quantities.

Distributed applications on Ethereum require payments of this token to fuel every computational and storage operation on the system. Without requiring payments for operations, the system would be vulnerable to many sorts of attacks and would not be viable or secure. The payments are made to owners of computational resources in exchange for securing the Ethereum network, for transmitting transactions, for storing data and for processing computations required by distributed software applications.

People and businesses are interested in purchasing ETH to power their own business applications, to make use of business applications offered by other service providers, to trade on forthcoming exchanges, or to speculatively hold for future sale to people and businesses. ETH may be purchased in the Genesis Sale (details forthcoming, please watch this space), on forthcoming 3rd-party exchanges and ATMs, and on exchanges that are implemented as DApps on Ethereum.

When purchasing ETH in the Genesis Sale, the buyer is supporting the development of the product, just as with a kickstarter campaign. When the product is completed and ready for delivery, buyers will be able to claim their purchased ETH from the genesis block — the root block of the Ethereum blockchain.

What is Ethereum, the Software Stack?

A software stack is a set of technologies, realized at different layers and levels of abstraction and possessing different complementary capabilities that work well together to enable a software development team to build a full, back-end to front-end software service for an end user. Ethereum provides a full-stack solution for developing and delivering ÐApps, the front end of which may be accessed by an end user from a web page, dedicated front-end applications, or more commonly from the Ethereum ÐApp Browser. The Ethereum stack is the first of its kind to enable developers to deliver decentcon software applications.

When delivering an ÐApp the developer or deployer of that ÐApp does not arrange hosting of back-end server processes as with traditional software services. Rather, the code is embedded as payload in a transaction on the Ethereum network and sent to one or more mining nodes on the network. Miners that receive the transaction will broadcast it to all of the peers that they are aware of, provided the transaction sender has included enough ETH, the cryptofuel that powers operations on the system, to pay for the transaction. This transaction diffuses through the network, peer to peer, and eventually is packaged into a block and locked into the blockchain. Blocks are created by miners approximately once per minute. Once the transaction with the code payload is embedded into a block, subsequent transactions can be sent to an address that is designated as the controller interface for that ÐApp to invoke processing of the ÐApp.

When an end user wishes to activate one or more services offered by this ÐApp, she will typically interact with a front-end user interface, loaded into the ÐApp Browser (probably Qt-based or JavaScript/HTML5/CSS3) to trigger desired actions. User interface components will be cached on some kind of decentralized BitTorrent-like cloud and pulled in by the ÐApp Browser as needed. The user interface will formulate Ethereum transactions and send these, with a suitable amount of the cryptofuel and any input data required, to the address of the controller interface of the ÐApp. Once collected into a block, the transaction will trigger execution of the ÐApp and the states of various components (called contracts) of the ÐApp will transition to a result state. A peer-to-peer fast messaging protocol, will enable the user interface to reflect such changes, and will facilitate communication among different DApps and among users.

One thing to notice is that, from the perspective of application hosting, there is virtually nothing to be done. The back end is launched into the blockchain “cloud” and the front end will usually be represented as a installable tile in the Ethereum ÐApp Browser. The end user will download the browser once and the browser will receive continual updates from BitTorrent or a BitTorrent-like distribution system. While browsing the distributed ÐApp catalog in the browser, the end user can install any ÐApp of interest in her browser with a no cost, one-click installation. These tiles will be organized categorically by users and each will be invokable into in a full blown, user interface “responsively” sized and configured to the dimensions and capabilities of the browser (some weaker devices may have limitations).

The programming paradigm just described will be very unusual in comparison to typical development technologies and will require innovative (and perhaps sometimes kludgey) approaches. If a programmer can only expect the state of the business logic to update once per minute, stochastically, techniques will have to be developed for certain kinds of applications to perhaps cache certain expected state changes and wait on back end processing before updating the front end. Even more complicated is the fact that a block housing transactions and associated ÐApp state changes can be constructed and included in the blockchain but then find itself not part of the main consensus blockchain soon after and possibly have the associated transactions remain unconfirmed and unprocessed for a period of time. Worse, an intervening transaction might be processed first, thus rendering the first transaction invalid. An entire new field of blockchain-based software development techniques is required. Many developers will forge novel solutions. And some fundamentally new approaches may be required. And for this, we are developing the Crypto Currency Research Group (CCRG) to conduct general research of benefit to the entire niche. Please watch this space for more on the CCRG.

The Necessity to Build and Launch an Ecosystem on Genesis Day

Imagine if Microsoft released the Xbox and there were no games.

On the day on which the Ethereum genesis block is created, many of the elements of the ecosystem — core infrastructure, mining network, user app browser and applications — will be in place. Granted there will be an enormous amount of development to do beyond the genesis to craft Ethereum into a sophisticated, decentralized consensus (decentcon) application platform. But on day one, there will be “launch titles.”

Originally, when the idea behind Ethereum was conceived in November, the intent was for it to be a simple “altcoin” (in fact, a meta-protocol on top of Primecoin) with a scripting language built in. Over time, however, as we realized the project’s potential our scope necessarily grew, and our current intent is to release a flagship product called the “EtherBrowser:” a browser that can browse both the old-school Internet and the decentralized web (Web3.0). From the moment of inception of the Ethereum network, the following elements in the EtherBrowser and the ecosystem will be operational:

• a fully functional implementation of the Ethereum blockchain which enhances the Bitcoin technology with one-minute block times and stronger security (GHOST protocol), which decentralized applications (“ÐApps”) can use for anything that requires consensus (eg. currency and token systems, name registries, proof of existence, etc., …)
• a fully functional peer-to-peer protocol, which ÐApps can use to send messages between users. For example, a decentralized messaging ÐApp will use this protocol for actual message sending, but the blockchain for registering user accounts.
• an elegant, browser-and-app-store user interface for using ÐApps
• network nodes (miners) that process transactions and computations, secure the network through a consensus process and are compensated by fees and the issuance of new ether
• a standard set of “built-in” utility-level ÐApps: distributed wallet, distributed ID system, distributed reputation system, distributed messaging system, distributed name registry service, distributed catalog of distributed applications, etc., will serve as just a few of the low-level utilities on the system
• a standard set of built-in tools for both developer and end-user: blockchain explorer, contract explorer, transaction constructor, encrypted messaging tool, signature tool, authentication tool, …. And a debugger will be available for the hard core.

And soon after the genesis we hope to see a rich set of third-party distributed applications, e.g. distributed storage services, distributed notary services, distributed exchange services, distributed escrow and arbitration services, financial contracts, insurance contracts, lending services, purposed reputation systems, games, entertainment services, etc., … Each of the ÐApps in the different business verticals will be able to make use of the lower level, system utility ÐApps like the ID and reputation systems.

Without operational distributed applications, Ethereum is a hollow shell. In order to have a broad offering of distributed applications from day one, non-profit, public-good elements must be built in conjunction with commercially driven applications in competitive markets. From this requirement, Ethereum takes its dual mandate.

It can be argued that certain elements within an ecosystem should be developed for the common good, and do not benefit from a profit motive. Certain other elements, are better developed in a competitive, for-profit context. For instance, it makes some sense to develop a coherent, large-scale, systematized road system for the public good, using public tax dollars. But it probably does not make sense to build cars with public tax dollars, since development under the pressures of free market competition forces the design and production of better products and benefits the market as a whole.

Dual Mandate: Collaborative Non-Profit and For-Profit Development

Two hub organizations will lead the Ethereum Project under dual mandate: a for-profit entity based in Zug, Switzerland, and a non-profit organization, based in Toronto, Canada. Both of these organizations will be constructed in a fashion that will enable each to remain strong and financially independent to ensure years of development and growth of the ecosystem.

The Ethereum ecosystem will initially be constructed by the non-profit and for-profit entities in partnership, ideally with broad participation from many other independent entities. The founding leadership will put into place mechanism that ensures that the foundational elements of the ecosystem are built and maintained in a fashion that adheres to the founding principles. Funding and independence will be guaranteed to the organizations (either state-registered businesses or eventually blockchain-registered businesses) that guide the various avenues of development of the core infrastructure.

At the same time, human economies are largely about free market commerce (or should be), so the non-profit organization, to some extent — and especially the for-profit entity — will assist independent business efforts in the space to launch and flourish. This assistance can take a variety of forms from providing resources and guidance, to maintaining support channels, to the creation of joint ventures.

The Hybrid Organization Model

“MOZILLA IS ONE SUCH [HYBRID NON-PROFIT/FOR-PROFIT] ORGANIZATION AND, AS I LOOK AROUND, I SEE OTHERS. THERE IS ALOT [SIC] OF UPSIDE TO HOW THESE ORGS WORK, ESPECIALLY THE POTENTIAL TO MOVE MARKETS TOWARDS THE PUBLIC GOOD AT A GLOBAL SCALE.

“…THE MORE I DIG, THE MORE I AM CONVINCED THAT ORGANIZATIONS LIKE MOZILLA, WIKIPEDIA, KIVA, MIRO AND SO ON THAT MASHUP MISSION, MARKET AND THE CULTURE OF THE WEB REPRESENT A NEW PATTERN WORTH UNDERSTANDING.

“MISSION + MARKET + WEB HYBRIDS MATTER BECAUSE THEY CAN WIELD THE POWER NEEDED TO MOVE MARKETS AT A GLOBAL SCALE, WHILE STILL LOOKING OUT FOR THE SMALL GUY, TAKING THE LONG VIEW AND STAYING TRUE TO THEIR PUBLIC BENEFIT MISSION. THEY SHOW US HOW ORGANIZATIONS COULD — AND MAYBE SHOULD — WORK IN THE FUTURE.”

• MARK SURMAN, EXECUTIVE DIRECTOR, MOZILLA FOUNDATION

Trolltech/Digia (Qt), WordPress, Red Hat, Google Android and the Open Handset Alliance, The Mozilla Organization and several others have pioneered the dual mandate approach and built thriving ecosystems and successful companies. The model that Sun developed in the late 90s is also instructive.

Sun Microsystems (now Oracle) developed the Java computer language and libraries in house. As innovative as it was, it is likely that it would not have acquired such large market share, had Sun not realized that they, as a for-profit company, could not control a foundational aspect of software development that it, and many of its competitors, were expected to use. To address this conflict of interest, Sun open sourced Java and developed the Java Community Process to shepherd growth of the platform in a nonpartisan fashion.

Ethereum is an open source project and will remain open source. And the Ethereum Project, under the auspices of its non-profit foundation will create a community development process philosophically similar to the Java Community Process. In fact, Ethereum, thus far has been developed under a less formalized community development process.

The Ethereum non-profit entity will specify and guide the development of the core Ethereum infrastructure. It will employ a non-partisan community development process and will develop, conduct and support research initiatives in the general cryptocurrency space. The non-profit will have a membership composed originally of the Ethereum founders, and soon will add other independent leaders in the emerging space.

The Ethereum for-profit entity will be charged with the task of developing certain elements of the core infrastructure in collaboration with the non-profit entity and building out the Ecosystem with distributed application services and businesses that it develops itself, funds, or otherwise supports.

We believe this to be the most effective structure in the near term. That said, we are DAOists (where DAO means Distributed Autonomous Organization). We will look to move as much infrastructure and governance as soon as possible onto the blockchain. Our OpenSalary system will probably be the first component to move to the blockchain. Please stay tuned for more on the topics of OpenOrganization and DAOification of the two organizations. Our goal, if we do our jobs properly, is to put ourselves out of (state-registered) business.

Our current proof of work design, blockchain-based proof of work, is the second iteration of our attempt to create a mining algorithm that is guaranteed to remain CPU-friendly and resistant to optimization by specialized hardware (ASICs) in the long term. Our first attempt, Dagger, tried to take the idea of memory-hard algorithms like Scrypt one step further by creating an algorithm which is memory-hard to compute, but memory-easy to verify, using directed acyclic graphs (basically, trees where each node has multiple parents). Our current strategy takes a much more rigorous track: make the proof of work involve executing random contracts from the blockchain. Because the Ethereum scripting language is Turing-complete, an ASIC that can execute Ethereum scripts is by definition an ASIC for general computation, ie. a CPU – a much more elegant argument than “this is memory-hard so you can’t parallelize as much”. Of course, there are issues of “well, can you make specific optimizations and still get a large speedup”, but it can be argued that those are minor kinks to be worked out over time. The solution is also elegant because it is simultaneously an economic one: if someone does create an ASIC, then others will have the incentive to look for types of computation that the ASIC can’t do and “pollute” the blockchain with such contracts. Unfortunately, however, there is one much larger obstacle to such schemes in general, and one which is unfortunately to some degree fundamental: long-range attacks.

A long-range attack basically works as follows. In a traditional 51% attack, I put 100 bitcoins into a fresh new account, then send those 100 bitcoins to a merchant in exchange for some instant-delivery digital good (say, litecoins). I wait for delivery (eg. after 6 confirmations), but then I immediately start working on a new blockchain starting from one block before the transaction sending the 100 bitcoins, and put in a transaction instead sending those bitcoins back to myself. I then put more mining power into my fork than the rest of the network combined is putting into the main chain, and eventually my fork overtakes the main chain and thereby becomes the main chain, so at the end I have both the bitcoins and the litecoins. In a long-range attack, instead of starting a fork 6 blocks back, I start the fork 60000 blocks back, or even at the genesis block.

In Bitcoin, such a fork is useless, since you’re just increasing the amount of time you would need to catch up. In blockchain-based proof of work, however, it is a serious problem. The reason is that if you start a fork straight from the genesis block, then while your mining will be slow at first, after a few hundred blocks you will be able to fill the blockchain up with contracts that are very easy for you to mine, but difficult for everyone else. One example of such a contract is simply:

i = 0 while sha3(i) != 0x8ff5b6afea3c68b6cd68bd429b9b64a708fa2273a93ea9f9e3c763257affee1f: i = i + 1

You know that the contract will take exactly one million rounds before the hash matches up, so you can calculate exactly how many steps and how much gas it will take to run and what the state will be at the end immediately, but other people will have no choice but to actually run through the code. An important property of such a scheme, a necessary consequence of the halting problem, is that it is actually impossible (as in, mathematically provably impossible, not Hollywood impossible) to construct a mechanism for detecting such clever contracts in the general case without actually running them. Hence, the long-range-attacker could fill the blockchain with such contracts, “mine” them, and convince the network that it is doing a massive amount of work when it is actually just taking the shortcut. Thus, after a few days, our attacker will be “mining” billions of times faster than the main chain, and thereby quickly overtake it.

Notice that the above attack assumes little about how the algorithm actually works; all it assumes is that the condition for producing a valid block is dependent on the blockchain itself, and there is a wide range of variability in how much influence on the blockchain a single unit of computational power can have. One solution involves artificially capping the variability; this is done by requiring a tree-hashed computational stack trace alongside the contract algorithm, which is something that cannot be shortcut-generated because even if you know that the computation will terminate after 1 million steps and produce a certain output you still need to run those million steps yourself to produce all of the intermediate hashes. However, although this solves the long-range-attack problem it also ensures that the primary computation is not general computation, but rather computing lots and lots of SHA3s – making the algorithm once again vulnerable to specialized hardware.

Proof of Stake

A version of this attack also exists for naively implemented proof of stake algorithms. In a naively implemented proof of stake, suppose that there is an attacker with 1% of all coins at or shortly after the genesis block. That attacker then starts their own chain, and starts mining it. Although the attacker will find themselves selected for producing a block only 1% of the time, they can easily produce 100 times as many blocks, and simply create a longer blockchain in that way. Originally, I thought that this problem was fundamental, but in reality it’s an issue that can be worked around. One solution, for example, is to note that every block must have a timestamp, and users reject chains with timestamps that are far ahead of their own. A long-range attack will thus have to fit into the same length of time, but because it involves a much smaller quantity of currency units its score will be much lower. Another alternative is to require at least some percentage (say, 30%) of all coins to endorse either every block or every Nth block, thereby absolutely preventing all attacks with less than that percent of coins. Our own PoS algorithm, Slasher, can easily be retrofitted with either of these solutions.

Thus, in the long term, it seems like either pure proof of stake or hybrid PoW/PoS are the way that blockchains are going to go. In the case of a hybrid PoW/PoS, one can easily have a scheme where PoS is used to resolve the issue described above with BBPoW. What we’ll go with for Ethereum 1.0 may be proof of stake, it might be a hybrid scheme, and it might be boring old SHA3, with the understanding that ASICs will not be developed since manufacturers would see no benefit with the impending arrival of Ethereum 2.0. However, there is still one challenge that arguably remains unresolved: the distribution model. For my own thoughts on that, stay tuned for the next part of this series.