The internet re-creates old problems

Since the advent of the internet our lives are becoming increasingly digitized. Money, mail, commerce, communication, entertainment, etc. We increasingly rely on internet services.

Internet services tend to devolve into winner-take-most markets. Google/FB control internet advertising, Google controls search, Facebook controls social media, Netflix controls streaming, Uber/Lyft control ridesharing, Amazon controls ecommerce, Amazon/Microsoft control cloud, Paypal/Stripe control payment processing, Visa/Mastercard/American Express control credit card networks, etc.

This narrow control of essential internet services creates new problems. If just a few controlling entities simultaneously “deplatform” you, you can be digitally disenfranchised. Twitter/Facebook/YouTube can prevent your voice from reaching your followers, Facebook/Google can cut off your internet advertising, Visa/Mastercard/American/Discover can cut you off from receiving payments, the list goes on.

Because digital disenfranchisement is so damaging, it’s weaponized by political entities. Political entities use laws, regulations, the threat of regulations, and the treat of being disenfranchised from banks + payment processors to coerce internet services to censor politically unpopular activity. Internet services caved into the pressure and now are willing censors because they are not willing to risk significant business disruption over a very small percentage of their user base.

Why care about censorship by privately owned businesses?

Because there’s more going on underneath the surface. If you look at the overlapping trends, what emerges is an old problem:

1. The internet is now playing a fundamental role in our lives for speech and commerce.
2. Just a few entities control access to the vast majority of internet services (e.g. banking, payment processing, credit cards, online advertising, social media).
3. Political entities are pressuring internet services to censor unpopular content and disenfranchise controversial users lest the internet services face significant business disruption.

The combination of these factors means that we have lost some fundamental rights in our transition to the digital age. Government is censoring unpopular speech and commerce through a few levels of indirection. Worse still, it’s all legal because no internet service wants to risk business disruption by challenging the system.

Where does blockchain come in?

In 2008, a new computing platform (Bitcoin) was developed through the use of clever cryptography. These platforms, also known as cryptocurrencies, have a special property that they are not controlled by anyone. There is nobody to make the decision to censor or disenfranchise content. This lack of control is generally referred to as trust-minimization or decentralization. One notable feature common to all cryptocurrencies is a blockchain, which is where the name comes from.

Anything that can be computed in a datacenter can be computed on a blockchain. This is to say that blockchain is or can be an alternative to existing internet services.

Cryptocurrencies, unlike internet services, is much harder to harm with laws and regulations. Also unlike internet services, cryptocurrencies are essentially sovereign digital economies— they do not depend on external services such as payment processors or banks to survive.

Political entities do not have leverage over cryptocurrencies like they do with internet services. Blockchains offer us digital ecosystems resistant to political interference. By extension blockchains are highly compatible with individual freedoms and civil rights in a digital world.

Introduction

Urbit is the mysterious, interesting project you’ve never heard of. Or maybe you’ve heard it, because it’s gotten a fair amount of publicity for being a moonshot project. The project operates on a new software stack you don’t quite understand, and claims to be an alternative to the perils of centralized computing today. It’s wacky enough to call performance art, but they’ve published real software which anyone can run. Unlike many other pie-in-the-sky ideas, Urbit was founded by a computer science PhD with expertise in the fields he’s tinkering with. It seems like it’s full of hot air but it’s not easy to dismiss.

Urbit is famously difficult to grasp

Understanding Urbit at first seems much deeper than what it does at a high level because it has its own operating function, interpreter, programming language, virtual machine, and networking model. Each of these has unusual design decisions and understanding the sense in these requires understand the design choices of modern operating systems, interpreters, programming languages, virtual machines, and networking model as well as how these interact with each other.

The steelman case for Urbit

Urbit is an experimental computing paradigm

There are a number of ways to describe Urbit:

• 100 year computer. Namely, the kind of computer you’ll still be using in 100 years.
• An alien computer. If an advanced alien spacecraft crashed into the Earth, what would it’s computer system look like?
• A new computing stack. How would computing look if we threw away everything we knew and reinvented it with the lessons we’ve learned along the way.
• An operating function.
• Your personal private server.
• If your operating system were a blockchain

Sounds wacky that all these things could describe the same thing, right? The most down-to-Earth way of understanding Urbit is that its founder disagrees with the way we’ve done things in computing for the last 50 or so years. Namely, he disagrees with design decisions (e.g. networking, the quasi-deterministic behavior of modern CPUs), the client-server model (your digital life on Google, FB, etc.), and the complexity of modern software (how many lines of code is your operating system?).

What Urbit offers in return is a virtual machine. This virtual machine has some new properties: it’s strongly deterministic, formally specified, simple, and portable. Bundled with this is an interpreter, a new programming language, networking, and an operating function.

Urbit is a server-side browser

Everyone has a client-side browser. Chrome, Firefox, Opera, etc. What makes these browsers client-side is that they are the clients in a client-server architecture, where the servers are typically the services you use (e.g. Gmail, Facebook, Amazon, etc.). By inverting this relationship, you get a browser (i.e. sandboxed kernel) which acts as the server. Put in another way, it’s a peer-to-peer computing paradigm to challenge our client-server computing paradigm.

Urbit reduces leaky abstractions

Software abstractions are often built on top of shaky foundations. Software ultimately runs on hardware, and so can never truly be decoupled from the layers below it. At the software-software interface, the separate modules are not supposed to make assumptions about each other, both imperfect systems. The implications sometimes relate to performance — to have a fast program you sometimes need to violate the abstraction (e.g. traversing a 2D array to use caching best). The implications can also relate to soundness — TCP is a reliable message protocol built off of IP, an inherently unreliable one.

With Urbit remaking the whole computing stack, the hope is that these leaky abstractions can be reduced as they are all being designed against each other.

My take on the project

Urbit is deliberately obfuscated

There is no way to reconcile how detailed and intricate Urbit is and the non-existence of clear explanations. It doesn’t take a genius to understand the big picture of Urbit — the project is just deliberately obfuscated. This is a red flag because vanity (e.g. “Only smart people understand Urbit”) is really not a productive personality trait in technology.

Community building is an important aspect of any new technology. But for people to use it, need to understand its value proposition. Urbit fails badly in that regard.

What is Urbit? It’s a virtual machine built for distributed environments. You won’t find that explanation anywhere because they tend to emphasize every aspect of their new stack like it’s the singular core value proposition. It ends up leading to rabbit holes where the reader gets lost in unnecessary detailed technical discussions when they’re just trying to find out what the big picture is.

And why is Urbit being built? The only de-obfuscated explanation of what Urbit aims to be is from one section in their 57 page whitepaper.

Urbit is designed to work as a “personal server.” This is not yet an established product category, so let’s explain it.

Everyone has a personal client, a secondary kernel isolated from the OS: the browser. Almost no one has a personal server, but they should. Urbit is a “browser for the server side”; it replaces multiple developer-hosted web services on multiple foreign servers, with multiple self-hosted applications on one personal server.

Why attack this problem with a clean-slate stack? Arguably, what stops people from running their own servers is the usability challenge of administering a Unix box on the public Internet. The Unix/Internet platform is 40 years old and has built up a lot of complexity. Mechanical simplicity does not guarantee humane usability, but it’s a good start.

A clean-slate personal server, with its own encrypted packet overlay network, can forget that Unix and the Internet exist. It can run on Linux and send packets over UDP; it can both provide and consume HTTP services; but its native stack is not affected by 20th-century design decisions.

HTTP services? Since a new network has no network effect, a node must find its first niche as a client and/or server on the old network. For its earliest users, Urbit has two main roles: as an HTTP client, a personal API aggregator (which organizes and controls your own data on your existing cloud accounts); (2) as an HTTP server, personal publishing and identity management (blogging, archiving, SSO, etc.). But Urbit still differs from existing Web application platforms in that an instance is designed to serve one primary user for its whole lifespan.

Violates Gall’s Law

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.[9]

This is a general trend in complex systems — complex systems are built up incrementally. Urbit is designed completely from scratch. I would say either the odds are against Urbit, or their development timeline is going to be decades (e.g. by making simple versions of what they want to build, and let that complexity develop over time).

Urbit is conflicted in their deliverables

Supposedly Urbit’s deliverable is a personal server. There are unambiguously better ways of going about creating a personal server. Namely virtualizing existing computing stacks, not creating an entirely new computing stack to virtualize.

Complexity in design is at odds with development speed and a major factor in why Urbit is decades in development. I don’t think it’s reasonable to say Urbit is really a personal server anymore — their focus has primarily been on creating the “perfect” stack oriented towards distributed computing. If you’d like a personal server you are best off working with pre-configured virtual guest operating systems, possibly existing in the cloud.

Architectural astronauts — Urbit is over-engineered

The scope of Urbit’s design is much larger than it should be for their stated deliverables. I’d rank it squarely between Ethereum and IOTA. Unlike Ethereum, Urbit has no use-cases that couldn’t be done through other means. Unlike IOTA, the project is slightly more grounded as it tends to focus on things it can deliver (see: Jinn, a ternary microprocessor).

What these projects share in common is that they are made by architectural astronauts. That is, these systems are made by trying to abstract design to the high heavens and tend to that software is a means to an end, meant to solve a real-world problem:

• Ethereum — what if Bitcoin could be a general-purpose computer?
• IOTA — what if we abstracted a blockchain into a DAG, invented our own cryptography, and abstracted binary to ternary computing?
• Urbit — what if we redesigned the entire computing stack?

What about if we just tried to focus a problem people tend to experience today, right now?

Conclusions

Urbit appears to be more interested in building a “perfect system” than solving the problem they claim to want to solve. I am skeptical that Urbit is going to be anything but a niche project for a few reasons:

• The project is deliberately obfuscated
• Violates Gall’s law
• Urbit is conflicted in its deliverable
• Urbit is over-designed

What it would take to change my mind is an important problem that Urbit uniquely solves or is uniquely capable of solving that alternatives can’t achieve. Failing that, to me Urbit is a vanity project.

Introduction

Ethereum 1.0 wouldn’t be undergoing a complete redesign unless it had major flaws. So how did we get here? And why did Bitcoin seem to fare much better? Two important factors are user experience and economics. At a minimum, for a product to succeed it needs to be a compelling alternative to an existing problem, and the transaction fee must not exceed the economic value of the actual transactions. Together these point to an upwards trajectory for Bitcoin and a downwards trajectory for Ethereum 1.0.

Competing on User Experience

There’s a saying that for one product to replace another with network effects, it needs to be ten times better. Specifically it must be good enough to justify the painful switching costs. Here we examine that first competitor and if those improvements could arguably be called a 10x better experience.

Bitcoin was 10x better

Who was Bitcoin’s first competitor? Gold comes to mind, but Bitcoin’s inflation in the early years was very large, far exceeding that of physical gold mining. There was little Bitcoin had to offer gold bugs in terms of longevity, inflation, decentralization, at least for now. It was not yet a competitive product.

Rather, Bitcoin’s first competitor was the wire / ACH transfer. In the developed world it’s hard to think of someone without a bank account, and the base of people with experience using these workflows is about as high as the number of people who have ever filed taxes. Moving money could cost $30 for a wire, and take one business day which could mean three total days given that banks often don’t operate on the weekend. ACH transfers are cheaper but much slower, taking 3–5 business days to process.

Bitcoin was an obvious improvement with 10 minute block times and fees that were for a very long time under a penny. Unlike banks, Bitcoin didn’t shut down after 5 PM or on weekends. It was an obvious 10x improvement, so much so that years later many continued to think of Bitcoin as a consumer payments network rather than a settlement layer.

That Bitcoin is today thought of as an alternative to gold rather than the wire transfer is irrelevant. During its most formative years it was able to onboard users by providing a clear alternative to bank transfers.

Ethereum turned out to be 10x worse

Who was Ethereum’s first competitor? Many think it was Bitcoin, but it was hardly better equipped to offer a substantial improvement with respect to payments. Rather, than being engineered for payments, it was a general purpose platform and originally branded a “world computer”.

This world computer where anybody could write their own decentralized applications was often referred to as ushering in Web 3.0, where Ethereum would presumably be the backbone of a secure and decentralized internet. Since the contemporary web is referred to as Web 2.0, I think it’s a fair thing to say it was Ethereum’s first competitor. Both the internet and Ethereum share the common trait of being permissionless platforms that anyone can build on.

The contemporary web is built out using the client-server model and is extremely scalable thanks to horizontal scaling (analogous to sharding). This ability to scale is its superpower: there are billions of internet connected users, tens of billions of internet connected devices, and room for more. Latency is often so small it’s often not neurologically perceivable. Bandwidth is good enough to stream video and costs are largely free, subsidized by advertising.

Ethereum is not exactly a platform ready in any sense to offer improvements on the contemporary web. Its bandwidth isn’t enough to upload small images (the most data that can be uploaded per block is about 13 KB). At 15 transactions per second only about 1 million daily active users can be supported. Latency is far longer than the 2 second limit that will frustrate users on the web. Every state change is approximately $0.06, which bodes poorly given how much interactivity is part of the normal web browsing experience.

Ethereum is unfortunately not the 10x improvement anyone is looking for. If we’re polite, it’s a 10x worse experience. And if we’re honest, it’s several orders of magnitude worse still. Ethereum was picking a battle that couldn’t be won here. Web 2.0’s superpower was scalability and that was Ethereum’s weakness.

Economics of transactions

It’s an economic reality that the value of the transactions must at a minimum exceed the transaction fees paid. Without this, we can’t realistically expect to onboard users. Nobody is interested in leaving money on the table. Single fee markets behave like you might expect, but multiple competing fee markets can crowd out applications with low economic value.

Bitcoin’s single-application platform was smooth sailing

Transactions on Bitcoin were intended for wealth transfer. Although there were secondary uses of Bitcoin such as gambling and storing data, the primary function had the highest economic value. This meant that using the platform as intended was not impeded by secondary uses.

Ethereum’s multi-application platform had unexpected interactions

Transactions on Ethereum were meant to power dapps. Wealth transfer was meant to be a secondary use that unfortunately could not be designed out of Ethereum. So what happens when a low-value application is on the same platform as a high-value application? Unless they both offer comparable economic value, the low-value application may be entirely priced out. Picture dapp A’s bottom 1st percentile of transactions justifying a fee of above $0.06 and dapp B’s top 99th percentile of transactions justifying a fee of below $0.06.

Wealth transfer out-priced dapps on Ethereum

In Ethereum’s case, despite its intended use case being for decentralized applications, the most popular use of Ethereum is still just transferring wealth without the assistance of dapps. Ironically, what was surely considered to be a secondary use of Ethereum is now setting a transaction fee baseline that’s putting dapps out of business.

Interacting with the web, unlike transferring wealth, is not a high-risk workflow. If you try to authenticate to a website or update your Facebook status and there is some interruption or error, you can try again. There is no real risk of catastrophic loss and consequently little need for security, legal systems, or insurance like with wealth transfer. This is largely the reason that software engineering doesn’t require licenses to work in, in contrast with other fields like medicine or other engineering fields.

Web 3.0 applications have been crowded out by wealth transfer. This has been the fate of most dapps, failing to deliver economic value on a per transaction basis greater than the current median fee of $0.06.

The Ethereum 1.0 dapps that survived lacked traction

With that said, there have been a few categories of dapps which have provided enough economic value to survive. Most notably they are gambling, decentralized exchanges for on-chain tokens, prediction markets, ICOs, and collateral-backed loans. What they share is that people are willing to pay on par with baseline transaction fee for these workflows. (It is not a coincidence that they involve moving potentially large sums of money at once.) The problem, however, is that these are niche applications whose values are way out of line.

0x, one of the most popular dex protocols, has collected only $2000 in lifetime transaction fees despite having a market cap of $160M. The token is also not necessary for the protocol to function and will likely be forked out by major relayers. Augur, the most popular prediction market, has only $40k staked in predictions yet has a $170M market cap. No dapp has more than 1000 daily active users on a regular basis and only a couple dozen have more than 100 daily active users. Something is not right with these numbers.

Conclusions

So why did Bitcoin do so well and Ethereum always seemed to struggle?

Bitcoin was a 10x improvement over the wire / ACH transfer. Bitcoin only had one use case which also had high economic value, so the fee market adjusted to what users were willing to pay.

Ethereum 1.0 was 10x worse compared to contemporary web architecture. It was an inherently unscalable system (monolithic blockchain) competing with an extremely scalable system (modern web). The situation is so bad that they need a complete re-architecture. Wealth transfer on Ethereum (not intended to be the primary use-case) created a baseline transaction fee that drowned out all applications with low economic value (i.e. most dapps). The dapps that did survive were less numerous and successful than what was expected.

Join Coinmonks Telegram Channel and Youtube Channel get daily Crypto News

Also, Read

• Copy Trading | Crypto Tax Software
• Grid Trading | Crypto Hardware Wallet
• Crypto Telegram Signals | Crypto Trading Bot
• Best Crypto Exchange | Best Crypto Exchange in India
• Best Crypto APIs for Developers
• Best Crypto Lending Platform
• An ultimate guide to Leveraged Token

Why Ethereum 1.0 failed and Bitcoin succeeded was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

How not to waste $13 billion

Introduction

You could say that misunderstandings about the nature of dapps have resulted in the misappropriation of about $13 billion dollars between 2017 and 2018. While some of these ICOs may one day lead to something which merits the initial capital investment, it’s hard to argue that this will be the case for many (if any at all). The technology has been improperly leveraged and overcapitalized (unsuccessfully) in an effort to overcome fundamental limitations. Here I explain how the upsides and downsides of dapps compared to contemporary web services to show how to successfully leverage dapps.

Dapps offer a different architecture than scalable web services

The alternative architecture offered gives hope to dapps finding a use-case considering that dapps will have a hard time competing with web services.

Scalable web service architecture

Web services use the client-server architecture with centralized computing. The client-server architecture means that the end-user will make use of a remote computer to use the service. This is typically done for a number of reasons, but mainly because it’s scalable. This allows for a single entity to leverage economies of scale and share that computing power / data storage with users for free (usually in exchange for their data or to show them ads). Adding new users is easy because all that’s required to access the service is a lightweight, internet-connected computing device, and most people already own personal computers and cell phones. You could say this architecture exchanges security from hostile adversaries for better efficiency. Typically security is largely outsourced to government anyway (e.g. common law), so these architectures can focus strictly on efficiency.

Blockchain/dapp architecture

Blockchains use a peer-to-peer network and each user validates the entire blockchain. Validation typically requires downloading the entire blockchain and checking that every transaction conforms to the protocol to compute the final state. Adding new users is harder because it requires users owning hardware capable of validating the entire blockchain within a reasonable period of time. Owning personal computers is common, but requiring several hundred GB of data and days of syncing is a UX anti-pattern. The highly distributed blockchain data makes the network more resilient to attacks. You could say this architecture exchanges efficiency for better security. Unlike web services, blockchain networks do not outsource any of their security, even to governments. More often, governments are considered an adversary in the threat model.

More on the blockchain/dapp architecture

The blockchain is a cloud platform which can never be shut down

Cloud services are just server hardware rented out as a product. Basically web hosting. In today’s centralized cloud services, the service provider can revoke access at their discretion. In contrast, any code uploaded to the blockchain must stay there indefinitely. This is because the nature of blockchain validation requires that all data be present, so objectionable or politically sensitive data cannot be excised without preventing the ability to perform full validation. As long as full validation is a priority, data on the blockchain is censorship-resistant.

Full nodes are like servers

All full nodes contain the current state as well as the entire blockchain. This also means that they have a copy of each dapp and the contract code. If someone wanted to, they could offer access to blockchain data as a service. In other words, users have two options for accessing dapps:

1. Run your own full node. The hardware requirements are high and the time to validate all state is high. This is a UX anti-pattern but allows anyone to run dapp code in a trust-minimized, private manner.
2. Full node as a service. Here clients would request node data (e.g. all account information for a dapp associated with a given public key) and interact through a browser. To them, it would be as if they were running a full node, and the hardware requirements are pretty low. This is a somewhat trustful, less private way of accessing a dapp. It’s also scalable.

Inefficiency is a consequence of censorship-resistance

Blockchain networks are only censorship-resistant because copies of the blockchain are highly distributed. However, that high level of distribution means intensive on-chain computation or high-capacity data storage are prohibited. This is because the hardware requirements must be kept reasonably low for the full node count to stay reasonably high. The exact number of full nodes necessary for censorship-resistance is not well understood, but for the time being any service which wishes to retain this property should be conservative. Once a service is centralized there is no going back. This means:

• Transaction throughput must be limited. Transactions require data storage and computation to verify. If it takes you longer than the average block time to verify all transactions in a block, you are effectively prevented from full validation.
• Only the bare minimum should be persistently stored on-chain. Data is forever.
• A fee market is necessary to disincentivize spam, raising costs for any kind of operation. Microtransactions or applications without a minimum of economic value may not make sense.

Dapps offer a new balance of features to existing censorship-resistant services

Today’s censorship-resistant services offer this important feature in one of two ways:

1. By hiding the location of a centralized service. (e.g. Tor hidden services)
2. By keeping data highly distributed with no single point of failure. (Freenet, Bitmessage)

The unspoken reality of smart contract platforms is that they are a consequence of taking a highly distributed data store and adding scalable business logic capabilities. That is, if we embedded user-created APIs (smart contracts), a virtual machine, a formal means to triggering those API calls (transactions), and a way of ordering transactions in a highly distributed data store (a blockchain), we get a smart contract platform.

This is great news. It means that dapps offer something compelling and unique that both web services cannot offer and neither can existing censorship-resistant services.

The biggest feature difference offered by dapps is that they lack human and machine points of failure. The big question really comes down to how scalable they can be made. With the client-server model, this is a real possibility.

Why Ethereum’s “Unstoppable world computer” narrative failed

Dapps as censorship-resistant cloud-computing is more-or-less the same as its conception as an unstoppable (read: censorship-resistant) world computer (read: cloud computer) back in 2014. So if they had it right the first time, what happened?

They failed to target the correct markets

Gambling, adult classifieds, and anonymous markets are the three most profitable categories which require some degree of censorship resistance. Only in the first case was there any attempt made at pursuing products which could offer something on the Ethereum platform. It would be fair to say that the Ethereum team was composed of technologists without any clear sense of product-market fit.

Instead, the Ethereum community targeted inappropriate applications which rarely needed censorship-resistance at all. It seems that their primary target was services which used some trusted intermediary, and the reality is that the additional rent imposed by the trusted intermediary was nowhere near the additional costs that would be incurred by a decentralized architecture. The largest markups products usually see is something like 50x (e.g. pharmaceuticals), but the inefficiency of dapps (at least on Ethereum) is orders of magnitude larger on most (all?) metrics.

They never evaluated the costs

It was pretty clear from the start that blockchains wouldn’t offer anything cost-effective relative to conventional cloud computing platforms, such as Amazon web services. Given that they were targeting the wrong (or at best, suboptimal) markets, they really should have paid more attention to how cost-effective their solution was.

They put the technology ahead of the product-market fit

Ethereum was not a solution which started with a real-world problem. It was a generalization of a technology that itself was solving a very specialized problem (trust-minimized wealth transfer). Given this, they never optimized the architecture to solve any problem in particular, and were caught off guard when they found that Ethereum was too inefficient and costly for every problem domain they targeted.

Conclusion

Dapps are just code on an immutable cloud (the blockchain). The highly distributed blockchain data makes this code censorship-resistant. Dapps are absent both hardware and human points of failure which is a unique feature set that does not exist in other censorship-resistant technologies. Anything which doesn’t require this censorship-resistance may be better off using a completely centralized alternative. Ethereum was right when they called it an unstoppable world computer, but they failed to properly analyze the costs or target the correct markets.

Get Best Software Deals Directly In Your Inbox

Dapps are just censorship-resistant cloud-computing was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why it fails as a global money

tldr; see title

Note: “Ripple” refers to XRP; All tokens are collectively referred to as “Ripple assets”. Ripple (XRP) is distinguished from other things which share the same name by a qualifier such as “Ripple platform” or “Ripple company”. Ledger refers to the overall state of the system which is typically computed from but does not include the transaction history, analogous to Bitcoin’s UTXO set.

Introduction

Here I analyze how fit the Ripple (XRP) is to serve as a supranational electronic currency on the Ripple platform. This is assuming that the SEC does not declare Ripple (XRP) a security, banks actually use Ripple (XRP) on the Ripple platform, people actually also use Ripple (XRP) as an electronic currency, and Ripple (XRP) captures most of the economic value on the Ripple platform. The conclusion is that the Ripple platform is peacetime, low-stakes financial software not fit to serve as critical infrastructure of any kind. The issue at hand is that the Ripple platform works poorly in adversarial environments, and preventing a major attack vector compromises the benefits of decentralization entirely.

Why the focus on Ripple (XRP) as a supranational currency?

It’s pretty widely acknowledged that Ripple’s official strategy is adoption in the banking sector as a bridge asset. For banks to actually use Ripple, it needs a huge amount of liquidity, and that liquidity can’t come from the banks.

Need for constant liquidity: This is because slippage makes the price of traded assets (such as the bridge asset) extremely volatile at the moment of exchange especially if fulfilling multiple orders. Liquidity decreases slippage, and it also decreases price volatility when holding.

This liquidity cannot come from banks: If it did, banks would be better off with a token they created, which would allow them to own 100% of the supply as well.

So who supports Ripple’s price, thereby creating that liquidity? The only way forward that I can see is if Ripple works as a general purpose cryptocurrency. This is not a particularly bad direction given that Ripple’s market cap is currently about $19B, which is to say there is probably some real liquidity. For reasons that may or may not have to do with classification as a security, this happens to be how Ripple (XRP) is marketed now. And since we’re talking about liquidity that can support the bulk of the world’s banking, it needs to be a really, really successful cryptocurrency. With that in mind, the focus is on Ripple as a supranational currency.

Some requirements for a global electronic currency

This list is not exhaustive but we will find that these aspects are relevant to the discussion.

Fungible

This means that units of money are indistinguishable. Fungability allows anyone to receive a payment and not concern themselves with whether others will discriminate against those tokens. If the true value of cash is not its nominal value, it increases mental transaction costs, adds considerable friction to end-users, and is ultimately less useful as a currency.

Trust-minimization

Two people who distrust each other must be able to engage in commerce.

Censorship-resistant

This means that it is difficult to any entity to exclude transactions from being confirmed. This is analogous to freezing funds or preventing those funds from being used in certain ways.

Resistant to theft or burning

User balances should be treated like property rights since tokens are a bearer asset. The owner(s) alone should have control over their funds.

Difficult to counterfeit

Counterfeit money dilutes the relative purchasing power of everyone else who has stake in this system. For cryptocurrencies, creating tokens outside of the protocol is considered counterfeiting.

One set of account balances

There must be one set of account balances that is shared by everyone. People who are mutually distrustful must be able to engage in commerce on the same ledger.

Scalable

As the number of users grow and the value of the tokens appreciate, the system must be able to retain its core properties and function.

Graceful failure modes

If the security assumptions for consensus are no longer true, what happens? When an attack becomes possible, how expensive is it to make arbitrary changes?

Ripple platform’s failure modes

How the Ripple ledger or consensus can be disrupted largely comes down to the behavior of trusted peers. As the Ripple company mentions, the system depends on these validators not colluding.

During consensus, each node evaluates proposals from a specific set of peers, called chosen validators 6. Chosen validators represent a subset of the network which, when taken collectively, is “trusted” not to collude in an attempt to defraud the node evaluating the proposals. [source]

Denial of service (DOS)

With >20% of trusted validators disagree, service can be halted. Consensus requires that at least 80% of trusted validators agree. From the Ripple company whitepaper:

Thus for a UNL of n nodes in the network, the consensus protocol will maintain correctness so long as: f ≤ (n−1)/5 (1) where f is the number Byzantine failures. In fact, even in the face of (n−1)/5+1 Byzantine failures, correctness is still technically maintained. The consensus process will fail… [source]

Consensus failing means that no transactions can be confirmed, making the system unusable. This does actually require that validators collude, as an attacker can knock validators offline with the same effect (unresponsiveness is considered a Byzantine failure).

Rewriting state permanently — excluding or reordering historical transactions

Nodes of the network recognize a ledger instance as validated when a supermajority of the peers have signed and broadcast the same validation hash 8. Going forward, transactions are applied to this updated and now validated ledger with sequence number N+1.

In cases where a node is in the minority, having computed a ledger that differs from its peers, the node disregards the ledger it computed 9. It recomputes the correct ledger, or retrieves the correct ledger as needed.

If >80% of trusted validators collude, transaction history can be permanently reordered without violating consensus rules. With the Ripple platform, transaction history is relative. It’s whatever your peers say it is. Much like Ethereum technically didn’t violate consensus rules from the DAO incident, nobody is violating the Ripple platform’s protocol by re-constructing a new ledger from existing transactions. And fully validating the ledger against all transaction history will not protect you.

Rewriting state arbitrarily— violating consensus rules

If >80% of trusted validators collude, they can break consensus rules, and these changes will be accepted by anyone who does not validate their history against this new ledger. This means they can mint funds, burn funds, and steal funds without any transactions needing to take place. This attack is only made possible against those who don’t fully validate transaction history, which makes it extremely important that you only trust validators on the Ripple network who do full validation.

Scaling implications — critical infrastructure

Here we assume that the Ripple platform is too big to fail, meaning preventing Ripple platform’s failure modes is a top national priority. The primary threat model are foreign, coordinating countries disrupting consensus.

Trust concentration — DOS protection

Realistically the only ledger state that matters is among the people you do business with. There is no benefit to trusting people who are not within your economic confines because in the event of a dispute, only the ledger of your economy matters (not somebody halfway across the world). That is to say, trusting too many other validators could cause you to be forked out of your own economy. The larger the Ripple platform’s contribution to the economy, the riskier a denial of service (DOS) attack becomes.

At the right scale the security of the Ripple platform within national infrastructure come into question as an issue of national security. Trusting a node is not just a statement about their ledger but also about their ability to resist distributed denial of service attacks which could take them offline. Government efforts would be directed towards mitigating these failure modes. We can expect that government will run their own secure validators in their country, which would be considered authoritative for the uses of domestic banking. Governments would almost certainly mandate that no more than 20% of trust for domestic banks be directed towards validators not under government control to prevent this attack vector.

Since validators can sometimes be offline for reasons unrelated to an attack, in practice banks might weight 85+% of their trust domestically.

Trust concentration to comply with law

Running a validating node may expose the operator to legal risk. During consensus, nodes vote on which transactions they wish to confirm, and we can expect there to be restrictions on this vote can be exercised if this ledger controls the flow of serious money. It is entirely possible that validators which participate in consensus must register as financial service providers and comply with applicable regulation, regardless of who trusts them or not.

At the right scale, the Ripple platform has geopolitical implications. We can reasonably expect the US government to require that validators contributing to consensus within their jurisdictions comply with international sanctions or law enforcement requests. The same holds true for every other jurisdiction. I see a few paths here:

1. Delegate the entirety of your trust to domestic banks or government validators, which will only propagate legal transactions. This is fairly low maintenance.
2. Use software which acts as a filter for transactions which may not be legal. This is higher maintenance as the determination of legal and suspicious transactions may be complex and constantly changing. I see this as out-of-reach for individuals who do not have a business reason for this.
3. Do not participate in consensus, which means your validator is a tracking node.

It would be trivial for law enforcement to enforce any policies that relate to consensus as they can connect to validators and view this data in real time. While the way I described how this could play out isn’t guaranteed, it is clearly within the reach of government to do things this way as the actual number of validators is fairly small, within 200 as of recently. For comparison, Bitcoin has about 10,000 listening nodes as of now which support the network.

Governments can alter domestic ledgers

Earlier I discussed how <20% of trust will be weighted to validators outside of government control to prevent DOS attacks on domestic infrastructure. As it were, this means that government can control >80% of the weighted trust which is the necessary minimum to rewrite state and even violate consensus rules.

Government and law enforcement will have an interest in censoring transactions, freezing accounts, and possibly even inflating the supply as a source of revenue. This would be true even if they didn’t control a supermajority of trust domestically, but in this case they happen to. Governments will change the ledger as much as they can get away with, and that state will propagate to all ledgers who transitively trust them.

Ledger fragmentation

While many people may not directly trust government validators, they have no choice but to trust those they do business with. For most people they will trust businesses, retail banks, and friends. Businesses will trust major business partners, and their banks. Banks will trust their government. Government trusts themselves.

Due to the pattern of trust concentration, changes to the ledger within a jurisdiction’s nodes will propagate locally but won’t propagate to other hubs of trust (e.g. other jurisdictions). So each country will have their own separate ledger, and the differences between ledgers will increase over time.

This presents a large problem for anyone who must do international business in this low-trust environment. Ironically, Ripple (XRP) was meant for international settlements, but as we can see this does not work well across separate hubs of trust and what separates those hubs are national borders.

No such thing as a global ledger

Provided that national infrastructure protects against DOS attacks, any kind of transaction censorship within a hub will fragment the ledger permanently.

It’s possible that we can get around this by partitioning the address space into separate countries, each of which make the determination of which transactions are permissible, but this incompatible with the protocol as it exists. It’s possible we can get around this by having each country issue their own tokens, but countries will still want to censor Ripple (XRP) as it pertains to sanctions or criminal investigations, so we are back to our original problem.

Practically speaking, there is no way we can get around this as it’s not what the Ripple platform was designed to handle. Ripple platform was meant to work only within hubs of trust, not across separate, mutually distrustful hubs.

Once a ledger fragments, there is no general way to reconcile it without dropping the transaction history altogether. We can expect that the Ripple ledger and assets would be an asset denoted by its national confines. Such as XRP-US, XRP-China, XRP-Russia. The same private key would have different economic values in different jurisdictions due to inflation of the supply, government stability, etc. Cross-border exchange would be difficult.

No use for a counterparty-less asset

The token Ripple (XRP) draws its main benefit from being an asset without a counterparty. With a fragmented ledger, each fork controlled by some government, there is no additional benefit of XRP over fiat.

Scaling implications — non-critical infrastructure

While not the focus of this article, I think it’s helpful to go over how the Ripple platform would function as non-critical infrastructure, because it still has some pretty significant limitations. Here we assume the Ripple platform is not related to national security, so the threat model becomes any single jurisdiction disrupting consensus, including friendly ones. Domestic banking would not take place on the Ripple ledger.

Trust dissipation — DOS protection

Maintaining a single global ledger requires that we not delegate trust at more than 20% to any single group which might be likely to collude. Since collusion is most likely within national borders we must be sure not to not trust any single nation at more than 20%. This means that >80% of our trust must be to jurisdictions outside of our own.

Coordinating governments can censor transactions, freeze accounts, or stop the network

Governments are known to coordinate with each other for political purposes. Crossing the 20% line for global trust will come down to at most 39 countries (which would be an equal allocation of trust to each jurisdiction). Taking a look at intergovernmental organizations is pretty clear evidence that this level of cooperation is possible. While you may not assign trust to a government, everyone is beholden to their governments and must follow their laws. This is to say that governments ultimately have control over how their validators will behave.

Intergovernmental cooperation is common. For example, NATO has 29 member states. The United Nations has 193 member states. The European Union has 28 member states. The International Monetary Fund has 189 members. The European Central Bank has 19 EU member states. Interpol has 192 member countries. The World Trade Organization has 164 member states. Only one or two large intergovernmental organizations need to cooperate to halt consensus.

To be realistic, sovereignty isn’t distributed equally among the 193 countries in existence. Some countries have extensive ability to exert influence or project power on global scale, and they are referred to as potential superpowers. The most commonly mentioned ones are United States, European Union, China, India, Russia, and Brazil. This is to say there is not a whole lot of benefit to delegating trust outside of these potential superpowers, as they ultimately will have power over the smaller, less powerful countries. One or two of these major powers coordinating could halt consensus.

Coordinating governments could counterfeit Ripple at the right price

If the Ripple markets were large and robust enough, it would be within the interests of all governments to come together and mint Ripple. In this way they would treat the Ripple network as their own central bank at the right price. While governments can easily print more fiat, inflating the supply of Ripple could give them an easy way of generating money without it affecting the exchange rate of their fiat.

Since each country must balance minting money and destabilizing their local currency, minting Ripple would be a much more attractive proposition because they are unlikely to face the negative externalities in the same way. I am guessing the motive would be there when the average nation would stand to gain $100 million, which be about $20 billion inflation worldwide.

A low-trust environment can cause ledger fragmentation

If there is an international incident, such as a cold or hot war, we can expect that the highly connected web of trust globally will partition. The cold war was a 45 year period of geopolitical tension between at least two world superpowers. Trust must be distributed widely for there to be a single ledger, and low-trust environment can encourage people to delegate trust in such a way that prioritizes the security of their local network. This creates hubs of trust which won’t allow fragmented ledgers to reconcile across the hubs.

Less overall demand for Ripple assets

There is little reason to hold assets on a platform outside of what is necessary to fulfill a task. Keeping more money than necessary on the platform is, if anything, a decision of convenience regarding the expected near-term future use of the platform’s services. Since we’re assuming the Ripple platform does not facilitate much of the world’s commerce, we can expect less demand for Ripple assets.

Returning to those requirements for global electronic currency

There are two scenarios to consider: Ripple platform as critical and non-critical infrastructure.

Fungible

1/5 — Critical infrastructure: The ledger will fragment as governments have the interest and ability to make arbitrary changes to the ledger which will propagate within national borders according to the protocol. Ripple assets are not guaranteed to have the same nominal value or even relative purchasing power across borders. That government can easily freeze or confiscate funds makes dirty coins or coins without a provably clean history even more risky to accept.

3/5 — Non-critical infrastructure: Provided there are no periods of international tension, there will likely be a single ledger that won’t be tampered. This is to say that the tokens will have the same nominal value and relative purchasing power across jurisdictions.

Trust-minimization

Two people who don’t trust each other can engage in commerce only when they share the same hub of trust. Specifically, 80% of each person’s trusted validator set must overlap if they wish to engage in commerce without service interruptions and >50% overlap is required to ensure they are guaranteed to use the same ledger. There is no way to verify that your trusted validator set overlaps with someone you are engaging in commerce with as UNLs are private.

1/5 — Critical infrastructure: Same level of trust as fiat (everyone trusts their govt).

2/5 — Non-critical infrastructure: Less trust required than fiat but two mutually distrustful people trust the same collection of entities, akin to a consortium. There is no good way to verify that there is sufficient trust overlap.

Censorship-resistant

1/5 — Critical infrastructure: Since >20% of trust is given to government either directly or transitively so transactions can be prevented and funds effectively frozen. Governments can also require all other domestic validators to adhere to blacklists or whitelists.

1/5 — Non-critical infrastructure: Cooperating governments can easily halt consensus and prevent the movement of funds.

Resistant to theft or burning

1/5 — Critical infrastructure: Governments will have >80% of weighted trust which allows them to make arbitrary ledger changes including inflating the overall supply.

3/5 — Non-critical infrastructure: Funds are unlikely to be stolen since it requires large-scale intergovernmental cooperation. However, the indefinite freezing of funds is logically equivalent to funds being burned, and this requires a level of cooperation within reach (>20% of weighted trust).

Difficult to counterfeit

1/5 — Critical infrastructure: Governments will have >80% of weighted trust which allows them to make arbitrary ledger changes including inflating the overall supply.

2/5 — Non-critical infrastructure: If the Ripple markets were large and robust enough, governments could easily come together to counterfeit Ripple as they control validators within their jurisdictions. Such an act would be mutually beneficial to all governments and could occur if the markets could support $20 billion inflation.

One set of account balances

1/5 — Critical infrastructure: The ledger is very likely to fragment across mutually distrustful hubs of trust. The level of fragmentation is likely to be somewhere between the number of global superpowers to the number of separate countries. Mutually distrustful people who don’t share the same hub of trust cannot engage in commerce on the same ledger.

3/5 — Non-critical infrastructure: One ledger, provided no periods of international tension. If there is a cold or hot war, the ledger is likely to fragment.

Scalable

The Ripple platform scales extremely poorly when it comes to censorship-resistance. Regarding counterfeiting, the platform scales well up until the point where it’s worth the cooperation of governments to treat the platform as a central bank. Regarding fragmentation, the platform only works in peacetime environments, but scales well until the point where it becomes too big to fail.

Graceful failure modes

The failure modes are extremely bad and once those security assumptions are no longer true, attacks are free beyond this point. With full validation, the transaction history can be re-ordered in any way, causing transactions to disappear or appear in an inconsistent order. Without validation, the ledger can be changed in arbitrary ways that violate the protocol such as inflating the supply, altering balances, and burning money.

Conclusion

Ripple platform is peacetime, low-stakes financial software for groups who trust the same entities. There is no way to fully protect against denial of service attacks without giving some group the power to make arbitrary changes to the ledger at no cost. As a global currency, Ripple would not survive a cold war without severe fragmentation. During a hot war, Ripple would fail entirely.

As a supranational currency, Ripple (XRP) provides no advantages over fiat. If Ripple platform becomes too big to fail then DOS attacks would be prevented by delegating >80% of trust to government, which gives them complete control of the ledger within their borders. This means Ripple assets fragment for each national government. Since governments have the desire and opportunity to freeze funds, censor transactions, and inflate the supply, we can expect them to do just that. Cross border, Ripple is not guaranteed to have the same nominal value or relative purchasing power.

As a supranational currency it’s important to have a single set of account balances, something strongly resistant to government control, and something which can survive adversarial environments. Ripple platform is not that solution.

Introduction

Ethereum’s community has recently been going about a rebranding of Ethereum. This is a consequence of dapps falling short of expectations when Ethereum was once thought of as a world computer. There are dapps and they work, but they fail to find product market fit and attract users. The Ethereum community is now focusing on the few dapps which seem to have the most promise, often financial tools such as exchanges and collateral backed assets, branding Ethereum’s narrative as open finance.

Here I use first-principles to identify how we should try to leverage dapps to find better product-market fit, focusing on the censored web.

What is a killer application?

From the wikipedia page:

a killer application (commonly shortened to killer app) is any computer program that is so necessary or desirable that it proves the core value of some larger technology, such as… a software platform...[1] In other words, consumers would buy the (usually expensive) hardware just to run that application. A killer app can substantially increase sales of the platform on which it runs.[2][3]

So we just need to find something that requires the unique properties of blockchains and dapps, and it needs to solve the underlying problem that drives consumer adoption more effectively than on other platforms. Examples of this were Internet Explorer facilitating Windows purchases, and Email facilitating personal computer purchases.

About dapps

Properties

1. They allow for trust-minimized computations.
2. They are tightly coupled with a monetary system.
3. They can be censorship-resistant (platform dependent).

Dapps are sometimes described as enabling permissionless innovation but this lends more to the lack of regulation around cryptocurrencies and dapps in general than to any of its existing properties.

The DAO was capitalizing on #1, trust-minimization, to allocate money fairly based on shareholder preference. The “open finance” narrative is capitalizing on #2, the coupling with a monetary system, to create financial tools. This article is going to focus on #3, censorship resistance.

Performance metrics

.

The performance metrics of dapps on Ethereum are startlingly inefficient compared to centralized services. There are no performance metrics I know of where dapps out-compete centralized alternatives. This is to say that dapps are unlikely to compete with web services as a general computing and data storage platform. Worse still is that any technology improvements will apply to AWS/BerkleyDB in the same way that they apply to dapps.

Users will typically choose whatever solution solves their underlying problem. Unfortunately those problems are typically speed and cost, which decentralized systems do not excel at. This is to say that there is not much sense in dapps trying to compete with existing web services without a really, really good business reason. Instead, we can find a niche for dapps by leveraging their properties to solve specific problems better than centralized services. Fortunately, censorship-resistance is something that dapps can be great at, and web services are weak at.

What is our threat model for censorship?

Governments

This is the most obvious case. Anything service which may violate codified laws, anything against the interests of powerful political or business groups, anything against the interests of government, etc is at risk. This requires a very sophisticated kind of censorship-resistance that is tactfully decentralized and operates within the bounds of the law, or merely something beyond the reach of control by anyone. Think Napster, Wikileaks, BitTorrent, Backpage.

Platform owners

Typically platforms exert censorship pre-emptive of government pressure. It’s why Craigslist shut down their personals section; why Twitter is purging bots; why Shapeshift is requiring KYC; and why Facebook/YouTube is removing content that could be considered objectionable. Platforms will also remove content not conducive to their growth, which is why platforms will frequently remove nudity and allow users to report harassment. If the censorship were not happening because of government pressure, then an architectural change is not needed. The answer would just be to run the service on another platform with more friendly owners.

In this article I focus on censorship-resistance from governments because its the only case that requires a new kind of platform. There are also known business models which have been suppressed by government.

How governments exert censorship

The service is legal

Intimidation by government with the threat of federal charges that could land the owners in prison for decades. If they do not comply, like Backpage or Wikileaks, then they are often cut off from banks and credit processing companies using the same method of intimidation. Personal and company assets can be frozen under civil and criminal asset forfeiture without the owners needing to be convicted of a crime.

Their homes or offices may be raided. Government can pulls strings to have the mainstream media write about you in ways that is less-than-flattering, with the intent of biasing the public from which a jury will be chosen for your trial. The probability of being charged with an unrelated crime at a time is unexpectedly high (e.g. Julian Assange, Cody Wilson). It goes on. See the history of the pirate bay to get a feel for this.

The service is illegal

Immediate criminal asset forfeiture of personal and company assets and arrest of the owners. If you live abroad, like Kim Dotcom, you will be extradited.

Politics and legal games

When all other routes fail, a loosely related topic is heavily politicized and used to pass a new law. Out of self-preservation, platforms will shut down any services that could put them at risk. This is arguably the case with FOSTA-SESTA where platforms for sex work were targeted under the guise of sex trafficking.

Government intimidation is extremely effective, so much that platforms will censor preemptively on advice from their lawyers. The incentives of platform censorship are to censor liberally. Censoring too little could put the site operators at risk of prosecution, censoring too much is just dealing with user complaints. It’s an easy decision.

Censorship-resistance in the real world

How censorship-resistant are clearnet web services?

When you visit a website in your browser, your computer asks a DNS resolver finds the IP address associated with that domain name. With this IP address you contact the website directly. IP addresses are assigned by an Internet Service Provider who keeps records of their customers. In the case a government wants to censor a website, they go to the respective ISP and ask for the customer information related to the IP address. Law enforcement can use this information to track down the owners of the servers, and take physical control of the servers.

The lack of censorship-resistance with clearnet web services is so severe that your perception of the prevalence of censorship is tainted by survivorship bias. Clearnet sites are so vulnerable to censorship that few people even attempt to host censor-prone content, because government have made examples of others in a very public way.

The vast majority of sites which have been censored died a quick death, never saw the light again, and left few traces of their brief existence. The ones that survived are hosted by dedicated activists living in more friendly jurisdictions, or merely platforms that hosted other untargeted content.

How censorship-resistant are Tor hidden services?

The most advanced kind of censorship-resistance that exists with web services is with a Tor hidden service. Services are accessed by their onion addresses, such as facebookcorewwwi.onion. Tor is a proxy overlay network, or a communication protocol on top of the internet. When you request a resource from a Tor hidden service, that request is routed through several computers who never know the full details of who you are, the content of your message, and who you are talking to simultaneously. In that way, nobody end-user has direct knowledge of the IP address of the website they are talking to.

Tor hidden services survive by obfuscating the true location of the server. The Tor network does not provide perfect privacy and this anonymity can be broken. Once the IP address of the hidden service is found, the servers can be monitored to identify the administrators. Historically, identifying the location of a Tor hidden service has often required a level of sophistication usually only accessible to governments. This is to say good censorship-resistance exists only for low-value targets.

Darknet markets are the most famous examples of hidden services which are also high-value government targets. The markets themselves do not survive for very long and very few make it to the three-year mark.

The main issue with running a hidden service prone to censorship is the danger it poses to the administrator if they are deanonymized. Ross Ulbricht, the first darknet market administrator, was sentenced to two life sentences plus forty years without the possibility of parole. During this investigation and trial, there were multiple serious violations of the 4th and 8th amendments. Multiple federal agents in the case were convicted of crimes related to their work on the case (source, source, source). Seemingly, none of it mattered as Ulbricht’s conviction was never overturned. This is to say that governments will readily violate their own constitutions and laws to censor high-value targets and rarely face penalties.

How censorship-resistant are Ethereum dapps?

It is impossible to remove objectionable content without removing the ability for users to perform trust-minimized validation of the blockchain’s integrity. There are currently about 15,000 copies of the Ethereum blockchain. It’s fair to say that Ethereum provides better censorship-resistance than Tor because the data is much more widely distributed. Hidden services are typically only distributed to the extent that it diminishes the effect of distributed denial of service attacks.

Dapps also provide better privacy for accessing content since users running a full node download the entire state, not revealing which information they are accessing. The privacy implications are when sending transactions because the first node to propagate a transaction is likely where it originated from. If Ethereum implements a privacy measure like Bitcoin’s Dandelion BIP, sending transactions to censorship-prone dapps will be much safer for end-users.

Ethereum has about 20 mining groups with greater than 0.5% total hashrate. This is the weak point in blockchain censorship because if miners won’t accept transactions to certain smart contracts, nobody can update the dapp service. So far the odds are in the dapps’ favor because only one group needs to include your transaction in a block for it to become part of the global state. For context, Tor has about 826 exit routers which can exert censorship on that network if controlled. It’s important that over time that block production becomes more distributed, because groups that small are not difficult for governments to censor.

On the other end, Ethereum’s community has censored a dapp with the DAO. The DAO was a buggy smart contract that was also a custodian to 14% of the total Ether supply at the time. Unfortunately, the contract was quickly hacked after raising the ICO. The community decided to change the global state by altering the blockchain, causing a hard fork. It appears that the biggest risk to dapp censorship on a censorship-resistant platform right now is the actual community. In this sense, Ethereum is the right technology but may have the wrong community. Ethereum Classic, the minority fork of Ethereum which does respect dapp immutability, may be a better choice for censorship-prone dapps.

Lastly, Ethereum does not have on-chain privacy. Like Bitcoin, all the transaction details are public and pseudonymous. This is problematic because it puts anyone interacting with these censorship-prone dapps at risk. Blockchain analysis can link addresses to identities. Obfuscation through optional mixing does not provide strong privacy guarantees and moving large amounts of tokens over a public network is almost impossible. There have been many arrests through blockchain analysis, but none known through the use of cryptocurrencies with strong, mandatory on-chain privacy like Monero.

To date, no blockchain has been censored. There is no legal basis for this and even if there was, it would be extremely difficult to do so because thousands of nodes exist in every jurisdiction, and sometimes even in space. This is despite some blockchains hosting data that would otherwise be subject to takedown notices. We have enough information to say that this is a better platform than Tor for censorship-prone services, and the issues beyond this relate to on-chain privacy, network privacy, decentralizing mining, and preserving the concept of immutability.

What kind of censored services make sense as dapps?

The case for dapp markets

The closest analogy to dapp markets are darknet markets, run as Tor hidden services. The worldwide revenue of darknet markets was estimated to be $100M–$200M from 2013–2015. There is clearly a market for this.

Darknet markets face the most adversarial environment known: Multiple government agencies from multiple jurisdictions will coordinate to take down these services and willingly violate their own laws in the process (e.g. Operation Onymous and Operation Bayonet). That they take down darknet markets successfully validates that a more decentralized platform is necessary. This also suggests that smart contract platforms that prioritize censorship-resistance may have an economic moat.

The major downside is that without strong on-chain privacy and mandatory privacy, the native cryptocurrency is unsafe to use. But it doesn’t stop the market from being implemented and using a separate currency, or on/off-chain mixers from being developed to mitigate this.

The case for dapp gambling

There’s definitely money to be made from online gambling. Especially on a platform that is censorship-resistant, provides trust-minimized computing, and provides a source of randomness (new block hashes). Online gambling is has been one of the most popular uses of blockchain technology. In Ethereum it’s a recognized major category.

It’s not clear what the minimum level of decentralization needs to be for dapp gambling to be viable. Governments have typically not paid much attention to this so far despite it being illegal or regulated in most jurisdictions. Currently every cryptocurrency supports dapp gambling to the extent of their programming without censorship. If governments do clamp down on blockchain gambling, only platforms sufficiently censorship-resistant will have an economic moat.

The case for dapp classifieds

The closest analogy would be sex work classifieds. Craigslist was estimated to make about 30% of their revenue from adult ads in 2010. Their total revenues were $122M in 2015. Backpage once made 99% of their revenues from adult classifieds from 2013–2015, and their total revenue was $135M in 2014.

FOSTA-SESTA makes it a crime for websites to facilitate sex trafficking by hosting related user-generated content. There is now extreme legal risk for any platform to host user-generated content related to consensual sex work that isn’t trafficking. This was arguably the intent of FOSTA-SESTA and so sex work classifieds can no longer exist on centralized platforms.

The uncertainty about a dapp platform is that it hasn’t been tried as a hidden service yet. My impression is that nobody tech savvy enough has tried to solve this problem in a serious manner which is why there are no Tor classifieds. Regardless, it’s likely that if someone did implement this successfully as a hidden service and it captured the market, it would become a high-value target like darknet markets. Sex trafficking is a sensitive political issue much like drug trafficking, so we can infer that creating hidden service classifieds would be just as risky as creating a darknet market.

What censored services don’t make sense for dapps yet?

Anything which requires dealing with large media files or content that must be updated very frequently by the same entity. Transaction fees add up, and those fees need to be distributed among users of the actual service to be economical. Torrents, image galleries, video, etc. are likely not cost effective given that the cost of uploading 1 GB of data to Ethreum is about $460,000. However, small compressed images are possible if they add business value, and as technology improves this may become more cost effective for media that is just a few megabytes.

Why use dapps at all when we can use dedicated products for these services?

There are products such as OpenBazaar, Syscoin, Particl that all seek to provide decentralized marketplaces. So why use a dapp platform when we can use those?

General dapp platform provides greater privacy

If darknet markets were to gain a footing on these specialized platforms, it would likely be their only major use-case. If you hosted a Particl node and its major use case was for darknet markets, it could be inferred that you are a user, vendor, or administrator with non-negligible probability. The same inference cannot be made with a general smart contract platform because they can be used for much broader applications. The same argument applies to other censored services.

For example, 97% of Tor traffic is used for the clearnet. In fact, the most popular service on Tor is Facebook. Tor also has more than 2 million daily active users. Tor is used by journalists, criminals, political dissidents, privacy activists, and apparently a lot of regular people too. The many uses of Tor make it difficult to discern information about someone if you know they are using the software.

Dapp platforms allow for multiple implementations and low switching costs

If you don’t like one dapp implementation, use another without downloading a new chain. It may be that fully autonomous markets and administered markets are both successful. Or it may be that one market is inefficient and expensive but another market is designed very carefully to keep the costs low (e.g. uploading uncompressed vs compressed data). Maybe one market keeps html, javascript, and css on a smart contract for a really great front-end.

Individual dapps are easier to audit than entire services

Privacy and safety are perhaps the top priorities for censored services. Open source is a minimum, but the amount of code which could materially impact privacy is extremely large for specialized products. Dapps have much less code to audit than entire software products. It would be easier for services which need a decentralized platform to share one. That way audits can be limited to the business logic of dapps.

Are there better alternatives for hosting censorship-prone services than smart contract platforms?

Dapp platforms are scalable

Freenet and Bitmessage are both decentralized data stores for static data. This is very similar to a smart contract platforms, but without contracts, virtual machines and such that every smart contract has arbitrary write access by the owner and read-only access by everyone else authorized to see the data. If Ethereum has smart contracts, then Freenet + Bitcoin or Bitmessage + Bitcoin have dumb contracts.

For that reason I say that Freenet + Bitcoin or Bitmessage + Bitcoin have limited scalability. Business logic needs to be implemented manually by each person and the communication overhead is surely very high unless buyers and vendors are talking over instant messenger. It’s definitely possible to implement censored services on these platforms, but the user experience is a pain and these platforms feel awkward when used like this compared to the more familiar Tor hidden services.

Dapp platforms are efficient

It turns out that smart contract platforms are the logical conclusion of building an online service around a censorship-resistant data store. That is, if we start with a censorship-resistant data store and require it to execute business logic in a decentralized manner, we get a smart contract platform (i.e. contracts + virtual machines + blockchains). This suggests that smart contract platforms as we know them are already efficient in their high-level design. Blockchains are required to serialize the execution order of transactions. If we find a better solution, it will likely be an even better smart contract platform as opposed to a different kind of platform altogether.

How would dapps work as a web-like service?

Backend

The dapp itself would assume the role of a server in the client-server model. Read-only requests to this backend would come in the form of remote procedure calls. This is analogous to http GET requests. Write requests would come in the form of transactions to the network. This is analogous to http POST requests. Authentication would be done through control of addresses which is what dapps already do.

Although smart contracts code is immutable, software design techniques can leverage the mutable data of a contract to proxy the function calls to other smart contracts so that the service may be updated in a cost-effective manner. There could be a kill switch to prevent further changes when the protocol is mature enough.

Frontend

The user interface would be strictly separate from the dapp server. The interface itself would start off as a command line interface but would ultimately be implemented through a web browser. Metamask had the right idea by leveraging the browser interface for dapps, but for censorship-prone dapps end-users should be running their own full nodes to preserve their privacy.

The goal is that users don’t even realize they’re interacting with a blockchain. Dapps could present their user interface through a separate contract that contains html, javascript, and css. In the future there may be separate contracts which independently implement the user interface and users can pick and choose. The only requirements to use a dapp securely would be an online, synced node; a browser; and a private key.

Conclusion

Dapps are too inefficient to compete with web services as a general platform but can work when people decide to leverage their major advantages, such as censorship-resistance. Web services that are heavily prone to censorship are quickly taken down or migrate to Tor hidden services. Tor hidden services fail to protect high-value targets because they are not censorship-resistant but rather hidden, and hiding is not enough to prevent censorship. A platform which provides censorship-resistance is needed for censorship-prone services. Smart contract platforms which prioritize censorship-resistance have an economic moat for hosting censorship-prone services and this need is satisfied better than with specialized platforms.

Dapps can successfully compete with the censored web was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

As part of my research on the minimum necessary levels of decentralization for censorship-prone services to function I went digging through the laws which allow our internet to exist in its current form. Democratic governments will typically act within the bounds of their own legal system when it comes to censorship so it makes sense to understand the legal aspects of hosting content that could violate laws.

Laws that protect internet service providers

The basis of internet providers being able to host the content of their users without being sued or violating laws come down to safe harbors. Safe harbor laws are provisions or regulations that state certain actions do not violate certain rules.

• 1996 Communications Decency Act (CDA). It gave a safe harbor for internet service providers from obscene and objectionable content. Section 230 explicitly states “No provider or user of an interactive computer service shall be treated as the publisher or speaker of any information provided by another information content provider.” The interpretation is that internet service providers are not to be considered publishers, and thus not liable for content that their users post.
• 1998 Online Copyright Infringement Liability Limitation Act (OCILLA). This was considered the Safe Harbor of the DMCA, an act meant to adapt copyright law to the digital age. It exempted internet intermediaries from copyright infringement of their users provided that they follow certain rules.
• 2018 Stop Enabling Sex Traffickers Act (SESTA) and Allow States and Victims to Fight Online Sex Trafficking Act (FOSTA). FOSTA-SESTA amended section 230 of the CDA to remove safe harbor provisions for user-generated content related to sex trafficking.
• Case law. Too many to list, but the case law regarding the CDA is a good start. They each create precedents which can be used to settle future cases.

Lessons learned from the file sharing wars

File sharing is perhaps the only technological precedent which closely mirrors the needs of cryptocurrencies. Both of these technologies faced censorship and the way to circumvent this was with decentralization.

John Backus has written extensively on this. Focusing on the history of file sharing is not the aim of my research but there are some interesting takeaways from this. For example, it wasn’t the most decentralized protocols that won. Excessive decentralization created horrible user experiences and it was only the ones which tactfully decentralized and only in the areas necessary. Other takeaways:

• If infringing or illicit content is centralized, takedown requests can be issued to prevent access to those services.
• Closed-source software can leave the owners open to secondary liability if they do not modify the code in ways that discourages infringing uses, such as search filters for p2p file sharing. Open source code does not have this problem because the code can be modified by anyone.
• Having substantial legal uses increases the legal standing in the event that there are illicit uses.
• Solicit customers on the basis of illegal uses can be a liability.
• Profiting from the illegal actions even if you don’t engage in it can be a liability for centralized platforms.
• Decentralization is an effective legal tactic.

Conclusion

The concept of decentralizing everything is an unnecessary and costly approach. There is no need to decentralize things which are legal. Also, decentralization is expensive and should be used sparingly. It’s created a terrible user experience which is the basis of how users choose products. The focus should be to decentralize only what is necessary. Generally internet service providers are not liable for user-generated content because they are not considered publishers by law.

tldr; A smart contract platform is the minimum viable product for an online service which requires a highly distributed data store. It is technologically superior to Tor hidden services in terms of censorship-resistance.

Introduction

Nobody I’ve heard of thinks of smart contract platforms as extremely efficient censorship-resistant online services. Here I am going to demonstrate that they are by showing the minimum requirements of a service which provides highly distributed data storage. Smart contract platforms improve significantly on Tor hidden services and the best way to see how is to design a better system and see what comes out.

Background on censorship-resistant services

Tor hidden services with Bitcoin were the first way to offer a service in a censorship-resistant manner that scaled. In this setup, the administrator ran a database and a server as part of the hidden service. They both provided data storage and a means of executing business logic. Bitcoin was obviously the means of payment.

The weakness with this setup was that there was no real censorship-resistance in terms of data storage or executing business logic. Rather, the hidden nature of the service meant it could operate so long as it was not discovered. Once it was discovered, there was no way to protect the service from being taken down. So let’s try to improve on this by adding censorship-resistance to these core features.

Minimum requirements to offer online services, censored or not

1. Data storage
2. A way to implement business logic
3. Payments

Conventionally, data stores are provided by databases and business logic is implemented by servers. With Bitcoin we’ve solved the payments problem, so let’s figure out how we can build a system whose data and servers can’t be taken down.

What if we used a censorship-resistant means of data storage?

This would be like using a decentralized data store such as Freenet and Bitmessage, or a distributed blockchain. These are censorship-resistant because the former two are decentralized and the latter is immutable. All that we require right now is that the data is highly distributed, and everyone has a copy. The problem with using a blockchain in this case is that it requires a consensus mechanism which is a lot of overhead, so let’s avoid it unless we need it. The main issue with these options is that they only contain static content. This is to say that there’s no way to implement the actual business logic when end-users interact with these web pages. For now, we have the censorship-resistant data storage part solved. Now we just need to figure out how to execute the business logic.

How can we implement business logic on a distributed data store?

First, let’s consider how updates to data are made. Unlike a centralized data store where only the owner needs to make an update to one copy and shares it with others, this decentralized data store is distributed throughout the network and it all needs to be updated in real time by the people who possess those copies of that data.

For trust-minimization, we want to formally specify the kinds of ways service data can be altered with access rights. We can do this by having a separate static document describe how the service is to be used and by whom, which we can consider a contract. An abstract programming interface (API) in the contract can rigorously specify what instructions can be executed and how they are executed.

End-users invoke a public facing API function directly and they authenticate with a public/private key. Other users can repeat these instructions to verify that the change was legal. Since executing these changes manually is error-prone and doesn’t scale, a virtual machine can execute these instructions on behalf of the end-user.

But this leaves open one more problem — how do we know the right order to execute instructions? What if two conflicting instructions are issued at the same time? We can use a relative time stamping service like a blockchain. With a token and consensus mechanism, control of the blockchains can be decentralized, which is necessary given the critical role it plays in this system.

How to offer censorship-resistant online services

1. Blockchain for immutable data storage and transaction serialization.
2. A smart contract to specify the operations that can be performed on the service data and by whom, and a virtual machine to execute business logic in transactions.
3. Native token for payments and transaction fees.

This is just a smart contract platform. We tried to design a service which would offer censorship-resistance at the data storage layer and somehow we ended up with something familiar that we never thought of as having incredible security properties.

Smart contract platforms are highly efficient censorship-resistant services

It turns out that if you have a highly distributed data store for an online service:

• A contract is necessary for specifying what changes can be made, who is authorized to make those changes, and how to make those changes.
• A virtual machine is necessary to execute those instructions.
• A relative time stamping service (blockchain) is necessary to order transactions for the virtual machine.
• A consensus mechanism is necessary to decentralize control of the blockchain and keep the copies in sync.
• A token is necessary to reward block producers for securing the system.

Conclusion

Smart contract platforms are the logical result of using a highly distributed data store to implement an online service. It’s efficient because it includes only the minimum requirements without the burden of unnecessary features. The only reasonable technology improvement would be mandatory, on-chain privacy.

Smart contract platforms are superior to Tor hidden services regarding censorship-resistance. The weakest point of hidden services is that if the servers are discovered they can be taken down. Smart contract platforms, in contrast, can’t be taken down.

Introduction

Dapps offer the same data storage and computations that can be performed using web services with centralized databases. Here I compare performance metrics and the cost of services between the two. Specifically I compare write speed, write costs, data storage costs, and sync speed. I use Amazon web services (AWS) as the benchmark for efficient web services and BerkleyDB for a database that is accessible to anyone today. I use Ethereum since it is the most popular dapp platform.

Write speed:

How long does it take to write to the system such that someone else can read it? For Ethereum this means how long does it take for transactions to confirm. The highest transaction volume Ethereum has ever had was on January 4th 2018 with 1.35M confirmed transactions. That’s 15.6 transactions per second. For comparison, I use some performance metrics of BerkelyDB database. For transactional writes to disk, the slowest system allows 34,888 writes per second. A web service will typically use a centralized database like BerkleyDB. Transactional write latency is at least 2.2 thousand times slower write speeds through Ethereum than with a centralized database.

Write costs:

Every update on the Ethereum chain will require a transaction fee and a gas fee. On September 1st 2018, the price for the median transaction fee is $0.06, and the average is $0.21. Actions which would trigger a fee would be sending a message, making a purchase, uploading data, editing data. Amazon API gateway offers 1 million API calls for $4.25 per month. The actual cost of changing internal data on a website server has no direct costs. Ethereum has at least 14 thousand times more expensive write costs.

Storage costs:

In the Yellow paper, the price of storing a 256 bit word is 20k gas. The gas price is about 2.5 Gwei on September 1st 2018. So storage of one KB is 0.0016 ETH (there are 32 * 256 bits = 1 KB). Storage of one GB is 1600 ETH. As of the same date the price of ETH is $288. So the price of storing 1 GB is $460,800. For Amazon’s S3 pricing their most expensive option is $0.023 per GB of storage. Ethereum’s has at least 20 million times more expensive data storage than contemporary web services.

Sync speed:

The average block is about 22 KB as of September 1st 2018. On Geth I downloaded 119 blocks in 7 minutes on a client that has only been out of sync for a few months. So that’s approximately 2.618 MB of data in 124 seconds, or 6.2 KB per second. In my experience, this is not an overly slow sync speed. In fact, with the chain data of about 100MB, this would suggest that I could sync with Ethreum’s entire history in less than 4 hours, which is very fast. In contrast, the global internet connection speed was about 5.6 MB / second in 2015. So syncing blockchain data on Ethereum is conservatively about 903 times slower bandwidth than contemporary web architecture.

Conclusion:

To be clear this is a conservative estimation of the inefficiency of dapps. I have used pessimistic numbers for AWS/BerkleyDB and optimistic figures for Ethereum. The significance of this is that Ethereum was never realistically a competitive general computing platform and this should have been obvious from the very beginning. Any future technology improvements will apply to web services in the same way that they will apply to blockchains.

Get Best Software Deals Directly In Your Inbox

How inefficient are dapps? was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Among BCash’s finer engineering decisions was to keep the same proof of work algorithm as the parent project. Due to this oversight, the BCash network is susceptible to attacks from Bitcoin’s hashpower, which as of August, 2018 is 10 times larger than BCash’s hashpower. BCash is already within striking distance of individual Bitcoin pools, and if it drops much further, it won’t be very costly to attack either. As hashpower follows price, any change in BCash’s price will have profound security implications. The secondary effects from successful long block reorgs will be people accurately calculating the number of confirmations necessary to ensure these attacks can not happen, and they will not favor usability. Several dozen confirmations may be the standard for BCash’s future.

BCash is already falling further and further behind Bitcoin

The original differentiator between Bitcoin and BCash were the scaling solutions each were pursuing. Bitcoin is pursuing second-layer networks like Lightning and BCash is pursuing larger blocks at the expense of decentralization. There are many differences between these projects as of one year post fork, but for the purposes of how the future might unfold:

• Bitcoin retained the vast majority of contributors over BCash. I personally do not know of any developer converts.
• Lightning has made significant progress. Several implementations exist on main-net. Over just a few months, there are now 100 BTC, 3000 nodes, and 11k channels.
• Bitcoin core has 3000 more commits and 100 more contributors than Bitcoin ABC.
• Bitcoin isn’t having a transaction fee crisis like what big blockers predicted. The median transaction fee is $0.15 for Bitcoin.
• The number of transactions on BCash is minuscule. In fact, Bitcoin blocks are more than 10 times larger than BCash blocks, and Bitcoin blocks aren’t even full.

All of these things I would describe as severely discouraging for BCash’s progress and likelihood of somehow changing the course of the trend. BCash’s main advantage over Bitcoin, low on-chain transaction fees, are ironically far outdone by lightning’s fees, being on the order of one Satoshi per transaction. I am skeptical that lower on-chain transaction fees will provide much of a competitive advantage on its own.

What happens when BCash falls far enough behind

If BCash’s price relative to Bitcoin drops too low, smaller Bitcoin mining pools can execute intermittent 51% attacks on the BCash network. They don’t need to be ideologically motivated to do so, as an attack like this can defraud an exchange. It can be immensely profitable.

If successful attacks cause a market panic and the price drops further, attacks can become even more frequent, but this is not necessary to cause lasting damage. The merchants accepting BCash are going to lose money and subsequently confidence in the six confirmation heuristic. Instead they will perform accurate calculations on the number of confirmations required to prevent a reorganization taking into account Bitcoin’s hashpower.

What might be a safe number of confirmations? Conservatively, whatever hashpower goes into Bitcoin’s 6 confirmation rule. If BCash has 10% the hashpower of Bitcoin, then that would mean approximately 60 BCash confirmations. Or 10 hours. Liberally, whatever the longest block re-org is plus one, for the brave. Anybody transacting with non-trivial amounts of money will need to be especially cautious regarding BCash.

What if BCash changes their proof-of-work algorithm?

This is the only sane and rational countermeasure to mitigate the problem of being the non-dominant PoW algorithm cryptocurrency. If they switch to some alternative they start over entirely with their mining infrastructure and their claims of being the “original Bitcoin” diminish even further. It is worth mentioning that switching a PoW algorithm is a major design decision that requires a kind of specialized knowledge and skill the BCash community is less-than-likely to have. If they make a mistake in design, coding, or testing, more exploits and attacks may follow.

Since this was an entirely avoidable problem, waiting until attacks are carried out will diminish confidence in the maintainers / leadership of BCash as responsible and competent. Even if the community does have the foresight to change the PoW algorithm ahead of time, it may fundamentally alter the believably of BCash’s claims as the true Bitcoin.

Conclusion

BCash keeping the same PoW algorithm as Bitcoin is a questionable decision given that Bitcoin’s hashpower can attack the BCash network with relative ease and low risk. It is at the point that BCash can realistically be attacked by several Bitcoin mining pools. Since hashpower trails price, BCash must keep its price from falling too low relative to Bitcoin unless everyone using it is willing to wait a few dozen confirmations per transaction just to be safe.