A New Perspective on Blockchain: Database, Consensus, Rollup, and Bridge
Original Author: Patrick McCorry
Original translation: 0x 26
This article is from the Arbitrum Foundation and Lemniscap by Patrick McCorry. Patrick is the first cryptocurrency doctoral graduate in the UK. During his doctoral studies from 2013 to 2016, he researched Bitcoin and Ethereum related topics. Afterward, he 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 Layer 2 direction and was acquired by Infura. During his time at Infura, he also created a set of blockchain courses. Afterward, 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 uses first principles to abstract blockchain into the form of a consensus protocol + database and explains the working principles of Layer 1, Layer 2, and cross-chain bridges, as well as the differences between Layer 1 and Layer 2.
The following is the original article translated by Alldynamics:
"Blockchain as a Database"
There is a lot of controversy about whether the validation bridge defines the existence of rollups, or in other words:
Is a rollup equal to a bridge?
Let's take a step back and look at this problem from first principles.
What is a blockchain?
How do we transfer assets from one database to another through a bridge?
We will discuss these two topics in two articles. After the discussion, we will reassess these two topics to evaluate their correctness.
What is a blockchain?
The main purpose of a blockchain: allowing any third party to compute the same database information and trust that the data is valid.
The core of the blockchain is a database that records:
Account balances
Smart contract code
Program states
In almost all systems, the blockchain defines the order of all historical transactions.
At least, that's what we have learned for a long time.
It doesn't have to be a list of transactions. It is likely a list of state differences with zero-knowledge proofs on the side.
So, what is blockchain?
Blockchain is a group of ordered data tables that can calculate database copies based on certain rules.
Let's reiterate the purpose of blockchain:
Allow users to calculate database copies.
The sole task is to make replicating this database possible.
Quite boring, isn't it?
Consensus on Blockchain
One of the challenges with blockchain is:
How does the community achieve global consensus and recognize what a true blockchain is?
If we can achieve unity on the same blockchain, users worldwide can calculate the same database.
This leads to the idea of a consensus protocol with a simple goal:
Enable a group of possibly anonymous, untrusting parties to reach a decision.
In the context of blockchain, a consensus protocol allows one party to propose a data "block" and append it to the top of the data sequence, which all other parties agree is indeed the new block header.
This is why it's called a blockchain, because we all reach consensus on the same data block!
Designing and implementing a consensus protocol involves considering many technical challenges:
Can we achieve openness, allowing anyone to participate?
How much communication complexity is required for parties to reach consensus?
Is it possible to provide economic incentives for people to actively participate?
Although this is a very interesting and complex topic, let's not focus on these challenges for now. The only thing to remember is that there only needs to be one consensus protocol that allows all parties to reach consensus on a new data block.
New Practical Examples of a Consensus Protocol
Over the years, particularly in the pursuit of blockchain Layer 1, the community has gone through various attempts at configuring consensus protocols:
Nakamoto on Bitcoin
Gasper on Ethereum
Tendermint on Cosmos
Snowman on Avalanche
In almost all cases, the strategy for introducing a protocol into the market is to release a new consensus protocol that continuously updates the database. It's not just about deploying the consensus protocol but also includes all the infrastructure surrounding it. And on a societal level, enabling the honest majority to participate without permission.
This is a daunting task.
It also raises an interesting question:
If I want to launch a chain that eventually becomes a new database, do I really need to introduce a new consensus protocol?
Surprisingly, the answer is no!
Rediscovering Existing Consensus Protocols
Blockchain can act as a bulletin board, allowing everyone to see the same information.
Before diving into the details, let's imagine an abstract concept:
A bulletin board that ensures continuous visibility of data to all interested parties.
This is a concept related to electronic voting protocols. The bulletin board allows all users to access the same protocol records. Users can retrieve these records, execute them independently, and verify the correctness of the protocol. In the context of electronic voting, the bulletin board can be used to verify the proper functioning of the voting process and the accuracy of vote counting.
So, what does this have to do with blockchain? Well, as long as:
Anyone can access the data on the bulletin board,
Then, anyone can have a copy of the database with timestamps. In fact, many Layer-1 chains, especially Bitcoin and Ethereum, serve as excellent bulletin boards. Furthermore, they make it easy to write data onto the bulletin board.
Simply roll up the data and publish it to the blockchain system
Reusing existing blockchain systems is referred to as rollup.
Rollup: All the data is aggregated and published onto the corresponding chain.
The heavy lifting of determining data ordering and ensuring accessibility by anyone is left to the existing blockchain systems. This is not a new idea. In fact, it has been around for about 10 years. Rollup methods have become a popular way to bootstrap new databases.
There are many examples: Coloredcoins, MasterCoin/Omni, Ordinals, Arbitrum, Optimism, StarkEx, ZkSync, Polygon Hermez, Scroll.
All of the above projects, along with some others, are attempting to bootstrap new databases on top of Bitcoin or Ethereum.
In fact, due to the popularity of this approach, there is even a platform called Celestia that focuses on building databases specifically for launching rollups.
We can still think of rollup as blockchain:
A series of periodically published data, appended to an ordered and related database.
The blocks may look different, or they may even be a sequence of data blocks. But overall, it is still a structure that appends data, ultimately having a (causal) ordering.
Ultimately, whether it is developing a new consensus protocol or reviving an existing one, the goal is the same: to generate a database.
Principles for Parsing Block Data Structure
The community is responsible for executing and enforcing globally recognized rules, especially to counter internal system nodes.
The assumption is that all parties can access the same data, and the ultimate challenge is to get all parties to adhere to the same set of rules, namely the rules for parsing data blocks and calculating database replicas ("state transition functions").
An example of parsing data:
Take a data block and parse it into a transaction,
Check if the transaction is executable, execute it on a specific virtual machine, and propagate the updates to the database.
This leads to a unique problem in cryptocurrency:
When dealing with parsing data, a set of globally agreed-upon parsing rules is needed.
In coordinating globally consistent parsing rules, we need to consider two scenarios:
Execution of operations. Rules that all parties agree on are executed 99.9% of the time.
Governance of rules. All parties have a process for proposing and agreeing on new rules.
First, almost all discussions link the security of blockchain networks to the daily execution of rules. This is crucial because it focuses on how software and participating parties continuously execute the same set of rules to protect the database.
However, ensuring the ultimate security of a blockchain network, especially when operational execution encounters problems, means updating the rules. There must be a process for changing rules and achieving social consensus among all participants on when to implement new rules.
Let's explore the concepts of execution and governance in more detail.
Execution of Operations
It is the responsibility of all of us to continuously execute the rules and validate every proposed update to the database.
The daily execution of operations is what makes blockchain systems so exciting in terms of computing databases!
We just need to agree on the following two points:
Where to find the total ordering of data blocks and the rules for parsing data blocks.
That's it. As long as the database follows the rules, all participants have the opportunity to access data blocks and execute the rules.
Regardless of whether participants are large or small, initiating sorters or home nodes, everyone should have confidence in the content of the database.
Furthermore, as long as all market participants execute the same rules, they can compute the same database replica, allowing the market to determine what should be considered the true blockchain.
Governance of Rules
All blockchain systems must be guided by a set of rules for parsing data and calculating databases.
Almost all blockchain systems require a bootstrapping phase:
(Bitcoin) Bitcoin Core from Satoshi Nakamoto
(Ethereum) The Yellow Paper from Gavin Wood.
Usually, a project is bootstrapped by a small group of developers who decide the rules, launch the blockchain, and then hand over the software (and rules) to a larger community.
The next step is changing those rules.
There are many reasons for changing the rules, such as software upgrades or fixing bugs. Any modification to the rules requires broader agreement, also known as social consensus.
There are two ways to achieve consensus for rule changes:
Rough consensus. An opaque and unclear process.
On-chain governance. A clear process of token holders voting.
The former, rough consensus, is at the core of blockchain networks like Bitcoin and Ethereum. It involves a human-driven process of reaching agreement with various participants and then developers implementing upgrades and proposing a activation date for the upgrade to take effect.
The latter, on-chain governance, was first introduced by Tezos, allowing participants to vote explicitly on whether an upgrade should be deployed and then providing a schedule for the software to be updated upon successful voting. As we will soon see, the approach of on-chain governance has gained popularity in DAOs as a way to manage the governance of a single project.
In both cases mentioned above, agreement still needs to be reached on the proposed upgrade, and even then there is no guarantee that it will go smoothly:
No blockchain split: The upgrade is successfully executed, and a single new-rule database is accepted globally (including the market).
Blockchain split: If there is controversy over the upgrade and both sides continue to operate, it could result in a permanent fork as two communities apply different rules and compute different databases with their own market values.
In other words, the governance process only provides a blurry outcome, and it is possible that the community will reject the proposed upgrade. (The real outcome) can only be determined after the activation date and the execution of the upgrade. It is very likely that community members will oppose and disregard 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 new rules:
Hard Fork. Nodes that have not upgraded will reject detectable changes to the rules. With detectable changes to the rules, non-upgraded nodes will not be able to participate in the new rules.
Soft Fork. Nodes that have not upgraded will ignore undetectable changes to the rules. With undetectable changes to the rules, non-upgraded nodes will ignore these changes.
The concept of hard fork or soft fork focuses on whether changes to the rules can be detected and how the network responds to them. There can be intense debates around which method should be used, as it ultimately affects the censorship resistance of the network, its resilience against malicious attacks, and whether users can choose rule changes explicitly.
The World of Databases
The pursuit of the entire blockchain network is to build an open database that allows anyone to read, write, and protect it.
In the past 14 years, the biggest experiment in the community has always been focused on how to build a "better" database.
There have been obvious evolutions:
Managed database. Replicate the web2 experience, 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.
Some examples:
Centralized trading platform. Almost all trading platforms implement a web2-style database, where it is not possible for anyone to calculate replicas of the database.
Proof of Authority (PoA). Some blockchain systems rely on a designated, or multiple designated authorities to publish new blocks to update the database. Anyone can download blocks, parse data blocks, and calculate replicas of the database. They just don't have authority to propose new blocks.
Nakamoto Consensus. Anyone 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 - what makes a good database - is very subjective and depends on the metrics the community is trying to optimize:
Does it value participants in the consensus protocol being able to participate?
Does it value participants being able to download replicas of the database?
Does it restrict who can write to the database without requiring approval from trusted operators?
Doesn't care about the cost of transacting on the system? Perhaps trying to keep the data open to anyone?
What makes it easiest for grandma to transact?
We can objectively define metrics and assess how well blockchain systems achieve their stated goals. Communities will always debate which metrics matter and how they outperform their competitors on those metrics. However, ultimately what matters is where users choose to transact and why they make that choice.
Only one question - how do we move assets from one database to another? For example, a typical user flow might include:
Onboarding. Buy tokens on Coinbase
Transfer. Move tokens from Coinbase to Ethereum
Action. Try DeFi applications
Transfer. Move tokens from Ethereum to Arbitrum
Action. Try DeFi applications
Transfer. Move tokens from Arbitrum to Binance
Off-chain. Convert to fiat currency.
All named systems are databases with different levels of security and audibility. However, in order to achieve asset transfer, we need to talk about bridges, which will be the focus of our next article!
Bridging the World - Introduction
A Brief Review: "Blockchain as a Database"
The previous article discussed "What is blockchain", which is a great opportunity to understand the purpose of blockchain.
So, what is blockchain?
Blockchain is simply a data structure that determines the overall order of data (transactions).
It has only one purpose:
Anyone can access the blockchain, parse data (transactions) in order, and calculate replicas of the same database.
Now it's time - one of the most difficult problems to solve in a blockchain network: how can participants verify that they have the same and unique replica of the blockchain?
In simple terms, the entire field of blockchain engineering focuses on:
Implementing a single database.
The only way for all parties worldwide to converge on the same blockchain is to join a consensus protocol. It allows all parties to collectively agree on adding the latest data block.
An interesting side note is that a data block does not necessarily have to be a transaction list. In fact, there are two options:
Transaction history. A clear list of transactions to be executed. State
Differences in state. A "state difference" list that can be used to update storage slots in the database.
Participants determine how to parse data into a set of rules ("state transition function") that can be applied to database updates. State transition methods have emerged relatively recently due to the rise of proof of validity.
Therefore, ultimately, the focus of all blockchain protocols is to ensure correct data ordering and make it public to everyone. In fact, there is a very subtle assumption:
Recent broadcast. The consensus protocol can only guarantee the publication of data at a certain point in time.
It cannot guarantee that the decisions made in the past that have reached consensus are available, and most of the nodes that provide data are altruistic (Translator's Note: Most of the nodes that provide historical transaction data are altruistic behavior. This is because in the blockchain network, nodes are not obliged to continuously store all transaction data).
Finally, when deciding how to ensure the openness of database data, projects can make the following choices:
Deploy a new consensus protocol ("Layer 1")
Reuse existing consensus protocols ("rollup")
The former is a challenging task. It requires the entire ecosystem to be willing to stand up, and usually requires a honest majority of participants to protect the system.
Rollup acknowledges that it is difficult to bootstrap such an ecosystem, and it is not worthwhile to reinvent the wheel. It is much easier to use Layer 1 as a bulletin board and let it guarantee the availability (and ordering) of all relevant data.
Whether a project decides to deploy a new Layer 1 or rollup, all approaches will lead to a world of databases with varying degrees of trust assumptions and security.
We can easily classify them as "closed", "public" or "open" databases, with the focus being on whether the database can be publicly read and the mechanisms used to write to the database.
Cross-chain bridges for transferring assets from one database to another.
The above content may sound theoretical, but there is empirical evidence that we now live in a world with hundreds or thousands of databases that want to interact with cryptographic assets.
This leads to the next question:
How can users transfer their assets from one database to another?
We need to study how users can transfer their assets from one database to another.
More broadly, how they can pass information between different systems. Let's find out!
Bridging the World
It's all about how to send messages from one database to another through bridges
There is a component that can help realize the imagined blockchain world:
Bridge: provides a channel for difficult or impossible things to cross.
In fact, the bridge's work is simple. It should allow messages to be passed from one database to another. It can be seen as a communication protocol, where the entity (bridge) is situated between the sender and the receiver.
All communication protocols strive to meet the following properties:
Timely delivery. Messages should be received by the recipient as quickly as possible.
Integrity. The complete content should be delivered.
Verifiability. The recipient can verify that the message is indeed initiated by the sender.
It is worth noting that bridges as communication protocols do not focus on protecting the privacy of messages. This is an optional feature in the field of bridges, and there are no bridge protocols that protect message privacy at the moment.
Now, the main issue that bridges need to address is the ability to make the recipient trust the authenticity of the message, i.e., the proof process.
Manually Operated Bridge
We believe that manually operated operating systems can transmit information and prove its authenticity.
In almost all bridge designs, there is a set of authoritative institutions between the sender (Database A) and the recipient (Database B). Of course, the sender and recipient are likely to be smart contracts existing in their respective databases.
These authoritative institutions will:
Acquire. Get new messages from Database A.
Sign. Digitally sign all messages that will be sent to Database B.
Proof. Send the digital signature and message to database B.
The proof process requires the recipient's database (database A) to verify that the message is indeed signed by a trusted authority. If so, it can have confidence in the content and source of the message.
Key question: trust in these designated authorities.
Furthermore, both the sender and the receiver must have full trust in the designated authority to deliver the message and prove its integrity. This is because without the help of a third party, the sender and the receiver cannot see the outside world.
This bridge can be called 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 also the most difficult to protect on a large scale.
Unfortunately, the entire meaning of cryptocurrencies and the movement initiated by Satoshi Nakamoto is to eliminate all trust required for system operation and replace it with cryptographic proof.
We need to do better.
Evolution of Proof of Confidence
We can attempt to reduce the role of intermediaries to only be carriers of the message
We should send cryptographic proof along with the sender's message to prove the authenticity of the message.
If successful, this proof should make the recipient smart contract believe in the authenticity of the message without having to trust a human party.
Roles of artificial operation can be reduced: assisting in the transfer of the message (as a relay) from database A to database B.
Let us explore several different approaches to prove its practical significance.
Enforce Correct Proof (Nomad)
For this approach, we pose the following questions:
Can we reduce the trust in human operation by requiring the artificial operation to be responsible for its proof?
In this approach, the authority still needs to prove the authenticity of the message, but if the authority attempts to cheat, it may be immediately penalized. For example, by incorrect and conflicting messages.
The Nomad protocol is an example of implementing this responsible approach.
It assumes two authoritative parties:
Authentication Authority. Responsible for reading from database A, signing the message it sends, and submitting the signature to database A.
Veto Authority. Responsible for cross-verifying that the signed message originated from database A to protect database B.
The Authentication Authority should lock a significant amount of assets to prevent malicious behavior, and anyone can play this role. On the other hand, specifying the Veto Authority before the protocol actually operates, and how to make the Veto Authority role non-admissionary, remains an open research question.
The Nomad protocol has three stages:
Authenticate message. The authenticator reads the message from database A, signs the message, and submits the signature to database A.
Message relay. Anyone can take the signed message and forward it to database B.
The veto stage. There is a fixed time window (e.g., 30 minutes) for the party with veto power to check if the message sent to database B is identical to the message on database A. If they are 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 the party with veto power to monitor malicious signed messages on all supported databases.
We need to consider the scenario where the party with power tries to deceive the bridge protocol:
1. The authenticator confirms and signs a message that is not confirmed by database A.
2. The vetoing party rejects a message confirmed by database A.
In the first case, the authenticator unilaterally generates a digital signature, and if they attempt to deceive the receiver, 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 penalize the authenticator.
In the second case, it remains a fully trusted role, and there is no counterattack method within the protocol. It should be noted that protocol records are public to all participants and the veto power can be revoked through voting afterwards. However, by that time, losses may have already occurred, as vetoing honest messages may have significant impact on time-based actions (i.e., settlement) of smart contracts.
Checking the Consistency of the Simplified Payment Verification (SPV) Protocol
Tracking the blocks agreed upon by their respective consensus protocols, as well as evidence regarding specific transactions and more general database records.
For the second approach, the following questions are raised:
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 periodically at the top of the chain. Blocks can be considered as batch updates to the database.
In this approach, the goal is to allow the smart contracts on database B that receive (messages) to track and trust the data generated by the consensus protocol on database A.
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.
In summary, a light client allows users to understand the values recorded in the database and be confident that the consensus protocol agrees that the data should exist in the database.
The concept of a light client is as ancient as Bitcoin.
The Bitcoin whitepaper refers to it as 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.
All block headers form a chain structure, and the hash value of each block header includes the result of the proof of work.
The SPV process operates as follows:
Encrypt commitment. Each block header contains an encrypted commitment (Merkle root) representing the entire Bitcoin database. In addition, the block header contains the link to the previous block and its own proof of work.
Check the longest chain. Any user should be able to obtain and independently verify the block header data and the longest chain so far.
Include proof. Once users are confident that their list of block headers represents the main chain, anyone can provide them with inclusion proof (Merkle root) for specific data in the database.
Confirmation. Users can cross-check the inclusion proof with the relevant block headers and then confirm specific data in the database.
The Bitcoin SPV mode can serve as the foundation for building lightweight client bridges, allowing smart contracts on another blockchain to access the content of the Bitcoin database.
An old project called BTCRelay implemented a lightweight client bridge between Bitcoin (database A) and Ethereum (database B). It is an Ethereum smart contract that can parse Bitcoin block headers, inclusion proofs, and track the longest chain through proof of work. Ultimately, its purpose is to verify whether UTXOs are indeed stored in the Bitcoin database and allow another smart contract to operate on them.
Unfortunately, BTCRelay was somewhat ahead of its time. Although it was fully functional, it did not receive much attention.
We can learn some lessons from this project:
Accumulated gas costs. Tracking block headers requires many on-chain transactions, and the financial cost accumulates over time.
Only applicable to Bitcoin forks. BTCRelay is only compatible with blockchain from the forked Bitcoin codebase. Blockchains using different consensus protocols require specialized implementations of their own lightweight clients.
Trust in consensus is still needed. BTCRelay can only check if the proof of work is correct and cannot verify if block headers are valid. If a malicious miner produces a valid proof of work with a malicious block header, the bridge could be compromised. Waiting for about 6 confirmations and relying on the assumption of the majority of honest Bitcoin miners (>51%) is still necessary.
Some research is primarily focused on the ability to reduce accumulated gas costs by aggregating multiple block headers into a single update. For example, NIPOPOWS and Glimpse focus on PoW-related lightweight clients.
However, with the advent of many bridges on other blockchain networks following the idea of building lightweight client bridges, the dawn of success has emerged:
IBC of Cosmos
Rainbow bridge of Near
P-Chain of Ava
Both IBC and P-Chain have dedicated layers to track from different consensus protocols. They both follow the majority of honest signatures generated by consensus protocols, but more often than not, if the consensus protocol decides to deceive the underlying layer, they sign a conflicting message and there are not always consequences.
Still Trusting Participants - Can We Do Better?
All efforts are focused on passing trust to the most likely trusted parties, but ultimately still rely on trusting the majority of honest parties!
Looking at all the bridges listed in this article, we always rely on a group of intermediaries who must ensure the authenticity of the messages being sent via the bridge, even if it means ensuring that a consensus protocol has reached a single decision.
I suppose there is a basic requirement that bridges always need a group of intermediaries to help transmit messages from the sending party's database to the receiving database.
If we accept this premise, we can also consider it meaningful to track the decisions made by participants in the consensus protocol because they are the source of truth that determines the total order of updates applied to the database.
This raises one final question:
Can we build a bridge that independently verifies the validity of decisions made by the consensus protocol?
This has a subtle distinction.
The bridge not only needs to check whether the consensus protocol agrees on the total order of database updates, but also needs to check if the updates themselves are valid relative to all other updates in the database.
If this can be achieved, then the recipient's smart contract (database B) can be confident that the updates applied in database A have been verified and that the data in the database is actually valid.
Then, it can read the database, extract relevant information, and perform actions on it.
Can we do this? The answer is yes.
Rise of the Verification Bridge
We can sort all data blocks using the consensus protocol of database A and then the bridge nodes 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 to not only check if a decision has been made, but also independently verify the correctness of the decision's content.
The overall idea is to take a few more steps than a light client bridge:
Fraud and validity proofs. Extend the capabilities of the light client to succinctly verify the correctness of large-scale computations.
Data availability layer. Remove the consensus protocol from database B by reusing database A to sort data blocks.
Open membership. Allow parties to self-appoint and contribute to the validity of all database updates.
To avoid repeating the analysis of the bridge, only the last question needs to be discussed.
This article only focuses on:
The ability to pass messages back and forth between databases.
Making the recipient confident 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
The treasury holds tokens in database A and authorizes the issuance of an equal number of tokens in database B through the bridge.
Now, we can deploy smart contracts on each database that 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 smart contracts include:
Treasury. A smart contract on the sending database for custody of assets.
Issuance. A smart contract on the receiving database with the authority to issue IOUs for the assets in the treasury.
At a higher level, these two smart contracts can achieve a deposit/withdrawal process that most users familiar with transferring assets to another system are accustomed to:
Deposit process. Users can deposit coins into the treasury of database A, which can send a message on the bridge to issue the same amount of assets to the user's 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 vault 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 vault on database A and read access to the issuer on database B can verify if the assets cover the liabilities. In other words, anyone can verify if the issued tokens have a fully collateralized vault as a backing.
What's next?
Cryptocurrency is an extraordinary database and a "bridge project"
Of course, if we want to move assets in the database and make it operate on a large scale, everything depends on the security of the bridge and how we trust the integrity of the sent information.
Historically, we have failed to establish secure bridges because they relied on humans to protect the sent information. This includes most major exchanges like BitFinex, Binance, Bitstamp, and worst of all, MtGox, which all experienced loss of user funds due to bridge accidents. Additionally, there are bridges for transferring funds across blockchains such as PolyNetwork, Ronin Bridge, and Harmony.
As a community, we have been experimenting with various bridge designs over the years, some relying on trusted intermediaries while others attempt to shift trust onto the consensus protocols of respective blockchains.
Validating the bridge is taking it a step further – not only trusting the decisions made by the consensus protocol, but also verifying if it is a valid decision.
Original article links:
Blockchain as a Database (Part 1)Bridging Databases (Part 2)
