Interoperability is a recently emerging concept in Web 3, referring to the ability of different computer systems, networks, operating systems and applications to work together and share information. As the communication and semantic interaction on the chain become more and more complex, the diverse needs of users on the chain have exceeded the technical capabilities that can be applied to a single chain.

The Web 3 application, which was originally regarded as an innovative experiment, has gradually been accepted by the public, and its appearance has given the dawn of possible solutions to key problems. Issues such as information opacity, security, and underlying technology will be improved by relying on the technical advantages of the blockchain. However, there is a long way to go on the road to support the technical foundation of experimental innovation to popularize.

secondary title

TL;DR

• text

• Today's public chain solutions face problems such as mismatched chain performance and operating costs, fragmented liquidity, and limited customizability, which virtually limit the diversity and scale expansion of on-chain applications;

• From decentralized applications to customized application chains is a feasible way to realize business scale from 1 to 100, and dYdX is making valuable attempts;

• Connected Contracts led by Moonbeam is helping more cross-chain interoperability protocols move from commonly used EVM compatibility to native multi-chain business expansion;

• "Containerized app chain" is an important step for Moonbeam to become a Web 3 cloud infrastructure. The challenges that restrict the construction of public chains such as security, underlying deployment, and customization will be easily solved.

as i wasOpening talk for Illuminate/22first level title

History does not repeat itself, but there will always be striking similarities

My sharing will include:

• Moonbeam focuses on the background of cross-chain

• How we build cross-chain solutions

• Why do you believe in a multi-chain future?

History can always inspire me, and looking back at technological changes has benefited me a lot.

As Mark Twain once said, history does not repeat itself, but there are always striking similarities.

We can perceive a set of laws of development from history. For me, the development history of general-purpose computing is a lesson worth learning. Its changes and evolution are similar to the road of blockchain (Web 3) moving forward with the giant wheel of time, and it continues to develop over time.

Here I show two timelines. I believe you still remember that computers were expensive and scarce in the early days of their birth, and computer resources were scarce. However, thanks to the perfect functional system in the later period, more users shared the functions of computers.

Compared to now, this pattern still exists, and is even correct in some respects, when we extend it to the blockchain, the Ethereum mainnet, and even Moonbeam.

We all know that the resources on the blockchain are still scarce, and many users still share the resources of the blockchain like computers. In this way, the blockchain can also be simply regarded as a community-based computer.

Up to now, our blockchain has undergone a new evolution, and the application chain (APP Chain) has come into view. This is somewhat similar to the historical path of computer popularization. Instead of sharing the resources of a computer, we have our own computer directly.

By analogy, Lisk is also expressing this concept in the blockchain world: that is, in Web 3, your application will match its own blockchain instead of a shared resource blockchain platform.

I think we are in a symbiotic environment of thousands of chains, whether it is the application chain or the smart contract platform for sharing resources, it is the first time to appear together. They can pass information to each other.

You must know that "multi-chain" is something that has entered the public eye this year. Many people may not realize that cross-chain interoperability has emerged this year, but it has successfully attracted the attention of the industry in the early stages of development, and it may become the underlying infrastructure of decentralized applications.

first level title

Connected Contracts is an effective solution to achieve interoperability

In this vision, Moonbeam focuses on what we describe asConnected Contracts. Through the cross-chain interoperability protocol, smart contracts can acquire users, services, etc. from any chain on Moonbeam. There are already a large number of applications running on Moonbeam in this way, and you will see more demonstrations of well-known projects using cross-chain interoperability protocols to realize their own business, including the introduction of how their business is developed and used.

Back to Moonbeam, how did we realize the idea of ​​Connected Contracts?

Key point 1: Integrate as many cross-chain interoperability protocols as possible. As a parachain developed based on Polkadot, we have the advantage of native access to XCM, which is a cross-chain communication system.

Key point 2: Realize the integration of multiple types of information transmission systems in Moonbeam, such as Axelar, LayerZero, Wormhole, Hyperlane and more protocols are shining brightly in Moonbeam.

We are doing our best to provide developers with more choices and help them integrate more blockchains at the same time.

At the same time, we also built aFully compatible with the development environment of Ethereum. This is a huge project that requires simultaneous introduction of multiple development tools and infrastructure to jointly create a friendly and familiar development environment. For example, block browsers such as Etherscan that everyone is familiar with, or various development tools that everyone expects to use in an EVM compatible environment.

first level title

The existing multi-chain deployment solution cannot solve the essential problem of business expansion

So, what is the current status of multi-chain development, and what bottlenecks have you encountered?

In the first wave of multi-chain deployment, multi-chain tends to be more deployed.

Specifically, if an agreement wants to operate on 5 different blockchains, it may need 5 different sets of contract agreements to support the application's ability to run on 5 different public chains. For example, you need to deploy a set of contracts on the Ethereum mainnet, a set on Polygon, and a separate set of contracts on Moonbeam or BNBChain.

This method realizes the idea of ​​multi-chain deployment, but each contract on each public chain is like an isolated island, and users and services cannot collude with each other between chains. The obvious disadvantage is the challenge of fragmentation.

As a user, you must know which network you are on. If you want to move to the same protocol on another network, you need to use the power of a third-party cross-chain bridge to re-convert the assets to the new network and start again.

first level title

Prime Protocol provides a liquidity fragmentation solution

To give an example, this case can also be heard later in the explanation of Prime Protocol member Colton, which is an underlying architecture solution that supports multi-chain information transmission. Prime Protocol has created a native multi-chain architecture, which is a hub-and-spoke architecture that helps you deploy business on all public chains that want to interact with contracts, and at the same time realize the intercommunication of business between different chains.

Coordination between multiple chains only needs to focus on one chain, instead of dispersing energy to each public chain that deploys business. It's like having a super smart contract. Let's call it a multi-chain hub built on Moonbeam. Business interactions on other chains are like remote satellites around the hub, such as on the Ethereum mainnet, BNBChain or other public chains.

According to this idea, Prime helps users realize the possibility of users interacting with any other public chain on one chain, and the information transmitted across chains can also be transmitted to the central hub of the cross-chain. For example, the actions of users depositing assets on other chains can be read remotely and directly used as credentials as a reference for interaction on another public chain. This is like a coordinated main hub and branches on the chain.

first level title

Moonbeam achieves the first cross-chain interaction between Polkadot and Cosmos

Another real case of Connected Contracts cross-chain isCross-chain interaction between Moonbeam and Osmosis。

Osmosis is a DEX based on the Cosmos SDK. They hope to realize the function of depositing DOT with one click. Users can directly deposit native DOT into the deposit address located in Osmosis.

A lot of complex logic is hidden behind this function. When users use native DOTs, these DOTs need to go through Moonbeam, become xcDOT through XCM, and then route to Cosmos interchain through Moonbeam’s Axelar and then to Osmosis. When DOT enters Osmosis, the action of synthesizing LP will be triggered.

It's like chain osmosis, with many steps happening in a multi-chain transfer. But looking back, users don't need to understand these tedious steps, because they don't need to undertake all the complicated operations. This is a very typical and simple user experience, and it also shows the great power of the Connected Contracts smart contract. Hide complex technical principles and underlying technology, and present a simple and convenient experience to end users.

first level title

Building a cloud infrastructure for Web 3 is Moonbeam's goal

Regarding what Moonbeam is planning, I will also make some introductions, that is, Containerized app chains (containerized application chains).

first level title

What drives application quality to application chain?

Looking back on the past few years, a large number of application chains have been launched on various basic layers. Even if we only look at three ecosystems: Polkadot, Avalanche, and Cosmos, a large number of application chains have been born in these ecosystems.

You can find some well-known projects in the industry, such as dYdX (the largest decentralized derivatives platform in the industry), this project started on the Ethereum mainnet, and then they migrated to Layer 2 solutions and landed in Starkware to expand their business . Recently, dYdX announced that they are building an application chain in Cosmos. Seeing this kind of phenomenon, it is worth thinking about why the next step of the application is the application chain?

I think there are several key drivers.

First, performance and cost. Imagine that when you are on a shared platform and need to obtain a lot of resources from this platform, the price of resources will rise with the demand. Over time, users who use your products will have to bear the negative damage caused by the increase in service costs.

It is not difficult to find such problems in the process of casting NFT. The operation efficiency of the chain becomes slower, and the usability of NFT decreases accordingly. If you have a dedicated application chain, it will not be a problem to configure various functions on the chain, because this is a chain exclusive to your product app, and the user experience can be well protected.

For an application that is experiencing rapid growth, it is very attractive for them to expand the business scale and hope that users will grow exponentially.

Second, customizability. With the expansion of dapp business, products will need to cover a wider user group. The execution ability of product landing will become the driving force for optimizing dapp. If the flexibility of business expansion can be satisfied in the infrastructure, it will be of great benefit to the improvement of efficiency.

I believe this factor will also push the project party to have a chain dedicated to its products, and realize a customized, flexible and optimized development environment.

The final motivator, perhaps a bit more philosophical, is value capture. When your application is upgraded to a public chain, the token circulating in the application will have the same value as the Layer 1 public chain. It has important functions to protect the security and stability of the basic chain, such as pledge or other functions will be integrated into the token itself. Therefore, this is also one of the important driving factors for the project party to choose to become the application chain.

The above three factors are the main reasons why I think the driving project becomes the application chain.

first level title

What are the challenges of becoming a Lisk?

For example, the most basic requirements for infrastructure, you will need a set of Bootstrap validators, create (or find) a group of block producers, or set the role of producing blocks for the entire chain, you have to pay attention to a lot of basic work. However, when you use a shared resource platform such as a public chain for these tasks, you can directly obtain these resources by paying. Therefore, from application to application chain, for many project parties, it is a turning point of qualitative change, which also makes many project parties daunted by the independent development of application chain planning.

Another important issue is security. Paying for the security of the chain may not be directly proportional to the actual efficiency of the chain. To put it bluntly, if your product is released for the first time, but the product is not popular with the market, but in order to maintain the application chain, you still have to pay a huge fee for security. Even the security of the application chain is not stable in the early stage. There may only be a small-scale validator set to maintain, and the economic value of the token is not reflected in the early stage. At this time, the chain is vulnerable to external malicious attacks.

Third, around the challenges faced by existing public chains, the limitations of composability and fragmented liquidity still exist. After all, all you can rely on is the public chain developed by yourself (Moonbeam also has a complete EVM development environment support, and the composability of EVM is applicable to most projects).

first level title

Prospects for Containerized App Chain

I'm thinking about a concept, let's call it "Containerized app chain". The goal of this concept is to make it very simple for developers to build an application chain.

Developers only need to follow the logic of building a blockchain or use the features of Substrate Runtime to change the corresponding code according to their own product requirements, while Polkadot and Moonbeam are the providers of application chain security.

Note that there is a new function here, that is, the Container itself will be an execution environment, which will provide the functions required by the complete application chain and other services required to develop the application chain. Therefore, Container is an execution environment that supports block production and maintains the state of the blockchain, and is the technical support that supports chain operation (block production).

If you also agree with my point of view, assuming that we really landed in a container-like execution environment, the benefits we can benefit are obvious.

For example, the ability to control costs and expand business that I just mentioned. And the realization of all this is as simple as deploying smart contracts in Moonbeam's EVM-compatible environment. Developers don't need to worry about building the most basic infrastructure, just focus on the code related to their own product performance.

I think this feature has incredible potential, and the ease of use of this feature is exciting.

I hope to take this opportunity to show you a map, how Container will go to the ground, and let the various application chains be combined. This PPT will show a wider field of view than Moonbeam. Among them, you will find that Moonbeam plays a key role in the EVM execution environment-becoming the gateway of each integration, because Moonbeam is connected with various cross-chain protocols, and has a better performance than native DeFi that is only compatible with the EVM execution environment ecosystem.

I have a broader view that in the future more services are needed to provide a better developer experience, help them manage the entire life cycle of their products, and continue to expand their business and attract more users.

Under the above architecture, Moonbeam and all service components are obviously the key parts, which are like routers, passing various information across. The App chain Container I just mentioned is the basis for realizing these components. You need to complete a lot of work to complete the construction of the basic work. After the application chain is established, you need to process a large number of transactions on different chains, but the interaction of these businesses will still return to Moonbeam, an independent business, but it can closely interact.

My industry vision is to build a cloud-like development environment. As a developer, use different services to build applications, and can interact with each other and work together. It can almost be regarded as a product toolkit dedicated to each product.

This is the industry vision I'm thinking about these days.

Moonbeam will play a key role in this - the role of interconnection and free transfer.

Watch the video replay: https://www.youtube.com/watch?v=698 Ae-O 17 po