The Quiet Death of Ripple’s Codiu§ Project
Why decentralized infrastructure has still a long way to go
Ripple Labs Inc, steward of the Ripple Protocol and manager of the second largest cryptocurrency by market capitalization after Bitcoin, has quietly shelved the open source project Codius, which it had founded about a year ago and actively maintained ever since. Although the code was eventually versioned to a symbolic “1.0”, the project never gained much more than the curious attention of some hardcore enthusiasts.
[…] we’ve realized that Codius is an optimization and — right now, with a small and nascent decentralization market — a premature one. We have no plans to work on a Codius 2.0, instead we are building our own decentralized applications “manually” as described above.
Of course, the code behind the Codius project is up for the taking to anyone able to type git clone. But the project didn’t hit EOL prematurely because of a lack of developer resources — quite the contrary. Rather, the feedback of the community was simply not strong enough to justify the expenditure.
Ripple Lab’s decision is interesting for many reasons. Most importantly though, should this event be a warning to all those currently investing their time and money into building a global and decentralized infrastructure?
The idea behind Codiu§
Codius is an answer to the following question:
How to execute software in an untrusted environment and still be able to trust whatever the software has computed?
There are different ways to answer that question and each one comes with a specific set of systemic compromises. Codius was interesting in that it delivered a complementary set of such advantages and disadvantages vis-a-vis the popular Blockchain infrastructure that solves the problem of trusted code execution for networks such as Bitcoin, Ethereum and many more.
Same Same But Different
Codius too leverages the principle of distributed consensus to achieve the desired trust property of its system. However, whereas Bitcoin & Co build a completely separate communication infrastructure on top of the TCP/IP stack, thereby slowing the network’s computational power down by a factor of ~10000, Codius leverages existing commodity webhosting infrastructure to run arbitrary code at normal speeds and at much cheaper cost than a “Virtual Blockchain Computer” could ever dream to accomplish.
The difference lies in the size of the consensus pools when comparing Codius’ and e.g. Bitcoin’s consensus scheme. In the Codius world, there is no ‘global’ consensus pool as there is in Bitcoin, for the simple reason that a Codius pool does not drive a global payment network. A Codius consensus pool is better compared to >>YOU<< doing some google searches for the purpose of finding the cheapest vendor of a certain tech gadget you plan to purchase. Once you’ve found enough websites referring e.g. to Amazon as the cheapest supplier of the desired product, you’ll eventually settle on making your order in their store.
You have reached an inner consensus.
The number of google searches you would perform until you’ve decided where to purchase can be roughly compared to the number of Codius instances you would spawn into a specific consensus pool, whose quorum decision you would entrust to perform certain sensitive operations in your name, such as ordering a product on amazon, or paying recurring subscription fees to various services.
Codius in a Blockchain Ecosystem: Local vs. Global
In order to understand the purpose that Codius was intended to serve in the wider Blockchain ecosystem, one has to understand the systemic limitations of the latter. For all the security that Blockchains are able to generate through their crypto-economic governance and incentive scheme, they suffer from inherent slowness when it comes to general-purpose computation, as well as from an inherent blindness when it comes to incorporating rich information about the outside world.
This is where Codius’ complementary infrastructure decisions unfold their beneficial value to Blockchain-driven networks. Whereas Blockchains are good at delivering global consensus among thousands to millions of nodes, Codius’ solution is intended to deliver local consensus relevant only to specific individuals.
The affordances of local consensus schemes lie mainly in two areas:
Computational Complexity and Data Richness.
Since instances of the Codius execution environment are hosted on cheaply available infrastructure they can perform resource-intensive general-purpose computation at a fraction of the cost than a “Blockchain Computer” ever could. Same goes for incorporation of outside information, since unlike a Blockchain, a Codius instance has unfiltered access to the whole internet.
From a Platform vs. Services perspective, the relationship between Blockchains and Codius looks like this:
If you want to better understand the lower half of the graphic, I advise you to read this. This post focuses on the upper half, i.e. the Codius service layer.
From a Blockchain-centric viewpoint, Codius constitutes, what is commonly referred as an “Oracle”, i.e. an information gateway between a Blockchain and the outside world. Because the information feed provided by a given Codius oracle has been independently validated by a number of distributed instances, it serves to complement a Blockchain’s inherent trust model.
Why Codius’ Trust Model failed
It is mostly unfair to claim that Codius’ trust model really failed — rather: it has actually never been put to the test. The reason for this is what I initially hinted to as the “community feedback”, which was in some sense lacking.
An implicit yet fundamental requirement of Codius’ trust-enabling infrastructure is the existence of a functioning ecosystem of competing hosting-providers that offer the execution of Codius-style containers/vm images. Only if such a market with a functioning competitive landscape is available, does the trust property of Codius’ infrastructure emerge.
Codius’ notion of validating outside information works by assuming that although not any singular Codius instance may be trusted, a certain majority quorum of independent instances may indeed be considered trustworthy. As it turns out, the requirement of independence equates to the existence of a complex market-based ecosystem for Codius-style infrastructure provision. An ecosystem that didn’t evolve despite Ripple Labs’s best efforts in terms of generating publicity for the project.
What this means for the Decentralization Landscape
In terms of interpreting Codius’ early exit from the landscape of decentralized service providers, two things come to mind.
Firstly, the difference between centralized and decentralized service provision is not valued by a significant share of consumers and businesses in and outside the wider Blockchain ecosystem. Just look at the existing market of centralized service providers for Blockchain-based networks, which is already struggling to find an audience for its products. Conceptually, a centralized service is still much easier to grasp than a decentralized one. Codius never even left the world of command line interfaces.
Secondly, the difference between Codius-like oracles and classic centralized services providers is not just an “optimization problem” as Stefan Thomas likes to put it. It is connected the fundamental question of how much power we want to give to users and how much control should reside with the tech firms that increasingly regulate our daily lives.
 Personal Autonomous Agents anyone?
 As opposed to the much more limited domain of fiduciary code, to which Blockchains are essentially limited to. There is currently no other, equally significant type of code in sight, which would justify the investment of similar economic resources as is done e.g. in the case of Bitcoin’s Blockchain, which runs the currency’s internal fiduciary code).
 Vitalik Buterin talks about three kinds of facts: (1) mathematical, (2) global and (3) local. Blockchains excell at (1) but are completely helpless regarding (2) and (3).
 To the extent, the decision any miner or mining pool in the Bitcoin network implicitely or explicitely makes, namely whether to use its resources to serve or to attack the network, is an economic one, the same goes for hosters of codius instances. Therefore, only if the business of running such instances in an ‘honest fashion’ is economically more desirable than starting to tamper with the computational processees of individual instances (because the hoster somehow profits from a specific outcome), is the emergence of trust feasable.