Blockchain as a Database (Part 1)

Rollup != Bridge?

There has been a substantial discussion on whether a validating bridge defines the rollup, or put another way:

rollup ==? bridge.

We should step back and look at the problem from first principles.

• What is a blockchain?

• How do we bridge assets from one database to another database?

Both topics will be covered over the course of two blog posts and then we can re-visit the above statement to evaluate whether it is true or not.

What Is a Blockchain?

A blockchain serves a single purpose: allow another party to compute a copy of the same database as everyone else and have confidence that the database is valid

At the heart of a blockchain is a single database and it records:

• Account balances,

• Smart contract code,

• Program state.

In nearly all systems, the blockchain defines the total ordering of all historical transactions.

At least, for a very long time, that is what we have been taught.

There is no reason it has to be a list of transactions. It may very well be a list of state diffs alongside a zero knowledge proof!

So — what is a blockchain?

Blockchain. An ordered list of data “blobs” that is used to compute a copy of the database according to a fixed set of rules.

Let us re-iterate the ONLY purpose for a blockchain:

• Allow a user to compute a copy of the database.

The only job is to enable replication of a single database.

Boring, right?

Reach Agreement About the Blockchain

One of the harder puzzles:

• How can the community reach worldwide agreement and recognise what is indeed the one true blockchain.

If we can all agree upon the same blockchain, then we can all compute a copy of the same database!

This lead’s to the idea of a consensus protocol and the goal is simple:

• Enable a group of parties, potentially pseudonymous and mutually distrustful of each other, to reach agreement on a single decision.

In the context of a blockchain, the consensus protocol enables one party to propose a block of data ‘blobs’, append it to the tip of a chain of blocks and for all other parties to agree that it is indeed the new tip.

This is why it is called a blockchain as we are all reaching agreement on a chain of blocks!

There are many technical challenges to consider when designing and implementing a consensus protocol:

• Can we enable open membership so anyone can participate?

• What is the communication complexity for parties to reach agreement?

• Is it possible to add financial incentives for people to step up and participate?

We will not focus on these challenge although it is a really fun and complex topic to explore. The only takeaway is that we simply need a consensus protocol to exist and that it can enable all parties to reach agreement on new blocks of data.

New Instantiation Of A Consensus Protocol

Over the years, certainly in the pursuit of layer-1 blockchains, the community has experimented with a vast configuration of consensus protocols:

• Nakamoto on Bitcoin

• Gasper on Ethereum (Gasper)

• Tendermint on Cosmos

• Snowman++ on Avalanche

In nearly all cases, the go-to-market plan is to launch a new consensus protocol that will agree on updates to the database. Furthermore, it is not just about deploying a consensus protocol, but all the surrounding infrastructure for it alongside the social aspect of enabling an honest majority of parties to participate in it.

It is a Hercule feat to accomplish.

This brings us to an interesting question:

• If I want to launch a blockchain, and ultimately a new database, do I really need to instantiate a new consensus protocol?

Remarkably, the answer is no!

Reuse an Existing Consensus Protocol

A blockchain can act as a public bulletin board that guarantees a consistent view to all parties

We need to consider a single abstract concept before diving further:

• Public bulletin board. Guarantees a consistent view of the data to all participants that want access to it.

It is a concept related to e-voting protocols. A public board allows all users to get access to the same protocol transcript. The users can take the transcript, execute it independently, and verify the protocol was run correctly. In the case of e-voting, it is to check that the voting protocol was run correctly and that all the votes were indeed counted as part of the tally.

How is this related to blockchains? Well, as long as:

• Anyone can get access to the data posted on the public bulletin board

Then, anyone can get access to the timestamped data and compute a copy of the single database. In practice, many layer-1 blockchains, certainly Bitcoin and Ethereum, make really good public bulletin boards. Additionally, they make it easy for anyone to write data blobs to the public bulletin board too!

Just roll up the data and post it to a blockchain system.

Reusing an existing blockchain system is called the rollup.

Rollup: All data is rolled up by the operator and posted to the respective blockchain.

The hard work of deciding the total ordering of data blobs and guaranteeing that anyone can access data is left to the existing blockchain system. It is not a new idea. In fact, it has been around for around 10 years. The rollup approach has gained popularity as a way to bootstrap a new database.

There are many examples:

• Coloredcoins

• MasterCoin / Omni

• Ordinals

• Arbitrum

• Optimism

• StarkEx

• ZkSync

• Polygon Hermez

• Scroll

All the above projects, alongside others, are trying to bootstrap a new database on top of Bitcoin or Ethereum.

In fact, due to the popularity of the approach, there is a project that will someday launch called Celestia. It is focused on building a platform that is dedicated to enabling rollup-like databases.

In all cases, we can still view rollups as blockchains:

• A batch of data blobs is periodically published,

• It is appended to the total ordering of all relevant data blobs.

The blocks may look different, it may even be a stream of data blobs, but the general idea sticks with an append-only data structure that eventually has a total (or causal) ordering.

In the end, whether we deploy a new consensus protocol or re-use an existing one, the goal is the same: bootstrap a single database.

Rules for Parsing Data Blobs

It is up to the community to step up and enforce the globally agreed rules rules, especially to fight back against the system’s operators.

Assuming that all parties can get access to the same data, the final challenge is for the parties to all agree upon the same set of rules (‘state transition function’) for parsing the data blobs and computing a copy of the database.

An example of parsing the data:

• Take a data blob,

• Parse it as a transaction,

• Check if the transaction is executable,

• Execute it on a specific virtual machine,

• Apply update to the database.

It leads to a unique problem for cryptocurrencies:

• We need worldwide consensus on the same set of rules for parsing the data.

There are two scenarios we need to evaluate when coordinating worldwide consensus for parsing the rules:

• Operational enforcement. The rules, agreed by all parties, is enforced 99.9% of the time by the software run by the parties.

• Governance of rules. There is a set process for all parties to propose and agree to a new set rules.

First and foremost, nearly all discussions link the security of a blockchain network to the day-to-day operational enforcement of the rules. It is an important conversation as it focuses on how the software, and all parties, are continuously enforcing the same set of rules to protect the database.

However — the ultimate backstop for protecting a blockchain network, especially when the operational enforcement breaks down — is the process for updating the rules. There must be a process to achieve social consensus from all participants on how to change the rules and when the new rules will be enforced.

Let’s explore the concepts of enforcement and governance in more detail.

Operational Enforcement

It is up to all of us to continuously enforce the rules and validate every proposed update to the database

The day-to-day operational enforcement is what makes a blockchain system for computing the database so exciting!

We simply need to agree on:

• Where to find the total ordering of data blobs

• A rule set for parsing the data blobs

And that is it. All participants have an opportunity to get the data blobs, enforce the rules, and only respect the database that follows the rules.

It doesn’t matter whether a participant is large, small, a proposer or an at-home node, everyone should have confidence about what the database’s content.

Going further, as long as all market participants enforce the same rules, and they can compute a copy of the same database, then we can allow the market to dictate what should be considered the one true blockchain.

Governance of Rules

All blockchain systems must be bootstrapped with a set of rules for how to parse the data and compute the database

Nearly all blockchain systems require a bootstrapping phase:

• Bitcoin core by Satoshi Nakamoto

• Yellow paper by Gavin Wood.

More often than not, a project is bootstrapped by a small group of developers who decide the rules, launches the blockchain, and then gives the software (alongside the rules) to a wider community.

The next step is the process for changing the rules.

There are good reasons why the rules should be changed over time such as to enable a software upgrade for a new feature or to fix known bugs. Any rule change requires agreement across a wide variety of participants, or put another way, social consensus.

There are two approaches for achieving consensus to change the rules:

• Rough consensus. An opaque and not well-defined process.

• On-chain governance. An explicit voting process by token holders.

The former, rough consensus, is at the heart of blockchain networks like Bitcoin and Ethereum. It involves human-oriented processes to reach agreement with various participants, then developers implement the upgrade and a flag day is organised for when the upgrade can go live.

The latter, on-chain governance, was first pioneered by Tezos to enable participants to explicitly vote on whether an upgrade should be deployed and then for provide a timeline for the software to be updated upon a successful vote. As we will see soon, the on-chain governance approach has become popular with DAOs as a way to govern the deployment of a single software instance.

In both cases, there is still a requirement to reach agreement on the proposed upgrade and there is no guarantee it will go without a hitch:

• No blockchain split: An upgrade is executed without a hitch and worldwide consensus (including the market) accepts only a single database with the new rules.

• Blockchain split: If the the upgrade is contentious and it still goes ahead, then it can lead to a permanent fork as both communicates apply different rules and compute different databases with their own market caps.

Put another way, the governance process provides an indication on whether the community may accept the proposed upgrade. We can only be certain after the flag day and execution of the upgrade. It is very well possible that community members will dissent, ignore the new rule, and allow two competing databases to emerge. Just like BTC/BCH and ETH/ETC.

As a final note, there are two ways to implement a new rule change:

• Hard fork. A detectable change to the rules that non-upgraded nodes will reject.

• Soft fork. A non-detectable change to the rules that non-upgraded nodes will ignore.

The idea of hard or soft forks focuses on whether non-upgraded software can detect the rule change and how it will respond to it. It is very easy to get into a heated debate around which approach should be used as it ultimately has an impact on the network’s censorship-resistance, ability to fend against hostile take overs and whether users can explicitly opt-in to the rule change.

A World of Databases?

The entire pursuit of blockchain networks is to build an open database that allows anyone to read, write, and protect it.

Over the past 14 years, the largest experiments by the community has always focused on how to build a “better” database.

There has been a clear evolution:

• Custodial database. Replicate the web2 experience, but trust the operator to protect the integrity and liveness of the database.

• Public database. Allow anyone to read the database, but ultimately trust an operator to update it.

• Open database. Allow anyone to read, write, and protect the database.

To provide some examples:

• Centralised exchanges. Nearly all exchanges have implemented a web2-style database and it is not possible for anyone to compute a copy of the database.

• Proof of authority. Some blockchain systems rely on an appointed, or multiple appointed authorities, to publish a new block to update the database. Anyone can download the blocks, parse the data blobs, and compute a copy of the database. They just don’t have the authority to propose a new block.

• Nakamoto consensus. Anyone, who is willing to use the financial resources to do so, can participate in the process of updating the database by publishing (and voting on) new blocks. Again, anyone can download the blocks, parse the data blobs, and compute a copy of the database.

Now — we use the word “better” as the answer — because what makes a good database is very subjective and it depends what metric the community is trying to optimise for:

• Maximise participants who can participate in the consensus protocol?

• Maximise participants who can download a copy of the database?

• Restrict who can write to the database without approval of a trusted operator?

• Minimise the cost of transacting on the system? Perhaps while trying to keep the data public for anyone to download?

• What is the easiest for grandma to transact on?

We can objectively define metrics and evaluate how well a blockchain system achieves its stated goals. Communities will argue forever on the metrics that matter and how they achieve it better than their competitors. However, what ultimately matters is what the marketplace of users decides to transact on and why they made that decision.

There is only one problem — how do we move assets from one database to another database? For example, a typical user flow may involve:

• On-ramp. Buying coins on Coinbase,

• Transfer. Moving coins from Coinbase to Ethereum,

• Action. Experiment with DeFi applications,

• Transfer. Move coins from Ethereum to Arbitrum,

• Action. Experiment with DeFi applications,

• Transfer. Move coins from Arbitrum to Binance,

• Off-chain. Withdraw to fiat.

All the named systems are databases in their own right with various degrees of security and audibility. But, to enable the transfer of assets, we need to talk about bridges :)

That’ll be the focus of our next article!