BEP-100: BSC Application Sidechain

BNB Smart Chain
1

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 and bring new features.

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. 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.

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

5.1 Consensus Layer

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 (0x0000000000000000000000000000000000003000)

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.

5.2 Native Token Transfer

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 (0x0000000000000000000000000000000000003001)

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.

6. License

The content is licensed under CC0.

4 Likes
3

Based on discussion I think we can formalize next specification for BAS chains.

  1. BAS chain should be an L2 solution for BSC, by default each validator in BAS sidechain is a relayer for cross chain events between BSC and BAS.
  2. BAS should provide cross chain communication for native BAS assets between BSC and BAS, but all BNB tokens should be managed on BSC side. BAS project can create a bridge contract for BNB to mint their own BNB-Peg token on BAS or use external bridges to bridge assets between BSC and BAS, but BSC doesn’t provide native full cross chain bridge for BNB and BEP20 since BSC can’t relay on BAS’s security model.
  3. Literally BAS is a framework for developers that helps them to build L2 solutions over BSC chain and that provide all required features for doing inter-chain communication between BAS and BSC like ZK proofs.
  4. BAS sidechain can implement consensus and validator as they want and manage validators on their own using their own consensus or staking schemes.
  5. BAS should be able to designed as standalone fee-free backend that can do fast computations and can publish balance proofs to BSC once some period of time.

P.S: the document above will be re-written once we reach consensus on the BAS structure and requirements

4 Likes
4

Great post @dmitry123 !

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
6

Here is an ugraded version. I havn’t found how to edit initial post, so posted it here as comment.

7

Great post @dmitry123 !

9

Cross Chain Communication

Native support scope

  1. Validator set information syncing between BAS and BSC;
  2. Native token transfer between BAS and BSC.

For native cross chain packages, since the native token represents the value of the BAS network, validators on BAS should be the relayers.

For this part, BEP100 should design and implement the detailed protocol.

Third part support scope

  1. BNB and any BEP20 tokens;
  2. ERC721, ERC1155 tokens;
  3. Any other cross chain messages.

Since the security model of the BAS network, 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.

For this part, BEP100 should define the standard interface for integration and provide default implementation like cBridge.

The upgraded version BEP100 may need to clarify this part more clearly.

Staking

The initial BEP100 suggests to implement staking on BSC, while the upgrade version seems to implement staking on BAS.

There is some shortcoming to implement staking on BSC:

  1. Limited validator election strategy. Since all BAS validator elections happen on BSC and share the same logic, it is not possible to implement a different election strategy.
  2. Limited reward distribution strategy. If staking happens on BSC, the reward distribution has to happen on BSC, because all BAS share the same system contract on BSC, it is not possible to implement a flexible reward distribution mechanism.
  3. Validator election snapshot. The validator relayers need to sync validator set changes packages to BAS, usually cross chain package is a smart contract event triggered by transaction, it is not possible to guarantee 100% trigger event periodically.

Strongly recommend implementing staking on BAS, BAS can even choose POA consensus engines without staking. So BAS registration flow should be following:

  1. Developers create their own BAS application with genesis and initial set of validators.
  2. Then send a transaction attached with a. the same initial validators info; b. native bep20 token address; to BASValidatorHub to become a BAS in the BSC network. The BAS would get a global unique BAS_CHAIN_ID as a return of this transaction. This step is permissionless.
  3. Users on BAS stake or vote for new validators through any mechanism implemented on BAS.
  4. Each Validator on BAS must run relayers, all these relayers keep watching the validator set changes on BAS periodically and assemble a ⅔+ BLS signature, any of them can submit the transaction on to the BASValidatorHub contract on BSC.
  5. The BASValidatorHub contract would fetch the origin validator set info of this BAS and verify it against the BLS signature and eventually update with a new validator set.

I strongly recommend that the registration of BAS should be permissionless, since I think BSC does not want to credit any BAS.

For the default staking module on BAS, I get few suggestions for the BEP100:

  1. In this proposal, the staking contract interface is defined as golang interface, I think it is better to define it as ABI interface.
  2. For the default implementation, rocketpool is a very good option, this is exactly how ETH2.0 staking was designed.

Native Token Cross Chain Transfer

A workflow graph is highly suggested on BEP100 to demonstrate:

  1. How native token flow between BSC and BAS;
  2. How to synchronize the total supply to guarantee the circulation if it is an inflated token on BAS or BSC.

Other Topics Need Discuss

Default implementation of Validator Relayers

  1. How validator relayers communicate with others to assemble BLS signatures, is it possible to implement a vote pool on BAS?
  2. Is there any need to design incentive mechanisms for relayers?
2 Likes
10

Celer’s cBridge doesn’t support BLS, it is relaying on ECDSA cryptography. If we’d like to use aggregated signatures then we need to modify their smart contract interfaces because we need to send only one signature instead of multiple. Also we need to design additional communication channel between validators to let them collect all signatures or they can just store them in smart contract as you mentioned here. In this doc I’m going to specify mechanism for validator sync between BAS and BASValidatorHub to let cross chain communication work properly.

Its already specified as Solidity interface that is an ABI representation

I didn’t get your idea. Rocketpool is not a staking pool for managing validators, its a staking pool for managing eth2 providers and distributing rewards. It might be quite different to want we want. Maybe they have inside some provider voting mechanism, but I believe its very overcomplicated to use them. Better to find simplier solution, I believe such exists.

We can’t guarantee this because BSC doesn’t relay on the BAS security model.

1 Like
11

Here are also my thoughts regarding the next things that must be also specified in this proposal.

Fast-finality and BLS cryptography

Parlia is a BFT-like consensus where only one validator produces a block and to be sure in the correctness of this operations we must wait for the confirmation time, usually its 2/3*N+1, where N is active validators (15 blocks for the current configuration). It means that to prove one block we must upload at least 15 blocks to the blockchain. BLS cryptography with parlia’s fast-finally can solve this problem because in this case we can collect one aggregated signature and send only this aggregated signature in the BSC, but here we must know BLS public keys of each validator. Currently BLS cryptography is merged to the official geth repository, but it’s not supported by BSC yet, so it might take some time to apply these changes to the parlia consensus engine. Also it’s not strictly required to use BLS, geth has support of BN256 curve since Byzantium fork can be used as a replacement for BLS.

Here we have next solutions:

  • Break compatibility with Parlia and implement fast-finality in the BAS version of Parlia using BN256 curve.
  • Wait for the BSC’s version of fast-finality and for BLS support.

For now let’s assume that fast-finality is an optional solution for the BAS since we have a lot of moving parts here.

Native Asset Bridge

To bring cross chain bridge functionality for the native assets we must do block header verification in the BSC and verify validators signatures.

Here we have next problems:

  • It’s not strictly required for BAS to use parlia’s compatible headers or EVM execution environment at all
  • We can avoid state transition verification, but we can’t avoid block chain verification

The first problem is much more complicated, here we must figure out how to verify the correctness of the block header and of the chain if we don’t know what consensus and execution environment is used. To reach this we’d like to introduce a block verification function (BFF) that must be specified by the BAS development team. BFF is a function in the Solidity language that is able to verify block headers from BAS applications. This is a simplified version of the state verification function from Polkadot. BFF is one of the required parameters to register BAS in the BSC’s smart contract.

BASValidatorHub

BASValidatorHub is a system smart contract that is responsible for storing all registered BAS applications, it also contains information about their chain identifier and block verification functions.

ABI Interfaces

In the post above I made several mistakes in the ABI specification and system addresses. For parlia’s compatibility its required to have next system smart contracts:

  • ValidatorSet (0x0000000000000000000000000000000000001000)
  • SlashingIndicator (0x0000000000000000000000000000000000001001)
  • SystemReward (0x0000000000000000000000000000000000001002)

Here is ABI interfaces for them:

interface IValidatorSet {
  function getValidators() external view returns (address[] memory);
  function deposit(address validator) external payable;   
  receive() external payable;
}

interface ISlashingIndicator {
  function slash(address validator) external;
}

interface ISystemReward {
  receive() external payable;
}

Each system smart contract must define an init() method.

Staking Smart Contract

Default implementation of BAS will contain staking smart contracts on Solidity for EVM execution environment. This smart contract is an extension over IValdiatorSet and allows users to manage active validators based on the total delegated amount and distribute rewards between stakeholders. It’s not strictly required to have EVM implementation of such smart contracts but for default BAS solutions it might be very useful. I’m not going to specify here ABI methods for such smart contracts because it’s implementation-defined and each BAS developer can implement their own version based on their requirements.

On-chain Governance

Each BAS should have on-cain governance to let users vote for the new proposal on the chain. The governance is based on the compound’s alpha governance and validator owners in the chain are able to create new proposals and vote for them. Voting power is distributed based on the total delegated amount to the validator. Once ⅔ of the quorum is reached and >51% of votes are for the proposal then it can be executed by anyone on the chain. Governance is able to manage staking parameters like felony threshold or jail period.

12

We don’t have to change the Celer’s cBridge implementation, Bridge can integrate with whatever cryptography. The above suggestion just is for native cross-chain packages, third-party integration is not within the scope.

13

Agree with you about the rocketpool part.

Both the value of native token on BAS and cross-chain communication relies on the validators of BAS, so it is not a problem. Since the cross transfer of native tokens should be natively supported by the BSC genesis contract, we should provide a clear circulation about it.

14

For the Native Asset Bridge, my concern is that BFF must be affordable for BAS. In most cases, the light client need to upload continuous headers, which is quite expensive.

15

Yes, agree, it might be gas consuming, but not much. Block verification is not very complicated function, but we will have to verify block headers to be sure that validator transition is well-done. Also using BLS we don’t need to pass all block headers into it, it’s enough to publish only epoch blocks that contains new validator set and signatures from all previous validators.

If we assume that block verification consumes ~50k gas (w/ state modification), then we have next calculations:

  • per each block: 50k gas/block, then its ~16k gas/sec
  • per epoch: 50k gas/epoch (epoch can be from 5 minutes up to 1 day), then its between ~160 gas/sec (for 5 min epoch) and 0.57 gas/sec (for 1 day epoch)

We can see that by bringing fast-finality we can reduce this computations a lot.

16

I’m going to add this to the final proposal. I’m going to publish it here these days.

17

Nice put for all to understand a bas

18

When will the beta version appear

19

@dmitry123 @zoro Thanks for the great work!

I suggest we first focus on the Staking (with reward logic) and Governance model for this BAS first.

For native asset transfer, if BAS validators can serve as relayers, they naturally become the creditable oracle for BAS to bring the native asset on and off BSC.

Meanwhile, the third party bridges can serve some transfer as well.

As zkSync is marching aggressively. I think ZK Rollup may be the eventual goal for the asset transfer. It has the advantages:

  1. reuse the BSC security
  2. the “great exit” can be an easy way to sunset any BAS which can be relief in some scenario.
20

Here is PR for the proposal, its still under WIP, because I want to clarify some moments in the proposal based on the first test implementation. I’m going to post my additional thoughts in the PR comments.

In the first version I’m going to focus on:

  • Parlia consensus compatbiility
  • System smart contracts including staking, slashing and treasury
  • PoC for the native assets bridge
2 Likes
23

Hi all,

I built a BAS network with only 3 validators and I noticed that for every new block generated, a corresponding new miner address is generated.

This is different from BNB mainnet, all blocks are generated only by defined validators.

Can you help me understand why there is this difference?

24

I’m looking for information on BAS but it seems that everything has stopped until 2022, are you still working or is it a suspended project?