BEP-100: BSC Application Sidechain

BNB Smart Chain
5

BEP-100: BSC Application Sidechain

1. Summary

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.

2. Abstract

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. The standard will help us to define requirements for such sidechains.

3. Status

This BEP is a draft.

4. Motivation

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.

5. Specification

Literally BAS is a modular framework for creating BSC-compatible side chains that defines requirements for integration with the BSC ecosystem and brings development-ready EVM-compatible features like staking, RPC-API or smart contracts. Since BSC doesn’t rely on the BAS security model, that is why there is no default embedded production-ready bridge solution between BSC and BAS networks, but instead of it BAS provides protocols and standards for integrating third party bridges that can be managed by the BAS validator set of other projects like AnySwap or Celer Network cBridge, of course if they trust the BAS developer team.

BAS brings several programmable and configurable modules that can be used or modified by developers to reach their business goals.

Here is an example of such modules:

  • Networking - for p2p communication between different BAS nodes
  • Blockchain & EVM - for block producing and EVM transaction execution, of course each BAS can define their own runtime execution environment based, for example, on WebAssembly
  • Web3 API - for basic compatibility with Web3 ecosystem including MetaMask and other applications
  • Transaction Pool - for managing internal BAS policies for transaction filtering and for charging fees from BAS users
  • PoA & PoS Consensus - for users to be able to vote for the honest validators in the BAS network and guarantee the safeness of actions applied on the chain
  • Storage & State - for persisting local data

5.1 Consensus Layer

BAS provides next consensus engines in default implementation:

  • Parlia (PoSA)
  • Proof of Authority (PoA)

Using the Parlia consensus engine motivates users to stake their funds and vote for the honest validators that makes BAS sidechain much more decentralized and trustless. It also helps stakers to gain rewards from their stakes by receiving fees from block producers.

To be able to interact with Parlia consensus engine, BAS must support staking contract that is compatible with next interface:

interface IParlia {

    // Return list of validators for current epoch
    function getValidators() external view returns (address[] memory);

    // Increase validator's income fee balance for just
    // produced block
    function deposit(address validator) external payable;

    // Slash previous validator for the missed block
    function slash(address validator) external;

    // Increase treasury fee that can be paid to developers or relayers
    receive() external payable;
}

BAS provides default implementation and financial model for staking and it is embedded to the genesis block as system smart contract, but BAS developers can choose another model based on their business requirements.

5.2 Smart Contracts

Each BAS sidechain is technology-agnostic, meaning that it’s able to include or modify any module inside BAS and bring any consensus or runtime execution environment. By default BAS provides an EVM execution environment with a predefined set of system smart contracts for platform operation. If BAS developers want to bring more functionality to their sidechain then they should implement it on their own or contribute it to the BAS official template to extend the default module set with additional extensions that can be used by other developers in the future.

5.3 Cross Chain Bridge

To let users bridge assets from other EVM compatible chains or BSC to BAS we introduce next embedded system smart contracts that implements compatibility with different bridges.

In default BAS implementation we’re going to have next bridge standards:

  • Celer Network’s cBridge
  • Chain Safe’s ChainBridge

5.4 System Contracts

System contracts are precompiled contacts that are injected into genesis blocks. They can only be modified or upgraded only using a hard fork of the entire blockchain.

Currently BAS is designed to have the next default system smart contracts:

  • ParliaStaking (0x0000000000000000000000000000000000003001) - provides compatibility with Parlia consensus engine
  • CelerBridge(0x0000000000000000000000000000000000003002) - provides compatibility with Celer Network’s cBridge solution to be able to use their relayers
  • ChainSafeBridge(0x0000000000000000000000000000000000003003) - provides compatibility with ChainSafe’s bridge smart relayers

6. License

The content is licensed under CC0.

3 Likes