Ethereum Project Update

Development of the Ethereum project has gone very well over the months since inception.  The core activity — development of the software platform — is on track and many developers around the world are starting to build small, exploratory distributed applications on the platform, even though we are still not yet in alpha release.

The 5th installment of the proof of concept series will be released soon, though many community members download the developing source code, compile it and use it on a regular basis for their various activities.

Other core activities include attention to legalities in different jurisdictions regarding the pre-sale, development and testing of the hot/cold wallet system, and development and testing of the sale web site.  These are well on their way to completion.  Documentation regarding the sale is also nearing completion though there are still some incomplete items in the critical path that makes it difficult for us to set a sale date as yet.

All of these activities are embedded in an ongoing base of support and communications activities.  These have grown extensive due to the global popularity of the project.  Our twitter followers number in excess of 6000.  The number of global meet-ups that focus on Ethereum exclusively or significantly currently numbers 58 groups in 49 different cities, spread over 19 countries.  13,300 people have subscribed to our newsletter.  And the  various discussions on reddit/r/etherum and forum.ethereum.org are active.

This project is agile and fast moving and has benefitted from several leadership reorganizations since inception. It is anticipated that this fluidity will continue as each of us are dedicated remaining lean and agile and to doing what is best for the project at any given time.

Stephan Tual and Taylor Gerring have been on the project and essential to it since the early days.  Though they had significant input already, this has been formalized and they are now part of the leadership group.

The most recent phase of business activity involved strong attention to the legalities of the sale and Charles Hoskinson was ideal to lead that effort.  But that effort is now substantially complete and Charles will be moving on to other activities in the space.

Please stay tuned to this channel as we will continue to release information regarding software development activities and details of the pre-sale for absorption and feedback.

 

What If Ethereum Lived on a Treap? Or, Blockchains Charging Rent

Although truly solving blockchain scalability fundamentally, that is to say figuring out a solution to the problem that every node must process every transaction, is a very hard problem, and all suggested solutions rely on either highly advanced cryptography or intricate multi-blockchain architectures, partial solutions that provide a constant-factor improvement over the way Bitcoin does things are actually quite easy to find. In Ethereum, for example, we have the concept of a separate state tree and transaction history, allowing miners to easily store only existing account states and not historical transaction outputs that are no longer relevant and thereby drastically reducing the amount of storage that would be required; if Bitcoin is any indication, savings should be around 90%. Another improvement is the use of accounts instead of coins/UTXO as the fundamental unit, allowing each user to take up less than a hundred bytes on the blockchain regardless of how many transactions go in and out of their account. Of course, both of these are partially, or perhaps even fully, offset by the fact that Ethereum has a much larger scope, intending to use the blockchain for much more than just monetary transactions, but even if that is true it makes scalability all the more necessary. What I am about to describe in this article is another anti-bloat strategy that could potentially be used to achieve very substantial gains, this time targeting the issue of “dust”.

Dust, in simple terms, refers to the accumulation of tiny outputs (or accounts) on the blockchain, perhaps with only a fraction of a cent worth of coin, that are either dumped onto the blockchain maliciously or are simply too low-value to be even worth the increased transaction fee to send. On Ethereum, dust of the second kind can also consist of accounts that have zero balance left, perhaps because the user might want to switch to a different private key for security reasons. Dust is a serious problem; it is estimated that the majority of the Bitcoin blockchain is dust, and in the case of Litecoin something like 90% of the outputs are the result of a single malicious blockchain spam attack that took place back to 2011. In Ethereum, there is a storage fee on SSTORE in order to charge for adding something to the state, and the floating block limit system ensures that even a malicious miner has no significant advantage in this regard, but there is no concept of a fee charged over time; hence, there is no protection or incentive against a Litecoin-style attack affecting the Ethereum blockchain as well. But what if there was one? What if the blockchain could charge rent?

The basic idea behind charging rent is simple. Each account would keep track of how much space it takes up, including the [ nonce, balance, code, state_root ] header RLP and the storage tree, and then every block the balance would go down by RENTFEE multiplied by the amount of space taken up (which can be measured in bytes, for simplicity normalizing the total memory load of each storage slot to 64 bytes). If the balance of an account drops below zero, it would disappear from the blockchain. The hard part is implementation. Actually implementing this scheme is in one way easier and in one way harder than expected. The easy part is that you do not need to actually update every account every block; all you do is keep track of the last block during which the account was manipulated and the amount of space taken up by the account in the header RLP and then read just the account every time computation accesses it. The hard part, however, is deleting accounts with negative balance. You might think that you can just scan through all accounts from time to time and then remove the ones with negative balances from the database; the problem is, however, that such a mechanism doesn’t play nicely with Patricia trees. What if a new user joins the network at block 100000, wants to download the state tree, and there are some deleted accounts? Some nodes will have to store the deleted accounts to justify the empty spots, the hashes corresponding to nothing, in the trie. What if a light client wants a proof of execution for some particular transaction? Then the node supplying the proof will have to include the deleted accounts. One approach is to have a “cleansing block” every 100000 blocks that scans through the entire state and clears out the cruft. However, what if there was a more elegant solution?

Treaps

One elegant data structure in computer science is something called a treap. A treap, as one might or probably might not understand from the name, is a structure which is simultaneously a tree and a heap. To review the relevant data structure theory, a heap) is a binary tree, where each node except for leaves has one or two children, where each node has a lower value than its children and the lowest-value node is at the top, and what data structure theorists normally call a tree is a binary tree where values are arranged in sorted order left to right (ie. a node is always greater than its left child and less than its right child, if present). A treap combines the two by having nodes with both a key and a priority; the keys are arranged horizontally and the priorities vertically. Although there can be many heaps for each set of priorities, and many binary trees for each set of values, as it turns out it can be proven that there is always exactly one treap that matches every set of (priority, value) pairs.

Also, as it turns out, there is an easy (ie. log-time) algorithm for adding and removing a value from the treap, and the mathematical property that there is only one treap for every set of (priority, value) pairs means that treaps are deterministic, and both of these things together make treaps a potential strong candidate for replacing Patricia trees as the state tree data structure. But then, the question is, what would we use for priorities? The answer is simple: the priority of a node is the expected block number at which the node would disappear. The cleaning process would then simply consist of repeatedly kicking off nodes at the top of the treap, a log-time process that can be done at the end of every block.

However, there is one implementation difficulty that makes treaps somewhat challenging for this purpose: treaps are not guaranteed to be shallow. For example, consider the values [[5, 100], [6, 120], [7, 140], [8, 160], [9, 180]]. The treap for those would unfortunately look like this:

Now, imagine that an attacker generates ten thousand addresses, and puts them into sorted order. The attacker then creates an account with the first private key, and gives it enough ether to survive until block 450000. The attacker then gives the second private key enough ether to survive until block 450001. The third private key lasts until 450002, and so forth until the last account susrvives until block 459999. All of these go into the blockchain. Now, the blockchain will have a chain of ten thousand values each of which is below and to the right of all of the previous. Now, the attacker starts sending transactions to the addresses in the second half of the list. Each of those transactions will require ten thousand database accesses to go through the treap to process. Basically, a denial of service attack through trie manipulation. Can we mitigate this by having the priorities decided according to a more clever semi-randomized algorithm? Not really; even if priorities were completely random, there is an algorithm using which the attacker would be able to generate a 10000-length subsequence of accounts that have both address and priority in increasing order in a hundred million steps. Can we mitigate this by updating the treap bottom-up instead of top-down? Also no; the fact that these are Merkle trees means that we basically have to use functional algorithms to get anywhere.

So what can we do? One approach is to figure out a way to patch this attack. The simplest option would likely involve having a higher cost to purchasing priority the more levels you go down the tree. If the treap is currently 30 levels deep but your addition would increase it to 31 levels, the extra level would be a cost that must be paid for. However, this requires the trie nodes to include a built-in height variable, making the data structure somewhat more complicated and less minimalistic and pure. Another approach is to take the idea behind treaps, and create a data structure that has the same effect using plain old boring Patricia trees. This is the solution that is used in databases such as MySQL, and is called “indices“. Basically, instead of one trie we have two tries. One trie is a mapping of address to account header, and the other trie is a mapping of time-to-live to address. At the end of every block, the left side of the TTL trie is scanned, and as long as there are nodes that need to be deleted they are repeatedly removed from both tries. When a new node is added it is added to both tries, and when a node is updated a naive implementation would update it in both tries if the TTL is changed as a result of the transaction, but a more sophisticated setup might be made where the second update is only done in a more limited subset of cases; for example, one might create a system where a node needs to “purchase TTL” in blocks of 90 days, and this purchase happens automatically every time a node gets onto the chopping block – and if the node is too poor then of course it drops off the edge.

Consequences

So now we have three strategies: treaps with heights, tries with time-to-live indices and the “cleansing block”. Which one works best is an empirical question; the TTL approach would arguably be the easiest to graft onto existing code, but any one of the three could prove most effective assuming the inefficiencies of adding such a system, as well as the usability concerns of having disappearing contracts, are less severe than the gains. What would the effects of any of these strategies be? First of all, some contracts would need to start charging a micro-fee; even passive pieces of code like an elliptic curve signature verifier would need to continually spend funds to justify their existence, and those funds would have to come from somewhere. If a contract cannot afford to do this, then the contract could just store a hash and the onus would be on the transaction sender to send the contract the code that it is supposed to execute; the contract would then check the hash of the code and if the hash matches the code would be run. Name-registry applications might decide to work somewhat differently, storing most of their registrations using some Merkle tree-based offchain mechanism in order to reduce their rent.

However, there is also another more subtle consequence: account nonce resets. For example, suppose that I have an account, and I received and sent some transactions from that account. In order to prevent replay attacks (ie. if I send 10 ETH to Bob, Bob should not be able to republish the same transaction in order to get another 10 ETH), each transaction includes a “nonce” counter that increments after every transaction. Thus, the account header stores the current transaction nonce, and if the current nonce is 2 then the only transaction that will be accepted is one with a nonce of 2, at which point the nonce will go up to 3. If accounts disappear, then nonces could reset to 0, leading to potentially dangerous situations if a user accumulates some funds in an account, then lets the balance drop to zero and the account disappear, and then refills it. One solution would be for transactions to have a maximum block number, which can be set to 10 days in the future by defauly, and then require all withdrawals to leave enough balance for the account to last another 10 days; this way, old transactions with nonce 0 would be too old to replay. However, this adds another inefficiency, and must be balanced with the benefit of blockchains charging rent.

As another interesting point, the history of the blockchain would become relevant again; some dapps, wishing to store some data forever, would store it in a transaction instead of the state, and then use past block headers as an immutable rent-free datastore. The existence of applications which do this would mean that Ethereum clients would have to store at least a headers-only version of the history, compromising Ethereum’s “the present state is all that matters” ideology. However, an alternative solution might be to have a contract maintaining a Merkle mountain range, putting the responsibility onto those users that benefit from particular pieces of information being stored to maintain log-sized Merkle tree proofs with the contract remaining under a kilobyte in size.

As a final objection, what if storage space is not the most problematic point of pressure with regard to scalability? What if the main issue is with bandwidth or computation? If the problem is computation, then there are some convenient hacks that can be made; for example, the protocol might be expanded to include both transactions and state transition deltas into the block, and nodes would be free to only check a portion of the deltas (say, 10%) and then quickly gossip about inconsistencies to each other. If it’s bandwidth, then the problem is harder; it means that we simply cannot have every node downloading every transaction, so some kind of tree-chains solution is the only way to move forward. On the other hand, if space is the problem, then rent-charging blockchains are very likely the way to go.

On Long-Term Cryptocurrency Distribution Models

One of the challenges when creating a new cryptocurrency is figuring out what the distribution model is going to be. Who is going to receive the currency units, at what time, and what is the mechanism that decides? Despite the crucial importance of this question, there has actually been comparatively little thought into the issue compared with other aspects of currency, like consensus algorithms and feature sets. The question is particularly challenging because, just like many other problems in the cryptocurrency space that have parallels in the “real world” at large, cryptocurrencies also face the requirement of decentralization: it is considered unacceptable to have a cryptographic platforms whose continued operation depends on the existence of any specific party in the long term. Given this rather stringent requirement, how should a new currency distribute itself?

So far, the problem is still in its very early stages of discussion. While the question of short-term distribution is a highly dynamic debate between different types of asset carryovers, one-way transfers, two-way pegs, pre-mines, pre-sales and other mechanisms coming out almost every month, long-term distribution in nearly every cryptocurrency now follows one of two strategies: nothing at all, or mining. The reason why having a fixed never-growing supply is undesirable is obvious: it encourages wealth concentration and creates a static community of holders without an effective way for new people to get in, and it means that the coin has no way to incentive any specific kind of activity in the long term. The issue with mining, however, is more subtle. Cryptocurrency mining generally serves two functions; first, it provides a way of securing the network, and second, it serves as a distribution model, giving hundreds of thousands of people around the world a way of getting access to a few coins. So far, mining has been considered necessary for the former, and an effective way of doing the latter. More recently, however, there has been a substantial amount of interest and research into proof of stake, including strategies such as transactions as proof-of-stake, delegated proof of stake and a partial solution to nothing-at-stake, Slasher, suggesting that mining might not be necessary after all. Second, the rise of both ASICs and professional GPU farms is turning mining itself into an increasingly concentrated and quasi-centralized community, so any new mining-distributed currency will quickly be dominated by professional companies and not “the people” at large. If both trends continue, and mining proves to be a bad model for distribution, it will therefore need to be replaced. But then, the question is, by what?

So far, we know of several answers:

  • Pretend that the problem does not exist. This is the solution that has been taken by most proof-of-stake cryptocurrencies, and surprisingly enough even proof-of-work currencies, today.
  • Centralized distribution: let some central authority hand out coins according to some formula.
  • Useful proof-of-work: hand out coins to anyone who performs a particular socially useful computation, eg. weather prediction. This algorithm need not be used for consensus; it can exist simply to distribute coins while proof-of-stake does the hard work of maintaining consensus.
  • Algorithmic consensus distribution. Essentially, some kind of dynamic, adaptive consensus-based process for determining who gets new coins.

The second is theoretically the most powerful; currency units can be distributed either to everyone in the world for maximum fairness or to pay bounties for protocol development, external charitable causes or anything else. However, at the same time actually using such a mechanism arguably kills the whole point of a cryptocurrency: that it is decentralized and depends on no specific party for its continued existence. Thus, we can think of the centralized distributor as an ideal that we want to approach, sort of like the ideal of a bureaucrat god found in economic efficiency theory, and see how close to that ideal we can approach while still maintaining a structure that is guaranteed, or at least highly likely, to remain stable in the long term.

Useful Proof of Work As Distribution: A Relaxed Algorithm

Useful proof of work is likely the simpler idea. Initially, it was considered impossible to make a proof of work based on useful computation because of the verification problem: a proof-of-work task cannot take longer than a few thousands steps because every node in the network also needs to verify it to accept the block. Primecoin was the closest we got, and even there computing chains of prime numbers is not really all that useful. Now, thanks to the existence of a programming environment with a built-in computational stack trace mechanism, there is actually an alternative approach that removes this particular obstacle, using spot-checking and deposit sacrifices to make sure that work is being done correctly. The approximate algorithm for doing so is as follows.

1. Suppose that F(k) is a function that takes 32 bytes of random data as an input, carries out some computation taking n steps (where n is fairly large, say ten billion) and then returns a value R which is socially useful.
2. In order to perform one round of mining, start off by choosing a random m, and let B be the block header. Let k = sha3(B + m) as the seed.
3. Define a function STEP(P, D) -> D' where P is the program code, D is some tuple of data perhaps including stack, memory and program counter representing the state of the computation, and STEP carries out one computational step and returns the modified computational state D'.
4. Let D[0] = { pc: 0, stack: [], memory: [k] } (or some other construction involving k in a different computational model). Let D[i] = STEP(P, D[i-1]) where P is the program corresponding to the evaluation of F. D[n] should, in some appropriate fashion, contain the result of F.
5. Define H as a hash function of D[i]; something like sha3(pc + str(stack) + str(memory)) satisfies as a quick-and-dirty option. Let H[i] = H(D[i]). Compute all D[i] and all H[i] and let R be the root of a Merkle tree of all H[i]. If R < 2^256 / D then the work is valid and the miner is entitled to a reward.

Basically, we take the state of the program after each computational step (we can optionally make STEP process the execution of a few thousand computational steps for greater efficiency; this does not seriously compromise anything), and build a Merkle tree out of the whole thing and look at the root. This is somewhat tricky to implement; fortunately, however, the Ethereum virtual machine and block structure is already almost an exact replica of this algorithm, so one could take that code and use it almost verbatim.

The algorithm described above by itself has an obvious hole in it: it is not easy-to-verify, so fraudulent miners can easily pollute the network with bad-seeming blocks. Thus, as an anti-spam and anti-fraud mechanism, we require the following:

1. To be able to mine, nodes must purchase a “mining bond” of price N * R (say, R = 10^18 and N = 100), which returns to the miner after 10000 blocks. Each mining bond allows the miner to submit one work at a time.
2. If a miner submits a seemingly-valid work, including the m and k values, the root, and the socially useful output, then the mining bond reward increases by R
3. Anyone else with a mining bond can check the work themselves. If the Merkle root at the end is inconsistent, then they can publish a “challenge” transaction consisting of some number (say, 16) of sub-nodes. At that point, the original submitter has the choice of either giving up (as defined by not posting a response within 25 blocks), sacrificing their entire mining bond to the checker, or make a “response” transaction pointing out the first of those subnodes that they disagree with. If a response is submitted, the challenger must respond going down one level further, providing the sixteen subnodes between the last agreed subnode and the first disagreed subnode, and so forth, until the process converges upon the interval between two adjacent H[i] and H[i+1] values in the tree. At that point, the miner must submit the values of D[i] and D[i+1] in a transaction, which is considered valid if and only if P(D[i]) = D[i+1].

The problem is, however, that the process of checking takes as long as the original computation itself, so there does need to be an explanation as to why anyone would do it. If all miners attempt to cheat frequently, then it makes sense to perform spot-checks in order to collect the deposit (which we assumed to be 100x), but if miners realize this and as a result don’t cheat then there is no longer an incentive to check, so no one would check and miners would have free rein to cheat. This is a classic hawk-dove equilibrium paradox, and can be solved by game theory (here, we assume that mining has a cost of 0.5 and a reward of 1):

Cheats Does not cheat
Checks (-100, 101) (0.5,-0.5)
Does not check (1,0) (0.5,0)

Computing a mixed-strategy equilibrium in this simplified two-player model shows the miner cheating 0.5% of the time and the checker checking 0.5% of the time; under those two conditions, each player is indifferent to the strategy of the other so there is no opportunity for either one to further optimize and cheat. If we push closer to the economic equilibrium of mining and we say that mining has a cost of 0.9, then the equilibrium has a cheating rate of 0.9% and a checking rate of 0.9%. Thus, economically driven spot-checking is a legitimate strategy for ratting out fraudulent mining attempts, and can keep cheating rates arbitrarily low if we are willing to push up collateral requirements.

So what kind of work can we do? First of all, it might be better not to include computation that is incapable of handling noise, ie. where a bad answer accepted as a good answer does more than 100x as much bad as an actual good answer. Second, the algorithm here allows for work that is not easy-to-verify, but it does nothing to allow work that is data-heavy. For example, SETI is data-heavy – you need to have a picture of the sky in order to search it for aliens. Third, the algorithm must be parallelization-friendly. Running a machine learning algorithm on terabytes of data is not really something that can be split into discrete chunks, even large-sized ones. The second criterion can potentially be relaxed; because there isn’t really any benefit to mining with bad data versus good data, an SETI foundation can be set up which provides a stream of data for miners to work with, and adds a very small subsidy to encourage miners to use it. Theoretically, the foundation can even be decentralized and run as a proof-of-stake-voting algorithm on a blockchain. The simplest kind of socially useful computation to use, however, might be genetic algorithms. Genetic algorithms are often used to find solutions to problems that are intractable in closed-form, like finding optimal radio antenna shapes, spaceflight trajectories, aerodynamic shapes, and so forth; the blockchain may provide an ideal environment for doing such computation on everyone’s nodes for free. Certain classes of data search and aggregation puzzles could also potentially be split up, though they are much more data-heavy whereas genetic algorithms are close to data-free once launched.

Parliaments And Better Algorithms

Algorithmic consensus distribution is the more interesting possibility. What if there can be a consensus algorithm to distribute tokens over time, where that algorithm can reward arbitrary good work? For example, one might want to pay bounties to people who contribute to the ecosystem, or even to the world in general. The simplest approach here seems to be to randomly select a “parliament” – every N blocks, stakeholders can vote on 200 nodes that will make the decision of where the newly generated funds will go.

The obvious question to ask is: what are the economics of this? In theory, the nodes will want to select the distribution that optimally benefits the community as a whole, so as to maximize their chance of getting re-elected. However, are there opportunities for corruption? We all know that traditional democracy is highly imperfect, so how do we know that our crypto-enabled wealth distribution scheme will be any better? Fortunately, there is one strong argument to be made that it actually will be. The reason is that traditional democracies have a number of very serious failure modes; for example, a parliament can seize people’s property, conscript people into armies for war, restrict free speech, etc. In this case, however, there is a very clear and obvious upper bound on how much damage a parliament could do: it could redirect the money to split among itself. There is also the risk that the parliament will crowdfund something which is a public bad to society, but a public good among themselves (eg. a war), but they have no existing military apparatus to latch onto and no existing public consensus that they are supposed to be using coercive power for any reason at all so they are in no better a position to do such a thing than any other group commanding a similar level of economic resources. Thus, if we suppose that parliaments fail, say, 33% of the time, then we can see how in a democracy this would be catastrophic but here it only means that the distribution mechanism becomes 67% as useful as it could be.

Another criticism is that such a mechanism, no matter how it may be constructed, will invariably create some sort of political governance class, and thus will stabilize around a particular small set of political viewpoints, generate its own form of inequality, and eventually lead to a long-term hostile takeover. This would be limited in effect, but even still at its worst 100% of the new currency issuance will be siphoned off by a crypto-political elite. One solution is to make parliaments randomly selected (ie. demarchy) rather than elected, reducing the chance of such conspiracies further but at the cost of weakening the parliament’s expected level of expertise on optimal distribution and its ability to form long-term consistent institutions; however, if we want to create a system that has the political image of being neutral and decentralized that is perhaps something that we actually want.

However, we probably can, and certainly must at least try, to be more imaginative. Parliaments and voting are only the simplest and crudest form of having a decentralized organization; there are almost certainly better alternatives based on principles such as holarchy, liquid democracy, futarchy and various combinations of these and other ideas that we have not thought of but that will become possible because of the much higher degree of both interconnectedness and information processing efficiency provided by modern technology. Ideally, as much of the process as possible would be in some fashion automated – the process should function as a DAO, not a DO, and the position of highest power, or the closest philosophical analog of such a thing, should be held by an algorithm and not a set of people – perhaps a sacrifice from the point of view of optimality at any particular time, but, one might argue, a boon for long-term stability, and an especially appropriate choice for a cryptographic platform that intends to claim some concept of neutrality.

A simple futarchy-based implementation might work as follows. Suppose that there are N projects asking for a grant consisting of the entire currency supply to be distributed during some time period, and the desire is to select the one that will maximize the value of the coin after one year. We create N sub-tokens, T[0] ... T[N-1], where the value of T[i] is zero if project i does not get chosen but can be redeemed for one currency unit after one year if the project does get chosen. Then, we create subtokens R[0] ... R[N-1], where the value of R[i] is zero if the project does not get chosen or an amount of currency units equal to 232 computational steps in value (we include a small useful-PoW or useless-PoW market into the coin for this purpose) if the project does get chosen. Now, suppose that the probability of project i getting chosen is P[i] and the value of the token in the event that project i gets chosen after one year is V[i]. We note that the value of T[i] is P[i] * V[i] and the value of R[i] is P[i] * K where K is the cost of computing 232 computational steps. Hence, the project with maximum P[i] / R[i] also maximizes V[i] / K and hence V[i], so that project is assumed to maximize the value of the coin and hence chosen. The only challenge left is figuring out what the risks of market manipulation attacks are assuming there are individual parties with non-negligible market power. This strategy seems more mathematically clean and less vulnerable to turning into something centralized, but on the other hand there seem to be fewer safeguards to prevent it from becoming evil. The best response might simply be that a coin run by an evil DAO will lose public support, and hence will lose value, so the futarchy algorithm itself might select against such undesirable actions. Second, of course, the futarchy does not command a military and there is no pre-existing public consensus that it is entitled to employ any kind of coercion.

Ultimately, both of these approaches could be combined. One can have a parliament, or a futarchy, select useful proof of work algorithms or even data for specific useful proof of work algorithms, or one can have a parliament or futarchy with useful proof of work as its voting mechanism. However, one important conclusion here is that both of the algorithms described are complicated; there is no easy solution to figuring out how to distribute coins in a good way. Which, given the state of the financial system at large, makes sense; if it was easy to distribute coins fairly then the US dollar and other fiat currencies would have likely been overthrown in favor of such alternatives in at least some parts of the world a long time ago. Because of the complexity involved, it is unlikely that either of these will be used for ether itself; ether is intended to be boring crypto-gasoline with simple properties to target maximum stability and reliability, not a super-advanced economically innovative decentralized autonomous organization. So if you want to see GeneticAlgoCoin, FutarchyCoin and ParliamentCoin developed, feel free to run them on top of Ethereum as sub-currencies; the Serpent compiler is all yours to play with.

Credit to Neal Koblitz for suggesting the idea of spot-checking and convincing me of the importance of useful PoW, Robin Hanson for inventing futarchy, and realistically probably at least several cryptographers who came up with the concept of multi-round challenge-response protocols before me

Long-Range Attacks: The Serious Problem With Adaptive Proof of Work

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.

The Xbox and Ethereum’s Dual Mandate

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 (Web 3.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.

 

What is Ethereum? Project, Platform, Fuel, Stack.

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.

 

DAOs, DACs, DAs and More: An Incomplete Terminology Guide

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 to 1FxkfJQLJTXpW6QmxGT6oF43ZH959ns8Cq 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.

Serpent upgrades: More Fun Stuff

For an intro tutorial to Serpent, see http://blog.ethereum.org/2014/04/10/pyethereum-and-serpent-programming-guide-2/

Over the past two weeks our primary focus has been getting all of the clients updated to PoC5 compatibility, and it definitely has been a long road. Among the changes to the VM include:

  • The new init/code mechanism: basically, when you create a contract, the code provided will execute immediately, and then the return value of that code will be what becomes the contract’s code. This allows us to have contract initialization code, but still keep to the same format of [nonce, price, gas, to, value, data] for both transactions and contract creation, also making it easier to create new contracts via forwarding contracts
  • Reordering transaction and contract data: the order is now [nonce, price, gas, to, value, data] in transactions and [gas, to, value, datain, datainsz, dataout, dataoutsz] in messages. Note that Serpent retains the send(to, value, gas), o = msg(to, value, gas, datain, datainsz) and o = msg(to, value, gas, datain, datainsz, dataoutsz) parameters.
  • Fee adjustments: transaction creation now has a fee of 500 gas, and several other fees were updated.
  • The CODECOPY and CALLDATACOPY opcodes: CODECOPY takes code_index, mem_index, len as arguments, and copies the code from code_index ... code_index+len-1 to memory mem_index ... mem_index+len-1. These are very useful when combined with init/code. There is also now CODESIZE.

The largest changes, however, have been to the architecture surrounding the protocol. On the GUI side, the C++ and Go clients are evolving rapidly, and we will see more updates from that side coming very shortly. If you have been following Ethereum closely, you have likely seen Denny’s Lotto, a full implementation of a lottery, plus GUI, written and executed inside the C++ client. From here on, the C++ client will shift toward being a more developer-oriented tool, whereas the Go client will start to focus on being a user-facing application (or rather, meta-application). On the compiler side, Serpent has undergone a number of substantial improvements.

First, the code. You can peek into the Serpent compiler under the hood and you will be able to see all of the functions available, together with their precise translations into EVM code. For example, we have:

72:     ['access', 2, 1,
73:         ['', '', 32, 'MUL', 'ADD', 'MLOAD']],

This means that what access(x,y) is actually doing under the hood is it’s recursively compiling whatever x and y actually are, and then loading the memory at index x + y * 32; hence, x is the pointer to the start of the array and y is the index. This code structure has been around since PoC4, but now I have upgraded the meta-language used to describe translations even further, so as to include even if, while and init/code in this construction (before they were special cases); now, only set and seq remain as special cases, and if I wanted to I could even remove seq by reimplementing it as a rewrite rule.

The largest changes so far have been for PoC5 compatibility. For example, if you run serpent compile_to_assembly 'return(msg.data[0]*2)', you will see:

["$begincode_0.endcode_0", "DUP", "MSIZE", "SWAP", "MSIZE", "$begincode_0", "CALLDATACOPY", "RETURN", "~begincode_0", "#CODE_BEGIN", 2, 0, "CALLDATALOAD", "MUL", "MSIZE", "SWAP", "MSIZE", "MSTORE", 32, "SWAP", "RETURN", "#CODE_END", "~endcode_0"]

The actual code there is just:

[2, 0, "CALLDATALOAD", "MUL", "MSIZE", "SWAP", "MSIZE", "MSTORE", 32, "SWAP", "RETURN"]

If you want to see what’s going on here, suppose that a message is coming in with its first datum being 5. We thus have:

2 -> Stack: [2]
0 -> Stack: [2, 0]
CALLDATALOAD -> Stack: [2,5]
MUL -> Stack: [10]
MSIZE -> Stack: [10, 0]
SWAP -> Stack: [0, 10]
MSIZE -> Stack: [0, 10, 0]
MSTORE -> Stack: [0], Memory: [0, 0, 0 ... 10]
32 -> Stack: [0, 32], Memory: [0, 0, 0 ... 10]
SWAP -> Stack: [32, 0], Memory: [0, 0, 0 ... 10]
RETURN

The last RETURN returns the 32 memory bytes starting from 0, or [0, 0, 0 ... 10], or the number 10.

Now, let’s analyze the wrapper code.

["$begincode_0.endcode_0", "DUP", "MSIZE", "SWAP", "MSIZE", "$begincode_0", "CALLDATACOPY", "RETURN", "~begincode_0", "#CODE_BEGIN", ..... , "#CODE_END", "~endcode_0"]

I elided the inner code explained above to make things clearer. The first thing we see are two labels, ~begincode_0 and ~endcode_0, and the #CODE_BEGIN and #CODE_END guards. The labels mark the beginning and end of the inner code, and the guards are there for the later stages of the compiler, which understands that everything between the guards should be compiled as if it is a separate program. Now, let’s look at the first parts of the code. In this case, we have ~begincode_0 at position 10 and ~endcode_0 at position 24 in the final code. $begincode_0 and $endcode_0 are used to refer to these positions, and $begincode_0.endcode_0 refers to the length of the interval between them, 14. Now, remember that during contract initialization the call data is the code that you’re feeding in. Thus, we have:

14 -> Stack: [14]
DUP -> Stack: [14, 14]
MSIZE -> Stack: [14, 14, 0]
SWAP -> Stack: [14, 0, 14]
MSIZE -> Stack: [14, 0, 14, 0]
10 -> Stack: [14, 0, 14, 0, 10]
CALLDATACOPY -> Stack: [14, 0] Memory: [ ... ]
RETURN

Notice how the first half of the code cleverly set up the stack so that it would push the inner code into memory indices 0…13, and then immediately return that chunk of memory. In the final compiled code, 600e515b525b600a37f26002600035025b525b54602052f2, the inner code sits nicely to the right of the initializer code that simply returns it. In more complex contracts, initializers can also serve functions like setting certain storage slots to values, or even calling or creating other contracts.

Now, let us introduce the latest and most fun feature of Serpent: imports. One common use case in contract land is that you want to give a contract the ability to spawn off new contracts. Problem is, how to you put the code for the spawned contracts into the spawner contracts? Before, the only solution was the uncomfortable approach of compiling the newer contracts first, and then putting the compiled code into an array. Now, we have a better solution: import.

Put the following into returnten.se:

x = create(tx.gas - 100, 0, import(mul2.se))
return(msg(x,0,tx.gas-100,[5],1))

Now, put the following into mul2.se:

return(msg.data[0]*2)

Now, if you serpent compile returnten.se and run the contract, you notice that, voila, it returns ten. The reason why is obvious. The returnten.se contract creates an instance of the mul2.se contract, and then calls it with the value 5. mul2.se, as the name suggests, is a doubler, and so it returns 5*2 = 10. Note that import is not a function in the standard sense; x = import('123.se') will fail, and import only works in the very specific context of create.

Now, suppose you are creating a 1000-line monster contract and want to split it up into files. To do that, we use inset. Into outer.se, put:

if msg.data[0] == 1:
  inset(inner.se)

And into inner.se, put:

return(3)

Running serpent compile outer.se gives you a nice piece of compiled code that returns 3 if the msg.data[0] argument is equal to one. And that’s all there is to it.

Upcoming updates to Serpent include:

  • An improvement of this mechanism so it doesn’t load the inner code twice if you try to use import twice with the same filename
  • String literals
  • Space and code-efficiency improvements for array literals
  • A debugging decorator (ie. a compiling function which tells you what lines of Serpent correspond to what bytes of compiled code)

In the short term, though, my own effort will focus on bugfixes, a cross-client test suite, and continued work on ethereumjs-lib.

Decentralized Protocol Monetization and Forks

The idea of releasing a new currency as a mechanism for funding protocol development is perhaps one of the most interesting economic innovations to come out of the cryptocurrency space. In the past twenty years, we have seen a growing centralization in the protocols that underlie the internet, with the rise of proprietary chat systems and social networks like Facebook, and a large part of the reason for this trend has been the need for monetization; if Facebook was cryptographically secure and decentralized, the developers would have no way to make money by data mining their users’ activities and taking a 30% cut of their internal currency, and so decentralized alternatives to Facebook have largely fizzled due to lack of institutional support and funding. With decentralized protocols, however, we have discovered a new mechanism for monetizing them: create internal assets, and sell them to pay for the development of the protocol.

In general, so far we know of two classes of “internal assets” that can be sold in this way; first, there is the idea of creating an internal token system, a crypto-fuel with a floating price that has some value in the network, and second, one can introduce name registrations; for example, a decentralized Twitter might fund itself by building in its own decentralized username registration mechanism similar to Namecoin and selling off the 1-4 letter names. This new monetization model is powerful, and in the first of the two above-described implementations already has a number of proven successes, but it is also incredibly non-intrusive – it requires no licensing schemes, proprietary software, crippleware or privacy infringement, and in fact no one actually has to explicitly “pay” for anything at all (if you buy tokens you are just swapping into a different asset, which may well even go up in value relative to other assets). However, in this model there is one concern that many people have raised, and that is the question of forks. In short, if one releases a new decentralized protocol that is based on a token system, why won’t someone else release a fork with either their own token system, or a token system that is somehow tied to an asset with an existing userbase, and if one releases a decentralized Twitter with a built-in name registration system why won’t someone release a fork that points to their own name registration system, or even the original Namecoin?

In traditional business, there are two solutions to the problem. One is to give up the idea of making everything open-source, and keep at least the latest version of the client proprietary. The other is to release the protocol for free, and then sell services. Of course, both approaches have their own very well-understood flaws. In the context of a decentralized blockchain application, most of the benefits of decentralization are lost when the code becomes proprietary – with a proprietary mining algorithm, for example, there is no way to prove that it does not have a backdoor for its developers, and is therefore equivalent to the developers simply running a centralized server and asking the community to trust them. The second approach, selling services, is also flawed; first, the revenue is in most cases vastly insufficient, and second, it incentivizes the organization to produce only a minimal decentralized protocol in order to then sell centralized services on top, rather than building up an entire decentralized ecosystem.

Many decentralized projects are pursuing neither of these strategies; for example, Ethereum itself is 100% open source, and have been since even before the day that it publicly launched. Many protocol organizations, including our own, are interested in transforming themselves into “decentralized autonomous organizations”, which necessarily implies a very high degree of transparency. Given this, what is a decentralized protocol’s “moat” against forks? What stops another group from taking all of our code and research ready-made and creating their own version of the blockchain, perhaps with one or two superior features (or simply having a large endowment and dumping it all into superior marketing), and taking us over? The question is a difficult one, but it has a number of interesting answers, both in terms of Ethereum specifically and decentralized protocols as a whole.

On Flimsy Moats and Dictators

In order to answer the question, it is important to first understand that, in the space of tech companies and especially social networking startups, a large number of them are literally backed by almost nothing but social consensus. Theoretically, it is entirely possible for all of the employees at Snapchat, Tinder, Twitter or any other such startup to all suddenly agree to quit and start their own business, completely rebuild all of the software from scratch within months, and then immediately proceed to build a superior product. The only reason why such companies have any valuation at all is a set of two coordination problems: the problem of getting all employees to quit at the same time, and the problem of getting all of the customers to simultaneously move over onto the new network. In the context of a service like Dropbox, the latter issue does not exist; because Dropbox is just as useful to each individual if one other person is using it or a million, there is no reason why people can’t move over a few at a time. In the context of a social network, which is useless unless everyone else is already on it, the problem is fundamental.

In the abstract, this may seem like a flimsy justification for why tech companies are valuable; when thinking about something that represents billions of dollars of value, one naturally expects that value to be backed up by something tangible like physical resources or government force, not just some ethereal instantiation of the fact that it’s hard for large groups of people to suddenly move from one social configuration to another. In reality, however, even physical resources and government force are backed by nothing but a social coordination problem – if 70% of the victims of a dictatorship were to simultaneously rise up against their dictator, the government would get toppled pretty quickly, and yet most dictators even running rather brutally oppressive regimes are quite comfortable sitting in their lofty thrones knowing that such a thing will almost certainly not happen.

Given this background in theory, what exactly are the social coordination problems backing up a decentralized blockchain? What exactly is the “moat” that is backing up the value of the “official” Ethereum blockchain or Mastercoin state transition system, and ether as a mechanism of storing value and paying for transaction fees, as opposed to alternate clones like “aethereum“? Specifically, what are the necessary factors that make the original version of a given decentralized protocol superior, when all of its underlying features can easily be cloned, and even improved upon as soon as a group discovers even one flaw in the original (in the case of Bitcoin, for example, one can trivially improve the Bitcoin protocol by removing the requirement for multisig spending transactions to have an extraneous zero in the spending script code, an anti-feature which was introduced accidentally)? As it turns out, there is quite a lot.

Teams

First of all, every project has a core development team. In fact, this aspect is actually stronger in the case of a decentralized token system than a traditional tech company. While in a traditional tech company, there might be only a very small number of people with shares in the company and who are thus incentivized to stick with it and see it succeed, in the case of a decentralized token system there are dozens or even hundreds of people holding tokens associated with the project; in fact, many people actually choose to be paid predominantly in tokens. In the case of Ethereum, for example, the size of the list of people who will be receiving ether as compensation for work done currently stands at sixty-eight, and will increase even further as time goes on. And all of these tokens are, of course, untradeable until the protocol actually launches, so all of the token holders are strongly incentivized to do their best to ensure that the system does as well as possible. Thus, the team, the set of people who know the most about how the protocol works from the experience of having actually developed it, is a decentralized project’s core asset that competitive spinoffs cannot so easily “fork” and replicate, and it is the team that will be responsible for much of the rest of the project’s “moat”.

Network Effects of Exposure

The simplest reason why people will use the original blockchain and not a fork is simple: it’s the default. People hear about Bitcoin first, so they go to bitcoin.org and download the Bitcoin client, and use Bitcoin to buy and sell goods and services, not Bitcoin Scrypt. For the same reason, people use the official version of most open-source projects and not any of the thousands of forks, buy music, books and movies instead of trying to download them via torrents, and use popular Bitcoin wallets instead of less popular ones. Any fork of a given protocol necessarily comes after the original, and is therefore much less likely to gain media attention.

Moral Pressure

Another important reason why the original version of a protocol is more likely to gain media attention than a fork is plain old public morality: people believe that the developers of a project deserve to get compensated, and so a fork which is developed with the primary purpose of depriving the developers of compensation is likely to be viewed negatively, or at least less favorably, by many people. This moral effect can be a very powerful one, and contributes heavily to the original protocol’s greater exposure; the best empirical evidence for this is likely the success of services like Netflix over filesharing-based alternatives.

At the same time, however, if the original developers of a protocol start taking development in an undesirable direction (eg. introducing backdoors, introducing excessively intrusive monetization vehicles, or even just being too plain slow), then the moral effect can rapidly turn on its head and even support the first credible effort to try to wrest away a project from its creators; following the prior example, the pertinent example here is the media success of the Pirate Bay and Popcorn Time. Thus, moral pressure can work both for and against a decentralized protocol, and it is the protocol developers’ responsibility to ensure that the community opinion of their project remains positive, and serves as an important check-and-balance to make sure that the core team behind a project continues to move the project forward at a solid pace and in an agreeable direction.

Network Effects of Currency Unit Liquidity

One argument that is often raised against forks of Bitcoin is the idea of liquidity, or specifically market depth: smaller currencies are inherently weaker than larger currencies because there are fewer people buying and selling them, and so you will move the price much more if you try to sell a large amount. However, this argument is only important up to a certain point; once a currency reaches a sufficient size, it has enough market depth to cover all ordinary usage, and so additional depth provides little value. Hence, this network effect provides a moderately strong edge against forks with a new token system, which will have very low market depth to start off, although at the cost of a slight disadvantage against forks that tie in existing large currencies via two-way-pegging mechanisms.

Ecosystemic Network Effects

An important feature of decentralized protocols, and social protocols in general, is that they also build ecosystems. On a social network, for example, there is a one-dimensional network effect: a social network is more useful if more people use it. With a currency, that effect becomes two-dimensional: a currency attracts more users if there are more merchants, and more merchants if there are more users. Once development effort, security and liquidity come into play, this increases to three to six dimensions. All of these interdependencies make it hard for a new version of a social network to bore its way into mainstream acceptance, as initially it starts off with nothing.

In the case of Ethereum, the tightly integrated nature of the currency system actually makes the network effect in some respects highly multi-dimensional. The relevant property of the Ethereum architecture is the first-class-citizen property of contracts: contracts can interact with, send and receive messages from and hold accounts with other contracts much like external accounts can. This allows you to cleverly pull together long chains of contracts and applications, using contracts of different types at each step of the interaction process. For example, I might hold some shares of a decentralized autonomous organization (contract A), where the shares are held on a decentralized market (contract B) in a multisignature account (contract C) for added security. The co-signer of said multisig account is paranoid about quantum computing, so he uses custom cryptography (contract D) based on verifying Lamport signatures for authentication. The organization would then store some of its funds in a USD-pegged asset using a financial derivatives market (contract F) using a combination of centralized and decentralized data feeds (contracts G, H, I), and internally uses a name registration system (contract J) to store all of the functions that it calls. A single transaction may end up calling all of these contracts multiple times.

Liquid markets for on-blockchain assets, liquid markets for message publication, and a robust ecosystem of DAOs, decentralized exchanges, financial markets and data feeds all support each other and make the Ethereum blockchain stronger. The Ethereum blockchain is not just a blockchain; it’s really one large decentralized computer where all of the components are tightly linked together, and each component provides additional tools for other components to play with.

Bugs and Attacks

This is a small point, but an important one. There is always a risk that either the protocol or the client implementation will be flawed in some way. As hard as the Bitcoin developers have tried, the bitcoind source code has had problems crop up over the years, and twice in Bitcoin’s history (specifically, the integer overflow exploit in 2010 and the fork in 2013) such problems have even led to a consensus failure that required manual resolution. In theory, developers of every protocol try as hard as they can to ensure that bugs never happen in the first place. In practice, of course, there is always a chance that something will slip by, the price will start crashing ten or twenty percent within an hour, and it will be up to the developers, the miners and the large businesses to quickly push out and coordinate a fix. Sometimes, such errors may not even be the protocol’s fault; a massive megacorporate or government-sponsored 51% attack or a globally coordinated distributed denial of service on the entire network are also possibilities, and might need special measures to be dealt with. Thus, as decentralized as peer to peer protocols aspire to be, ultimately they do benefit considerably from some degree of institutional support in times of crisis – support that the original developers who understand the protocol and software best are the best-equipped to provide.

Protocol upgrades

Ethereum 1.0 is far from perfect, and between our discussions on the development roadmap and the Hard Problems of Cryptocurrency we have been very open about admitting this. There are plenty of ways that blockchain technology could be improved, ranging from research on price-stabilized currencies to better fee structures, alternative consensus models and, as a holy grail, multi-blockchain architectures or SCIP. However, the intricacies of actually coming up with the math and then implementing these mechanisms, are in many cases even figuring out whether or not they are even possible, are sufficiently complex that we have decided there is a large list of features we are simply not going to do for Ethereum 1.0. To that end, we have established the long-term roadmap that we will release Ethereum 1.0 in Q4 2014 at the latest, and at the same time we have already started to set up efforts to research the kinds of improvements that we can theoretically add, specifically in terms of scalability, with a plan to crystallize them into Ethereum 2.0 at some point around 2016. Ethereum 2.0 will use “ether 2.0” as its currency, where the main initial mechanism for obtaining a unit of ether 2.0 is simply to provably destroy a unit of ether 1.0.

Thus, the currency inside of a protocol is backed not just by the utility and network effects of the current implementation of that protocol, but also the promise of better future versions of the protocol to come. Of course, cryptocurrency protocols are hard to change, and in practice Bitcoin has proven very difficult to change in the short term, but more large-scale re-architectures are actually somewhat easier to implement than small changes when one looks at the ratio of effort to effect. We have already seen the Master Protocol make several upgrades, and we will likely see Ethereum 2.0, 3.0 and perhaps even further over the next few years and decades.

What’s the Point?

Finally, the most important argument of all is, what’s the point of a fork? In the case of Bitcoin, there are many reasons to fork the code – you might want to add support for more transaction types, change the currency supply, replace the currency with a centralized alternative backed by the US dollar, or change the type of cryptography used. If a protocol is correctly generalized, however, there simply is no way to improve that can’t be replicated inside the protocol itself. For example, if you are using Ripple then you can use Ripple equally easily to store XRP, cryptocurrencies, fiat currencies, local community currencies or Little Bobby’s Magic Token Points. Hence, concerns about optimal monetary policy, politicization or depoliticization of money or many of the other debates surrounding Bitcoin have no bearing on the success of the Ripple protocol itself. In the case of Ethereum, the protocol has a generic programming language, making the system even more malleable: if someone comes up with a blockchain-based system that is better than Ethereum in some fashion (with the exception of secure near-instant block times), then someone else can fork it right back inside of Ethereum itself by simply implementing it as a contract. This fork would immediately benefit from Ethereum’s ecosystemic network effects, allowing users to benefit from both the superior feature and the ability to interface seamlessly and directly with an existing ecosystem of liquid markets, data feeds and DAOs. Using this power of the contract mechanism, Ethereum will be able to contain side-chains of Bitcoin, Litecoin and Dogecoin (yes, even Scrypt-based coins can be turned into side-chains via computational stacktraces and an economically incentivized challenge-response protocol), name registrations, post-quantum cryptography and an unlimited number of other features.

Thus, on the whole decentralized protocols lie in an interesting place in the modern economy. On the one hand, much like Bitcoin itself, they are in a very clear way “backed by nothing”. On the other hand, they actually have quite a powerful backing underneath, and one that is difficult to unseat; in practice, we have seen very few examples of any open source software fork unseating the original, both in the cryptocurrency space and outside of it. Nothing has unseated Bitcoin, nothing has unseated Litecoin and nothing has unseated Dogecoin. The only forks that do gain serious community acceptance are the ones that add a large body of new features, and these forks always succeed in carving out a niche of their own. Fortunately, we still have many decades to go in seeing exactly how the decentralized protocol ecosystem is going to play out.

The Issuance Model in Ethereum

Ether (ETH), the cryptofuel that powers distributed applications on the Ethereum platform, will be issued at a constant annual linear rate via the block mining process. This rate is 0.3 times the total amount of ETH that will be purchased in the pre-sale.

While the best metaphor for ETH is “fuel for running the contract processing engine,” for the purposes of this post, we will treat ETH purely as a currency.

There are two common definitions of “inflation.”  The first relates to prices and the second relates to the total amount of money in a system – the monetary base or supply.  Similarly for the term “deflation.”  In this post we will distinguish between “price inflation,” the rise in the general price level of goods and services in an economy, and “monetary inflation,” the growth in the supply of money in an economy due to some sort of issuance mechanism.  Often, but not always, monetary inflation is a cause of price inflation.

Though the issuance of ETH is in a fixed amount each year, the rate of growth of the monetary base (monetary inflation) is not constant.  This monetary inflation rate decreases every year making ETH a disinflationary currency (in terms of monetary base).  Disinflation is a special case of inflation in which the amount of inflation shrinks over time.

It is expected that the amount of ETH that will be lost each year caused by transmissions to addresses which are no longer accessible is estimated to be on the order of 1% of the monetary base. ETH may be lost due to loss of private keys, death of owner without transmission of private keys, or purposeful destruction by sending to an address that never had an associated private key generated.

If we assume that Ethereum sells 40,000 BTC worth of ETH in the pre-sale, and if we assume that the average price is 1500 ETH/ BTC, 60,000,000 ETH will be created in the genesis block and assigned to purchasers. Every year, in perpetuity, 18,000,000 ETH will be issued though the mining process.  Taking into account both creation of new ETH and loss of existing ETH, in the first year, this represents a monetary inflation rate of 22.4%.  In the second year the rate drops to 18.1%.  By the tenth year, the rate is 7.0%.  In year 38, it hits 1.9%. And in the 64th year, the level of 1.0% is reached.

Image

Figure 1.  Amount of ETH in existence (dark green curve) on the left axis.  Monetary base inflation rate (light green curve) on the right axis.  Years on the horizontal axis.  (Adapted from Arun Mittal with thanks.)

 

By approximately the year 2140, the issuance of BTC ceases and since some BTC will likely be lost each year, the monetary base of Bitcoin is expected to start shrinking at that point.

At approximately the same time, the expected rate of annual loss and destruction of ETH will balance the rate of issuance.  Under this dynamic, a quasi-steady state is reached and the amount of extant ETH no longer grows. If the demand for ETH is still growing at that point due to an expanding economy, prices will be in a deflationary regime.  This is not an existential problem for the system since ETH is theoretically infinitely divisible. As long as the rate of price deflation is not too rapid, pricing mechanisms will adjust and the system will operate smoothly.  The traditional main objection to deflationary economies, wage stickiness, is likely not to be an issue since all payments systems will be fluid.  Another frequent objection, borrowers forced to repay loans with a currency that grows in purchasing power over time, will also not be a problem if this regime is persistent, since terms of lending will be defined to account for this.

Note that while the monetary inflation remains greater than zero for many years, price levels (tracked as price inflation and deflation) are dependent on supply and demand, so are related to, but not totally controlled by the rate of issuance (supply).  Over time it is anticipated that growth of the Ethereum economy will significantly outpace growth of the supply of ETH, which could lead to an increase in the value of ETH with respect to legacy currencies and BTC.

One of Bitcoin’s great value propositions was the algorithmically fixed total issuance of the currency which mandated that only 21,000,000 BTC will ever be created.  In a time of profligate legacy currency printing in an exponentially doomed attempt to patch over the fact that there is too much debt in the global economic system (with more debt), the prospect of a universally accepted cryptocurrency that can serve eventually as a relatively stable store of value is attractive.  Ethereum recognizes this and seeks to emulate this core value proposition.

Ethereum also recognizes that a system intended to serve as a distributed, consensus-based application platform for global economic and social systems, must strongly emphasize inclusiveness. One of the many ways we intend to foster inclusiveness is by maintaining an issuance system which possesses some churn.  New participants in the system will be able to purchase new ETH or mine for new ETH whether they are living in the year 2015 or 2115. We believe we have a achieved a good balance between the two goals of fostering inclusiveness and maintaining a stable store of value. And the constant issuance, especially in the early years, will likely make using ETH to build businesses in the Ethereum economy more lucrative than hoarding speculatively.