[BRC-100] A Vertical Scaling Framework for brc-20 based on BRC-100 by Mikael.btc

Intro
1

A Vertical Scaling Framework for brc-20 based on BRC-100

Summary

This proposal proposes a vertical scaling framework for brc-20 protocol, which is implemented by bridging brc-20 assets to BRC-100 protocol, similar to the vertical scaling solution of Layer 2 or side-chain for Bitcoin.

Abstract

brc-20 is a very innovative token protocol, but it does not support the decentralized applications with complex computing logic. The decentralized, censorship-resistant and permissionless DeFi applications such as AMM DEX and Lending cannot be realized within the brc-20 protocol. And the BRC-100 protocol is extended from brc-20, which is an extensible decentralized computing protocol based on Ordinals Theory, and is designed for decentralized applications like DeFi, GameFi, etc.

But currently meta-protocols on Bitcoin are heterogeneous and unable to communicate with each other. Different meta-protocols are like different chains, sharing the security of the Bitcoin blockchain and having different computing capabilities. The purpose of this framework is to extend the computing capabilities of the brc-20 protocol, by bridging the assets based on brc-20 to the BRC-100 protocol. So that brc-20 can have the computing capabilities of BRC-100 protocol, and can enjoy the state machine model, application nesting, decentralized on-chain governance and other infrastructures defined in BRC-100, which can vertically scale brc-20 in the same way that Layer 2 or side-chain vertically scales Bitcoin. From this perspective, BRC-100 can be regarded as the side-protocol of brc-20, similar to Ethereum can be regarded as the side-chain of Bitcoin.

This framework consists of two parts: relay protocol and BRC-100 protocol. The relay protocol consists of Bitcoin relay, brc-20 relay and BRC-100 relay, which are respectively responsible for the security and cross-protocol management of BTC, brc-20 assets and BRC-100 assets. The BRC-100 protocol supports UTXO model and state machine model, introduces protocol inheritance and application nesting, supports built-in decentralized on-chain governance, and make applications deployed based on BRC-100 have extensible computing capabilities. Each decentralized application scenario will be an extension protocol of the BRC-100 protocol stack. All tokens/applications that implement BRC-100 and its extension protocols are compatible with each other, which means that a token/application can be used in any other application/token or child application/token. BRC-100 relay will also exist as a BRC-100 extension protocol: BRC-103.

Description

This framework is composed of the relay protocol and the BRC-100 protocol. Assets based on brc-20 and BTC can be safely bridged through the relay protocol into the BRC-100 protocol, so that they can participate in the decentralized applications such as DeFi of the BRC-100 protocol. And users can bridge the assets back to the source brc-20 protocol or Bitcoin blockchain at any time.

Replay Protocol

Meta-protocols on Bitcoin are heterogeneous and cannot communicate with each other. Different protocols are similar to different chains. They share the security of the Bitcoin blockchain and have different computing capabilities. So BRC-100 protocol stack needs the relay protocol to complete the communication between brc-20 and BRC-100, and to bridge assets from brc-20 to BRC-100 to participate in the decentralized applications like AMM DEX, Lending.

The relay protocol uses two-way peg technology to operate in a safe and decentralized manner without trust or custody of user assets. The relay protocol is responsible for managing the transferring of assets among the Bitcoin blockchain, brc-20 and BRC-100, and includes Bitcoin relay, brc-20 relay and BRC-100 relay.

1. brc-20 Relay and Bitcoin Relay

Since the brc-20 relay and Bitcoin relay lack native support for security in the brc-20 protocol and Bitcoin blockchain, the technology: Distributed Private Key Control or MPC (Secure Multi-Party Computation) will be used to ensure the security of user assets and the completeness of protocol logic. That is, both brc-20 and BTC assets need to be entrusted to a multi-signature address, and requires that the multi-signature address cannot transfer user assets at will, and also can provide correct feedback according to the user’s withdraw operation in the BRC-100 relay.

2. BRC-100 Relay

The BRC-100 relay is defined by the BRC-103 protocol: A Relay Protocol among Bitcoin, brc-20 and BRC-100, which is an extension protocol of BRC-100. The BRC-103 protocol is inherited from the BRC-100 protocol and controls the transferring of pegged assets on BRC-100 through Transfer Proof with absolute censorship resistance and security.

Transfer Proof means that when minting pegged assets on the target protocol (BRC-100), the transfer data on the source protocol (brc-20 or Bitcoin) needs to be submitted as proof at the same time, which can be transaction hash or Inscription ID. So that all BRC-100 indexers can verify the correctness of the pegged asset mint. Transfer Proof is an important application of the BRC-100 protocol Oracle.

The following will take brc-20 token: “ordi” as an example to introduce the two-way transfer of assets based on brc-20 and BRC-100, where “bridge” is a cross-protocol application based on the BRC-100 protocol, “bridge:ordi” is a child relay application based on the relay protocol BRC-103, and is also the pegged token corresponding to “ordi”. “:” means that the application “bridge:ordi” is a child application of the parent application “bridge”.

Bridge brc-20 Token “ordi” to BRC-100

First, the user need to transfer the brc-20 token “ordi” to the owner address of the BRC-103 application: “bridge:ordi” (BRC-100 Relay). Then the user can use “mint2” operator and “issue” cop (computing operation) to mint the corresponding pegged token: “bridge:ordi” to his wallet, completely decentralized, trustless, censorship-resistant and permissionless. The user only needs to submit the Inscription ID of the “ordi” transfer of brc-20 as the proof attribute, then the BRC-100 indexers can do the verification for the mint. The example is as follows.

{ 
 "p":"BRC-103",
 "op":"mint2",
 "tick":"bridge:ordi",
 "amt":"200",
 "cop":"issue",
 "from":"bridge:ordi",
 "proof":"ordi_transfer_inscription_id"
}

Bridge “ordi” Back to brc-20 Protocol

First, the user needs to use “burn2” operator with “withdraw” cop to burn the pegged token: “bridge:ordi” to its owner address, and then the brc-20 Relay will return the brc-20 token: “ordi” to the user’s address.

{ 
 "p":"BRC-103",
 "op":"burn2",
 "tick":"bridge:ordi",
 "amt":"200",
 "cop":"withdraw",
 "to":"bridge:ordi"
}

3. The Security of Relay Protocol

The security of relay protocol is the basis for the implementation of this framework. BRC-100 can be regarded as the side-protocol of brc-20 in the framework. The security requirements for relay protocol are very similar to the security requirements for cross-chain bridge of side-chains or Layer 2.

  • The security of main protocol assets (brc-20, Bitcoin), by Distributed Private Key Control or MPC (Secure Multi-Party Computation) technology to ensure security, trustless, censorship resistance and permissionless.

  • The security of side-protocol (BRC-100) assets, by the BRC-100 extension protocol: BRC-103 to ensure security, trustless, censorship resistance and permissionless. No one, including the owner of the application, can transfer user assets at will, and minting the pegged assets must meet the requirements of Transfer Proof.

  • The security of cross-protocol processes, including two: from the main protocol to the side-protocol (BRC-100), and from the side-protocol (BRC-100) to the main protocol. For the former, BRC-103 is relied on to ensure security and “cannot be evil”. For the latter, Distributed Private Key Control or MPC (Secure Multi-Party Computation) technology is used to ensure security and “cannot be evil”.

BRC-100 Protocol

The purpose of this framework is to extend the computing capabilities of brc-20, by bridging brc-20 assets to the BRC-100 protocol, to enjoy the infrastructures provided by the BRC-100 protocol, and participate in the DeFi applications on BRC-100, where the BRC-100 protocol can be treated as the side-protocol of brc-20 protocol. Since BRC-100 protocol has been released on Sep. 2, 2023, this proposal only explains a few key points. For more details, please check: [BRC-100] Introduction to BRC-100, and BRC-100 protocol.

BRC-100 protocol is an extensible decentralized computing protocol based on Ordinals Theory. The BRC-100 protocol essentially describes a token with computing capabilities and state. Token deployed based on BRC-100 protocol is called application. Nesting and inheritance are supported by BRC-100. Nesting refers to creating child applications for an application to achieve modularity of application and extend the computing capabilities of the parent application. At the same time, the BRC-100 protocol supports protocol extension. Any protocol can inherit from BRC-100 or its extended protocol to extend the parent protocol. The BRC-100 protocol includes three parts: attribute, operation and computing operation. The operation cannot be extended to ensure that all tokens based on BRC-100 and its extension protocols are compatible with each other, attributes and computing operations can be extended by the extension protocol.

1. State of Application and Address

Besides the UTXO model, the BRC-100 protocol also introduces the state machine model to extend the computing capabilities of the protocol. Applications, child applications and addresses can all have states. For example, an application can hold tokens, and the address can have a balance in the application. The conversion of UTXO and state is completed through the operators: burn2/burn3 and mint2/mint3. The computing operation(cop) is used to represent specific computing logic, that is, the transition logic of application and address state. For example, address A burn 10 token1 to the application through the burn3 inscription. At this time, the application owns this UTXO and 10 token1. The application can allocate these 10 token1 by changing the internal state of any address or application by its computing logic. Then the address or application who has token1 in the application can mint it through the mint3 operator.

2. Protocol Inheritance

The BRC-100 protocol introduces the concept of inheritance. The protocols that directly or indirectly inherit from BRC-100 are called BRC-100 extension protocols. BRC-100 extension protocols must inherit from only one protocol. The extension protocol will inherit the properties, operations and computing operations of the parent protocol, and can only extend the properties and computing operations. All tokens/applications that implement BRC-100 and its extension protocols are compatible with each other, which means that a token/application can be used in any other applications/tokens or child applications/tokens.

3. Application Nesting

Applications deployed based on BRC-100 and its extension protocols can be nested, that is, another application can be created under one application, which is called child application. The ticker of the child application starts with “parent application ticker:”, and multiple applications can be created under one application, to complete multiple independent computing logics. For example, in the classic AMM DEX scenario, multiple LP child applications/tokens need to be created in one DEX application.

4. Decentralized Governance of Application

The BRC-100 protocol stack introduces a governance protocol: BRC-101, which can govern applications that implement BRC-100 or its extension protocol standard. And after the application starts DAO, governance needs to be completed through decentralized voting. The governance of application includes: update the attributes of application and child applications, create child applications, and stop application. Application governance is on-chain governance. After the voting on-chain is passed, the application should be notified through the computing operation: egov, then the application will automatically execute governance after the time lock.

5. Mint Token

BRC-100 protocol provides three mint operators: mint, mint2, and mint3, which are used to mint token in different scenarios. When deploying applications, you need to set the number of tokens that can mint by public (using operator: “mint”). The remaining tokens will use operator: “mint” to mint.

  • mint: Mint from Public, public mint, anyone can mint tokens to users, but the total number mint by “mint” operator cannot exceed the settings of the max and mma attributes of the application. After mint the circulating supply of token will be increased.

  • mint2: Mint from Whitelist, the application records the number of users or applications that can mint, anyone can mint2 tokens to users or applications under the application rules. After mint2 the circulating supply of token will also be increased.

  • mint3: Mint from State, mint3 the balance of users or applications in other applications, anyone can mint3 tokens to users or applications under the application rules. After mint3 the circulating supply of token will not be increased.

6. Burn Token

The burn is a newly introduced operation by the BRC-100 protocol. The user can inscribe the inscription of the burn operation and then transfer the inscription to the deployer of the application, which is similar to the semantics of the transfer operation. Then the inscribed token will be burned or transferred to the balance of the application. Similar to the definition of mint operation, there are three burn operators: burn, burn2, and burn3, which correspond logically to mint, mint2, and mint3 respectively. No extra configuration is required, all applications/tokens support these three burn operators.

  • burn: Burn to Public, everyone can use the operator to burn token. After the token is burned successfully, the circulating supply will be reduced, and the burned token cannot be minted again.

  • burn2: Burn to Whitelist, according to the application’s preset rules, after burn2 token to application, the user’s balance will be reduced, the state of the application will also be updated accordingly, the circulating supply will be reduced. In practice, the logic such as remove liquidity in AMM DEX can be realized by burn2.

  • burn3: Burn to State, burn3 will reduce the user’s token balance and increase the balance of “to” application. In practice, it can be used with mint3 to complete swapping token, adding liquidity and other logic in AMM DEX.

7. Examples

The following will show some examples in BRC-100.

For example, in the lending application, after user deposited token, the application uses “mint2” operator to mint the certification token to the user.

{ 
 "p":"BRC-107",
 "op":"mint2",
 "tick":"lending:cordi",
 "amt":"10",
 "cop":"mint_ctoken",
 "from":"lending:cordi"
}

For example, “mint3” the exchanged token in AMM DEX.

{ 
 "p":"BRC-103",
 "op":"mint3",
 "tick":"bridge:ordi",
 "amt":"20",
 "cop":"withdraw",
 "from":"amm_dex:lp_ordi_btc"
}

For example, using burn2 operator to burn liquidity certificate: LP token to remove liquidity in AMM DEX.

{ 
 "p":"BRC-102",
 "op":"burn2",
 "tick":"amm_dex:lp_ordi_btc",
 "amt":"12",
 "cop":"remove_liquidity",
 "to":"amm_dex:lp_ordi_btc"
}

For example, using “burn3” operator to add liquidity for “bridge:ordi” and “bridge:btc” token in AMM DEX.

{ 
  "p":"BRC-103",
  "op":"burn3",
  "tick":"bridge:ordi",
  "amt":"2000",
  "cop":"add_liquidity",
  "to":"amm_dex:lp_ordi_btc",
  "ts":[{
          "p":"BRC-103",
          "tick":"bridge:btc",
          "amt":"1"
  }]
}

Conclusion

To sum up, brc-20 protocol assets will be able to participate in the decentralized applications on BRC-100 such as AMM DEX and Lending through this framework, in a decentralized, trustless, censorship-resistant and permissionless manner. BRC-100, as the side-protocol of brc-20, will vertically scale brc-20 with extensible computing capabilities.

Reference

[1] [brc-20] Introduction to brc-20

[2] [BRC-100] Introduction to BRC-100

[3] BRC-100 Protocol

[4] MPC (Secure Multi-Party Computation)

[5] Follow the creator of BRC-100: Mikael.btc @MikaelBTC on Twitter to keep up to date with the latest BRC-100 developments

2 Likes