from partnering DApps such as Mirror Protocol and Injective, resulting in requests reaching up to 80% of block capacity.
To accommodate this growth in usage, we are proposing BCIP-6: Increase Block Capacity through Request Gas Parameter
⚡️ If the proposal passes, BandChain capacity to process requests by approximately 25% – making requests and transactions faster.
⛳️ BandChain team is constantly working to improve to meet the demands for oracle solutions in Web3 ecosystem, and will be committed to building a secure, reliable and scalable oracle solutions for the community.
Official Announcement 👉
https://medium.com/bandprotocol/bcip-6-increase-block-capacity-through-request-gas-parameter-4249f9291b57
Spread the word 👉 https://twitter.com/BandProtocol/status/1492021186217541632?s=20&t=ghJ5sCnS9ixqGwzRxQgbTQ
—————————————————
Recent Band Protocol Developments:
🔸 Band Protocol successfully launches Phase 2: Laozi
🔸 Band Protocol is now live on Celo’s Mobile-First DeFi Platform
🔸 Band Protocol partners with OASIS to Bring Open Finance to Mass Market
🔸 BandChain’s IBC Oracle Enables Injective to Launch the World’s First Decentralized Derivatives Markets
🔸 Band Protocol now live on Mooriver to bolster its ecosystem's scalability
This is a nice problem to have, but it does beg the question of availability as requests (as we all hope) continue to grow rapidly into the future. Would I be right in supposing that as this extra capacity is utilised by additional requests, we will again need to find a way to further increase block capacity? And would that increase come from a potential block size increase, and if it did, would that have any impacts on block generation time (and thus finality)? Thanks!
The only issue is during peak hours when the request fills up to 80-90% of the block capacity which the team is trying to resolve by reducing the "request gas parameter" which will increase the Bandchain capacity to process requests by approx 25%.
Обсуждают сегодня