ChainIDE#20 The design concept of "bridge" in the multi-chain era
Ethereum cannot meet the needs of all users due to its own scalability issues. Blockchain developers have also devoted themselves to the research and creation of other public chains. At present, an environment with more than 100 active public blockchains has been formed.Among them, public chains such as Polkadot, Cosmos, and Solana have their own user ecology, applications, and security models.
While forming this kind of multi-chain market structure, inevitably, it is necessary to realize the interoperability between different networks.Many developers are also aware of this, so as the multi-chain environment is gradually improved, the concept of "bridge" has also entered the public eye."Bridge" can unify the fragmented public chain structure, break the island effect of each public chain, and turn the public chain environment into an interconnected whole.
The specific role of "Bridge":
. Improve the productivity and utility of existing encrypted assets
. Provide more powerful product functions for existing agreements
. Unlock new features and use cases for users and developers
At an abstract level, a "bridge" can be defined as a system that transmits information (assets, contract calls, proofs, or status) between two or more blockchains.The design module of "Bridge" includes monitoring, information transmission/relay, consensus, and signature.
Type of "Bridge":
. Asset-specific type: The sole purpose of this type of "bridge" is to access a specific asset from an external chain.
. Chain-specific type: This type of "bridge" connects two different blockchain networks, and usually supports the simple operation of locking & unlocking Tokens on the source chain and casting any "packaged" assets on the target chain.
. Application-specific type: An application provides access to two or more blockchain networks, but it can only be used within the application.
. Universal: A protocol designed specifically for the transmission of information across multiple chains.
According to different verification mechanisms for cross-chain transactions, the design types of "bridges" are as follows:
. External Verifier & Federalism
Usually there is a group of validators that monitor the "mailbox" addresses on the source chain and perform operations on the target chain after they reach a consensus.
The transfer of assets is usually done by locking the assets in the mailbox and casting the same amount of assets on the target chain. These verifiers usually need to pledge a separate token to ensure security.
. Light client & relay
Participants monitor events on the source chain and generate encrypted proofs of past events recorded on the chain.
Then, these proofs and the block header are forwarded to the contract on the target chain (ie, "light client"), and then the target chain will verify whether an event is recorded, and perform operations after verification.
. Liquidity Network
This design is similar to a peer-to-peer network, where each node acts as a "router", holding the "inventory" of the source chain and target chain assets.
Do you think there is the best "bridge" design? Please leave your opinion.
Please talk about the "bridge" you know.
Welcome to discuss here!