Category Archives: Ethereum

Yet More Academic Warnings About Blockchains

One of the most important features of Nakamotoan blockchains is that they are “decentralized”[3] .  Blockchains and consensus protocols are grievously inefficient, but the price is considered worth paying in order to eliminate the potential for a few privileged actors to control the network.

Nakamoto-style blockchains are theoretically decentralized. This means that the system is capable of, and intended to be, run by a non-hierarchical group of peers.  But real networks are never perfectly decentralized in practice. There are also many possible dimensions of “decentralization”.

One important, if not preeminent dimension is decision making: just how are decisions actually made, and by whom?

Researchers from University College London report this spring that in fact the decision making is concerned Bitcoin and Ethereum are highly centralized [1].  This finding confirms the intuition of anyone who has dealt with these communities.  Regardless of philosophical intentions, there are a relative handful of people and organizations that have out-sized influence on these cryptocurrencies.

The study examined the public discussion and code repositories, where the design and implementation of the software infrastructure is recorded. This infrastructure embodies many technical decisions that affect the behavior of the system, the outcomes of users, the security and trustworthiness of the information, and even how decisions are made.

The decision-making process is modelled after the Internet and open source software. Ideas are formulated as public proposals, which are posted for global discussion. Implementations are published in open repositories, and also subject to evaluation and discussion.  The principle is that anyone on the Internet can propose features or changes, and that implementations will have widespread understanding and support by the time they are deployed.

The study examines the number of individuals who contribute to comments and code for different cryptocurrencies, as well as comparison to other open source code projects.

The results are pretty simple.

While “anyone on the Internet” is theoretically able to contribute, only a relatively small number of people actually write the code. And most files have only a handful of authors.  (Programmers will not be surprised at this: coding is hard work, and collaborative coding is even harder.)

Similarly, the open-to-anyone comment process is, in practice, dominated by a handful of individuals, who are de facto “experts”. This distribution parallels the pattern of actual coding, though whether “coders are experts” or “experts are coders” or there are two separate populations is not clear.

This study confirms what we have seen in practice: cryptocurrency communities are complicated, with many individuals, organizations, and interest blocs that exercise outsized influence. Their comparison to other code projects indicates that these are a natural pattern for “distributed” software projects.  The paper also include references to other studies that show just how “centralized” cryptocurrencies are.

The study did not, and could not, compare to non-decentralized projects, such as proprietary or sponsored systems.  My own experience is that such projects have similar patterns of concentration in decision making (a relative few highly influential designers and coders), though this case there is also a formal proprietor with decision-making authority which may override the contributors.

In other words, the pattern seen in this study is perfectly normal for software development.  The major difference is that there is no one “in charge”, so the de facto mavens rule.

It is important to note that, as the researchers discuss, there is a large ecosystem beyond the core software examined here.  These other projects, including exchanges, wallets, and services are organized in a variety of ways, some “decentralized”, and some very centralized (and opaque).  This means that the overall, end-to-end system is “patchy” and likely includes many islands of code, created and managed by different people.  It isn’t really reasonable to describe a cryptocurrency as purely “decentralized”.

This and many other studies show that the broad and often poorly defined notion that cryptocurrencies are “decentralized” is not realized in the actual, real-world implementation. Clearly, the Nakamotoan dream of a truly decentralized system has yet to be realized in practice.

This conclusion is important because this “decentralization” property underlies other important claims for the ultimate fairness and usefulness of the system.  For many people, the point of paying the high technical cost for decentralization is to achieve a system that is not, and cannot be, controlled by a powerful few.  If this goal is not really being accomplished, then the case for Nakamotoan blockchains is much weaker.

  1. Sarah Azouvi, Mary Maller, and Sarah Meiklejohn, Egalitarian Society or Benevolent Dictatorship: The State of Cryptocurrency Governance. 2018.
  2. Alyssa Hertig (2018) Major Blockchains Are Pretty Much Still Centralized, Research Finds. Coindesk,
  3. Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System. 2009.


Cryptocurrency Thursday


Cryptocurrencies: Yet More Warnings From The Academy

I have noted that the cryptocurrency community has a troubling history of ignoring academic research, even when it ­raises troubling warnings.  In a previous post, I noted that Professor Malkhi warns that the new Ethereum protocol is not secure—and the developers shrug.  And so on.

Now that cryptocurrencies are finally on the academic radar (I’ve been trying to get researchers interested for several years), these incidents are coming fast and often.

IOTA Flaming Out?

 IOTA is an interesting technology that seeks to really implement microtransactions, which they imagine will be useful for the Internet of Things (which they call the “Internet of Ownership”).

As I noted earlier, they whipped up their own hash function, which is a Really Bad Idea ™.   Considering that even half-clever rubes out here in Illinois (me) were aware of this issue as early as last August, it’s quite worrying that they were still using it in December, and then strongly resisted a report of a discovered flaw.  In fact, they accused the academic researchers of fraud and threatened legal action—for daring to report the problem to them.

Not even a shrug, but instead a ferocious counter attack intended to suppress the bad news.


IOTA is a peculiar bird.  They say they want to tackle the challenge of microtransactions which Nakamotoan blockchains really do not handle well.  And they tell the world they are a blockchain / cryptocurrency technology.

But they have no blocks and no chains.  And they have their own weird protocol and until recently, their own home-brew hash function. Notably, the system actually relies on centralized services to work.

They also say they are “open source”, though parts of the system are proprietary.  (Given the experience with the hash function they did publish, I can see that they don’t want people critiquing their code too closely.)

Hmm.  A centralized system with closed source?  That doesn’t seem very blockchain-y to me.

And they are tackling the IOT, which has grievous, deep, and wide security challenges.  Wow!

So what do they have?

They seem to have some technology that is tackling microtransactions (though we can’t really tell what they are doing), and a whole lot of PR.  They seem to be amply stocked with ego, as well.  That part is very Nakamotoan.

Is this something that you would trust?  Probably not.

Ethereum Contracts Have Problems

Ethereum’s “smart contracts” have always been a faith-based technology.  Faith that software can be trusted more than humans.  Faith that people can write error free code. Faith that people on the internet are generally honest.

Since the DAO disaster and ensuing oopsies, you’d think people would lose faith.  But that never happens, and Ethereum was awarded the CryptoTulip of the Year for outstanding achievements in Cognitive Dissonance.

There have been fixes and proposals for improved logic for “smart contracts”, though academic researchers have been trying to climb that particular mountain since Turing’s day.  In the real world, error free programs are so rare as to be unknown.  For that matter, despite millennia of effort, conventional contracts are still imperfect, and always contain escape clauses to deal with disputes and unforeseen developments.  Spoiler alert: “smart contracts” aren’t any smarter than any other contract.

This month researchers from National University of Singapore report a study of Ethereum contracts visible on the blockchain [1]. In general, it is very difficult to analyze the logic of Ehtereum smart contracts because they are complex (running custom languages in the Ethereum Virtual Machine), open-ended (i.e., a contract can call other contracts and services), and execute on any node of the Ethereum  network (i.e., in completely unpredictable environments).

“Contracts are relatively difficult to test, especially since their runtimes allow them to interact with other smart contracts and external off-chain services; they can be in- voked repeatedly by transactions from a large number of users” ([1], p.1)

Instead of logical analysis of each contract, the research studied traces of the contract execution, looking for aberrant behavior that likely reflects a bug.  They examine three patterns that they characterized as greedy, prodigal, and suicidal.

  • ‘Greedy’ contracts lock funds indefinitely.
  • ‘Prodigal’ contracts leak funds to other parties.
  • ‘Suicidal’ contracts are susceptible to being killed by any user.

The comprehensive study scanned over 900,000 (!) Ethereum contracts, executing the logic repeatedly and flagging potential problems.  They found problems in 34,000 (!) some contracts (over 2,000 distinct contracts—there are many replicates in the pool).  Close checking a sample of some 3,000 flagged contracts, they found 89% were confirmed as true bugs.

By my calculation, that’s close to 1 in 3 existing Ethereum contracts that have potentially catastrophic problems.

This is a really cool study.  The researchers likened this to randomly pushing buttons to see what happens, and they heroically pushed all the buttons many, many times.  (Sort of like the current administration’s approach to running the US government.)

It is interesting to note that on the supposedly “transparent” blockchain, less than 1% of the executable contracts had source code available. The study had to analyze execute the bytecodes—which is way harder than analyzing source code.  (But studying the actual bytecodes also revealed bugs in the language and virtual machine that would not be apparent from the source code alone.)

The opacity of these contracts highlights the fact that when you use an Ethereum contract, odds are you are “trusting” the code and other (unknown) people, because you can’t necessarily check the contract. In this supposedly “trustless” system, “faith” replaces “trust”.

Anyway, the result that these contracts contain many serious bugs is scarcely news to anyone who knows anything about programming. In fact, the fact that so many contracts didn’t have problems is really surprising.  Actually, this simply means that there are surely many more bugs that this study wasn’t scanning for.

It will be interesting to see how the Ether heads respond to this report.  My guess is they will shrug.

It is clear that the race for the 2018 CryptoTulip of the Year is wide, wide open.  So much bogosity, so little time to find it all.  But there are more and more competent researchers and actual grown ups investigating the vast acreage of CryptoTulips.

  1. Ivica Nikolic, Aashish Kolluri, Ilya Sergey, Prateek Saxena, and Aquinas Hobor, Finding The Greedy, Prodigal, and Suicidal Contracts at Scale. xariv, 2018.
  2. Mike Orcutt, Ethereum’s smart contracts are full of holes, in MIT Technology Review. 2018.
  3. Morgen Peck, Cryptographers Urge People to Abandon IOTA After Leaked Emails, in IEEE Spectrum – Tech Talk. 2018.



Cryptocurrency Thursday

(Note: This post was edited March 17 to clean up multiple spelling and typos.)

Dahlia Malkhi on Ethereum Casper Protocol

In addition to its jolly governance problems, Ethereum has been slouching towards doing something about scaling.  Specifically, Ethereum has been discussing a new consensus mechanism, based on ‘proof-of-stake’ (codename Casper).

Classical Nakamotoan consensus is based on proof-of-work, the crude, brute force requirement of expending real world resources to preclude cheating.  Proof-of-Stake substitutes a different ‘hard problem’, basically placing a bet on the ultimate consensus.  This approach is vastly more efficient than POW, running faster and using less computing resources.

Great, huh?

The question has to be, is this really a secure protocol?

This is not a question that can be solved by intuition or happy-talk.  It’s really, really hard to analyze this kind of protocol, and it would be wise to have some adult supervision before committing millions of dollars to a possibly flawed idea.

This winter Dahlia Malkhi (a very smart grown up) sloshed some icy water on the Casper protocol.  Alyssa Hertig reports that Malkhi was pretty clear that “proof-of-stake is fundamentally vulnerable” [1].  Speaking from decades of experience, she says there are trivial scenarios that break Casper.

The Coindesk report suggests that Casper’s advocate, Sensei Zamfir, replies to this criticism that the protocol is still useful, if it is ‘mostly’ OK.

All together now:    No, it isn’t.

I’m not enough of an expert to analyze this protocol in detail.  But I am smart enough to pay attention when Sensei Malkhi tells me it’s not secure.  She’s almost certainly correct.

The most troubling thing about this exchange is that Ethereum has a history of pushing on even in the face of expert warnings about security.  The DAO disaster was no surprise.  It was predicted by Cornell researchers days before the catastrophic loss and resulting hard forks.

Ethereum has been warned about Casper. It is another self-inflicted disaster waiting to happen.

This will be a test.  How many times will Ethereum walk off the cliff while we are yelling ‘stop!’

  1. Alyssa Hertig (2018) Vulnerable? Ethereum’s Casper Tech Takes Criticism at Curacao Event. Coindesk,


Cryptocurrency Thursday

Cryptocurrency Governance: Ethereum Leads The Way

In many ways Ethereum has surpassed the patriarch of the unhappy crypto family, garnering the CryptoTulip Award for 2017 .  As noted in the award, Ethereum is particularly noted for its whipsawing cognitive dissonance.

This week, Rachael Rose O’Leary gives a nice rundown on the dissonance surrounding EIP867, the proposal for a standard process for “returning funds”—by rewriting history [3].

The proposal itself is not especially innovative or radical, at least for most contexts.  But in the cryptoworld, the very idea is deeply contested, and has attracted fierce arguments and resistance.  O’Leary characterizes the dispute as reflecting two different Nakamotoan (Buterine?) principles:

  1. Code is Law
  2. Code is a Process

One of the curiouser concepts coming out of the Nakamotoan tradition is the slogan that “code is law”.  This is the principle underlying “smart contracts”, and the Distributed Autonomous Organizations built on them.  Technically, the idea is that the immutable, “write once” ledger is the sole and final “truth” of the system. If it’s on the ledger, it’s valid, else, not.

Applied to executable contracts, this means that once entered in the blockchain, the code is, by definition, correct—whether or not puny humans agree.  Furthermore, since the code and its results are immutable, they are beyond appeal, at least technologically.

These days, even talking about or planning for the possibility of appeals is anathema to many true believers.

I’ll note that the “code is law” slogan implicitly defines “law” as a set of impersonal, automatic, and immutable mechanical rules.  While humans have never yet achieved the superhuman state of being able to flawlessly write and execute unambiguous rules, some people seem to hope that computer code can provide this sort of “law”.  (The many oopsies already seen in Ethereum certainly raise questions about the supposed virtues of code.  This might have something to do with the fact that code is written by fallible humans.)

The “code is a process” view described by O’Leary is more aligned with the viewpoint of users, and with the notion that the code is there for a purpose and the purpose is “the law”.  In particular, the ledger and executable contracts are there to fulfill the intentions of the users.  From this point of view, tf and when the code does not meet the intentions of the humans, it is the code that is wrong, not the puny mortals. In this world, the mechanized processes (“the code”) are part of an overall system, not the ultimate and complete definition of it.

This “code is process” view is, of course, pretty similar to conventional business and engineering practices.  Inevitably, the determination of “correct” results depends on the opinions of the humans involved.  There may be quite a few people involved, and they may not agree with each other. For this reason, in this real life scenario, there always needs to be processes for judging and deciding cases.  You might say that “process is the law”.

The bitter spat about EIP867 is actually about the very nature of cryptocurrency systems.  Should we trust code more than humans? Can we trust code more than humans?  Are cyprotocurrency systems mechanical devices moving data around according to immutable rules?  Or are they people-to-people systems for transacting whatever business the people want?

One of Nakamoto’s “disruptive” idea is to evict people from the system.

(I think the syllogism implicitly is something like:
“People can’t be trusted”. 
“Therefore, remove the people from the loop.”
“Ergo, the system can be trusted.”)

Ethereum is finding that the people aren’t so easy to evict.

These fundamental questions are mutually contradictory, and therefore difficult to resolve in a single system. It falls upon the Nakamotoan-style “governance” process of Ethereum, adopted from open source software. Decisions are made through a propose-comment-revise-agree process, with final agreement in the form of de facto “consensus”—if you run the code, you “agree”, and if you don’t agree, you don’t accept the code.

To date, the savage talk in Ehterland shows that this governance process is not capable of deciding these issues. This has also been true in Bitcoinland .

I’ll note that the Nakamotoan concept of “consensus” in practice actually means “if you don’t like it, you can split off your own branch”.  This isn’t exactly what most of us mean by the term “consensus”, it is much more like “religious schism” (or apartheid)..  The resulting splitting is certainly “disruptive”, but not really in any good way.

While I would (and have) characterized the governance of cryptocurrencies as catastrophically flawed, Oleary reports  Ethereum founder and opinion leader Vitalik Buterin thinks it is “not that bad”.  He thinks the problem is “poor communication” [1].

What we got here is a failure to communicate.” (from Cool Hand Luke (1967))

With all due respect, I think Sensei Vitalik is flat wrong here.  The controversy is not about the way the proposal is presented, it is about the fact that such a proposal should not even be possible, in a Nakmotoan, code-is-law, world.  Worse, the fact that the powers-that-be have ruled such a move to be in-bounds reflects a deep disagreement about what the game is. (And it doesn’t help that there is a whiff of “insider trading” involved as well.)

No amount of explanation or communication can fix this kind of fundamental disagreement.

As Ethereum thrashes so visibly, it is important to say that these issues are endemic to Bitcoin and every other Nakamotoan cryptocurrency. However, Ethereum’s successful pioneering of “smart contracts” has pushed the community into extremely visible confrontations with the flawed logical foundations of the whole “code is law” movement.

Interesting times.

  1. Rachel Rose O’Leary (2018) Ethereum Governance ‘Not That Bad’ Says Buterin Amid Fund Debate. Coindesk,
  2. Rachel Rose O’Leary (2018) Hard Fork Refund? Developer to Appeal Ethereum for Hacked Millions. Coindesk,
  3. Rachel Rose O’Leary (2018) High Stakes: Ethereum’s Fight Over Lost Funds Explained. Coindesk,


Cryptocurrency Thursday

Cognitive Dissonance, Thy Name Is Ethereum

Ethereum was awarded the designation as CryptoTulip of 2017, and no small part of that distinction was due to its on-going efforts to deal with the catastrophic results of buggy “smart contracts”.

The DAO disaster of 2016 was “fixed” via an ad hoc hard fork that had the tiny side effect of creating a second, rump Ethereum currency.  Since that time, Ethereum has done several more forks to respond to problems.  And in 2017 a little oopsie resulted in millions of dollars worth of Ether being locked in inaccessible accounts.  This goof has not yet been addressed by a hard fork or any other technical fix.

The underlying problem, of course, is that Nakamotoan cryptocurrencies are designed to be “write once”, with the ledger being a permanent, unchangeable record.  This feature is intended to prevent “the man” from rewriting history to cheat you out of your money.  (This is a key part of the Nakamotoan definition of a “trustless” system.)

Ethereum has implemented executable contracts on top of this “immutable” data, which is where a lot of the problems come from.  Software is buggy, and “smart contracts” inevitably have errors or just plain produce incorrect or unintended results, such as theft.  But there is no way to correct the unmodifiable ledger, except by violating the write-once principle, i.e., a hard fork to rewrite history.

True Nakamotoists deeply believe in the unchangeable ledger not only as an engineering design but as the logical foundation of the new, decentralized world economy.  But Ether-heads have (mostly) acquiesced to multiple ad hoc forks to work around grievous bugs, which to my mind completely trash the whole point of the Nakamotoan ledger. The CryptoTulip Award citation noted “the tremendous cognitive dissonance Ethereum has engendered”.

It is very interesting, therefore, to see current discussions proposing to regularize this recovery process [2]. The idea, of course, is to reduce the risk and delay of ad hoc fixes with a more open proposal and review process.  Unfortunately, this process publicly endorses the very practice that the ledger is supposed to preclude.

This proposal has not been uncontroversial, for many obvious reasons.

In addition to the obvious problem with the whole idea of ever rewriting the ledger, the Ethereum community is dealing with questions about how “decentralized” decision making should work.

Theoretically, anyone on the Internet can have a stake in decisions about Ethereum software and protocols.  However, in the crypto world—and “open source” in general—some people are more equal than others.  Active programmers, AKA, “developers”, have influence and often veto power over technical developments.  And operators of large mining operations have veto power in their ability to adopt or reject particular features.

In the earlier ad hoc forks, the devs decided and then implemented the fork. There was little discussion, and the only alternative was the nuclear option of continuing to use the denigrated fork—which many people did. The result was two Ethereums, further muddled by additional changes and forks.

The proposed new process requires public discussion of forks, possibly including video debates. Critics complain (with good reason) that this is likely to introduce “politicians” into the process. I would say that it also will create factions and partisan maneuvering.  It is not inconceivable that (gasp) vote buying and other corruption might arise.

In short, this public decision-making process will be openly political.  What a development. The governance of Ethereum is discovered to be political!

Politics (from Greek: πολιτικα: Polis definition “affairs of the cities”) is the process of making decisions that apply to members of a group.

The explicit acknowledgement of human decision making creates a tremendous cognitive dissonance with the Nakamotoan concept of a “trustless” system, where all decisions are by “consensus”.  (In practice, “consensus” means “if you disagree, you can split off your own code”.)

But it also clashes with the core Ethereum idea of “smart contracts”, which are imagined to implement decentralized decision making with no human involvement. The entire idea of the DAO was to create an “unstoppable” enterprise, where all decisions were implemented by apolitical code.  When Ethereum forked to undo the DAO disaster, it essentially undermined the basic rationale for “smart contracts”, and for Ethereum itself.

And now, they want to have humans involved in the decision making!

The very essence of this dissonance is capture in a quote from Rachel Rose O’Leary:

For now, no further action will likely be taken on the proposal until ethereum’s process for accepting code changes, detailed in EIP-1, has been clarified.” [1]

In other words, EIP-867 is so completely inconsistent with the decision-making process it isn’t even possible to talk about it.  I guess they will continue to muddle through, ad hoc, violating the spirit of Nakamotoism.

I think that Ethereum is managing to radically “disrupt” itself and the whole concept of Nakamotoan cryptocurrency.

  1. Rachel Rose O’Leary (2018) Ethereum Devs Call for Public Debate on Fund Recovery. Coindesk,
  2. Dan Phifer, James Levy, and Reuben Youngblom, Standardized Ethereum Recovery Proposals (ERPs). Etherium Ethereum Improvement Proposal, 2018.
  3. Rachel Rose O’Leary (2018) Ethereum Developer Resigns as Code Editor Citing Legal Concerns. Coindesk,



Cryptocurrency Thursday

Cornell Report on Cryptocurrency “Decentralization”

One of the outstanding features of Nakamotoan blockchains is that it is a “decentralized” protocol—a peer-to-peer (overlay) network produces consistent updates to the shared data with no privileged leader or controller [2].  This property is a significant technical feature of Bitcoin and its extended family, and has even more symbolic and cultural significance for crypto enthusiasts.

“Decentralization” is supposed to impart technical robustness (there is no single point of failure), and political independence (there is no “authority” to be manipulated or shut down).  The absence of a “central” node also means that the protocol is “trustless”—there is no central service that must be trusted in order to do business. (I.e., you only need to trust your counterparties, not the rest of the network.)

In short, Nakamotoan blockchains and cryptocurrencies are all about being “decentralized”.

But what does “decentralized” mean?

In fact, the notion of “decentralized”, as well as the many related concepts, are poorly defined. In the context of a computer network, “centralized” can mean many things.  Indeed, a network transaction may depend on a number of physical and virtual layers, with different degrees of centralization involved simultaneously.  For example, a wi-fi network has various routers, links, switches, firewalls, and so on.  Even the simplest point to point link may pass through a number of shared channels and chokepoints that are technically “central” services, though the overlying service is decentralized, or centralized in a different way.  (Does that sound confusing?  In practice, it truly is.)

However, Nakamotoan “decentralization” is mostly about the logical organization of digital networks, as developed in so called “peer-to-peer” networks.  A classic Internet service is “centralized” in the sense that  client (user) nodes connect with a single server, which manages the whole system.  Clients trust the service to implement the protocol and protect all the data.  Note that so-called “centralized” services often run on many computers, even in many locations.  They are logically a single server, even if not physically a single node. (Does that sound confusing?  In practice, it is.)

Nakamotoan systems replace a single “trusted” service with a peer-to-peer protocol based on cryptography and economic incentives.  One of the critical design features is the use of algorithms that are impossible for a single node to hack.  This is important because In a conventional “centralized” service, once a server is suborned (or subpoenaed), the whole network is controlled.

In contrast, Bitcoin is designed so that the system cannot be controlled unless the attacker controls more than 50% of all the participating nodes.  In this design, security is assured by having a very large number of independent nodes in the network. This widespread participation is made possible by making the code openly available and letting anyone connect to the network.

While the cryptography has a relatively straightforward technical basis, other aspects of this security guarantee are less easy to define and they are actually empirical features of the network that may or may not be realized at any given moment.

For example, everything depends on the Bitcoin network being “owned” by many, many independent people and organizations.  If one person owned 51% of the network, then they would own all the Bitcoin.  And in fact, if one person owned 51% of the computing power (not the number of computers), they would own all the Bitcoin.

The point—and I do have one—is that while the Bitcoin protocol is designed to work in a decentralized network, the protocol only works correctly is the network really is “decentralized” in the right ways.  And there is no formal definition of those “right ways”, nor much proof that various cryptocurrency networks actually are decentralized in the right way.

This winter Cornell researchers report on an imporatant study of precisely these questions on the real (as opposed to theoretical or simulated) Bitcoin and Ethereum networks [1].

there have been few measurement studies on the level of decentralization they achieve in practice” ([1]. p.1)

This study required a technical system to capture data about nodes of the relevant overlay networks (i.e., real life Bitcoin or Ethereum nodes).  In addition, the study examined key technical measures of the nodes, to discern how the overall capabilities are distributed (i.e., the degree of decentralization).  These measures include network bandwidth (data transmission), geographic clustering (related to “independence”), latency (a key to fairness and equal access), and the distribution of ownership of mining power.  The last is an especially important statistic, to say the least.

The Cornell research showed that both Bitcoin and Ethereum have distinctly unequal distribution of mining power.  In the study, a handful of the largest mining operations control a majority of the mining power on the network.  (Since some authorities own or collaborate with multiple mining operations these counts underestimate the actual concentration of power.)   In other words, these networks are highly centralized on this essential aspect of the protocol.  The researchers note that a small non-Nakamotoan network  (a Byzantine quorum system of size 20) would be effectively be more decentralized—at far less cost than the thousands of Nakamotoan nodes ([1], p. 11).

Although miners do change ranks over the observation period, each spot is only contested by a few miners. In particular, only two Bitcoin and three Ethereum miners ever held the top rank.” ([1], p. 10)

These findings are not a surprise to anyone observing the flailing failure of the “consensus” mechanism over the last two years, let alone the soaring transaction fees and demented reddit ranting.  Cryptocurrency systems are designed to be decentralized, but they are, in fact, dominated by a few large players.

By the way, the two networks studied here are likely the largest and most decentralized cyrptocurrency networks.  Other nets use similar technology but have far fewer nodes and often far more concentrated ownership and power.  So thees two are the good cases.  Other networks will be worse.

The general conclusion here is that Nakamoto’s protocol trades off a huge, huge costs in equipment, power consumption, and decision-making efficiency to achieve the supposed benefits of a “decentralized” system.  Yet the resulting networks are actually highly centralized, though in opaque and hidden ways.  I think this is a fundamental flaw in the engineering design, and also in the philosophical underpinnings of Nakamotoan social theory.

I’d love to see similar careful studies of other underpinnings of Nakamotoism, including the supposed properties of “openness”, “trustlessness”, and “transparency”.

A very important study.  Nice work.

  1. Adem Efe Gencer, Soumya Basu, Ittay Eyal, Robbert van Renesse, and Emin Gün Sirer, Decentralization in Bitcoin and Ethereum Networks. arXiv, 2018.
  2. Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System. 2009.


Cryptocurrency Thursday

Ethereum explores actual software engineering

Cryptocurrency software generally has rather spotty quality.  Aside from the usual woes of ‘open source’ software, including a rush to market, minimal budgets, endless happy talk from the business side, and inexperienced programmers; cryptocurrencies suffer from their ‘decentralized’ governance model, which makes serious engineering difficult.

As a result, the major cryptocurrencies all have grievous performance problems, and, of course, awesomely dumb bugs.

Ethereum (winner of the 2017 CryptoTuilip of the Year award) has provided a veritable clinic on the shortcomings of decentralized management of software.

Now, it is true that Ethereum has an actual human founder (Vitalik Buterin), who does intervene to nudge (or even bulldoze) the community in certain directions.  But engineering changes are still done in the decentralized mode:  build it first, and then see if everyone agrees to use the modified software.  Astonishingly enough, letting users decide on every engineering detail (retroactively) is at best awkward, and at worst disastrous.

As widely noted, Ethereum has been experiencing performance issues due to the success of the CryptoKitties game.  In particular, the transactions for this one application have filled up the shared ledger, and sucked down processing time for all the nodes of the network.

Let’s be clear, these technical problems are perfectly normal, and, in fact, they are a sign that the software is successful and maturing.  There are any number of technical moves that might be made to increase capacity or ration usage or both.  Unfortunately, these normal engineering decisions required to save the whole system will disadvantage some individual users. Unfortunately, with the decentralized governance approach, anything that cannot command near unanimous approval cannot be implemented.

Amazingly enough, faced with potential collapse, Ethereum is seeing something almost unthinkable:  actually serious software engineering, beyond happy talk and and wringing in Reddit.

This month saw excitement over actual optimizations of the Ethereum system. Among other amazing fixes, various temporary files have been eliminated, vastly decreasing the storage needed.  Other fixes deal with gross inefficiencies in handling the data structures in memory.  It’s hard work, but pays off with much better performance.

Buterin himself is exploring serious redesigns including “stateless” clients and sharding.  These designs replace the mindless replication of all the data on every node with more clever ways to split up the data and work. These approaches are well known and well tried: they have been in use for decades in systems such as massively multiplayer online games (think World of Warcraft and other similar systems).  I’m sure they can be made to work pretty well for Ethereum.

Obviously, these are good ideas. They were good ideas twenty years before Ethereum was built.  It’s about time that these systems with millions and millions of dollars riding on them got up to reasonable levels of engineering.

I could be grumpy and point out that , back when I was a lad, we used to think things through before we released the product, not after several years, and hundreds of millions of dollars worth of goofs.

More important, though, is the observation that the optimizations that are rolling out now have been implemented by companies and individuals not constrained by a decentralized ‘consensus’ mechanism. The client-side software is more or less ‘open source’, but it isn’t governed by the same ‘everybody or nobody’ consensus rules.  Hence, it is possible to change the code relatively radically and relatively quickly.

In contrast, the server side stuff (e.g., sharding) is moving slowly. It’s worse than design by committee, it’s design by … who knows?  And even if a good plan emerges, it still has to survive the consensus process.  This could take years.

We’ll see.

As I said, this is a becoming case study in the difficulties of engineering decentralized systems.

  1. Alexey Akhunov. 2018. “Roadmap for Turbo-Geth.” Medium, January 6.
  2. Vitalik Buterin. 2017. “The Stateless Client Concept.” EtherResearch, October.
  3. Rachel Rose O’Leary,  2018. Blockchain Bloat: How Ethereum Clients Are Tackling Storage Issues. Coindesk.



Cryptocurrency Thursday