As a proponent of the Move programming language, every time I promote Move to developers, I always encounter the same question: What are the advantages of Move? Why Move?

It's like introducing your new lover to a friend - you always face similar questions. However, this question is not easy to answer. If we list the pros and cons one by one, there will always be people who question them. After all, the ecosystem of a new language is not yet mature, and the choice can only be based on its potential. Let me make a statement: Move has the most potential programming language to build an ecosystem like Solidity, and even surpass Solidity.

Target audience: Developers who are interested in the technology of the blockchain field. This article hopes to explain the current challenges faced by smart contracts and some solutions of Move in a simple way, with minimal use of code, so that readers who do not understand programming languages can also roughly understand it. Feedback from readers is appreciated.

This article was written in May 2022, when Move was just emerging and there was no current scale. I translated and reposted it here,original link.

Two Paths of Smart Contract​

If we go back a few years, there were mainly two ways to support Turing-complete smart contracts on new public chains.

One is to tailor existing programming languages and run them on universal virtual machines such as WASM. The advantage of this approach is that the current programming languages and WASM virtual machine ecosystem can be reused.

The other is to create a new smart contract programming language and virtual machine from scratch, like Solidity and Move.

At that time, many people were actually not optimistic about the Solidity&EVM ecosystem. They thought that Solidity was only useful for token issuance, had poor performance, weak tools, and was like a toy. The goal of many chains was to enable developers to use existing languages for smart contract programming, and the first path was more favored. There were few new public chains that directly copied Solidity&EVM.

However, after several years of development, especially with the rise of DeFi, people suddenly found that the Solidity ecosystem was different. The smart contract ecosystem that took the first path did not grow up. Why? I summarize a few reasons.

1. The blockchain's program runtime environment is very different from the operating system's program runtime environment. If we discard the libraries related to system calls, file IO, hardware, network, concurrency, and consider the execution cost on-chain, the amount of libraries that can share with smart contracts is very limited.
2. The first solution theoretically supports many languages, but in reality, programming languages with a runtime compiled into a virtual machine similar to WASM result in very large files, making it unsuitable for use in blockchain scenarios. The only ones that can be used are mainly C, C++, Rust, etc. without a runtime. The learning curve of these languages is not lower than the cost of smart contract programming languages like Solidity. Supporting multiple languages at the same time may lead to the fragmentation of early ecosystems.
3. Each blockchain has a different state handling mechanism, so even if they all use WASM virtual machines, smart contract applications on each blockchain cannot be directly migrated, and they cannot share a common programming language and developer ecosystem.

For application developers, they directly face smart contract programming languages, the basic libraries of programming languages, and whether there are reusable opensource libraries. The security of DeFi requires smart contract code to be audited, and every line of audited code represents money. If developers can slightly modify and copy existing code, they can reduce audit costs.

Now it seems that although Solidity took a seemingly slow path, it actually built its ecosystem faster. Many people now believe that Solidity&EVM is the endpoint of smart contracts, and many chains are beginning to support or port Solidity&EVM.

At this point, a new smart contract programming language needs to prove that it has stronger ecosystem building capabilities to convince people to pay attention to and learn to use it.

So the new question is, how to measure the ecosystem building capabilities of a programming language?

Programming language's ecosystem building ability​

The ecosystem building ability of a programming language refers to its code reuse capability, which mainly manifests in two aspects:

1. The dependency method between modules of the programming language.
2. The combination method between modules of the programming language.

"Composability" is a feature touted by smart contracts, but in fact, programming languages all have composability. We invented interfaces, traits to make composition more convenient.

Let's talk about the dependency method first.

Programming languages typically implement dependencies through three methods:

1. Using static libraries, which statically link dependencies during compilation and package them in the same binary.
2. Using dynamic libraries, which dynamically link dependencies at runtime. The dependencies are not included in the binary, but must be deployed on the target platform in advance.
3. Depending on remote procedure calls (RPC) at runtime. This refers to various APIs that can be called remotely.

Methods 1 and 2 are generally used in the common library. Common libraries are usually stateless, as it is difficult to assume how an application handles state, such as which file to write to or which database table to store in.

This kind of call occurs in the same process and method call context, sharing the call stack and memory space, with no strong isolation (or weak isolation), and requires a trusted environment.

Method 3 actually calls another process or a process on another machine, communicating with each other through messages, and each process is responsible for its own state. Therefore, state dependencies can be provided, and the call also has security isolation.

Each of these three methods has its pros and cons.

Method 1 includes the dependency libraries in the final binary, which has the advantage of not requiring the target platform environment, but the disadvantage of producing a larger binary.

Method 2 has the advantage of producing a smaller binary, but requires a runtime environment.

Method 3 can build cross-language dependency relationships and is generally used in scenarios involving cross-service or cross-organization collaboration. To facilitate developer calls, it is generally simulated as a method call through SDK or code generation.

In the history of technology, many programming languages and operating system platforms have spent a lot of effort trying to bridge the gap between remote and local calls, trying to achieve seamless remote calling and composition.

Just mention a few famous technical terms, such as COM (Component Object Model), CORBA, SOAP, REST, etc., all of which are used to solve these problems. Although the dream of seamless call has been shattered, and everyone finally relied on engineers to manually connect interfaces, splicing together the entire Web2 service, the dream is still alive.

Smart contracts have brought new changes to the dependency methods between applications.

Changes brought by Smart Contracts​

The dependency between traditional enterprise applications can be illustrated by the following figure:

1. Systems are connected through various RPC protocols, linking services running on different machines.
2. Various technical and manual "walls" are put in place between machines to ensure security.

In contrast, the execution environment of a smart contract is a sandbox environment constructed by the node of the blockchain. Multiple contract programs run in different virtual machine sandboxes within the same process, as shown in the following figure:

1. Calls between contracts are calls between different smart contract virtual machines within the same process.
2. Security depends on the isolation between smart contract virtual machines.

Using Solidity as an example, Solidity contracts (modules indicated as contract) declare their functions as public, and then other contracts can directly call the contract through this public method.

An RPC call process is shown in the following figure:

Image source https://docs.microsoft.com/en-us/windows/win32/rpc/how-rpc-works

In fact, the blockchain takes over all the communication processes between the Client and Server in the above figure, automatically generates stubs, implements serialization and deserialization, and makes developers feel that remote calls are just like local method calls.

Of course, there is no silver bullet in technology, and new solutions always bring new challenges that need to be addressed.

The Dependency Challenge of Smart Contracts​

Through the previous analysis, we understand that the invocation between smart contracts is actually a method similar to remote invocation. But what if we want to call dependencies through libraries?

In Solidity, a module indicated as library is equivalent to a static library and must be stateless.

The dependency on a library will be packaged into the final contract binary during compilation.

This creates a problem: if the contract is complex and has too many dependencies, the compiled contract will be too large to be deployed. However, if it is divided into multiple contracts, it will not be possible to directly share the state, and internal dependencies will become dependencies between remote services, increasing the call cost.

Can we use the second solution, loading dynamic libraries? For example, most contracts on Ethereum depend on the SafeMath.sol library, and each contract contains its binary. Since the bytecode is on the chain, why can't it be directly shared?

Therefore, Solidity provides the delegatecall method, similar to the dynamic linking library solution, which load the bytecode of another contract into the context of the current contract, allowing the other contract to directly read and write the state of the current contract. But this requires two things:

1. The calling and called parties must have a completely trusted relationship.
2. The state of the two contracts must be aligned.

Non-smart contract developers may not understand this issue. If you are a Java developer, you can think of each Solidity contract as a Class. Once deployed, it runs as a singleton Object. If you want to load a method from another Class at runtime to modify the properties of the current Object, the fields defined in these two Classes must be the same, and the newly loaded method is equivalent to an internal method, with full access to the internal properties of the Object.

This limits the use case and reuse of dynamic linking, and it is now mainly used for internal contract upgrades.

Because of the above reasons, it is difficult for Solidity to provide a rich standard library (stdlib) like other programming languages, to be deployed on the chain in advance and depended on by other contracts. It can only provide a few limited precompiled methods.

This has also led to the inflation of EVM bytecode. Many data that could have been obtained from the state via system contract code were forced to be implemented through virtual machine instructions. For example, instructions such as BLOCKHASH, BASEFEE, and BALANCE, the programming language itself does not need to know the chain-related information.

This problem is encountered by all chains and smart contract programming languages. Traditional programming languages did not consider security issues within the same method call stack, and when moved to the chain, they can only rely on static dependencies and remote dependencies to solve the dependency relationship. Generally, even a delegatecall solution like Solidity is difficult to provide.

So how can we achieve a way of calling between smart contracts similar to dynamic library linking? Can the invocation between contracts share the same method call stack and directly pass variables?

This approach brings two security challenges:

1. The security of the contract's state must be isolated through the security of the programming language itself, rather than relying on the virtual machine for isolation.
2. The cross-contract variable transfer needs to ensure safety and prevent arbitrary discarding, especially for variables that express asset types.

State Isolation for Smart Contracts​

As mentioned earlier, a smart contract actually executes code from different organization in the same process. Therefore, it is necessary to isolate the contract's state (which can be simply understood as the results generated when the contract is executed, which need to be saved for use in the next execution) to avoid security problems caused by allowing one contract to directly read and write the state of another contract.

The isolation solution is actually easy to understand - give each contract an independent state space. When executing a smart contract, the current smart contract's state space is bound to the virtual machine, which means that the smart contract can only read its own state. If another contract needs to be read, it needs to use the contract invocation mentioned earlier, which is actually executed in another virtual machine.

However, this isolation is not enough when using dynamic libraries for dependencies. Because another contract is running in the execution stack of the current contract, we need language-level isolation rather than virtual machine isolation.

In addition, the state space isolation based on contracts also brings up the issue of state ownership. In this case, all states belong to the contract, and there is no distinction between the public states of contracts and the personal states of users. This makes it difficult to calculate state fees, and in the long run, there will be a problem of state explosion.

So how can we achieve state isolation in smart contract languages? The idea is actually simple - based on types.

1. Utilize the visibility constraints that programming languages provide for types, a feature that most programming languages support.
2. Utilize the mutability constraints that programming languages provide for variables. Many programming languages differentiate between mutable and immutable references, such as Rust.
3. Provide external storage based on types as keys, limiting the current module to only read external storage using the types it defines as keys.
4. Provide the ability to declare copy and drop for types in programming languages, ensuring that asset-like variables cannot be copied or discarded.

The Move language uses the above solutions, with points 3 and 4 being unique to Move. This solution is also easy to understand because if we cannot give each smart contract program a separate state space at the virtual machine level, then using types for state isolation is a relatively easy-to-understand way because types have clear ownership and visibility.

In Move, the smart contract invocation between different organizations and programs is as shown in the following figure:

Different programs from different organizations are combined into the same application and run through dynamic libraries, sharing the same memory world of the programming language. Organizations can pass messages, also pass references and resources to each other. The rules and protocols for interaction between organizations are only constrained by the rules of the programming language. (The definition of resources will be described later in the article.)

This change brings several advantages:

1. The programming language and the chain can provide a rich library that can be deployed on the chain in advance(called XChain-Framework). Applications can directly depend on and reuse it, without including the std library in their own binaries.
2. Since the code of different organizations is in the same memory world state of the same programming language, richer and more complex combination methods can be provided. This topic will be described in detail later.

The dependency mechanism of Move, while similar to the dynamic library pattern, also utilizes the state-managing feature of the chain, bringing a new dependency pattern to programming languages.

In this pattern, the chain serves both as the execution environment for smart contracts and the binary repository for smart contract programs.

Developers can freely combine smart contracts on the chain through dependencies to provide a new smart contract program, and this dependency relationship is traceable on the chain.

Of course, Move is still in its early stages, and the capabilities provided by this dependency mechanism have not been fully utilized, but the prototype has emerged.

It can be imagined that in the future, incentive mechanisms based on dependency relationships will definitely appear, as well as new open source ecosystems built on this incentive model.

Later, we will continue to discuss the issue of "composability".

Composability of Smart Contracts​

Composability between programming language modules is another important feature of building a programming language ecosystem. It can be said that it is the composability between modules that needs dependencies, and different dependency methods provide different composability.

According to the analysis of dependency methods above, when discussing the composability of smart contracts in the Solidity ecosystem, it actually mainly refers to the combination of contract, not the combination of library. As mentioned earlier, the dependency between contracts is a type of dependency similar to remote invocation. What is actually passed between them is a message, not a reference or resource.

Here, the term resource is used to emphasize that this type of variable cannot be copied or discarded arbitrarily within the program, which is a feature of linear types that is not yet popular in programming languages.

Linear types come from linear logic, and linear logic itself is designed to express logic related to resource consumption that classical logic cannot express.

For example, if we have "milk," we can infer "cheese" logically, but we cannot express resource consumption or the logic that X units of "milk" can produce Y units of "cheese". Therefore, linear logic and linear types were developed, which can be applied in programming languages.

The first resource to be managed in programming languages is memory. Therefore, one application scenario of linear types is to track the use of memory to ensure that memory resources are properly reclaimed, such as in Rust. However, if this feature is widely promoted, we can simulate and express any type of resource in the program.

So why is it important to pass resources during composition? Let's first understand the current composition method based on Interface, which is the composition method used by most programming languages, including Solidity.

The most important thing when combining multiple modules is to agree on the functions to be called, as well as the parameter and return value types of the functions, which are generally called the "signature" of the function. We usually use Interface to define these constraints, but the specific implementation is left to each party.

For example, the ERC20 Token that people often talk about is an Interface that provides the following methods:

function balanceOf(address _owner) public view returns (uint256 balance)
function transfer(address _to, uint256 _value) public returns (bool success)

The definition of this interface includes a method for transferring Token to a specific address and a method for checking the balance, but there is no direct method for withdrawing Token. This is because in Solidity, tokens are a service rather than a type. Here is a similar method defined in Move:

module Token{
   struct Token<TokenType>{
      value: u128,
   }
}
module Account{
    withdraw(sender: &signer, amount):Token<STC>;
    deposit(receiver: address, token: Token<STC>);
    transfer(sender, receiver, amount);
}

As you can see, Token is a type, and a Token object can be withdrawn from an account. Some may ask, what is the significance of doing this?

We can compare the two methods of combination using a common analogy. A Token object is similar to cash in everyday life. When you want to buy something from a store, there are two payment methods:

1. The store and the bank have an interface connection to an electronic payment system. When you pay, you initiate a request to the bank to transfer the funds to the store.
2. You withdraw cash from the bank and pay at the store. In this case, the store does not need to connect to the bank interface in advance, it just needs to accept this type of cash. As for whether the store locks the cash in a safe or continues to deposit it in the bank after receiving it, that is up to the store to decide.

The second type of combination method can be called a resource-based combination method. We can refer to the resource that flows between contracts of different organizations as "free state".

The resource-based combination method is more similar to the combination method in the physical world, such as CDs and players, various machine components. This combination method is not in conflict with the interface-based combination method. For example, if multiple exchanges (swap) want to provide a unified interface for external integration, using the interface-based combination method is more appropriate.

There are two key advantages of the resource-based composition:

1. It can effectively reduce the nesting depth of interface-based composition. (flash loans is a good example for this but considering that some readers may not be familiar with the background of flash loans, I won't elaborate on it here).
2. It can clearly separate the definition of resources from the behavior based on resources.

A typical example is the NFT for soulbound. The concept of NFT for soulbound was proposed by Vitalik. It is intended to use NFT to express a certain identity relationship, which should not be transferable, such as graduation certificates, honor certificates, etc.

However, the NFT standards on ETH are all interfaces, such as several methods in ERC721:

function ownerOf(uint256 _tokenId) external view returns (address);
function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;

If you want to extend new behaviors, such as binding, you need to define new interfaces. This will also affect old methods, such as transferring NFT. If the NFT has been soulbound, it cannot be transferred, which will inevitably bring about compatibility issues. Even more challenging is the scenario where it is initially allowed to transfer but becomes untransferable after binding, such as some game props.

But if we think of NFT as an item, the item itself only determines how it is displayed and what properties it has. Whether it can be transferred should be encapsulated at the upper level.

For example, the following NFT defined using Move is a type.

struct NFT<NFTMeta: copy + store + drop, NFTBody: store> has store {
    creator: address,
    id: u64,
    base_meta: Metadata,
    type_meta: NFTMeta,
    body: NFTBody,
}

Then we can imagine the upper-level encapsulation as different containers with different behaviors. For example, when NFT is placed in a personal gallery, it can be taken out, but once it is placed in some special container, it requires other rules to be met before it can be taken out, which realizes "binding".

For example, Starcoin's NFT standard implements a container for soulbound NFT called IdentifierNFT: (The code is simplified)

/// IdentifierNFT contains an Option<NFT> which is empty by default, it is like a box that can hold NFTs
struct IdentifierNFT has key {
        nft: Option<NFT<T>>,
}

/// Users initialize an empty IdentifierNFT under their own account through the `accept` method
public fun accept<T>(sender: &signer);

/// Developers grant the NFT to receiver by using the MintCapability, and embed the NFT into the IdentifierNFT
public fun grant_to<T>(_cap: &mut MintCapability, receiver: address, nft: NFT<T>);

/// Developers can also take out the NFT in the IdentifierNFT of `owner` using the BurnCapability
public fun revoke(_cap: &mut BurnCapability, owner: address): NFT<T>;

The NFT in this box can only be granted or revoked by the issuer of the NFT, while the user can only decide whether to accept it or not. For example, in the case of a graduation certificate, the school can issue and revoke it. Of course, developers can also implement other rules for the container, but the NFT standard is unified. For readers interested in the specific implementation, please refer to the link at the end of the article.

This section illustrates a new way of combining things in Move based on linear types. However, the advantage of language features alone cannot naturally bring about an ecosystem of programming languages; there must also be application scenarios. Let's continue to discuss the application scenario expansion of the Move language.

Expanding the Application Scenarios of Smart Contracts​

Move, originally designed as the smart contract programming language for the Libra.

At the time, we were designing the architecture of Starcoin, and considering that Move's features aligned perfectly with Starcoin's goals, so applied Move to the public chain scenario.

Later on, after the Libra project was abandoned, several public chain projects were incubated to explore different directions:

• MystenLabs' Sui introduced immutable states, attempting to implement a UTXO-like programming model in Move.
• Aptos explored the parallel execution of transactions on Layer1 and high performance.
• Pontem attempted to bring Move into the Polkadot ecosystem.
• Starcoin explored the layered scaling solution of Layer2 and even Layer3.

Meanwhile, the original Move team at Meta (Facebook) is attempting to run Move on Evm, although this may result in losing the feature of transferring resource between contracts, it helps to expand the Move ecosystem and merge it with the Solidity ecosystem.

Currently, the Move project has been spun off as a completely community-driven programming language. It faces several challenges:

1. How to find the greatest common denominator between the requirements of different chains to ensure the language's universality.
2. How to allow different chains to implement their own specific language extensions.
3. How to share basic libraries and application ecosystems among multiple chains.

These challenges are also opportunities, and they conflict with each other, requiring trade-offs, and a balancing act to be found in development.

These challenges are also opportunities, but they conflict with each other, requiring trade-offs and move community need to find a balance in development progresses.No language has attempted this kind of endeavor before. This balance can ensure that Move can explore more application scenarios, not just those tied to blockchain.

In this regard, one problem that Solidity/EVM are entirely tied to the chain, and running EVM requires simulating a chain environment. This limits Solidity from expanding to other scenarios.

There are many different views on the future of smart contract programming languages, broadly speaking, there are four types:

1. There is no need for a Turing-complete smart contract language, Bitcoin's script is enough. Without a Turing-complete smart contract language, it is difficult to achieve universal arbitration capabilities and will limit the application scenarios of the chain. This can be seen in my previous article "Opening the 'Three Locks' of Bitcoin Smart Contracts."
2. There is no need for a new smart contract language, existing programming languages are enough, as we have analyzed above.
3. A Turing-complete smart contract language is needed, but the application scenario is limited to the chain, similar to stored procedure scripts in database. This is the view of most current smart contract developers.
4. Smart contract programming languages will be promoted to other scenarios and ultimately become a universal programming language.

The last one can be called the maximalist of smart contract languages, and I personally hold this view.

The reason is simple: in the Web3 world, whether it's a game or other applications, there needs to be a digital dispute arbitration solution if there is a dispute. The key technology points of blockchain and smart contracts are about proof of state and computation, and the arbitration mechanism developed in this field can be used in more general scenarios. When a user installs an application, is concerned about its security, and wants the application to provide proof of state and computation, that is, when the application developer must choose to use smart contracts to implement the core logic of the application.

Summary​

This article explains Move's attempts to implement on-chain smart contracts and the challenges faced by current smart contracts in terms of dependency and composability. Based on these attempts, the article also explores the potential for Move ecosystem building.

Afterword: When writing this article, the Rooch project had not yet been created, but ideas about layered solution and DApp building had been brewing in my mind for a long time. Rooch is an answer to how to use Move to build DApp beyond DeFi. For more details, please see the article "The Modular Evolution of Rollup Layer2".

Links​

1. https://github.com/move-language/move The new repository of the Move project
2. awesome-move: Code and content from the Move community
3. Soulbound (vitalik.ca) Vitalik's article about NFT Soulbound
4. SIP22 NFT Starcoin's NFT standard, including the explanation of IdentifierNFT
5. Unlocking the "Three Locks" of Bitcoin Smart Contracts (jolestar.com)

This article attempts to discuss the development and evolution of Rollup Layer2 from an evolutionary perspective, mainly addressing the following questions:

1. How does Rollup work?
2. Modular evolution of Rollup
3. Possibilities brought by Modular
4. Technological trends in modular application
5. Conclusion

How does Rollup work?​

The "trilemma" of blockchain has always been a difficult problem in the industry. If we consider that Layer1 blockchain should first ensure "decentralization" and "security," migrating the "scalability" solution out of Layer1 is a natural choice, hence Layer2. The new problem is how to ensure the security of Layer2 through Layer1.

Initially, there was an idea to periodically write the state tree root of the Layer2 application to Layer1, which could verify the application state through state proof, similar to the reserve proof of CEX. However, third parties cannot verify that two state transitions are correct in a public manner using this approach.

To further explore this problem, let's abstract it. The state of any program can be expressed through a state transition formula:

σt+1 ≡ Υ(σt, T)

This formula comes from the Ethereum Yellow Paper, but it can represent any program. Here, Υ represents the program, and σ represents the state. State σt+1 is calculated by program Y through state σt and transaction T. Transaction T represents the input to the program. At any time, if σt is deterministic, Y is deterministic, and T is deterministic, then σt+1 is deterministic.

So to provide public verifiability, the key is for Y to be publicly available, all historical T to be publicly available, and for their order to be determined. The intermediate states can be recalculated through Y and T. We can achieve the public availability of the program through open source, but how to ensure the public availability of T is another issue, which introduces the concept of data availability (DA).

Data availability requires a publicly available and immutable ledger to record the transactions of the application. The blockchain ledger is a system that naturally comes to mind. Therefore, writing Layer2 transactions back to Layer1 to ensure data availability is the origin of the name Rollup.

Therefore, a role is needed in the Layer2 system to collect users' transactions, sort them, and write them to DA. This role is called the Sequencer. The transaction sequence here is called the Canonical Transaction Chain.

With data availability guaranteed, everyone can obtain the final state by running the program to execute transactions. However, consensus has not been reached yet, as everyone is uncertain whether the results obtained by them are consistent with those of others, as software or hardware failures can lead to data inconsistency. Therefore, another role is needed to periodically publish the state tree root after executing transactions, which can be used by everyone to verify their own state. This role is called the Proposer. The submitted state also forms a state sequence corresponding to the transaction sequence, called the State Commitment Chain.

At this point, we have achieved the verifiability of the application. But if someone's result is inconsistent with the state submitted by the proposer, and it is determined that the problem is not with themselves, then it means the proposer cheated or made a mistake. How can others know about this? This requires the role of an Arbitrator. The arbitrator needs to be a trusted third party, which can be fulfilled by a contract on the chain.

There are two arbitration schemes for rollups:

1. Each time the Proposer submits a state, they also provide the validity proof, which proves the validity of state transition between the current state and the previous one, and is verified by the arbitration contract on-chain. The validity proof is generated using zero-knowledge techniques, which is called ZK Rollup.
2. Assuming the Proposer's results are correct, but if inconsistencies are found, fraud proof is submitted, which is judged by the arbitration contract. If the arbitration contract determines that the Proposer has cheated, the Proposer will be penalized, and the State Commitment Chain will be rolled back to the state before the fraudulent transaction. Of course, to ensure safety, a relatively long challenge period is usually set to achieve the final settlement of on-chain transactions. This is called Optimistic Rollup.

We also need to achieve asset interoperability between Layer1 and Layer2. Therefore, we build a bridge between Layer1 and Layer2, and use state proofs for asset settlement between them. Layer2's state root on Layer1 is guaranteed by Layer1's arbitration contract, so the security of this bridge is also guaranteed by the arbitration contract.

At this point, we have obtained a Rollup Layer2 solution secured by Layer1 which allows for asset interoperability with Layer1.

Of course, the Rollup solution has made some compromises:

1. Writing transactions to Layer1 means that the scalability of Layer2 is still limited by Layer1's block size. For example, in Ethereum, if a Layer2 fully occupies all Ethereum blocks, the average TPS it can provide is only a few hundred, and its scalability is limited by DA.
2. In order to save gas fees, the Sequencer will batch transactions into DA. Before writing to DA, the Sequencer may cheat by adjusting the order of transactions.

Here's a summary of the security and finality of transactions in Layer2:

1. If a user runs a Layer2 node and executes transactions in the order provided by the DA, the user can assume that the transactions are instantly confirmed and eventually settled because if the result of the user's execution differs from that of the Proposer, it indicates that the Proposer cheated and the on-chain state needs to be rolled back, which will eventually match the result of the user's own node. The main risk here is the risk mentioned earlier, which is the risk associated with the Sequencer adjusting the order of transactions that have not yet been written to the DA when syncing data in real-time.
2. If a user cannot run a node themselves and relies on an RPC provider, the user needs to take on a certain level of trust risk. However, this risk is similar to the risk of trusting a Layer1 RPC node. The additional risk here is the risk of the Sequencer discarding or rearranging transactions.
3. If the Proposer is wrong but no node initiates a challenge and the challenge period expires, the incorrect state cannot be rolled back, and the state can only be repaired through a hard fork by social consensus.

Modular evolution of Rollup​

Based on the previous analysis, in the Rollup solution, multiple contracts on the chain play different roles and represent different modules. It is natural to think about whether modules can be split across multiple chains to achieve higher scalability. This is the idea of modular blockchain and modular Rollup.

Modular has two meanings here:

1. Through modular design, the system becomes a plug-and-play system. Developers can meet different application scenario requirements through module assembly.
2. Based on the ability provided by 1, the implementation of the modular layer is not bound to the same Layer1, thus obtaining better scalability.

There are three main modular layers that we can consider:

• Data Availability Layer: Ensures that the transaction data of the execution layer can be obtained in a public way, and ensures the transaction sequence.
• Settlement Layer: Implements asset and state settlement between Layer1 and Layer2. It includes the State Commitment Chain and the Bridge.
• Arbitration Layer: Verifies fraud proofs and makes judgments (optimistic) or verifies valid proofs (ZK). The arbitration layer must have the ability to manipulate the State Commitment Chain.

DA Modular​

By migrating the DA function out and using an independent solution, the primary benefit is that the transaction gas fee of Layer2 is reduced by at least one order of magnitude.

From a security perspective, even if the decentralization of the DA chain is weaker than Ethereum, the main guarantee of the security of the DA layer is the transactions during the challenge period. After the challenge period, the DA is mainly used to facilitate other nodes to synchronize data, and it does not have a security guarantee. Therefore, the requirement for decentralization can be reduced by one level.

A DA dedicated chain can provide higher storage bandwidth and lower storage costs, and can be specifically designed for multiple applications to share the DA. This is also the foundation of current DA chains like Celestia and Polygon Avail.

After splitting the DA layer, we obtain the architecture shown in the figure below:

In the above figure, the DA is responsible for saving the Canonical Transaction Chain, and Layer1 is left with an L1ToL2 Transaction Queue to implement message communication between Layer1 and Layer2. Users can also write transactions directly to this queue to ensure the Layer2 is permissionless and that the Sequencer cannot audit users or transactions.

However, a new problem arises here. If the transaction sequence written by the Sequencer into the DA and the transaction sequence executed by the Proposer are inconsistent, how will the arbitration contract judge? One solution is to have a cross-chain bridge between the DA chain and the arbitration chain, which verifies the data proof provided by the DA chain in the arbitration contract. However, this solution depends on the implementation of cross-chain bridges between the DA and other chains, and the DA solution selection will be restricted. Another solution is to introduce Sequence proof.

Sequence Proof​

We can think of Sequencer as part of the DA solution. It is equivalent to an app-specific DA and has the following responsibilities:

1. Sequencer needs to provide DA guarantees for the time period before batch the transactions into the DA chain.
2. Sequencer needs to verify, sort, and finally write transactions into the DA.

If Sequencer generates a Sequence Proof for each transaction, it can solve two problems:

1. It provides a guarantee for transactions that have not been written into the DA chain, making it difficult for Sequencer to arbitrarily adjust the order or discard transactions.
2. If there is no cross-chain bridge between the DA chain and the arbitration chain, the availability of data can be ensured through the challenge mechanism of Sequence Proof.

Sequence Proof has the following characteristics:

1. It carries the signature of the Sequencer, proving that it was issued by a specific Sequencer.
2. It can prove the position of a transaction in the entire transaction sequence.
3. It is a type of accumulator proof. Each transaction generates a new accumulation result after being accumulated, which is related to all historical transactions before it. This makes it difficult to tamper with the results. One of the optional solutions for the accumulator is the Merkle Accumulator, and the accumulation result is represented by the root of the Merkle Tree.

How Sequence Proof works:

A user or an execution node submits a transaction to the Sequencer. The Sequencer returns the Sequence Proof to the user and synchronizes it with other nodes. If the Sequencer discards or changes the order of transactions before submitting them to the DA, the user or other nodes can submit the Sequence Proof to the arbitration contract to slash the Sequencer. The arbitration contract needs to read the root of the transaction accumulator from the State Commitment Chain contract to verify the Sequence Proof.

Let's discuss the following scenarios:

1. Sequencer discards or rearranges user transactions, which leads to the Sequencer generating two Sequence Proofs at the same position. The user submits the Sequence Proof to the arbitration contract, and the Sequencer needs to provide proof that the transaction is included in the root of the latest transaction accumulator. If it cannot provide the proof, it will be slashed.
2. Sequencer fails to write transactions into the DA chain correctly and colludes with the Proposer to hide transactions. If there is a bridge between the DA chain and the arbitration chain, verification can be done through the bridge to slash the Sequencer. Otherwise, the user can initiate a challenge to require the Sequencer to provide proof of a transaction's position and original information. In this case, the arbitration contract cannot judge whether the user is making a malicious challenge, so the Sequencer will not be slashed if it provides the data. For users, making a malicious challenge is not beneficial and lacks economic incentives.

By introducing Sequence Proof, Layer2 protocols become more secure.

Transaction Pipeline and Parallel Execution​

By assigning the Sequencer to the DA to solely handle transaction validation and sorting, another benefit is that it is easy to implement a transaction pipeline and parallel execution.

When validating a transaction, it is necessary to verify the signature and whether there is sufficient gas fee, and gas fee verification relies on the state. If we allow the Sequencer to verify transactions with a certain delay (in seconds) between the dependent state and the latest state to ensure that validation transactions are not blocked by executing transactions, then gas verification may be inaccurate and at risk of DDoS attacks.

However, we believe that assigning the Sequencer to the DA is a correct direction, so it is worth further research. For example, the DA part of the transaction fee can be split out and expressed through the UTXO (Sui Move Object) to reduce the cost of gas fee checking.

The Sequencer sorts the transactions and outputs them into a transaction pipeline, which is then synchronized to the Proposer and other nodes. Each node can choose a parallel execution scheme based on its own server situation. Each node needs to ensure that only transactions without causal relationships are executed in parallel, and transactions with causal relationships must be executed in the order of the Sequencer, so that the final result is consistent.

The Proposer needs to periodically submit the root of the state tree and the root of the accumulator to the State Commitment Chain contract on the chain.

So we have a modular Layer2 with low gas fees, high TPS, and greater security, this is Rooch.

• MoveOS: It includes MoveVM and StateDB, which are the system's execution and state storage engines. StateDB is built with two layers of Sparse Merkle trees and can provide state proofs. As mentioned earlier, the state tree and state proof are indispensable components of Rollup applications.
• RPC: Provides query, transaction submission, and subscription services to the outside world. Can be compatible with other chain's RPC API through proxying.
• Sequencer: Verifies transactions, sorts transactions, provides sequence proof, and streams transactions into the transaction pipeline.
• Proposer: Retrieves transactions from the transaction pipeline, batch executes them, and periodically submits them to the State Commitment Chain on the chain.
• Challenger: Retrieves transactions from the transaction pipeline, batch executes them, compares them with the State Commitment Chain, and decides whether to initiate a challenge.
• DA & Settlement & Arbitration Interface: Abstracts and encapsulates different modular layers to ensure that switching between different implementations does not affect the upper-level business logic.

Interactive Fraud Proofs with Multi-Chain Support​

In the Optimistic Rollup solution, it has always been a challenge for on-chain arbitration contracts to determine when off-chain transactions have been executed incorrectly. The initial idea was to re-execute Layer2 transactions on Layer1, but the difficulty with this approach is that Layer1 contracts would have to simulate Layer2 transaction execution, which would be costly and limit the complexity of Layer2 transactions.

The industry eventually came up with an interactive proof scheme. Since any complex transaction ultimately boils down to machine instructions, if we can identify the diverging instructions, we can simply simulate the execution of instructions on the chain.

Using the same state transition formula as before:

σt+1 ≡ Υ(σt, T)

where Υ represents an instruction, T represents instruction input, and σ represents the memory state that the instruction depends on. If a state proof is generated for each σ during execution, the two parties in a dispute can interactively identify the divergence point m, and submit state σ m-1 and instruction m to the on-chain arbitration contract for simulation. The arbitration contract can then provide a judgement after execution.

The remaining question is how to generate the proof, and there are mainly two approaches:

1. Implement it directly in the contract language virtual machine, such as Arbitrum's AVM and Fuel's FuelVM.
2. Implement a simulator based on an existing instruction set, which can provide proof capabilities within the simulator. For example, Optimism's MIPS-based cannon, Arbitrum's new WASM-based Nitro, and Rooch's MIPS-based OMO.

OMO is a general bytecode simulator with single-step state proof capabilities, designed for multi-chain execution environments. With support from OMO, the arbitration layer can be modular. Any chain that supports Turing-complete contracts can simulate OMO's instructions in its contracts and act as an arbitration layer.

ZK + Optimistic Combination Solution​

The industry has been debating the pros and cons of Optimistic Rollup and ZK Rollup, but we believe that combining the two can achieve the benefits of both solutions.

Based on the previous Optimistic solution, we introduce a new role, the ZK Prover. It generates valid proofs in bulk for the transaction states submitted by the Proposer, and submits them to the arbitration contract. After verification by the arbitration contract, the transaction can be settled from Layer2 to Layer1 for finality.

The advantages of this solution are:

1. The overall throughput of Layer2 will not be limited due to the performance issues of ZK.
2. ZK can shorten the challenge period of Optimistic and improve user experience.

Before the maturity of ZK solutions and hardware acceleration, we can build the ecosystem through Optimistic, and the modular solution can seamlessly integrate ZK in the future.

Multi-Chain Settlement​

If we further consider the trend of modular, it naturally leads to the question of whether the settlement layer can be deployed on another chain, since the DA can be migrated to another chain.

The asset settlement between Layer1 and Layer2 mainly relies on two components, one is the Bridge, and the other is the State Commitment Chain. When settling through the Bridge, it is necessary to rely on the State Commitment Chain to verify the Layer2's state proof. The Bridge can certainly be deployed on multiple chains, but there can only be one authoritative version of the State Commitment Chain, which is ensured by the arbitration contract.

This direction requires further research, but there is a preliminary solution. The State Commitment Chain on other chains is a mirror of the arbitration chain (Ethereum). This mirror does not need to synchronize all Layer2 State Roots to other chains, but users can map them as needed through Ethereum's state proof.

Of course, other chains also need to be able to verify the state proof on Ethereum, so they need to know the state root on Ethereum. Currently, there are two solutions for synchronizing Ethereum's state root to other nodes: 1. relying on an Oracle. 2. embedding an Ethereum light node to verify Ethereum's block header.

In this way, we can get a Layer2 solution that supports multi-chain settlement, but whose security is guaranteed by Ethereum.

The difference between this solution and cross-chain is:

1. If it is a cross-chain solution that relies on a relay chain, Layer2 can be regarded as replacing the relay chain and is a relay layer with security guaranteed by the arbitration contract.
2. If it is a cross-chain solution that verifies the state proof between chains, the multi-chain settlement solution shares the same technical solution for state root synchronization, but it is much simpler. Th synchronization requirement for state proofs is one-way in the multi-chain settlement solution, we only need to synchronize from the arbitration chain to other chains, rather than provide for two-way synchronization between each pair of chains.

Possibilities brought by Modular​

Through modular, developers can combine Rooch with other components to create different applications.

1. Rooch Ethereum Layer2 = Rooch + Ethereum (Settlement+Arbitration) + DA This is the network that Rooch will initially run on. It provides a Move execution platform that is secured by Ethereum and can interoperate with assets on the Ethereum network. It can be expanded in the future to support settlement on multiple chains.
2. Rooch Layer3 Rollup DApp = Rooch + DApp Move Contract + Rooch Ethereum Layer2 (Settlement+Arbitration) + DA If an application deploys its settlement and arbitration to Rooch Layer2, it becomes a Rooch Layer3 application.
3. XChain Rollup DApp = Rooch + DApp Move Contract + XChain (Settlement+Arbitration) + DA Any chain can provide developers with a Move-based Rollup DApp toolkit through Rooch. Developers can write their own application logic in Move language, and run a Rollup application with security guaranteed by XChain, and can interoperate with assets on XChain. Of course, this requires collaboration with developers from each public chain.
4. Sovereign Rollup DApp = Rooch + DApp Move Contract + DA Applications can also use Rooch as a Sovereign Rollup SDK, without deploying the Bridge and Arbitration contracts. The State Commitment Chain is also saved on DA to ensure verifiability, with security ensured by social consensus.
5. Arweave SCP DApp = Rooch + DApp Move Contract + DA (Arweave) The SCP and Sovereign Rollup have similar ideas, where SCP requires the application code to be saved in the DA layer. In Rooch, contract deployment and upgrade are both transactions, and the contract code is in transaction, is written to the DA layer, so we believe it meets the SCP standard.
6. Move DApp Chain = Cosmos SDK + MoveOS + DApp Move Contract MoveOS can be embedded as an independent Move execution environment in the runtime environment of any chain to build application chains or new public chains.
7. Non-Blockchain Projects Non-blockchain projects can use MoveOS as a database with data verification and storage proof capabilities. For example, it can be used to build a local blog system, where data structure and business logic are expressed through Move. As the infrastructure matures, it can be directly integrated into the blockchain ecosystem. Another example is using it for FaaS services in cloud computing, where developers write functions in Move, and the platform manages the state. Functions can be combined and called. There are more possibilities to be explored.

Rooch's modular design can adapt to applications of different types and stages. For example, developers can first validate their ideas by deploying contracts on the Rooch Ethereum Layer2, and then migrate the application to an independent App-Specific Rollup when it grows up.

Alternatively, developers can start the application directly through the Sovereign Rollup method, because in the early stages of the application, there is no high requirement for security, and there is no need to interoperate with assets on other chains. Later, as the application grows, and the need to interoperate with assets arises, and the security requirement increases, Settlement and Arbitration modularity can be enabled to ensure the security of the assets.

Technical Trends of Modular Applications​

Potential of DA has yet to be tapped​

From the previous analysis, it can be seen that regardless of the combination method, it depends on the DA layer. The role of the DA layer in decentralized applications is similar to the log platform in Web2 systems. It can be used for auditing, supporting big data analysis, and conducting AI training. Many applications and services will be built around the DA layer in the future. Currently, there are already DA chains such as Celestia, Polygoin avail, and there will be more in the future, such as EigenLayer, Ethereum danksharding, and so on.

According to the previous analysis, we conclude that the role of the Sequencer should belong to a part of the DA layer. If the DA layer can provide transaction verification capabilities for applications and has sufficient performance, the Sequencer's responsibilities can actually be fully borne by the DA layer, and users can directly write transactions to the DA layer. Of course, whether users can pay the Gas fee for DA with the application's token is another problem that needs to be solved.

DApp programming languages will explode​

New application forms will promote the explosion of new programming languages, as already seen in the Web2 era. Move will become the best language for building Web3 DApps. In addition to Move's language features, the following reasons are based on:

1. Using the same language for DApps can quickly accumulate the basic libraries needed for the application and form an ecosystem effect. Therefore, supporting multiple languages at the beginning is not a good strategy.
2. Decentralized applications must ensure verifiability at least, and smart contract languages can reduce many mental burdens for developers in ensuring verifiability.
3. Move's platform-agnostic nature makes it easy to adapt to different platforms and applications.
4. Move's state is structured, which is beneficial for DApp's data structure expression and storage retrieval.

Conclusion​

I entered the blockchain industry at the end of 2017. at the time, many teams were trying to build applications on the blockchain. Unfortunately, the infrastructure was not yet complete and the industry had not yet figured out a replicable pattern for building applications. Most application-based projects failed, which was a blow to developers and investors. How should applications be built on the blockchain? This question has been on my mind for five years.

Now, with the maturity of Layer1, Layer2, and smart contracts, as well as modular infrastructure, the answer to this question has become gradually clearer.

I hope that in the upcoming wave of Web3 DApp explosion, Rooch can help developers build applications faster and truly land them.

Rooch Network is delighted to announce its partnership with zkMove! Rooch will work closely with zkMove to bring its zk-rollup solution to Rooch’s fully interoperable, multi-chain ecosystem. Moreover we will explore new dApp usages and build the Move community together.

Zero-knowledge rollups or zk-rollups are a next-gen Layer2 scaling solution that enable blockchains to validate transactions faster and maintain low gas fees compared to traditional Layer 1s via a combination of on and off-chain processes.

zkMove is a zk-proof friendly Move language runtime environment. The initial idea of zkMove is to improve the programmability and composability of zk-proofs technology.

Some highlights of zkMove:

1. A type safe zero-knowledge proof-friendly bytecode virtual machine
2. No compromise on performance while pursuing Turing completeness
3. Safe and efficient scaling and privacy engine

For those readers interested in a deep dive into zkMove, there is a wealth of high quality information available at the zkMove medium (https://zkmove.medium.com/). The project is also hiring qualified engineers (https://www.zkmove.net)!

Rooch Network is committed to its partnership with zkMove, and together we will work to deliver the holy grail of blockchain on Rooch~ a fully interoperable, multi-chain ecosystem supported in part by zkMove’s layered solution.

Rooch Network will partner with MoveBit to ensure the highest possible level of security independently verified by an expert third party. Founded by experts and professors in security, MoveBit is a blockchain security company focused on Move ecosystem security. MoveBit will soon be a household name in the security audit sector of the blockchain industry.

“MoveBit is a security audit company for the Move ecosystem with a vision to make the Move ecosystem the most secure Web3 destination. The MoveBit team is comprised of security leaders from academia and enterprise with 10 years of security experience. The team was one of the earliest contributors to the Move ecosystem, working with Move developers to set the standard for secure Move applications.”

Some of MoveBit’s recent audits include Aptos, Starcoin, Starcoin DAO, PolyNetwork, Starswap, Transit Finance, OmniBTC, MoveDID, and Cetus.

Rooch will secure independent formal verification through MoveBit audits during key stages of project development to ensure the utmost security and to create an atmosphere of trust for ecosystem participants. Security audits will be published in conjunction with MoveBit.

Rooch Network has an established partnership with MoveFunsDAO, "A DAO for Move developers, with the main goal of uniting the developer community to build across multiple Move chain ecosystems." At the date of this posting, MoveFunsDAO has gathered more than 250 Move developers for the purpose of collective action and learning within the broader Move ecosystem, including Aptos, Starcoin, and Sui.

Most notably, MoveFuns has already organized a CTF MOVEment in December 2022 alongside organizers Aptos, Pontem Network, and Movebit, and we expect it to foster many great opportunities for developers rushing to Move.

MoveFunsDao & Rooch will keep a close relationship with the goal of empowering developers so the greater Move ecosystem can flourish while we grow an ever larger developer community.

A long, long time ago in a galaxy, far, far, wait– January 3rd, 2009, bitcoin went live on mainnet with the mining of its genesis block, and the blockchain was born. It wasn’t until 2015 that Ethereum 1.0 broke out onto the scene, delivering its landscape altering smart contracts. Ever since the blockchain industry has been rapidly iterating. Today, a pantheon of Layer1s have risen to the fore, delivering a suite of sophisticated features and application scenarios that have begun to disrupt traditional finance as we know it.

Baked into blockchain is the need to iterate, to seek the most optimal expression of crypto technology. And the holy grail is decentralized native multi-chain settlement that makes no sacrifices in its quest for throughput, security, or centralization. What if I told you Rooch Network can deliver on this dearest wish?

Rooch was one of the earliest infrastructure teams focused on layered solutions and the Move ecosystem. In 2018 the team focused on layer2 solutions for bitcoin’s lightning network, and after building the first Move-based state channel on libra in 2019, our team built the first Move public blockchain: Starcoin, then through 2022 created the Starcoin Framework, DeFi application scenarios, Bridges, MoveJS, MovefunsDAO, & DAOspace. In 2022 the Rooch team designed OMO, a general bytecode emulator with per-step state proof, which can be used to generate fraud proofs for optimistic rollup. OMO will be deployed on Rooch with zkMove, a ZK-rollup project we have an established partnership with. Rooch's architecture combines Optimistic & ZK via its ZK Prover, achieving the benefits of both solutions.

There’s a reason a project like Rooch doesn’t exist yet… only Rooch’s team has the technical ability and experience to bring a project of this magnitude to market.

Rooch core team is made strong by its emphasis on decentralization, with its core founding members scattered across the world. Jolestar is our Move Master Jedi, the Architect of Starcoin, a genius founder committed to high ideals. Triplex is a Einstein Quant developer with years of experience in distributed storage, and has the big brain to go with it. Chirstina Li wears many hats in service of Rooch, and has a wealth of investment experience in fintech (figure, klarna) before she applied her skills to web3 at Helium. Joe Chen, a core member of Rooch, literally translated the book on Move, MoveBook. Haichao is our team’s glue, an accomplished DevRel from Algorand & Aptos. Ren is Rooch’s Marketing lead, an entrepreneur with several businesses & a published author, graduated magna cum laude from LMU with a Bachelor’s in Business Administration. Lerencao was a core dev at Starcoin, is the Architect of Rooch’s OMO, and has years of blockchain experience. Sven is our resident Web2 expert, produced web2 games, and is the dev for DAOspace. We have the architect of MoveJS, Owen WU, a battle-hardened Move dev & full-stack developer, and 0xpause, a former AI engineer that cut his dev teeth at starcoin helping build the Starcoin Framework and DAOspace. WillQ is an expert in compiler, EVM, and Rust. Lshoo is a senior developer and architect with more than 10 years of web2 development experience supported by deep competencies in Scala, Rust, WebAssembly & Move, and work experience at Cosmos and Substrate. Roy Lieu is an expert in VM with years of experience in VM development.

Rooch is THE team uniquely positioned to leverage its applied technical experience to produce a miracle in blockchain tech: Rooch Network: a modular layer2 with multi-chain settlement powered by Move language and secured by Ethereum. Almost any web2 App can be refactored into a web3 DApp by the Rooch modular framework.

Rooch will implement a generic and verifiable contract execution environment. The overall idea is inspired by Cannon, and borrows part of its implementation from the Qiling framework. The network boasts throughput at 100,000 TPS.

On its Layer2, Rooch supports Decentralized ID, a plug-and-play DAO framework that supports fully on-chain voting and governance, Wallets with increased security thanks to Move, DEX, DeFi protocols, & Marketplaces. In the case of a project building on Rooch that requires a large scale NFT issuance, such as NFT minting in the tens of millions or hundreds of millions issuance, Rooch will allow the entire process from collection planning to minting to future trading to be fully on-chain, and always trackable. So if Instagram wants to have all of its pics produced everyday as NFTs, Rooch can do that. Additionally, for NFT props in GameFi projects on Rooch, we will be able to enable the props to upgrade or level up into more powerful items while ensuring the whole process and item features remain coherent on-chain.

Here’s an industry shattering capability– not only does Rooch significantly enhance smart contract security, it opens the door to multi-chain token & NFT launches. Any team worth its salt will rush to Rooch for this feature alone.

Rooch’s Layer3 opens up a new frontier with its instant transaction confirmation and distributed P2P network. The bread and butter of web2, micropayments, are brought back from the dead for blockchain. Any application can leverage the rooch-enabled P2P network to enable microtransactions, all they have to do is pay the network fee per byte, no proof of storage required. Rooch’s Modular DApp framework lets projects broaden their target market in the planning stage, while the move language and its modules shrink the development window for faster time to market.

Rooch is the missing link, the golden goose that will deliver on the “ancient” promise of a decentralized, fast & secure, multi-chain world.