The Decentralized Internet: Rethinking Trust
The Decentralized Internet: Rethinking Trust
Last month we posted an article raising some concerns about the increasing centralization of the Internet. Our intent was to highlight some of the risks of increased centralization and contrast the current situation with the original Internet architecture. We said relatively little about possible paths to re-decentralize, so this week we have started to explore some options in that direction. This is by no means a fully baked proposal, but rather an exploration of some of the technologies that might play a role in taking the Internet back to its decentralized roots.
Calls to decentralize the Internet have a compelling ring to them. As we noted previously, there are failure risks in having so much dependency on any given (logically) centralized platform, even when those platforms take advantage of the state-of-the-art in scalable and highly available distributed algorithms. But the issue is bigger than the technical question of how resilient the algorithms are. There is a broader issue of trust, and as we explore in this article, blockchains popularized by cryptocurrencies provide a path to decentralizing trust.
Without giving it much thought, users have invested enormous trust in the applications they use, notably the social media and search giants who not only store their personal photos and videos, but also manage their identity by providing Single Sign On (SSO) for other web applications. This is troubling to many people, which is another factor sparking interest in decentralized platforms: creating systems for which users do not have to trust a third-party.
Such platforms are now being built on top of blockchains like Bitcoin and Ethereum, precisely because blockchains are not controlled by a single organization. It’s easy to be distracted by all the hype, but a blockchain is essentially a decentralized log (ledger) that anyone can write a “fact” to, and later prove to the world that that fact was recorded. This enables smart contracts and some exciting new applications, such as Decentralized Finance (DeFi), but it also provides an opportunity to rethink how we manage more familiar on-line assets, like our identity, our email, our photographs and videos, and so on.
This vision of re-decentralizing the Internet so we don’t place so much trust in third-parties is a major pivot from today’s provider-centric world, and it takes a full software stack to make it a reality. For example, the Stacks Foundation supports an open source software platform to enable decentralized Internet applications. The Dfinity Foundation supports a similar ecosystem.
These new software stacks have multiple layers, starting with a blockchain at the bottom, followed by a smart contract layer that provides a high-level programming environment for specifying transactions. Both of these layers are interesting systems in their own right, but they also provide a foundation for rethinking the trust we currently place in web applications. A key component of trust is identity: you need to identify an actor before you can decide what you trust them to do. Blockchains provide a starting point to build an identity service that is administratively decentralized, with no distinct service operator, and no single principal to control who can create an identity and who cannot. In the Stacks architecture, for example, the Blockchain Naming System (BNS), builds such a service by implementing a replicated identity database log on top of a public blockchain. (BNS currently uses the Stacks blockchain, which is in turn anchored in Bitcoin, but that’s an implementation detail we’ll gloss over in this post.) The key is that when this database log is replayed, it produces the same view of all identities in the system as every other node reading the same view of the underlying blockchain. Moreover, anyone can register an identity by (indirectly) appending to the blockchain.
Instead of requiring users to place trust in a distinct set of identity providers, users are instead asked to trust that the majority of the decision-making nodes in the blockchain (miners) will preserve the order of writes (transactions). One of the central properties of blockchains is that they make it practically impossible to rewrite history. Under normal operation, miners stand to earn the most cryptocurrency by participating honestly.This allows the identity database log to remain secure against tampering without a distinct service operator. An adversary who wishes to tamper with the log would need to compete against the majority of miners to produce an alternative transaction history in the underlying blockchain–a task that is practically impossible given the proof-of-work (or proof-of-stake) requirements to write entries into the blockchain.
A protocol for reading and appending to the identity database log operates at a logical layer above the blockchain. Blockchain transactions are data frames for identity database log entries. A client appends to the log by sending a blockchain transaction that embeds the log entry, and a client reads the log back by extracting the log entries from blockchain transactions in the blockchain-given order. This makes it possible to implement the database log “on top” of any blockchain. (Keep in mind that by focusing on the naming service, I’m ignoring a lot of details about the rest of the stack, which Jude Nelson of the Stack Foundation summarized succinctly as: “BNS names are first-class digital assets… in fact, they’re NFTs.”)
Identities are distinguished by user-chosen names, which must be globally unique and are assigned on a first-come-first-served basis. Each name is then bound to a public key and a pointer to some “off-chain” state, which could take many different forms. In BNS, it can contain entire “subdomains” of names; it could also include links to a user’s identity in other spaces such as GitHub or social media. Names are registered in a two-step process: one to bind the client’s public key to the salted hash of the name, and one to reveal the name itself. The two-step process is necessary to prevent front-running—only the client that signed the name hash may reveal the name, and only the client that calculated the salted hash can reveal the pre-image. Once a name is registered, only the owner of the name’s private key can transfer or revoke the name, or update its off-chain state.
This is how a decentralized Internet might handle identity, but that’s just a start. For example, BNS uses a decentralized Key/Value Store (called Gaia) to bind a name to the associated off-chain state. This makes sense because, if you were to instead trust a cloud-provider’s centralized K/V store, you would have just replaced one centralized service with another. The end goal of the decentralized Internet vision is a new, fully decentralized software stack built around three high-level design principles:
Implement functionality client-side (e.g., Stacks.js in Stacks) to empower users over service providers (who still provide commodity storage options). This decouples business logic (that monetizes data) from storage logic (that persists data).
Design the system so users are able to select from multiple back-end platform choices, such as cloud storage providers. This avoids provider lock-in and the associated failure modes.
Distinguish between on-chain and off-chain data. The former establishes necessary proof-of-transaction using the blockchain, and the latter provides for scale and performance using, as in our example, a decentralized K/V store.
The ultimate success of an approach like this depends on users trusting the new decentralized platform, which is why it is important the foundational parts like the naming system are (and remain) open source. It also depends on how easy it is for users to opt-in, which is where the pull of a SSO remains attractive. Replicating that experience for other decentralized applications is technically doable—with a self-sovereign identity service serving as the cornerstone—but it’s hard to predict whether that is enough to overcome the entrenched network effects and inertia behind the existing centralized platforms. All that’s clear at this point is that (1) blockchains provide a path to replacing centralized trust with decentralized trust, and (2) being true to decentralization requires a new mindset (and design principles) for how we build network systems.
It’s worth noting that keybase provides a decentralized (and non-blockchain) solution to the problem of binding keys to identities, which is another component of trust. In other news this week, the decentralized Internet joined up with 5G and IoT to not only win buzzword bingo but to raise $111M of funding. And there was a spectacular warning that DeFi can be hacked. More prosaically, we’re putting the finishing touches on a new edition of our SDN book and also preparing a Japanese translation. SD-RAN and Network Verification are two of the topics we’re adding. If there are things that should be in the book, please let us know or open a GitHub issue.