Original title: "Blockchain as a Database", "Bridging Databases".

Original author: Patrick McCorry

Translation: Original text translation: 0x26

This article is from the Arbitrum Foundation and Patrick McCorry of Lemniscap. Patrick is the first cryptocurrency PhD graduate in the UK. During his PhD from 2013 to 2016, he researched Bitcoin and Ethereum related directions, and then served as an assistant professor at King's College London, and a researcher at UCL, NCL, and UIUC. In 2019, Patrick left the university to start a business in the Layer2 direction and was acquired by Infura. During his time at Infura, he also created a set of blockchain courses. Later, Patrick joined Lemniscap and the Arbitrum Foundation.

This article is divided into two parts. The first part is "Blockchain as a Database", and the second part is "Bridging Databases".

Patrick abstracts blockchain into the form of consensus protocol + database using first principles, and based on this, explains the working principles of Layer1, Layer2, and cross-chain bridges, as well as the differences between Layer and Layer2.

The following is the original article compiled by Jingluo Movement:

"Blockchain is a Database"

There has been a lot of controversy about whether the verification bridge has defined the existence of rollups, or in other words:

Rollup equals bridge?

Let's take a step back and look at this problem from first principles.

What is blockchain?

How to transfer assets from one database to another through a bridge?

We will discuss the above two topics through two articles, and after the discussion is completed, we will review these two topics and evaluate their correctness.

What is blockchain?

The main purpose of blockchain: to allow any third party to calculate the same database information and trust that this data is valid.

The core of blockchain is a database, which records:

Your balance.

Smart contract code

Program Status

In almost all systems, blockchain defines the order of all historical transactions.

At least this is what we have learned for a long time.

It doesn't have to be a list of transactions. It could very well be a list of state differences, with zero-knowledge proofs attached.

So, what is blockchain?

Blockchain is a set of ordered data tables that can calculate database replicas based on established rules.

Re-emphasizing the purpose of blockchain:

Allow users to calculate database replicas.

The only task is to make it possible to copy this database.

Very boring, right?

Reached consensus on blockchain

Reclaiming Existing Consensus Protocols

Blockchain can be like a bulletin board, allowing everyone to see the same message.

Before delving deeper, let's first imagine an abstract concept:

Announcement board, ensuring that all people with needs can continuously see the data.

Just roll up the data and publish it to the blockchain system

Reusing existing blockchain systems is known as rollup.

There are many examples: Coloredcoins, MasterCoin/Omni, Ordinals, Arbitrum, Optimism, StarkEx, ZkSync, Polygon Hermez, Scroll.

All of the aforementioned projects, as well as some other projects, are attempting to bootstrap new databases on top of Bitcoin or Ethereum.

In fact, due to the popularity of this approach, there is also a platform called Celestia that focuses on building databases specifically for launching rollups.

We can still think of rollup as a blockchain:

A series of regularly released data.

And will be attached to the related database with order.

The block may look different, and may even be a string of data blocks. But overall, it is still just an appended data structure, with a final total order (or causality).

Ultimately, whether developing a new consensus protocol or reviving an existing one, the goal is the same: to guide the creation of a database.

Principles for Analyzing Block Data Structures

Executed and enforced by the community are globally recognized rules, especially those that counteract internal nodes within the system.

Assuming that all parties can access the same data, the ultimate challenge is to make all parties follow the same set of rules, namely the same set of rules for parsing data blocks and calculating database replicas (the "state transition function").

An example of data parsing:

Take a data block.

Translate to English:

Parse it as a transaction.

Check if the transaction is executable.

Execute it on a specific virtual machine.

Update will be transmitted to the database.

This has led to a unique problem in the cryptocurrency industry:

When facing the parsing of data, a set of parsing rules with global consensus is needed.

When coordinating global unified resolution rules, we need to evaluate two situations:

Operation Execution. The rules agreed upon by all parties are executed 99.9% of the time.

Regulatory governance. All parties have a process of setting, proposing, and agreeing on new rules.

First of all, almost all discussions link the security of blockchain networks to the execution of daily rules. This is very important because it concerns how software and all parties involved continuously execute the same set of rules to protect the database.

However, the ultimate guarantee for protecting the blockchain network, especially when there are issues with executing operations, means updating the rules. Regarding how to change the rules and when to execute new rules, there must be a process that allows all participants to reach a social consensus.

(Bitcoin) The core of Bitcoin comes from Satoshi Nakamoto.

(Ethereum) Yellow Paper by Gavin Wood.

Usually, a project is led by a small group of developers who decide on the rules, launch the blockchain, and then hand over the software (along with the rules) to a larger community.

The next step is to change the rules.

On-chain governance. Clear process for token holders to vote.

In both of the above situations, it is still necessary to reach an agreement on the proposed upgrade, and even so, it cannot be guaranteed that it will proceed smoothly.

No blockchain split: smooth execution of upgrade, globally unified (including the market) to only accept one new rule of the database.

Blockchain Forking: If there is a dispute over an upgrade and both sides continue to operate, it may result in a permanent fork because the two communities apply different rules, calculate different databases, and have their own market values.

In other words, the governance process only provides a vague outcome, and the community may accept the proposed upgrade. (The real result) can only be determined after the marking day and upgrade execution. It is very likely that community members will oppose and ignore the new rules, allowing two competing databases to emerge. Just like BTC/BCH and ETH/ETC.

Finally, there are two ways to implement changes to the new rules:

Hard fork. Detectable changes to rules that non-upgraded nodes will reject. With detectable changes to rules, non-upgraded nodes will be unable to participate in new rules.

Soft fork. Undetectable changes to rules that non-upgraded nodes will ignore. Making undetectable changes to rules that non-upgraded nodes will ignore.

The concept of hard or soft forks focuses on whether changes to the rules can be detected and how to respond to them. There is often a heated debate about which method should be used, as it ultimately affects the network's resistance to censorship, ability to withstand malicious attacks, and whether users can clearly choose rule changes.

Database World

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

Over the past 14 years, the largest experiment in the community has always focused on how to build a "better" database.

There has been a clear evolution:

Hosted databases. Replicate the experience of web2, but trust operators to protect the integrity and vitality of the database.

Public database. Allows anyone to read the database, but ultimately trusts an operator to update it.

Open database. Allows anyone to read, write, and protect the database.

Here are some examples:

Centralized trading platform. Almost all trading platforms have implemented web2-style databases, and it is impossible for anyone to calculate replicas of the database.

Authority Proof (PoA). Some blockchain systems rely on a designated or multiple designated authorities to publish new blocks to update the database. Anyone can download the blocks, parse the data, and calculate a copy of the database. They just don't have the authority to propose new blocks.

Zhongben Cong Consensus. Anyone who is willing to use financial resources can participate in the process of updating the database by publishing (and voting on) new blocks. Similarly, anyone can download blocks, parse data blocks, and calculate replicas of the database.

Now - we use the word "better" because the answer to what a good database is, is very subjective. It depends on the metrics that the community is trying to optimize for:

Interested in participants who can participate in consensus protocols?

Participants who value the ability to download database copies?

Restrict who can write to the database without requiring approval from untrusted operators?

Do not care about the cost of trading on the system? Perhaps while trying to keep the data open to everyone?

What is the easiest way for grandma to conduct transactions?

We can objectively define metrics and evaluate how blockchain systems achieve their stated goals. The community will always debate which metrics are important and how they can better achieve these metrics than their competitors. However, ultimately, what is important is where users choose to trade and why they make that decision.

There is only one question - how do we move assets from one database to another? For example, a typical user flow may include:

上线。 Purchase tokens on Coinbase.

Transfer. Transfer tokens from Coinbase to Ethereum.

Action. Try DeFi applications,

Anyone can obtain the blockchain, parse data (transactions) in order, and calculate replicas of the same database.

Now it's time for one of the most difficult problems to solve in the blockchain network: how do participants verify that they have the same and unique copy of the blockchain?

In simple terms, the entire field of blockchain engineering is focused on the following areas:

An interesting side note is that data blocks may not necessarily be transaction lists. In fact, there are two options:

Participants decide how to parse the data into a set of rules ("state transition functions") that can be applied to update the database. Due to the rise of validity proofs, state transition methods have only recently emerged.

Therefore, ultimately, the focus of all blockchain protocols is to ensure the correct ordering of data and make it public to everyone. In fact, there is a very subtle assumption:

Recently broadcasted. The consensus protocol can only guarantee the publication of data at a certain point in time.

It cannot be guaranteed that decisions reached in history are all usable, and most nodes that provide data are altruistic (translator's note: most nodes that provide historical transaction data are driven by altruistic behavior. This is because in a blockchain network, nodes are not obligated to always store all transaction data).

Finally, when deciding how to ensure the transparency of database data, the project can make the following choices:

Deploy a new consensus protocol ("Layer1")

Reuse existing consensus protocols ("rollup")

The former is a daunting task. It requires guiding the entire ecosystem to be willing to stand up, and often requires the honest majority of participants to protect the system.

Rollup acknowledges that it is difficult to bootstrap such an ecosystem and that there is little value in reinventing the wheel. Utilizing Layer1 as a bulletin board and ensuring the availability (and ordering) of all relevant data is much easier.

Regardless of whether a project decides to deploy a new Layer1 or rollup, all methods will result in a database world with varying degrees of trust assumptions and security.

We can easily classify them as "closed", "public", or "open" databases, with the focus on whether the database can be publicly read and the mechanism used to write to the database.

Cross-chain bridge for transferring assets from one database to another.

The above content may sound very theoretical, but there is empirical evidence to suggest that we are now living in a world with hundreds or even thousands of databases that want to interact with encrypted assets.

This leads to the next question:

How can users transfer their assets from one database to another database?

We need to study how users can transfer their assets from one database to another database.

More broadly, how they pass information between different systems. Let's explore!

Bridge the World

This is all about how to send messages from one database to another database through a bridge.

There is a component that can help achieve the imagined world of blockchain:

Bridge: Provides a passage for things that are difficult or impossible to cross.

Verifiable. The recipient can verify that the message was indeed initiated by the sender.

One thing worth noting is that as a communication protocol, Bridge does not focus on protecting the privacy of messages. This is an optional feature in the field of Bridge, and there is currently no Bridge protocol that protects message privacy.

Now, the main problem that the blockchain industry needs to solve is to make the receiver believe in the authenticity of the message, that is, the proof process.

Artificial Operation Bridge

Furthermore, both the sender and receiver must fully trust the designated institution to transmit messages and prove their integrity. This is because without the help of a third party, the sender and receiver cannot see the outside world.

This type of bridge can be referred to as an artificial operational bridge.

It relies on humans (server-side applications) to facilitate communication and enforce all rules on behalf of the sender or receiver. It is the easiest type of bridge to deploy and can be applied to various different blockchains, but it is the most difficult to protect on a large scale.

Unfortunately, the entire meaning behind cryptocurrency and the movement initiated by Satoshi Nakamoto is to eliminate all trust required for system operation and replace it with cryptographic proof.

We can try to reduce the permissions of intermediary roles until only the messenger carrying the message remains.

We should send the proof of encryption along with the sender's message to prove the authenticity of the message.

If successful, this proof should make the receiving smart contract believe in the authenticity of the message without having to trust the human party.

Reduce the role of manual operation: assist in relaying messages from database A to database B as a relay.

For this method, we have the following questions:

In this method, the authoritative institution still needs to prove the authenticity of the message, but if the authoritative institution attempts to cheat, it may be immediately punished. For example, by sending incorrect and conflicting messages.

The Nomad Protocol is an example of implementing this responsible method.

It assumes that there are two authoritative parties:

Authentication authority. Responsible for reading database A, signing messages issued by it, and submitting the signature to database A.

The party executing the authentication right should lock up a considerable amount of assets to prevent malicious behavior, and anyone can play this role. On the other hand, the veto power must be specified before the protocol actually runs, and how to make the veto power role non-admission is still an open research question.

The Nomad protocol has three stages:

Authentication message. The authenticator reads the message from database A, signs the message, and submits the signature to database A.

Message Relay. Anyone can receive a signed message and forward it to database B.

Rejection stage. There is a fixed time window (e.g. 30 minutes) for the party with veto power to check whether the message sent to database B is exactly the same as the message on database A. If it is not the same, the message should be vetoed and cancelled.

Although for illustrative purposes, our example assumes only one receiving database, the Nomad protocol can be extended to allow multiple databases to receive the same signed message.

Database A is responsible for authentication, but relies on another party with veto power to monitor malicious signature messages on all supported databases.

We need to consider the possibility that the party with power may attempt to deceive the bridge protocol:

1. The authentication party confirmed and signed a message that has not been confirmed by database A.

2. The vetoing party vetoed the message approved by Database A.

In the first scenario, the authentication party unilaterally generates a digital signature. If they attempt to deceive the recipient, database A will be unable to recognize the digital signature. Either party can obtain the signature, send it to database A, and authorize database A to punish the authentication party.

In the second scenario, it remains a fully trusted role and there is no way to retaliate within the protocol. It should be noted that protocol records are public to all participants and veto power can be revoked through voting afterwards. However, by that time, losses may have already occurred as vetoing honest messages can have significant impacts on time-based actions (i.e. clearing) for smart contracts.

Check the Consistency of the Simplified Payment Verification (SPV) Protocol

Tracking blocks agreed upon by respective consensus protocols, as well as specific transactions and more general database records.

For the second method, we raise the following questions:

Can we track the consensus protocol of database A?

As mentioned earlier, all blockchain networks have a consensus protocol that agrees to generate new blocks at the top of the chain on a regular basis. Blocks can be thought of as batch updates to the database.

In this method, the goal is to allow the smart contract on database B to receive (messages) and track data generated by the consensus protocol from database A, and trust it.

To achieve this, the consensus protocol must be light client-friendly by default.

Light client: Requires minimal computation and data to understand and trust the current state of the database.

The Bitcoin white paper refers to it as the Simplified Payment Verification (SPV) mode. SPV allows users to verify that they have indeed received Bitcoin without verifying and storing a copy of the entire Bitcoin database.

The SPV process runs as follows:

Check the longest chain. Any user should be able to obtain the block header data and independently verify (PoW) the longest chain so far.

包含证明。 Once users are confident that their block header list represents the main chain, anyone can provide them with a proof of inclusion (Merkle root) for specific data in the database.

确信。Users can cross-check proof-containing data with relevant block headers and then confirm specific data in the database.

An old project called BTCRelay has implemented a light client bridge between Bitcoin (database A) and Ethereum (database B). This is a smart contract on Ethereum that can parse Bitcoin block headers, contain proofs, and track the longest chain through proof of work. Ultimately, its goal is to verify whether UTXOs are indeed stored in the Bitcoin database and then allow another smart contract to operate on them.

Unfortunately, BTCRelay is a bit ahead of its time. While its functionality is complete, it hasn't received much attention.

We can learn some lessons from this project:

Accumulated gas cost. Tracking block headers requires many on-chain transactions, and financial costs will accumulate over time.

Only applicable to Bitcoin forks. BTCRelay is only compatible with blockchains that have forked from the Bitcoin codebase. Blockchains using different consensus protocols require specialized implementation of their respective light clients.

Still need trust consensus. BTCRelay can only check if the proof of work is correct, but cannot check if the block header is valid. If a hostile miner creates a malicious block header with a valid proof of work, the bridge may be compromised. Waiting for about 6 confirmations and relying on the assumption of the honest majority of Bitcoin (>51% of miners are honest) is still necessary.

Some research is mainly focused on the ability to reduce accumulated gas costs by aggregating multiple block headers into one update. For example, NIPOPOWS and Glimpse focus on light clients related to PoW.

However, with many bridges on other blockchain networks following the idea of building light client bridges, a glimmer of success has emerged.

Cosmos的IBC

Near 的 Rainbow bridge

translates to "Rainbow Bridge in Near."Ava's P-Chain

Still Trusting Participants - Can We Do Better?

All work is focused on passing trust to the most likely trusted parties, but ultimately relies on the honesty of the majority!

Overview: All the bridges listed in this article rely on a group of intermediaries who must ensure the authenticity of messages sent through the bridge, even if it is just to ensure that a consensus protocol has reached a single decision.

I speculate that there is a basic requirement, which is that a bridge always needs a group of intermediaries to help transfer messages from the sending database to the receiving database.

If we accept this premise, then we can also consider the decisions made by participants in the tracking consensus protocol to be meaningful, as they are the source of truth for determining the total ordering of updates that will be applied to the database.

This leads to the final question:

Can we build a bridge to independently verify the validity of consensus protocol decisions?

This has a subtle difference.

The bridge not only needs to check whether the consensus protocol agrees with the total order of database updates, but also needs to check whether the update itself is valid relative to all other updates to the database.

If this can be achieved, then the recipient's smart contract (database B) can be confident that updates have been applied in database A and that the data in the database is actually valid.

Then, it can read the database, extract relevant information, and perform operations on it.

Can this be done? The answer is yes.

Verification Bridge's Rise

We can use the consensus protocol of database A to sort all data blocks and then the verifying node bridge can independently check the validity of all data blocks as updates to database B.

The core of the verification bridge is to enable smart contracts not only to check whether a decision has been made, but also to independently verify whether the content of the decision is correct.

The overall idea is to take a few more steps than a lightweight client bridge:

Fraud and Validity Proof. Expand the capabilities of lightweight clients to succinctly verify the correctness of large-scale computations.

Data availability layer. By reordering data blocks using database A and removing the consensus protocol from database B.

Open members. Allow all parties to self-appoint and contribute to the validity of all database updates.

In order to avoid redundant verification of the bridge analysis - only the last question needs to be discussed.

This article only focuses on:

The ability to pass messages back and forth between databases.

Ensure the recipient has confidence in the authenticity of the message.

We have not yet discussed how the bridge holds or transfers assets between databases.

This is because, fundamentally, all bridges are responsible for timely message delivery and ensuring the authenticity of the message to the recipient.

Assets and Liabilities

Now, we can deploy smart contracts on each database, and smart contracts can interact by sending messages on the bridge.

The most common application is to transfer assets from database A to database B (and vice versa).

These two types of smart contracts include:

金库。发送数据库上的智能合约，用于保管资产。

Vault. Send smart contracts on the database for asset custody.

Issuance. The smart contract in the recipient's database has the right to issue IOUs for the assets held in the custody.

At a higher dimension, these two smart contracts can achieve the deposit/withdrawal process that most users are familiar with when transferring assets to another system.

Deposit Process. Users can deposit coins into the insurance vault of Database A, and the insurance vault can send information through the bridge to issue the same amount of assets to the user address in Database B.

Withdrawal process. Users can request the issuer to destroy tokens on database B and send a message through the bridge to the treasury to release the same amount of tokens to the user's address for token withdrawal.

One of the benefits of this design is that anyone with read access to the gold vault in database A and read access to the issuer in database B can verify whether the asset covers the liability. In other words, anyone can verify whether the issued token has a fully collateralized gold vault as a backing.

What's the next step?

Cryptocurrency is an extraordinary database and "bridge project".

Of course, if we want to move assets in the database and make them run on a large scale, it all depends on the security of the bridge and how we trust the integrity of the information sent.

In history, we have never been able to establish secure bridges because they all rely on humans to protect the information being sent. Most large exchanges, including BitFinex, Binance, and Bitstamp, as well as the worst case of MtGox, have all suffered user fund losses due to bridge accidents. In addition, there are bridges for transferring funds across blockchains such as PolyNetwork, Ronin Bridge, and Harmony.

As a community, we have been trying various bridging designs for many years, some relying only on trusted intermediaries, while others attempt to transfer trust from intermediaries to their respective blockchain consensus protocols.

The verification bridge is just a further step - not only trusting the decisions made by the consensus protocol, but also checking if it is a valid decision.

Original link:

Blockchain as a Database (Part 1)

Bridging Databases (Part 2)

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia