The first BNB Chain Tech Community Call is coming.
The goal of these community calls is to give the BNB-Chain community a single place from which to share monthly technical updates on the development status and obtain feedback on proposed improvements.
The goal of these gatherings is to provide succinct descriptions of progress being made in the core BNB-Chain ecosystem.
To help our community become more engaged and creative, we’ll hold open brainstorming sessions where any community builder can join in and offer their views on the current proposal.
Proposed Agenda:
Introduction:
Welcome and introductions of speakers
Overview and purpose of the panel discussion
Latest BC Technical Update:
BEP-159 introduction summary: introduces a permissionless validator election mechanism and brings the staking economy onto Beacon Chain.
(select one participant to comment on it)
Latest BSC BEP Update/Discussion
BEP-174: Cross Chain Relayer Management is ready to be merged
Validator set - The biggest criticism people have of BNB chain is that it has so few validators. I understand that this is good for early stage chains because decisions can be made fast and the chain itself can be performant, however what is the end goal? Is it to open it up to unlimited number of validators?
I follow the BNB chain github fairly closely and there is still an unaddresed number of issues and PRs. I suppose the nodereal team is working behind the scenes on their own fork or something because there is very little commit activity. It also seems like guagualvcha is likely the most active person and makes almost all the code reviews for such a large chain. For BSC the last commit was 3 days ago, and before that it was in December. Even the develop branch doesn’t have much activity. Where is all the activity happening?
What is the status of ZKBNB? Can you share any metrics?
During the crosschain bridge hack, 2 million new BNB were minted. What steps have been taken to make sure that minting can never happen again? Also in the 22nd burn blogit says that 1 million were locked and the other million will be burned in the normal process. How is that fair that a hack leads to more supply and now we have to wait even longer to get the extra million burned. Wouldn’t it make more sense to lock 2 million or just lock 1 and burn the other right now? Is the reason this isn’t happening because of trying to avoid acting like a security?
I saw you weren’t able to answer them in the call, hopefully you can answer them here!
On top of the ones above I also have another question regarding greenfield. Is this a separate validator set? You mentioned potentially being able to execute lambda functions on greenfield, but how would validators have enoug compute power to be able to facilitate this?
Concerns raised about the impact of BEP-159 and lowering gas fees;
Introduction of Greenfield as a decentralized storage solution and comparison to other storage providers;
Need for compatibility with existing file systems mentioned by Storj;
BNB Core team highlights Greenfield’s integration with the BSC blockchain;
Aim to provide a user-friendly and developer-friendly experience for web3 applications with advanced features such as data indexing and programmability.
This BEP introduces a new staking mechanism on the BNB Beacon Chain
Aimed to increase decentralization, security, and community involvement;
Anyone will be able to participate in securing the network by becoming a validator or delegating their BNB to the validator they trust;
Based on BSC staking mechanism;
Validators can produce new blocks, earn rewards, and share the rewards with delegators;
The Validator set is determined by the rank of the accumulated bonded tokens on validator candidates;
Punishment for bad behavior by the validators is called “slashing.”;
Unbonding period for validators and delegators.
Outcome:
Strong concerns were raised by both Tranchess and NR validator about the impact of BEP-159 regarding the impact of this BEP;
Both Validators asked for more data to back up this BEP;
BNB Chain Core Dev team will work on providing more meaningful data to be able to understand the impact of BEP-159;
BSC BEP-174: Cross Chain Relayer Management is ready to be merged → link
Description:
New governance proposal type introduced to manage the set of whitelisted relayers on BSC: Relayer Managers;
Whitelist of relayers stored in the RelayerHub genesis contract on BSC;
Only relayer public keys registered via Relayer Managers can invoke the RelayerHub smart contract for cross-chain transfers;
Changes to the RelayerHub smart contract, including the introduction of new functions and deprecation of existing functions;
Relayer codebase updated to no longer register and deposit, and to call the new “verifyRelayer” method on the RelayerHub smart contract;
Existing relayer key migration discussed;
Manager keys supplied for existing relayers, and existing relayers will need to pull down the updated relayer code;
New CLI commands added for mainnet.
Outcome:
Improved security: After the BSC Bridge exploitation, the introduction of Relayer Managers adds an extra layer of security to the system by managing the set of whitelisted relayers;
No deposit requirement for Managers: Managers will not have to deposit any BNB, as opposed to the previous 100BNB deposit requirement;
Governance-based set of Manager public keys: The set of Manager public keys will be updated via governance, which allows for community control and transparency;
RelayerHub smart contract changes: The RelayerHub smart contract will be updated to support the addition and removal of managers via governance;
Smooth transition: The whitelistInit function will ensure a smooth transition so that the existing whitelisted relayers continue to be relayers after the hardfork;
Everyone agreed on the need to have a good mechanism to ensure that relayers are secured and aren’t able to behave maliciously;
Attendees are looking for more documentation / FAQ about who is currently managing the current set of relayers.
Upgrade transferGas for Staking(BEP153): 2300 → 5000 → link
Description:
Value of transferGas is currently set at 2300;
A simple send to a deployed smart contract using proxy consumes 2747 gas;
Staking.sol allows the use of only 2300 gas;
There is a need for a way to use an upgradable contract.
Outcome:
Multiple Security teams looked into the impact, and it is fine to move to 5000 gas;
no objection to the change. The BNB Core Dev team will push a governance vote for the BSC validators;
Proposal title: “modify transferGas from 2300 to 5000”.
BEP-172: Improvement on BSC validator committing stability → link
Description:
Update the Parlia consensus mechanism to improve network stability and efficiency;
Change the timestamp and delay settings for off-turn validators;
The previous system resulted in a “slash” and long delay when a validator missed their turn to commit a block;
The new calculation algorithm allows off-turn validator to commit a block in 4 seconds if the in-turn validator misses their turn;
Slash will no longer affect future blocks;
Remove recently signed validators from the candidate set for delay calculation;
Reduce minimum delay duration to zero and add 3 seconds to ensure blocks are committed within the expected duration (3 seconds);
Ensure all validators work appropriately.
Outcome:
Improved Network Stability: update enhances network stability by changing the delay setting for off-turn validators in the Parlia consensus. It helps the network recover faster and more efficiently after a slash event for a stable block-committing order.
Reduced Delays: update makes the network more efficient by reducing delay time and improving recovery time after a slash;
Improved Algorithm: updates the off-turn validation delay calculation algorithm, leading to quicker block commitment (within 4 or 3 seconds) in case of a missed turn by an in-turn validator, improving network efficiency and stability;
No Bad Influence on Future Blocks: prevents slashes from affecting future blocks by excluding recently signed validators from the calculation of the delay duration, enabling faster recovery of the network;
Increased Trust in the Network: improves network stability, efficiency, and trust, leading to increased confidence and participation;
the BEP-172 introduces significant improvements to the Parlia consensus and the overall efficiency of the network. The changes in the BEP will lead to a more stable, efficient, and trustworthy network, which is crucial for its growth and development.
Introduction of a new validator slash mechanism 2.0 for the BNB Smart Chain;
Aimed at punishing malicious validators in more scenarios;
Validators can either directly slash a validator for missing a proposal or propose a slash to a malicious validator if most validators agree;
Enriches the ways of monitoring validators and protects network security and smooth operation;
Current mechanism does not cover all malicious behaviors such as delays in broadcasting blocks and using poor machines;
New mechanism includes a point system with a basic slash count of 100 points;
Different levels of punishment based on the number of points collected;
More punishment scenarios to maintain reliable and safe operation of the network.
Outcome:
Improved network stability by penalizing malicious behavior;
Better protection of network interests by punishing validators who harm the network;
Fair competition through penalizing malicious behavior;
Limiting poor network/machine usage for validators to improve security/stability;
Fewer reorgs and stable TPS through new block difficulty;
Addresses unprovable evidence with the new mechanism;
Improved liveness by allowing other validators to re-generate blocks;
Overall, the argument for BEP-191 is to address the security and stability issues caused by validators delaying block broadcasts and to ensure the rights and interests of nodes and the reliable and safe operation of the BSC network.
Part 2 BNB Greenfield:
Description:
BNB Greenfield is a protocol for a decentralized storage network;
Connected to BNB Smart Chain (BSC) through relayers;
Allows users to create, own, and trade data assets with freedom and transparency;
Introduces programmable storage and opens up a range of use cases beyond traditional storage services;
Advantages over traditional hosted storage services, such as plug-n-play programmable decentralized data-sharing capabilities;
Data is referenced openly and multiple Storage Providers back up data in a decentralized manner for added reliability.
Thanks for your questions, please find some answers:
1:
BNB Chain focus is to keep improving decentralization by expanding validators from 40 to 100 (slowly but surely.)
BC: from 11 to 21
BSC: a total of 50, 29 are active.
Three chains and three groups of validators.
The BNB Chain still has some on-going work regarding the Proof of Stake consensus, BEP191 and BEP176 are some proposals that try to enhance the BNB economic in this ecosystem; once we are to answer and solve those issues, we will be stronger to increase our decentralization even further and have for a larger set of validator.
2:
NodeReal Dev Community is contributing to almost 40% of codes.
Guagualvcha is just one of the coordinators, such as merging the codes, etc.
We will work on increasing the code review process, testing process, etc
3: zkBNB is currently on testnet and the aim is to launch the mainnet by the first half of the year.
The team is engaged in enhancing the zkBNB platform and improving the user interface and user experience to make it more user-friendly and accessible. A number of projects have shown interest in constructing on top of zkBNB and are currently exploring and testing the possibilities.
The remaining fund from the exploiter is in Venus, which is not as lockable as on an EOA.
The BEP171 is a security enhancement proposal to prevent it from happening again, and also BEP174 proposes a more secure solution to manage cross-chain relayers. The development of both BEP is done, now under security audit.