- BEP-100: BSC Application Sidechain
BSC Application Sidechain (BAS) is an infrastructure for developers that helps them to build large scale BSC-based apps with higher throughput and much lower or even zero transaction fees. It is reached by using a separate consensus engine and modern execution environment that can be specified by developers or community and bring new features.
This paper describes the design of BAS-compatible sidechains and a protocol for interaction between BSC and BAS native assets. Since BAS applications are independent from the BSC consensus set BSC can’t rely on their security model. To protect users’ funds from malicious actions BSC doesn’t introduce direct internal protocol for cross chain communication between BSC and different sidechains, because one compromised BAS application can bring loss of users funds in BSC or other sidechains. That is why BAS applications rely only on their native token and BSC provides a protocol for creating Peg tokens for BSC’s native asset. The standard will help us to define requirements for such sidechains.
This BEP is a draft.
Today BSC is experiencing network scalability problems and Binance have proposed to use BAS in their Outlook 2022 paper to solve this problem because these side chains can be designed for much higher throughput and lower gas fees. In this document we want to define a protocol for consensus management and messaging between BAS and BSC so that it is easier for developers to use a ready-made solution and it is easier for BSC to integrate with them.
Since BAS is technology agnostic blockchain then their developers can choose any available solution for runtime execution environment and for consensus layer. In this case we should define the block verification function to be sure that communication protocol between BAS and BSC is not compromised, but we can avoid it by managing the validator set right in BSC system contracts. It also requires registration of all BAS chains in BSC system smart contracts, otherwise it is not possible to verify mint/burn operations with Peg tokens.
To reach it we need to create new system contract in BSC network:
- BASChainRegistry (
This smart contract manages an active validator set and each BAS application must keep any related to staking or delegations logic inside this smart contract. It will help us to protect BAS chains from being compromised and will help to bring full cross chain functionality between BSC and BAS chains for all tokens including BEP20 and native BNB. Of course the BAS chain might reject validator changes in their codebase but in this case such applications won’t be able to operate with the BSC network anymore.
BAS registration flow should be following:
- Developers create their own BAS application with genesis and initial set of validators.
- Then apply a proposal to BASRelayHub to become a BAS application in the BSC network (it can go through BSC verification or community voting process).
- After accepting a proposal users and application stakeholders must vote for new validators in this network using delegation mechanism.
- If quorum is reached and validators are elected then new BAS validators must accept new blocks from BSC relay hub smart contract by validating BSC validator set signatures (that can be found in the first epoch block).
- In case of native token swap from BAS to BSC chain can easily verify that operation was verified and signed by ⅔ of validators.
BAS should be able to create pegged tokens of their native currency in the BSC network, to reach these needs we must specify generic protocol to such swaps.
The scheme requires to have additional system smart contract in BSC network:
- BASRelayHub (
BASRelayHub is a system smart contract that exists in BSC blockchain and allows to manage cross chain operations for native tokens in BAS chains. To make it possible BAS validators must be registered as relayers and they should be able to relay and mint or burn peg tokens of their native assets in the BSC network. The native token in the BAS chain is used to pay for transaction fees and for system services where it is required. To reach compatibility between different BAS chains with BSC we must specify a standard for such interaction between sidechain and BSC. Celer Network’s cBridge solution can be a standard for BSC<->BAS interaction, but only for native tokens.
P.S: Since the security model of the BAS network can’t be verified then we can’t let users do cross chain transfers of the native BNB or any BEP20 tokens by default. This feature can only be introduced by a third-party solution only if they trust the developers of BAS application and their security model passed the public audition process.
Native token exchange flow should be following:
- User locks his native tokens in BAS application in a special smart contract.
- Relayers verify this operation and sign this message using cBridge’s compatible protocol.
- User can use collected validators signatures amounts to more than ⅔ staked protocol token to mint peg tokens in the BSC network.
Opposite flow is almost the same except that validators in the BAS network notarize transactions in BSC blocks instead of BAS’s.
The content is licensed under CC0.