[WIP] Added BEP100 proposal for the BNB Application Sidechain #132
Conversation
| ``` | ||
|
|
||
| Native asset bridge supports next user flows: | ||
| + Deposit (BAS -> BSC). When a user calls a deposit function it locks his native tokens in the smart contract and emits events. To be able to mint peg tokens in BSC chain, the user generates a proof that contains information about transaction receipt (including emitted events) with merkle patricia trie proof. This proof should be uploaded into the BSC chain where a `BASValidatorHub` smart contract can verify this proof and validators signatures from the BAS chain. |
There was a problem hiding this comment.
It is a bit different from what I learned from most Layer2 solutions: Deposit (L1 --> L2), Withdrawal(L2 --> L1). Do you think it is more straightforward to adopt the same workflow?
There was a problem hiding this comment.
Didn't get you fully. The flow you provided is what exactly is written in the text. For the deposit we lock tokens in the BAS to mint in the BSC, but for withdraw we burn pegged tokens in BSC to unlock them in the BAS. Sounds correct.
There was a problem hiding this comment.
BAS is kind of Layer2. Deposit (L1 --> L2), should be Deposit (BSC -> BAS)?
| ```solidity | ||
| interface IProofVerificationFunction { | ||
|
|
||
| function verifyValidatorTransition(bytes[] calldata proofs, uint256 chainId, address[] calldata existingValidatorSet) external view returns (address[] memory newValidatorSet); |
There was a problem hiding this comment.
What are the proofs here means? Are they the N blocks after the epoch?
There was a problem hiding this comment.
I guess existingValidatorSet should store on chain, otherwise how can we trust existingValidatorSet if it is an input parameter?
There was a problem hiding this comment.
You have described how to update the validator set here, should we have a chapter to describe how to bridge common cross-chain packages, a common interface is needed as well?
|
|
||
| ### 5.0 Circulation Model and Native Asset Bridge | ||
|
|
||
| The key parts of each BAS application are native token circulation model and cross chain bridge for native assets. Native assets of the BAS chain are located in the BAS application and managed by sidechain directly. BAS is designed to provide cross chain functionality for the native assets. Since native assets are fully managed by BAS developers they can compromise token supply or mint/burn tokens. We leave such a decision on the conscience of the developers, because by manipulating the supply of their tokens they only risk their reputation. The only thing required for native cross chain bridge is block header verification that allows one to keep an active validator set and verify the correctness of cross chain transactions. |
There was a problem hiding this comment.
Can cross-chain mechanism easily extend the support to ERC20, ERC721 that are issued on BAS(called native tokens)? Will BEP100 provide a default implementation for it?
| + SystemReward (`0x0000000000000000000000000000000000001002`) - treasury for the system rewards to cover relay fees and others | ||
|
|
||
| BAS defined smart contracts: | ||
| + StakingPool (`0x0000000000000000000000000000000000007001`) - staking pool that helps to aggregate stakes and optimize gas consumption for the reward calculation |
There was a problem hiding this comment.
0x59576Fb376F1FEaEdb9c768A724D8C06304538f5
| @@ -26,6 +26,7 @@ Here are the list of subjects of BEPs: | |||
| * [BEP-91](BEP91.md): Increase Block Gas Ceiling for Binance Smart Chain | |||
| * [BEP-93](BEP93.md): Diff Sync Protocol on BSC | |||
| * [BEP-95](BEP95.md): Introduce Real-Time Burning Mechanism | |||
| * [BEP-100](BEP100.md): BSC Application Sidechain | |||
| * [BEP-127](BEP127.md): Temporary Maintenance Mode for Validators | |||
| * [BEP-128](BEP128.md): Improvement on BNB Smart Chain Staking Reward Distribution | |||
| * [BEP-131](BEP131.md): Introduce candidate validators onto BNB Smart Chain | |||
There was a problem hiding this comment.
0x59576Fb376F1FEaEdb9c768A724D8C06304538f5
unclezoro
changed the title
| By default BSC brings only native asset cross chain functionality to the BAS applications. To reach this, each BAS application must be registered in the BSC smart contract. This smart contract assigns chain id to the BAS application and specifies BHVF (block header verification function). This function is used to verify the block header, but w/o state transitions. BHVF should be written in Solidity and be able to verify block header, the correctness of the chain for N blocks and check signatures. Since default BAS implementation is BSC-based then default chain implementation is supported by BAS validator hub, we define such function to allow other developers that don’t want to rely on EVM or parlia consensus engine to write their own verification function. Of course developers might publish malicious functions or a function with a vulnerability that allows them to skip block verification and they should provide an audition of this code to be trusted by a community. | ||
|
|
||
| System contract address of BAS Validator Hub smart contract is: `0x0000000000000000000000000000000000007000` | ||
|
|
There was a problem hiding this comment.
0x80439A6dD155b6Ba4e2040bF0e578C0D740D0De9
|
APPROVING |
|
Great |
|
Thanks Charles. My bitcoin was staking for 2 months and they charged me
$8300 they took it all and the other stakes got to keep there's and paid
near nothing.
…On Sun, Aug 18, 2024, 8:34 PM CharlesCowan ***@***.***> wrote:
***@***.**** commented on this pull request.
⛓️💥
—
Reply to this email directly, view it on GitHub
<#132 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A6DTIL7SJMSI5VJV4VUZUADZSE4PPAVCNFSM5P5LHPO2U5DIOJSWCZC7NNSXTPCQOVWGYUTFOF2WK43UKJSXM2LFO45TEMRUGQ2DKMRXGI2Q>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
This a draft of BEP100 proposal for Binance Application Sidechain (BAS) solution. I've already started to work on the first implementation of BAS-compatible chain and going to post here some clarifications for not finalized questions.