diff --git a/docs/announce/index.md b/docs/announce/index.md index a8973fb980..2edb5beb79 100644 --- a/docs/announce/index.md +++ b/docs/announce/index.md @@ -2,18 +2,18 @@ # Announcement
- +
-
Greenfield Savanna Hardfork (Testnet)
-
Bugfixing on Greenfield Testnet
+
Volta Upgrade of opBNB (Mainnet)
+
One BEP on opBNB Mainnet
- 2024 December 02 + 2025 Apr 17 - +
-
Greenfield Savanna Hardfork (Mainnet)
-
Bugfixing on Greenfield Mainnet
+
Maxwell Upgrade of BSC
+
Three BEPs on BSC Testnet/Mainnet
- 2024 December 12 + 2025 Apr 24
diff --git a/docs/announce/lorentz-bsc.md b/docs/announce/lorentz-bsc.md new file mode 100644 index 0000000000..2e9f20d099 --- /dev/null +++ b/docs/announce/lorentz-bsc.md @@ -0,0 +1,19 @@ +# Lorentz Upgrade of BSC + +
+ Hardfork +
+ +## Upgrade Timeline +The Lorentz upgrade will happen at: + +- Testnet: 2025-04-08 07:33:00 AM UTC +- Mainnet: 2025-04-29 05:05:00 AM UTC + +## Upgrade BSC Mainnet Nodes to v1.5.10 Before Hardfork +[v1.5.10](https://github.com/bnb-chain/bsc/releases/tag/v1.5.10) is a hard fork release for BSC Mainnet, the HF name is: [Lorentz](https://forum.bnbchain.org/t/bnb-chain-roadmap-mainnet/936#p-1418-h-2lorentz-wip-9) + + +There is only one BEP in Lorentz: + +- BEP-520: shorter block interval phase one: 1.5 seconds \ No newline at end of file diff --git a/docs/announce/maxwell-bsc.md b/docs/announce/maxwell-bsc.md new file mode 100644 index 0000000000..4f717f49bb --- /dev/null +++ b/docs/announce/maxwell-bsc.md @@ -0,0 +1,20 @@ +# Maxwell Upgrade of BSC + +
+ Hardfork +
+ +## Upgrade Timeline +The Maxwell upgrade will happen at: + +- Testnet: 2025-05-26 07:05:00 AM UTC +- Mainnet: TBD, target later Jun 2025 + +There are three BEP in Maxwell: + +- [BEP-524: shorter block interval phase two: 0.75 seconds](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP-524.md) +- [BEP-563: add Enhanced Validator Network proposal](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP-563.md) +- [BEP-564: add New Block Fetching Messages proposal](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP-564.md) + +## Upgrade BSC Testnet Nodes to v1.5.13 Before Hardfork +[v1.5.13](https://github.com/bnb-chain/bsc/releases/tag/v1.5.13) is a hard fork release for BSC Testnet, the HF name is: [Maxwell](https://forum.bnbchain.org/t/bnb-chain-roadmap-mainnet/936#p-1418-h-3-maxwell-wip-10) diff --git a/docs/announce/pascal-bsc.md b/docs/announce/pascal-bsc.md new file mode 100644 index 0000000000..6eeeaa4ff5 --- /dev/null +++ b/docs/announce/pascal-bsc.md @@ -0,0 +1,19 @@ +# Pascal Upgrade of BSC + +
+ Hardfork +
+ +## Upgrade Timeline +The Pascal upgrade will happen at: + +- Testnet: 2025-02-25 03:18:00 AM UTC +- Mainnet: 2025-03-20 02:10:00 AM UTC + +There are 5 BEPs in Pascal: + +- BEP-439: Implement EIP-2537: Precompile for BLS12-381 curve operations +- BEP-440: Implement EIP-2935: Serve historical block hashes from state +- BEP-441: Implement EIP-7702: Set EOA account code +- BEP-466: Make the block format compatible with EIP-7685 +- BEP-496: Implement EIP-7623: Increase calldata cost \ No newline at end of file diff --git a/docs/announce/volta-opbnb.md b/docs/announce/volta-opbnb.md new file mode 100644 index 0000000000..c0e808069d --- /dev/null +++ b/docs/announce/volta-opbnb.md @@ -0,0 +1,31 @@ +# Volta Upgrade of opBNB + +
+ Hardfork +
+ + +## Upgrade Timeline + +The Volta upgrade will happen at: + +- Testnet: Apr-02-2025 03:00 AM +UTC +- Mainnet: Apr-21-2025 03:00 AM +UTC + +## Upgrade opBNB op-node to v0.5.3-hotfix and op-geth to v0.5.7 Before Hardfork + +Releases: + +- https://github.com/bnb-chain/opbnb/releases/tag/v0.5.3-hotfix +- https://github.com/bnb-chain/op-geth/releases/tag/v0.5.7 + +Docker Images + +- ghcr.io/bnb-chain/op-node:v0.5.3-hotfix +- ghcr.io/bnb-chain/op-geth:v0.5.7 +- ghcr.io/bnb-chain/op-batcher:v0.5.3-hotfix +- ghcr.io/bnb-chain/op-proposer:v0.5.3-hotfix + +## Key Highlight: Shorten Block Interval + +- [BEP-543](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP-543.md): effectively reducing the block time from 1 second to an impressive 500 milliseconds. This enhancement significantly improves transaction efficiency and overall network performance, allowing for faster processing and a more seamless experience for users. \ No newline at end of file diff --git a/docs/assets/js/footer-menu.js b/docs/assets/js/footer-menu.js new file mode 100644 index 0000000000..bec1b8f71e --- /dev/null +++ b/docs/assets/js/footer-menu.js @@ -0,0 +1,526 @@ +const DEFAULT_FOOTER_MENUS = [ + { + "id": 1, + "items": [ + { + "data_analytics_id": "click_footer_chains_bsc", + "href": "https://www.bnbchain.org/en/bnb-smart-chain", + "id": 34, + "menu": 1, + "sort": 4, + "target": "_self", + "title": "BNB Smart Chain", + "data-analytics-id": "click_footer_chains_bsc" + }, + { + "data_analytics_id": "click_footer_chains_gf", + "href": "https://greenfield.bnbchain.org/en", + "id": 35, + "menu": 1, + "sort": 5, + "target": "_self", + "title": "BNB Greenfield", + "data-analytics-id": "click_footer_chains_gf" + }, + { + "data_analytics_id": "click_footer_chains_opBNB", + "href": "https://opbnb.bnbchain.org/en", + "id": 36, + "menu": 1, + "sort": 6, + "target": "_self", + "title": "opBNB", + "data-analytics-id": "click_footer_chains_opBNB" + } + ], + "menu": "Chains" + }, + { + "id": 2, + "items": [ + { + "data_analytics_id": "click_footer_use_wallets", + "href": "https://www.bnbchain.org/en/wallets", + "id": 38, + "menu": 2, + "sort": 3, + "target": "_self", + "title": "Download Wallet", + "data-analytics-id": "click_footer_use_wallets" + }, + { + "data_analytics_id": "click_footer_use_getBNB", + "href": "https://www.bnbchain.org/en/what-is-bnb", + "id": 39, + "menu": 2, + "sort": 4, + "target": "_self", + "title": "Get BNB", + "data-analytics-id": "click_footer_use_getBNB" + }, + { + "data_analytics_id": "click_footer_use_staking", + "href": "https://www.bnbchain.org/en/bnb-staking", + "id": 40, + "menu": 2, + "sort": 5, + "target": "_self", + "title": "Stake BNB", + "data-analytics-id": "click_footer_use_staking" + }, + { + "data_analytics_id": "click_footer_use_bnb-chain-bridge", + "href": "https://www.bnbchain.org/en/bnb-chain-bridge", + "id": 21, + "menu": 2, + "sort": 6, + "target": "_self", + "title": "Bridge Assets", + "data-analytics-id": "click_footer_use_bnb-chain-bridge" + }, + { + "data_analytics_id": "click_footer_use_DappBay", + "href": "https://dappbay.bnbchain.org?utm_source=Org&utm_medium=Channel&utm_campaign=homepage_240124&utm_content=homepage", + "id": 17, + "menu": 2, + "sort": 7, + "target": "_blank", + "title": "Explore dApps", + "data-analytics-id": "click_footer_use_DappBay" + }, + { + "data_analytics_id": "click_footer_use_BTCFi", + "href": "https://btcfi.bnbchain.org/", + "id": 41, + "menu": 2, + "sort": 8, + "target": "_self", + "title": "Earn by BTC", + "data-analytics-id": "click_footer_use_BTCFi" + }, + { + "data_analytics_id": "click_footer_use_payment", + "href": "https://www.bnbchain.org/en/payment", + "id": 42, + "menu": 2, + "sort": 9, + "target": "_self", + "title": "Pay by Crypto", + "data-analytics-id": "click_footer_use_payment" + }, + { + "data_analytics_id": "click_footer_use_liquidStaking", + "href": "https://www.bnbchain.org/en/liquid-staking", + "id": 43, + "menu": 2, + "sort": 10, + "target": "_self", + "title": "Earn by Liquid Staking", + "data-analytics-id": "click_footer_use_liquidStaking" + } + ], + "menu": "Use BNB Chain" + }, + { + "id": 5, + "items": [ + { + "data_analytics_id": "click_footer_example-hub", + "href": "https://www.bnbchain.org/en/example-hub", + "id": 56, + "menu": 5, + "sort": 2, + "target": "_self", + "title": "Demos & Tutorials", + "data-analytics-id": "click_footer_example-hub" + }, + { + "data_analytics_id": "click_footer_build_docs", + "href": "https://docs.bnbchain.org", + "id": 50, + "menu": 5, + "sort": 3, + "target": "_blank", + "title": "Documentations", + "data-analytics-id": "click_footer_build_docs" + }, + { + "data_analytics_id": "click_footer_build_faucet", + "href": "https://www.bnbchain.org/en/testnet-faucet", + "id": 51, + "menu": 5, + "sort": 4, + "target": "_self", + "title": "Faucet", + "data-analytics-id": "click_footer_build_faucet" + }, + { + "data_analytics_id": "click_footer_build_devTools", + "href": "https://www.bnbchain.org/en/dev-tools", + "id": 52, + "menu": 5, + "sort": 5, + "target": "_self", + "title": "Dev Tools", + "data-analytics-id": "click_footer_build_devTools" + }, + { + "data_analytics_id": "click_footer_build_submit-dApp", + "href": "https://dappbay.bnbchain.org/submit-dapp", + "id": 53, + "menu": 5, + "sort": 6, + "target": "_blank", + "title": "Submit dApp", + "data-analytics-id": "click_footer_build_submit-dApp" + }, + { + "data_analytics_id": "click_footer_build_DCellar", + "href": "https://dcellar.io/", + "id": 54, + "menu": 5, + "sort": 7, + "target": "_blank", + "title": "Greenfield Console", + "data-analytics-id": "click_footer_build_DCellar" + }, + { + "data_analytics_id": "click_footer_build_BNBChainList", + "href": "https://www.bnbchainlist.org", + "id": 55, + "menu": 5, + "sort": 8, + "target": "_blank", + "title": "BNBChain List", + "data-analytics-id": "click_footer_build_BNBChainList" + }, + { + "data_analytics_id": "click_footer_build_whitepaper", + "href": "https://github.com/bnb-chain/whitepaper", + "id": 19, + "menu": 5, + "sort": 9, + "target": "_blank", + "title": "Whitepaper", + "data-analytics-id": "click_footer_build_whitepaper" + } + ], + "menu": "Build" + }, + { + "id": 3, + "items": [ + { + "data_analytics_id": "click_footer_participate_events", + "href": "https://www.bnbchain.org/en/events", + "id": 22, + "menu": 3, + "sort": 1, + "target": "_self", + "title": "Events", + "data-analytics-id": "click_footer_participate_events" + }, + { + "data_analytics_id": "click_footer_participate_hackcathon", + "href": "https://www.bnbchain.org/en/hackathons", + "id": 24, + "menu": 3, + "sort": 2, + "target": "_self", + "title": "Hackathon", + "data-analytics-id": "click_footer_participate_hackcathon" + }, + { + "data_analytics_id": "click_footer_participate_MVB", + "href": "https://www.bnbchain.org/en/programs/mvb", + "id": 23, + "menu": 3, + "sort": 3, + "target": "_self", + "title": "MVB Program", + "data-analytics-id": "click_footer_participate_MVB" + }, + { + "data_analytics_id": "click_footer_participate_devProgs", + "href": "https://www.bnbchain.org/en/programs", + "id": 25, + "menu": 3, + "sort": 4, + "target": "_self", + "title": "Builder Support Programs", + "data-analytics-id": "click_footer_participate_devProgs" + }, + { + "data_analytics_id": "click_footer_participate_martiansProgram", + "href": "https://www.bnbchain.org/en/martians-program", + "id": 26, + "menu": 3, + "sort": 5, + "target": "_self", + "title": "Martians Program", + "data-analytics-id": "click_footer_participate_martiansProgram" + }, + { + "data_analytics_id": "click_footer_participate_governance", + "href": "https://www.bnbchain.org/en/bnb-chain-governance", + "id": 44, + "menu": 3, + "sort": 6, + "target": "_self", + "title": "Governance", + "data-analytics-id": "click_footer_participate_governance" + }, + { + "data_analytics_id": "click_footer_participate_bugBounty", + "href": "https://bugbounty.bnbchain.org", + "id": 27, + "menu": 3, + "sort": 7, + "target": "_blank", + "title": "Bug Bounty", + "data-analytics-id": "click_footer_participate_bugBounty" + }, + { + "data_analytics_id": "click_footer_participate_space-b", + "href": "https://www.bnbchain.org/en/space-b", + "id": 46, + "menu": 3, + "sort": 9, + "target": "_self", + "title": "Get Workspace", + "data-analytics-id": "click_footer_participate_space-b" + }, + { + "data_analytics_id": "click_footer_participate_EcosystemJobs", + "href": "https://jobs.bnbchain.org/jobs", + "id": 47, + "menu": 3, + "sort": 10, + "target": "_blank", + "title": "Ecosystem Jobs", + "data-analytics-id": "click_footer_participate_EcosystemJobs" + } + ], + "menu": "Participate" + }, + { + "id": 4, + "items": [ + { + "data_analytics_id": "click_footer_about_blog", + "href": "https://www.bnbchain.org/en/blog", + "id": 48, + "menu": 4, + "sort": 1, + "target": "_blank", + "title": "Blog", + "data-analytics-id": "click_footer_about_blog" + }, + { + "data_analytics_id": "click_footer_about_careers", + "href": "https://jobs.bnbchain.org/companies/bnb-chain#content", + "id": 30, + "menu": 4, + "sort": 2, + "target": "_blank", + "title": "Careers", + "data-analytics-id": "click_footer_about_careers" + }, + { + "data_analytics_id": "click_footer_about_verirfication", + "href": "https://www.bnbchain.org/en/official-verification", + "id": 31, + "menu": 4, + "sort": 3, + "target": "_self", + "title": "BNB Chain Verify", + "data-analytics-id": "click_footer_about_verirfication" + }, + { + "data_analytics_id": "click_footer_about_red-alarm", + "href": "https://dappbay.bnbchain.org/red-alarm/dapp", + "id": 49, + "menu": 4, + "sort": 4, + "target": "_blank", + "title": "Red Alarm", + "data-analytics-id": "click_footer_about_red-alarm" + }, + { + "data_analytics_id": "click_footer_about_privacy-policy", + "href": "https://www.bnbchain.org/en/privacy-policy", + "id": 28, + "menu": 4, + "sort": 5, + "target": "_self", + "title": "Privacy Policy", + "data-analytics-id": "click_footer_about_privacy-policy" + }, + { + "data_analytics_id": "click_footer_about_tou", + "href": "https://www.bnbchain.org/en/terms", + "id": 29, + "menu": 4, + "sort": 6, + "target": "_self", + "title": "Terms of Use", + "data-analytics-id": "click_footer_about_tou" + }, + { + "data_analytics_id": "click_footer_about_contactUs", + "href": "https://www.bnbchain.org/en/contact", + "id": 32, + "menu": 4, + "sort": 7, + "target": "_self", + "title": "Contact Us", + "data-analytics-id": "click_footer_about_contactUs" + }, + { + "data_analytics_id": "click_footer_about_brandGuidelines", + "href": "https://www.bnbchain.org/en/brand-guidelines", + "id": 33, + "menu": 4, + "sort": 8, + "target": "_self", + "title": "Brand Guidelines", + "data-analytics-id": "click_footer_about_brandGuidelines" + } + ], + "menu": "About" + } +] + +let cachedFooterMenus = null; + +async function fetchFooterMenus() { + // If we already have cached data, return it + if (cachedFooterMenus) { + return cachedFooterMenus; + } + + try { + const response = await fetch('https://www.bnbchain.org/api/v1/landing-menus'); + const data = await response.json(); + // Cache the response + cachedFooterMenus = data.footerMenus ?? DEFAULT_FOOTER_MENUS; + return cachedFooterMenus; + } catch (error) { + console.error('Error fetching footer menus:', error); + // Cache the default menus in case of error + cachedFooterMenus = DEFAULT_FOOTER_MENUS; + return cachedFooterMenus; + } +} + +function createMenuHTML(menu) { + const title = menu.menu; + return ` +
+
${title}
+ +
+ `; +} + +let observer = null; +let isUpdating = false; + +function setupObserver() { + if (observer) { + observer.disconnect(); + } + + const targetNode = document.body; + const config = { childList: true, subtree: true }; + + const callback = (mutationsList, observer) => { + // Prevent recursive calls + if (isUpdating) { + return; + } + + for (const mutation of mutationsList) { + if (mutation.type === 'childList') { + const footerInner = document.querySelector('.doc-footer__inner'); + const copyrightInner = document.querySelector('.doc-copyright__inner'); + + // Only update if footer elements are missing or empty + if ((!footerInner || !footerInner.children.length) || + (!copyrightInner || !copyrightInner.children.length)) { + + // Set flag before updating + isUpdating = true; + + // Use setTimeout to break the synchronous execution chain + setTimeout(() => { + initializeFooterMenus(); + isUpdating = false; + }, 0); + + break; + } + } + } + }; + + observer = new MutationObserver(callback); + observer.observe(targetNode, config); +} + +// Initialize footer content +function initializeFooterMenus() { + // Skip if already has content + const footerInner = document.querySelector('.doc-footer__inner'); + const copyrightElement = document.querySelector('.doc-copyright__inner'); + + if (footerInner?.children.length && copyrightElement?.children.length) { + return; + } + + // If we have cached data, use it immediately + if (cachedFooterMenus) { + updateFooterContent(cachedFooterMenus); + return; + } + + // Only fetch if we don't have cached data + fetchFooterMenus().then(footerMenus => { + updateFooterContent(footerMenus); + }); +} + +// Update footer content without triggering observer +function updateFooterContent(footerMenus) { + if (!footerMenus) return; + + const footerInner = document.querySelector('.doc-footer__inner'); + const copyrightElement = document.querySelector('.doc-copyright__inner'); + + if (footerInner && (!footerInner.children.length)) { + footerInner.innerHTML = footerMenus.map(menu => createMenuHTML(menu)).join(''); + } + + if (copyrightElement && (!copyrightElement.children.length)) { + const currentYear = new Date().getFullYear(); + copyrightElement.innerHTML = `© ${currentYear} Bnbchain.org. All rights reserved.`; + } +} + +// Handle initial page load +document.addEventListener('DOMContentLoaded', () => { + initializeFooterMenus(); + setupObserver(); +}); \ No newline at end of file diff --git a/docs/assets/js/inkeep-custom-button.js b/docs/assets/js/inkeep-custom-button.js new file mode 100644 index 0000000000..eea7d5be76 --- /dev/null +++ b/docs/assets/js/inkeep-custom-button.js @@ -0,0 +1,104 @@ +document.addEventListener("DOMContentLoaded", () => { + const inkeepScript = document.createElement("script"); + inkeepScript.src = "https://unpkg.com/@inkeep/cxkit-js@0.5.67/dist/embed.js"; + inkeepScript.type = "module"; + inkeepScript.defer = true; + document.head.appendChild(inkeepScript); + + const addInkeepWidget = ({ openChange }) => { + return Inkeep.ChatButton({ + baseSettings: { + env: "production", + apiKey: "40582708b8a0305555fa91c049bb0dfa4e192337819bd03c", // required - replace with your own API key + primaryBrandColor: "#fbc828", // your brand color, widget color scheme is derived from this + organizationDisplayName: "BNBChain", + colorMode: { + forcedColorMode: "dark", + }, + theme: { + styles: [ + { + key: "custome-theme", + type: "style", + value: ` + :root { + font-size: 16px; + } + .ikp-markdown-link { + color: #fbc828; + text-decoration: underline; + } + .ikp-chat-button__container .ikp-chat-button__button { + font-size: 16px; + padding: 8px 16px; + height: 48px; + } + .ikp-chat-button__container .ikp-chat-button__avatar-image{ + width: 24px; + height: 24px; + } + `, + }, + ], + }, + }, + aiChatSettings: { + aiAssistantName: "BNB Chain AI", + aiAssistantAvatar: `https://static.bnbchain.org/home-ui/static/images/logo.svg`, + introMessage: `Yo dev!\nI'm your AI-powered sidekick for all things BNB Chain — smart contracts, SDKs, RPCs, you name it.`, + disclaimerSettings: { + isEnabled: true, + label: 'Disclaimer', + tooltip: + 'My answers might not always be 100% accurate. Double-check when in doubt. Learn More', + }, + exampleQuestions: [ + "How do I get BNB?", + "How do I get started with RWA?", + "How do I start building or deploying a dApp?", + "Where can I find funding or grants?", + ], + }, + modalSettings: { + onOpenChange: openChange + } + }); + }; + + // Function to bind the click event to .ai-bot-wrapper + const bindAiBotWrapperEvent = (widget) => { + const aiBotWrapper = document.querySelector('.ai-bot-wrapper'); + if (aiBotWrapper) { + aiBotWrapper.replaceWith(aiBotWrapper.cloneNode(true)); + const newAiBotWrapper = document.querySelector('.ai-bot-wrapper'); + newAiBotWrapper.addEventListener('click', () => { + widget.update?.({ modalSettings: { isOpen: true } }); + window.dataLayer?.push({ event: "click_AiBot_floatBtn" }); + }); + } else { + console.warn('.ai-bot-wrapper element not found. Ensure it is rendered correctly.'); + } + }; + + inkeepScript.addEventListener("load", () => { + const widget = addInkeepWidget({ + openChange(isOpen) { + widget.update?.({ modalSettings: { isOpen } }); + } + }); + + bindAiBotWrapperEvent(widget); + + const originalPushState = history.pushState; + history.pushState = function (...args) { + originalPushState.apply(this, args); + setTimeout(() => bindAiBotWrapperEvent(widget), 300); + setTimeout(() => bindAiBotWrapperEvent(widget), 1000); + }; + + window.addEventListener('popstate', () => { + setTimeout(() => bindAiBotWrapperEvent(widget), 300); + setTimeout(() => bindAiBotWrapperEvent(widget), 1000); + }); + }); +}); diff --git a/docs/assets/style/components/ai-bot-button.css b/docs/assets/style/components/ai-bot-button.css new file mode 100644 index 0000000000..362978334e --- /dev/null +++ b/docs/assets/style/components/ai-bot-button.css @@ -0,0 +1,65 @@ +.ai-bot-wrapper { + height: 40px; + border-radius: 40px; + background: linear-gradient(180deg, #FFE900 0%, #18DC7E 100%); + padding: 1px; + overflow: hidden; + position: fixed; + z-index: 3; + right: 24px; + bottom: 80px; +} + +.ai-bot-wrapper button { + display: inline-flex; + appearance: none; + align-items: center; + justify-content: center; + user-select: none; + position: relative; + white-space: nowrap; + vertical-align: middle; + outline: 2px solid transparent; + outline-offset: 2px; + line-height: 1rem; + min-width: 72px; + padding-inline-start: 16px; + padding-inline-end: 16px; + padding-left: 15px; + padding-right: 7px; + border-radius: 38px; + background: #181A1E; + height: 100%; + color: #FFE900; + font-weight: 500; + transition: all 0.15s; + cursor: pointer; + font-size: 14px; + border-width: 0; +} + +.ai-bot-wrapper button:hover { + background: transparent; + color: #181A1E; +} + +.ai-bot-wrapper span { + display: inline-flex; + align-self: center; + flex-shrink: 0; + margin-inline-start: 0; +} + +.ai-bot-wrapper svg { + width: 24px; + height: 24px; + display: inline-block; + line-height: 1em; + flex-shrink: 0; + color: currentColor; + vertical-align: middle; +} + +[id^=inkeep-widget] { + display: none; +} \ No newline at end of file diff --git a/docs/assets/style/components/footer.css b/docs/assets/style/components/footer.css index f28c85ff3e..510220dddd 100644 --- a/docs/assets/style/components/footer.css +++ b/docs/assets/style/components/footer.css @@ -16,7 +16,7 @@ } .doc-footer__inner > div { - min-width: 270px; + min-width: 205px; } .doc-footer__inner > div > div { diff --git a/docs/bc-fusion/BEP299 b/docs/bc-fusion/BEP299 new file mode 100644 index 0000000000..03066b080c --- /dev/null +++ b/docs/bc-fusion/BEP299 @@ -0,0 +1 @@ +https://www.bnbchain.org/en/token-recovery diff --git a/docs/bc-fusion/faq/recovering-eos-token-from-safepal.md b/docs/bc-fusion/faq/recovering-eos-token-from-safepal.md new file mode 100644 index 0000000000..e5db811e6c --- /dev/null +++ b/docs/bc-fusion/faq/recovering-eos-token-from-safepal.md @@ -0,0 +1,45 @@ +--- +title: Recovering EOS Tokens from SafePal Wallet After BEP2 Shutdown - BNBChain Fusion FAQs +--- + +### Why can’t I recover my EOS tokens after the BEP2 network shutdown? + +The BNB Beacon Chain (BEP2) was officially shut down, and all recovery of assets like EOS requires using the **official token recovery dApp**. This dApp only supports specific wallets like **Trust Wallet** and **BNB Chain Wallet Extension**. If your tokens remained on BEP2 and were **not cross-chain bound**, they are not eligible for recovery. + +### My EOS tokens are on a SafePal hardware wallet. Can I use that for recovery? + +Unfortunately, **SafePal hardware wallets are not currently supported** by the official token recovery dApp. Even though you can sign transactions with SafePal, the dApp requires wallet extensions that can directly interface with it (e.g., Trust Wallet Extension or BNB Chain Wallet). + +### What if I have my seed phrase? + +If your SafePal wallet was created using a **seed phrase + passphrase** and you’ve forgotten the passphrase, you **cannot recover the wallet in another supported service** like Trust Wallet or MetaMask. Both the seed and passphrase are required for access. + +### Can I still use the SafePal wallet to recover EOS? + +Not through the **official recovery process**. The recovery dApp doesn't support direct connection to SafePal. Even though you can sign transactions, that isn’t enough to complete recovery without compatibility with the recovery tool. + +### Is there any workaround? + +At this time, **no official workaround** exists. If you **cannot remember the passphrase** and **cannot import the wallet into a supported service**, your access to the recovery tool is blocked. + +You can try: + +- Continuing to check with **SafePal support** for any recovery options. +- Monitoring for future updates to the **token recovery dApp** that might include SafePal support. + +### Can BNB Chain team recover my tokens? + +No. Token recovery is **only possible through self-custody**, meaning **you must control and access your wallet**. If you cannot provide the full credentials (seed + passphrase), no team or admin can assist with recovery due to decentralization and security policies. + +### Why wasn’t this communicated earlier? + +The BNB Beacon Chain sunset was publicly announced along with recovery guidelines. However, **not all hardware wallets were supported**, and **users were advised to migrate assets before the shutdown**. Unfortunately, if you missed the window and cannot access your wallet via supported tools, recovery is no longer possible through official channels. + +> **Important:** Always store your seed phrase and any additional passphrases securely. Use wallets and services that provide wide compatibility when dealing with network migrations. + +### Need help? + +If you’d like further assistance, you can: +- Reach out to **SafePal support**. +- Review the [official BNB Chain documentation](https://docs.bnbchain.org/bc-fusion/post-fusion/token-recovery). +- Join the community by [opening a ticket on Discord](https://discord.com/invite/bnbchain) to share your case. diff --git a/docs/bc-fusion/post-fusion/faq.md b/docs/bc-fusion/post-fusion/faq.md index 2da95e5b64..2f31fa17d0 100644 --- a/docs/bc-fusion/post-fusion/faq.md +++ b/docs/bc-fusion/post-fusion/faq.md @@ -64,4 +64,10 @@ the explorer for BC testnet will be shut down if there is no query traffic for a * Explorer service (including UI) - Testnet explorer service: https://testnet-explorer.bnbchain.org/ - - Mainnet explorer service: https://explorer.bnbchain.org/ \ No newline at end of file + - Mainnet explorer service: https://explorer.bnbchain.org/ + +# Other Commonly Asked Questions + +- [Recovering EOS Tokens from SafePal Wallet After BEP2 Shutdown](../faq/recovering-eos-token-from-safepal.md) + +If your issue is not listed here, please explore our other documentation or open an issue. diff --git a/docs/bnb-greenfield/getting-started/general-faqs.md b/docs/bnb-greenfield/getting-started/general-faqs.md index 13dfbfb3b1..471ac76492 100644 --- a/docs/bnb-greenfield/getting-started/general-faqs.md +++ b/docs/bnb-greenfield/getting-started/general-faqs.md @@ -136,3 +136,21 @@ If a single transaction only store a small size file to the Greenfield Network, * Be Mindful to Delete Currently, the reserve time to be charged on Greenfield is 6 months. It means a six-month storage fee will charged even for deleted items. + +### What shall I do if my account is frozen? +The reason for a frozen account and the way to resolve it are explained in detail in the [Force Settlement, Freeze and Resume](https://docs.bnbchain.org/bnb-greenfield/core-concept/billing-payment/#force-settlement-freeze-and-resume) section. + +To deposit funds into your frozen account and unfreeze it, you can follow these methods: + +#### Using the Greenfield Command + + * Refer to the [Account Operations](https://docs.bnbchain.org/bnb-greenfield/getting-started/greenfield-command/#account-operations) section to set up the environment locally. + * Once set up, execute the following two commands to deposit to your account: + ```shell + gnfd-cmd payment-account create + gnfd-cmd payment-account deposit --toAddress [your_fronzen_account_address] --amount [amount_of_bnb_in_wei] + ``` +#### Using the Greenfield Go SDK + + * Refer to the [Go SDK Example](https://docs.bnbchain.org/bnb-greenfield/for-developers/apis-and-sdks/sdk-go) section to set up the environment locally. + * Once set up, use [deposit](https://pkg.go.dev/github.com/bnb-chain/greenfield-go-sdk@v1.7.4/client#Client.Deposit) method to deposit to your account. diff --git a/docs/bnb-opbnb/advanced/full-stack-dapp.md b/docs/bnb-opbnb/advanced/full-stack-dapp.md index 3dfb467942..ac62518baa 100644 --- a/docs/bnb-opbnb/advanced/full-stack-dapp.md +++ b/docs/bnb-opbnb/advanced/full-stack-dapp.md @@ -13,9 +13,9 @@ opBNB is essentially an optimized layer-2 solution that delivers lower fees and For this tutorial, we will deploy a simple `HelloWorld` smart contract on the opBNB network and build a frontend using Reactjs to interact with the deployed smart contract for reading and writing data onto the opBNB blockchain. The `HelloWorld` smart contract is a simple string variable message that will be used for storing the user-defined messages, e.g., `Hello, opBNB User`. The `updateMessage` function will be used for updating the message variable to any user-defined string value. -This smart contract will then be deployed on the opBNB network using [Truffle IDE](https://trufflesuite.com/). We will then use the [Reactjs boilerplate](https://create-react-app.dev/) to build a front end to communicate with the smart contract. [Web3.js library](https://web3js.readthedocs.io/en/v1.10.0/#) is used for interacting with the smart contract and reading and writing data to the opBNB blockchain. We further use [Metamask](https://metamask.io/) for signing transactions and paying any gas costs. +This smart contract will then be deployed on the opBNB network using [Truffle IDE](https://trufflesuite.com/). We will then use the [Reactjs boilerplate](https://create-react-app.dev/) to build a front end to communicate with the smart contract. [Web3.js library](https://web3js.readthedocs.io/en/v1.10.0/#) is used for interacting with the smart contract and reading and writing data to the opBNB blockchain. We further use [TrustWallet](https://trustwallet.com/) or [Metamask](https://metamask.io/) for signing transactions and paying any gas costs. -*This is a basic example for educational purposes, and it assumes familiarity with [Truffle](https://trufflesuite.com/), [React](https://react.dev/), and [MetaMask](https://metamask.io/).* +*This is a basic example for educational purposes, and it assumes familiarity with [Truffle](https://trufflesuite.com/), [React](https://react.dev/), [TrustWallet](https://trustwallet.com/), and [MetaMask](https://metamask.io/).* ## Learning Takeaways @@ -28,10 +28,11 @@ By the end of this tutorial, you will be able to achieve the following ## Pre-requisites - [Node.js (Node v18.14.2)](https://nodejs.org/en/download/) +- [TrustWallet](https://trustwallet.com/) - [Metamask Web Wallet](https://metamask.io/) - [Truffle v5.10.0](https://trufflesuite.com/docs/truffle/how-to/install/) -- Get tBNB in your Metamask wallet configured with opBNB Testnet - - [Metamask Wallet Configuration for opBNB.](../get-started/wallet-configuration.md) +- Get tBNB in your wallet configured with opBNB Testnet + - [Wallet Configuration for opBNB.](../get-started/wallet-configuration.md) - [Deposit tBNB to your opBNB account](../get-started/deposit-to-opbnb.md) ## Demo Step-by-Step Guide diff --git a/docs/bnb-opbnb/advanced/local-node.md b/docs/bnb-opbnb/advanced/local-node.md index 9bda4f7bed..793d341f2a 100644 --- a/docs/bnb-opbnb/advanced/local-node.md +++ b/docs/bnb-opbnb/advanced/local-node.md @@ -123,14 +123,19 @@ export P2P_BOOTNODES="enr:-KO4QKFOBDW--pF4pFwv3Al_jiLOITj_Y5mr1Ajyy2yxHpFtNcBfkZ --syncmode=full \ --maxpeers=10 \ --networkid=$CHAIN_ID \ - --miner.gaslimit=150000000 \ --triesInMemory=32 \ - --txpool.globalslots=10000 \ + --txpool.globalslots=20000 \ --txpool.globalqueue=5000 \ - --txpool.accountqueue=200 \ - --txpool.accountslots=200 \ - --cache 32000 \ + --txpool.accountqueue=64 \ + --txpool.accountslots=16 \ + --txpool.pricelimit=1 \ + --txpool.nolocals=true \ + --pathdb.nodebuffer=list \ + --pathdb.proposeblock=3600 \ + --cache 6000 \ --cache.preimages \ + --journalfile \ + --history.transactions=0 \ --allow-insecure-unlock \ --authrpc.addr="0.0.0.0" \ --authrpc.port="8551" \ @@ -177,7 +182,7 @@ export P2P_BOOTNODES="enr:-J24QGQBeMsXOaCCaLWtNFSfb2Gv50DjGOKToH2HUTAIn9yXImowlR --sequencer.l1-confs=15 \ --verifier.l1-confs=15 \ --l1.http-poll-interval 3s \ - --l1.epoch-poll-interval 45s \ + --l1.epoch-poll-interval 3s \ --l1.rpc-max-batch-size 20 \ --rollup.config=./rollup.json \ --rpc.addr=0.0.0.0 \ @@ -196,8 +201,8 @@ export P2P_BOOTNODES="enr:-J24QGQBeMsXOaCCaLWtNFSfb2Gv50DjGOKToH2HUTAIn9yXImowlR --l1=${L1_RPC} \ --l2=${L2_RPC} \ --l2.jwt-secret=./jwt.txt \ - --l2.engine-sync=true \ - --l2.skip-sync-start-check=true \ + --syncmode=execution-layer \ + --l1.max-concurrency=20 \ --log.level=debug ``` diff --git a/docs/bnb-opbnb/advanced/node-best-practices.md b/docs/bnb-opbnb/advanced/node-best-practices.md index a8355e20d9..7f990b7264 100644 --- a/docs/bnb-opbnb/advanced/node-best-practices.md +++ b/docs/bnb-opbnb/advanced/node-best-practices.md @@ -81,17 +81,6 @@ It is particularly advised to operate a full node with PBSS and pebble to minimi For comprehensive details, consult the [PBSS document](./run-with-pebbledb-and-pbss.md). -### Archive Node(with op-reth) - -The Archive node mode archives the entirety of history trie data. -This mode is apt for scenarios necessitating access to the complete history trie data, such as block explorers and analytics. - -The current volume of history trie data approximates 3TB (as of the end of April, 2024). -Significant performance issues may arise in the op-geth implementation when managing extensive history trie data. -Therefore, it is recommended to operate the archive node in conjunction with op-reth. - -You can refer to [Reth Node for opBNB](./reth-node.md) for additional details. - ## Snapshots The latest snapshot data is accessible via the [opbnb-snapshot](https://github.com/bnb-chain/opbnb-snapshot) repository. diff --git a/docs/bnb-opbnb/advanced/reth-node.md b/docs/bnb-opbnb/advanced/reth-node.md deleted file mode 100644 index cb2e5cfdc2..0000000000 --- a/docs/bnb-opbnb/advanced/reth-node.md +++ /dev/null @@ -1,159 +0,0 @@ ---- -title: Reth Node - opBNB Develop ---- - -# Reth Node for opBNB - -OpBNB Reth is a Rust client developed to provide support for the opBNB network. It aims to enhance client diversity and performance on the BNB Chain. - -## Hardware Specifications - -To run OpBNB Reth effectively, ensure your system meets the following hardware requirements: - -* CPU with 16+ cores -* 128GB RAM -* High-performance NVMe SSD with at least 3TB of free space -* A broadband internet connection with upload/download speeds of 25 MB/s - -## Running opBNB Reth Node - -The opBNB Reth is an [execution client](https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-clients) for -opBNB network. You need to run op-node along with op-reth to synchronize with the opBNB network. - -**It's important to note that both op-node and op-reth must use the same JWT secret file for authentication.** -You can use the following command to generate JWT secret file and copy to the workdir for running op-node and op-reth. -```shell -openssl rand -hex 32 > jwt.txt -``` - -### Running OP Node -1. Download source code and build -```shell -git clone https://github.com/bnb-chain/opbnb -cd opbnb -make op-node -``` - -2. Start op-node -```shell -# for mainnet -export network=mainnet -export L1_RPC=https://bsc-dataseed.bnbchain.org -export P2P_BOOTNODES="enr:-J24QA9sgVxbZ0KoJ7-1gx_szfc7Oexzz7xL2iHS7VMHGj2QQaLc_IQZmFthywENgJWXbApj7tw7BiouKDOZD4noWEWGAYppffmvgmlkgnY0gmlwhDbjSM6Hb3BzdGFja4PMAQCJc2VjcDI1NmsxoQKetGQX7sXd4u8hZr6uayTZgHRDvGm36YaryqZkgnidS4N0Y3CCIyuDdWRwgiMs,enr:-J24QPSZMaGw3NhO6Ll25cawknKcOFLPjUnpy72HCkwqaHBKaaR9ylr-ejx20INZ69BLLj334aEqjNHKJeWhiAdVcn-GAYv28FmZgmlkgnY0gmlwhDTDWQOHb3BzdGFja4PMAQCJc2VjcDI1NmsxoQJ-_5GZKjs7jaB4TILdgC8EwnwyL3Qip89wmjnyjvDDwoN0Y3CCIyuDdWRwgiMs" - -# for testnet -# it's better to replace the L1_RPC with your own BSC Testnet RPC Endpoint for stability -# export network=testnet -# export L1_RPC=https://bsc-testnet.bnbchain.org -# export P2P_BOOTNODES="enr:-J24QGQBeMsXOaCCaLWtNFSfb2Gv50DjGOKToH2HUTAIn9yXImowlRoMDNuPNhSBZNQGCCE8eAl5O3dsONuuQp5Qix2GAYjB7KHSgmlkgnY0gmlwhDREiqaHb3BzdGFja4PrKwCJc2VjcDI1NmsxoQL4I9wpEVDcUb8bLWu6V8iPoN5w8E8q-GrS5WUCygYUQ4N0Y3CCIyuDdWRwgiMr,enr:-J24QJKXHEkIhy0tmIk2EscMZ2aRrivNsZf_YhgIU51g4ZKHWY0BxW6VedRJ1jxmneW9v7JjldPOPpLkaNSo6cXGFxqGAYpK96oCgmlkgnY0gmlwhANzx96Hb3BzdGFja4PrKwCJc2VjcDI1NmsxoQMOCzUFffz04eyDrmkbaSCrMEvLvn5O4RZaZ5k1GV4wa4N0Y3CCIyuDdWRwgiMr" - -./op-node/bin/op-node \ - --l1.trustrpc \ - --sequencer.l1-confs=15 \ - --verifier.l1-confs=15 \ - --l1.http-poll-interval 60s \ - --l1.epoch-poll-interval 180s \ - --l1.rpc-max-batch-size 20 \ - --rollup.config=./assets/${network}/rollup.json \ - --rpc.addr=0.0.0.0 \ - --rpc.port=8546 \ - --p2p.sync.req-resp \ - --p2p.listen.ip=0.0.0.0 \ - --p2p.listen.tcp=9003 \ - --p2p.listen.udp=9003 \ - --snapshotlog.file=./snapshot.log \ - --p2p.bootnodes=$P2P_BOOTNODES \ - --metrics.enabled \ - --metrics.addr=0.0.0.0 \ - --metrics.port=7300 \ - --pprof.enabled \ - --rpc.enable-admin \ - --l1=${L1_RPC} \ - --l2=http://localhost:8551 \ - --l2.jwt-secret=./jwt.txt \ - --syncmode=execution-layer -``` - -### Running opBNB Reth Archive Node -1. Download source code and build -```shell -git clone https://github.com/bnb-chain/reth.git -cd reth -make build-op -``` - -2. Start op-reth -```shell -# for mainnet -export network=mainnet -export L2_RPC=https://opbnb-mainnet-rpc.bnbchain.org - -# for testnet -# export network=testnet -# export L2_RPC=https://opbnb-testnet-rpc.bnbchain.org - -./target/release/op-reth node \ - --datadir=./datadir \ - --chain=opbnb-${network} \ - --rollup.sequencer-http=${L2_RPC} \ - --authrpc.addr="0.0.0.0" \ - --authrpc.port=8551 \ - --authrpc.jwtsecret=./jwt.txt \ - --http \ - --http.api="eth, net, txpool, web3, rpc" \ - --log.file.directory ./datadir/logs -``` - -3. Alternatively, you can run the op-reth node with docker -```shell -# for mainnet -export network=mainnet -export L2_RPC=https://opbnb-mainnet-rpc.bnbchain.org - -# for testnet -# export network=testnet -# export L2_RPC=https://opbnb-testnet-rpc.bnbchain.org - -# check this for version of the docker image, https://github.com/bnb-chain/reth/pkgs/container/op-reth -export version=latest - -# the directory where reth data will be stored -export data_dir=/xxx/xxx - -# the directory where the jwt.txt file is stored -export jwt_dir=/xxx/xxx - -docker run -d -p 8545:8545 -p 30303:30303 -p 30303:30303/udp -v ${data_dir}:/data -v ${jwt_dir}:/jwt \ - --name op-reth ghcr.io/bnb-chain/op-reth:${version} node \ - --datadir=/data \ - --chain=opbnb-${network} \ - --rollup.sequencer-http=${L2_RPC} \ - --authrpc.addr="0.0.0.0" \ - --authrpc.port=8551 \ - --authrpc.jwtsecret=/jwt/jwt.txt \ - --http \ - --http.api="eth, net, txpool, web3, rpc" \ - --log.file.directory /data/logs -``` - -### Running opBNB Reth Full Node - -To run a full node, simply add the `--full` flag when starting the op-reth node. - -## Benchmark Results - -We benchmark [Reth(v1.0.0)](https://github.com/bnb-chain/reth/releases/tag/v1.0.0), [op-nodes(v0.4.2)](https://github.com/bnb-chain/opbnb/releases/tag/v0.4.2) on AWS [i4g.4xlarge](https://instances.vantage.sh/aws/ec2/i4g.4xlarge)(16 core 128G) instance with NVMe SSD for opBNB. -It may take approximately 53 hours to sync the latest block on opBNB mainnet for an archive node and 50 hours for a full node. - -The op-reth supports Stage Sync which is rearchitected for better performance for the initial sync from genesis and Live Sync. -The following table displays the total time to stage sync and storage distribution after catch up on opBNB network: - -![img](../img/op-reth-stagesync-benchmark.png) - -The result shows an encouraging 690 MGas/s result on historical sync in the last 1M blocks (the historical sync numbers represent pure execution time during "backfills"). - -The live sync performance on the opBNB network is not very optimistic. We conducted an observation of the metrics for blocks [30467068, 30429919]. - -![img](../img/op-reth-livesync-benchmark.png) - -The main reason for the underperformance of Live sync is that mdbx is not a write-friendly database. The commit db at the end of block execution takes up several tens of milliseconds, a challenge that becomes more pronounced for fast-blocking layer 2 solutions like opBNB. \ No newline at end of file diff --git a/docs/bnb-opbnb/advanced/run-your-own-l2-with-opbnb.md b/docs/bnb-opbnb/advanced/run-your-own-l2-with-opbnb.md new file mode 100644 index 0000000000..d6d530b80e --- /dev/null +++ b/docs/bnb-opbnb/advanced/run-your-own-l2-with-opbnb.md @@ -0,0 +1,1178 @@ +--- +sidebar_label: Creating Your Own L2 Rollup Testnet +description: Guide to creating your own l2 rollup Testnet +--- + +# Creating Your Own L2 Rollup Testnet + +This tutorial is designed for developers who want to create l2 rollup testnet chain. You'll walk through the full deployment process and teach you all of the components that make up the l2 rollup, and you'll end up with your own l2 rollup testnet. + +You can use this testnet to experiment and perform tests, or you can choose to modify the chain to adapt it to your own needs. + +# Introduction + +The opBNB stack is the Layer 2 scaling framework for the BNB Smart Chain powered by[ bedrock version](https://community.optimism.io/docs/developers/bedrock/) of Optimism OP Stack. It works by offloading transaction processing and resource usage from the BNB Smart Chain, while still posting data to the underlying mainnet. Users can build their own L2 network with the framework. And then they can interact with the network by depositing funds from BSC and using applications and contracts on the network. Sequencers then aggregate transactions, compute state transitions and submit them to the rollup contract on BSC. Provers generate cryptographic proofs that prove the validity of these state transitions, and Verifiers check the proofs to verify the L2 network’s state is correct. At its core, it allows users to deposit and withdraw funds, use smart contracts, and view network data with high throughput and low fees. + +![image-20250411135104222](../img/image-20250411135104222.png) + +# What You're Going to Deploy + +## Deployment Architecture + +![image-20250411135320376](../img/image-20250411135320376.png) + +Sequencer + +Proposer + +Batcher + +Bridge node + +RPC node + + + +When deploying a l2 rollup chain, you'll be setting up four different components. It's useful to understand what each of these components does before you start deploying your chain. + +## Smart Contracts + +The l2 rollup gives you the ability to deploy your own l2 rollup that use a Layer 1 blockchain to host and order transaction data. The l2 rollup uses several smart contracts on the L1 blockchain to manage aspects of the Rollup. You'll be using the L1 smart contracts found in the [contracts-bedrock package](https://github.com/bnb-chain/opbnb/tree/develop/packages/contracts-bedrock) within the [opbnb](https://github.com/bnb-chain/opbnb). + +## Sequencer Node + +The l2 rollup uses Sequencer node to gather proposed transactions from users and publish them to the L1 blockchain. + +### Consensus Client + +The l2 rollup has a consensus client. The consensus client is responsible for determining the list and ordering of blocks and transactions that are part of your blockchain. In this tutorial you'll be using the [op-node](https://github.com/bnb-chain/opbnb/tree/develop/op-node) found within the [opbnb](https://github.com/bnb-chain/opbnb). + +### Execution Client + +The l2 rollup has an execution client. The execution client is responsible for executing transactions and storing/updating the state of the blockchain. In this tutorial you'll be using the [op-geth](https://github.com/bnb-chain/op-geth) found within the [op-geth](https://github.com/bnb-chain/op-geth) repository. + +Each of the Sequencer, Bridge, and RPC nodes runs both an op-node and an op-geth process—the sequencer start op-node process with a miner flag and the others run with fullnode flag . The key difference between an RPC node and a bridge node is that an RPC node exposes a public endpoint for external users to access, while a bridge node is not externally reachable. The bridge node functions like a cache for sequencer node : it forwards incoming transactions to the sequencer, helping prevent the sequencer’s transaction pool from being overloaded. + +## Batcher + +The Batcher is a service that publishes transactions from the Sequencer to the L1 blockchain. The Batcher runs continuously alongside the Sequencer and publishes transactions in batches (hence the name) on a regular basis. You'll be using the [op-batcher](https://github.com/bnb-chain/opbnb/tree/develop/op-batcher) of the Batcher component found within the [opbnb](https://github.com/bnb-chain/opbnb). + +## Proposer + +The Proposer is a service responsible for publishing transactions results (in the form of L2 state roots) to the L1 blockchain. This allows smart contracts on L1 to read the state of the L2, which is necessary for cross-chain communication and reconciliation between state changes. You'll be using the [op-proposer](https://github.com/bnb-chain/opbnb/tree/develop/op-proposer) of the Proposer component found within the [opbnb](https://github.com/bnb-chain/opbnb). + + + +# Software Dependencies + +| Dependency | Version | Version Check Command | +|:----------:|:-------:|:---------------------:| +| git | ^2 | git --version | +| go | ^1.21 | go version | +| node | ^20 | node --version | +| pnpm | ^8 | pnpm --version | +| foundry | ^0.2.0 | forge --version | +| make | ^3 | make --version | +| jq | ^1.6 | jq --version | +| direnv | ^2 | direnv --version | +| gcc | ^13 | gcc --version | +| libc-dev | ^2.35 | ldd --version | + + + +# Hardware requirements + +**CPU**: 4 × 2 GHz (or faster) 64‑bit processor cores + +**Memory**: 16 GB DDR4 RAM + +**For `op-geth` (execution layer)**: + +- High‑performance SSD with sustained IOPS ≥ 20,000, **or** an enterprise-grade NVMe SSD (to ensure low latency under heavy state‑healing workloads) [gist.github](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038?utm_source=chatgpt.com)[docs.optimism](https://docs.optimism.io/operators/node-operators/tutorials/mainnet?utm_source=chatgpt.com) +- ≥ 3 TB capacity + +**For `op-node` (consensus & aggregation)**: + +- Standard SSD (SATA or consumer NVMe) is sufficient, ≥ 500 GB + +## Notes on Specific Dependencies + +`node` + +We recommend using the latest LTS version of Node.js (currently v20). [nvm](https://github.com/nvm-sh/nvm) is a useful tool that can help you manage multiple versions of Node.js on your machine. You may experience unexpected errors on older versions of Node.js. + +`foundry` + +It's recommended to use the scripts in the [opbnb's](https://github.com/bnb-chain/opbnb) package.json for managing foundry to ensure you're always working with the correct version. This approach simplifies the installation, update, and version checking process. Make sure to clone the [opbnb](https://github.com/bnb-chain/opbnb) locally before proceeding. + +`direnv` + +Parts of this tutorial use [direnv](https://direnv.net/) as a way of loading environment variables from `.envrc` files into your shell. This means you won't have to manually export environment variables every time you want to use them. `direnv` only ever has access to files that you explicitly allow it to see. + +After [installing direnv](https://direnv.net/docs/installation.html), you will need to make sure that `direnv` is [hooked into your shell](https://direnv.net/docs/hook.html). Make sure you've followed [the guide on the `direnv` website](https://direnv.net/docs/hook.html), then close your terminal and reopen it so that the changes take effect (or source your config file if you know how to do that). + +# Get Access to a BSC testnet Node + +You'll be deploying a BSC l2 rollup that uses a Layer 1 blockchain to host and order transaction data. + +This guide uses the BSC testnet as an L1 chain. You can also use other EVM-compatible blockchains, but you may run into unexpected errors. If you want to use an alternative network, make sure to carefully review each command and replace any BSC testnet values with the values for your network. + +Since you're deploying your l2 rollup on BSC testnet, you'll need to have access to a BSC testnet node. + +# Build the Source Code + +You're going to be creating your own l2 rollup directly from source code instead of using a container system like [Docker](https://www.docker.com/). Although this adds a few extra steps, it means you'll have an easier time modifying the behavior of the l2 rollup if you'd like to do so. If you want a summary of the various components you'll be using, take another look at the [What You're Going to Deploy](#what-youre-going-to-deploy) section above. + +## Build the opbnb + +### Clone the opbnb +``` +cd ~ +git clone https://github.com/bnb-chain/opbnb.git +``` + +### Enter the opbnb +``` +cd opbnb +``` + +### Check out the correct branch + +You can choose the appropriate version according to your needs. The develop branch has the latest features. +``` +git checkout -b develop origin/develop +``` + +### Install dependencies + +``` +pnpm install +``` + +### Build the various packages inside of the opbnb +``` +make op-node op-batcher op-proposer +``` + +## Build `op-geth` + +### Clone op-geth +``` +cd ~ +git clone https://github.com/bnb-chain/op-geth.git +``` + +### Check out the correct branch + +You can choose the appropriate version according to your needs. The develop branch has the latest features. +``` +git checkout -b v0.5.7 +``` + +### Enter op-geth +``` +cd op-geth +``` + +### Build op-geth +``` +make geth +``` + +# Fill Out Environment Variables + +You'll need to fill out a few environment variables before you can start deploying your chain. + +### Enter the opbnb +``` +cd ~/opbnb +``` + +### Duplicate the sample environment variable file +``` +cp .envrc.example .envrc +``` + +### Fill out the environment variable file +Open up the environment variable file and fill out the following variables: + +| Variable Name | Description | +|:----------:|:-----------------------------------------------------------------------------------------------------:| +| L1_RPC_URL | URL for your L1 node | +| L1_RPC_KIND | Kind of L1 RPC you're connecting to, used to inform optimal transactions receipts fetching(Optional). | +| L1_CHAIN_ID | The Chain id of L1 chain ( bsc testnet is 97) | +| L1_BLOCK_TIME | The block interval value of L1 CHAIN | +| L2_CHAIN_ID | The Chain id of Layer 2 chain | +| L2_BLOCK_TIME | The block interval value of L2 CHAIN | + +# Generate Addresses +You'll need four addresses and their private keys when setting up the chain: + +* The Admin address has the ability to upgrade contracts. +* The Batcher address publishes Sequencer transaction data to L1. +* The Proposer address publishes L2 transaction results (state roots) to L1. +* The Sequencer address signs blocks on the p2p network. + +## Enter the opbnb +``` +cd ~/opbnb +``` + +## Generate new addresses +``` +./packages/contracts-bedrock/scripts/getting-started/wallets.sh +``` + +## Check the output +Make sure that you see output that looks something like the following: +``` +Copy the following into your .envrc file: + +# Admin account +export GS_ADMIN_ADDRESS=0xC18e23D98F121c48a56E19302D1B7FB9b82A0F2E +export GS_ADMIN_PRIVATE_KEY=0x5d5e555305c69711eb31dd24dd1530b137489c54ddc83afd421f581c3fbf6c67 + +# Batcher account +export GS_BATCHER_ADDRESS=0x7527Cc2860B71E654a98235c8CF5D8Ca792040FE +export GS_BATCHER_PRIVATE_KEY=0xf6c2a7cf909a41fc227b03cf6474c66eaff5e05b36a89394f5a5129598fa8d13 + +# Proposer account +export GS_PROPOSER_ADDRESS=0xeE7579518904123AE4b3BaB729A4B9c9c08D5658 +export GS_PROPOSER_PRIVATE_KEY=0x95176e9e67c1b97b4b7aaedf66e0b34b446f8683d545b44214240f6f1cfa6891 + +# Sequencer account +export GS_SEQUENCER_ADDRESS=0xeCF961D156a2ce02E98Ad26E79De62BcFd403cfd +export GS_SEQUENCER_PRIVATE_KEY=0xbb019ddc5f081b2be0c1c9406f89887ba90f4c8efbe5c4073ee067e56d3107ea +``` + +## Save the addresses +Copy the output from the previous step and paste it into your `.envrc` file as directed. + +## Fund the addresses +You will need to send BNB to the Admin, Proposer, and Batcher addresses. The exact amount of BNB required depends on the L1 network being used. You do not need to send any BNB to the Sequencer address as it does not send transactions. + +It's recommended to fund the addresses with the following amounts when using BSC testnet: + +* Admin — 1 BNB + +* Proposer — 2 BNB + +* Batcher — 15 BNB + + Estimated monthly consumption: + + \- **Batcher**: ~30 tBNB (testnet) / ~2 BNB (mainnet) + + \- **Proposer**: ~5 tBNB (testnet) / ~0.1 BNB (mainnet) + + + + +# Load Environment variables + +Now that you've filled out the environment variable file, you need to load those variables into your terminal. + +## Enter the opbnb +``` +cd ~/opbnb +``` + +## Load the variables with direnv +You're about to use `direnv` to load environment variables from the `.envrc` file into your terminal. Make sure that you've [installed `direnv`](https://direnv.net/docs/installation.html) and that you've properly hooked `direnv` into your shell. +Next you'll need to allow `direnv` to read this file and load the variables into your terminal using the following command. +``` +direnv allow +``` +`direnv` will unload itself whenever your `.envrc` file changes. You must rerun the following command every time you change the `.envrc` file. + +## Confirm that the variables were loaded +After running `direnv allow` you should see output that looks something like the following (the exact output will vary depending on the variables you've set, don't worry if it doesn't look exactly like this): +``` +direnv: loading ~/optimism/.envrc +direnv: export +DEPLOYMENT_CONTEXT +ETHERSCAN_API_KEY +GS_ADMIN_ADDRESS +GS_ADMIN_PRIVATE_KEY +GS_BATCHER_ADDRESS +GS_BATCHER_PRIVATE_KEY +GS_PROPOSER_ADDRESS +GS_PROPOSER_PRIVATE_KEY +GS_SEQUENCER_ADDRESS +GS_SEQUENCER_PRIVATE_KEY +IMPL_SALT +L1_RPC_KIND +L1_RPC_URL +PRIVATE_KEY +TENDERLY_PROJECT +TENDERLY_USERNAME +``` +If you don't see this output, you likely haven't properly configured `direnv`. Make sure you've configured `direnv` properly and run `direnv allow` again so that you see the desired output. + +If you don't want to use `direnv`, you can also set variables manually. + +# Configure your network + +Once you've built both repositories, you'll need to head back to the opbnb to set up the configuration file for your chain. Currently, chain configuration lives inside of the [contracts-bedrock package](https://github.com/bnb-chain/opbnb/tree/develop/packages/contracts-bedrock) in the form of a JSON file. + +## Enter the opbnb +``` +cd ~/opbnb +``` + +## Move into the contracts-bedrock package +``` +cd packages/contracts-bedrock +``` + +## Generate the configuration file +Run the following script to generate the `getting-started.json` configuration file inside of the `deploy-config` directory. +``` +./scripts/getting-started/config.sh +``` + +The script-based approach shown above is the one officially recommended by OP, and the generated configuration is the official version. However, we strongly recommend using the template method instead. A template is provided at the end of this document. You can use the information from getting-started.json together with the template to generate an OPBNB-style configuration. + +The following is an example our config template. In the template, You need to replace the following variables with the ones from your environment.：$l2ChainId，$l1ChainId，$GS_SEQUENCER_ADDRESS，$GS_BATCHER_ADDRESS，$GS_PROPOSER_ADDRESS，$GS_ADMIN_ADDRESS， $GS_ADMIN_ADDRESS . It is recommended to set `l2OutputOracleSubmissionInterval` to **3600** (default is **240**) to provide a greater buffer for module startup delays. + + +```python +{ + "l1ChainID": $l1ChainId, + "l2ChainID": $l2ChainId， + "l2BlockTime": 1, + "maxSequencerDrift": 600, + "sequencerWindowSize": 57600, + "channelTimeout": 1200, + "p2pSequencerAddress": $GS_SEQUENCER_ADDRESS, + "batchInboxAddress": '0xff0000000000000000000000000000000000'+str($l2ChainId), + "batchSenderAddress": $GS_BATCHER_ADDRESS, + "cliqueSignerAddress": "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266", + "l1UseClique": false, + "l1StartingBlockTag": $l1BlockTag, + "l2OutputOracleSubmissionInterval": 3600, + "l2OutputOracleStartingBlockNumber": 0, + "l2OutputOracleStartingTimestamp" $l2OutputOracleStartingTimestamp, + "l2OutputOracleProposer": $GS_PROPOSER_ADDRESS, + "l2OutputOracleChallenger": $GS_ADMIN_ADDRESS, + "l2GenesisBlockGasLimit": "0x5f5e100", + "l1BlockTime": 3, + "baseFeeVaultMinimumWithdrawalAmount": "0x8ac7230489e80000", + "l1FeeVaultMinimumWithdrawalAmount": "0x8ac7230489e80000", + "sequencerFeeVaultMinimumWithdrawalAmount": "0x8ac7230489e80000", + "baseFeeVaultWithdrawalNetwork": 0, + "l1FeeVaultWithdrawalNetwork": 0, + "sequencerFeeVaultWithdrawalNetwork": 0, + "proxyAdminOwner": "$GS_ADMIN_ADDRESS", + "baseFeeVaultRecipient": "$GS_ADMIN_ADDRESS", + "l1FeeVaultRecipient": "$GS_ADMIN_ADDRESS", + "sequencerFeeVaultRecipient": "$GS_ADMIN_ADDRESS", + "finalSystemOwner": "$GS_ADMIN_ADDRESS", + "superchainConfigGuardian": "$GS_ADMIN_ADDRESS", + "finalizationPeriodSeconds": 3, + "fundDevAccounts": true, + "l2GenesisBlockBaseFeePerGas": "0x5F5E100", + "gasPriceOracleOverhead": 2100, + "gasPriceOracleScalar": 1000000, + "gasPriceOracleBaseFeeScalar": 1368, + "gasPriceOracleBlobBaseFeeScalar": 810949, + "enableGovernance": false, + "governanceTokenSymbol": "OPBNB", + "governanceTokenName": "OPBNB", + "governanceTokenOwner": "$GS_ADMIN_ADDRESS", + "eip1559Denominator": 8, + "eip1559DenominatorCanyon": 8, + "eip1559Elasticity": 2, + "l1GenesisBlockTimestamp": $l2GenesisBlockTimestamp, + "l2GenesisRegolithTimeOffset": "0x0", + "l2GenesisDeltaTimeOffset": "0x0", + "l2GenesisCanyonTimeOffset": "0x0", + "systemConfigStartBlock": 0, + "requiredProtocolVersion": "0x0000000000000000000000000000000000000000000000000000000000000000", + "recommendedProtocolVersion": "0x0000000000000000000000000000000000000000000000000000000000000000", + "faultGameAbsolutePrestate": "0x03c7ae758795765c6664a5d39bf63841c71ff191e9189522bad8ebff5d4eca98", + "faultGameMaxDepth": 50, + "faultGameClockExtension": 0, + "faultGameMaxClockDuration": 1200, + "faultGameGenesisBlock": 0, + "faultGameGenesisOutputRoot": "0xDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF", + "faultGameSplitDepth": 14, + "faultGameWithdrawalDelay": 604800, + "preimageOracleMinProposalSize": 10000, + "preimageOracleChallengePeriod": 120, + "proofMaturityDelaySeconds": 12, + "disputeGameFinalityDelaySeconds": 6, + "respectedGameType": 254, + "useFaultProofs": false, + "usePlasma": false, + "daCommitmentType": "KeccakCommitment", + "daChallengeWindow": 160, + "daResolveWindow": 160, + "daBondSize": 1000000, + "daResolverRefundPercentage": 0, + "fermat": 0, + "L2GenesisEcotoneTimeOffset": "0x0", + "l2GenesisFjordTimeOffset": "0x0", + "snowTimeOffset": "0x0", + "haberTimeOffset": "0x0", + "wrightTimeOffset": "0x0" +} +``` + +in addition to replacing the Chain Info , you must also specify the following three parameters: + +1. l1StartingBlockTag + +2) l2OutputOracleStartingTimestamp + +3. l2GenesisBlockTimestamp + +You can also fetch the three values via the following script (here shown against BSC Testnet), + +```bash +#!/bin/bash + +# RPC endpoint of bsc testnet +RPC_URL="https://data-seed-prebsc-2-s2.bnbchain.org:8545" + +# Function to convert hex string to decimal +hex_to_dec() { + printf "%d\n" "$(( $1 ))" +} + +# Loop until a valid milliTimestamp is found +while true; do + # Get latest block number + block_tag_hex=$(curl -s -X POST "$RPC_URL" -H "Content-Type: application/json" \ + -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":74}' | jq -r .result) + + # Get block info + block_info=$(curl -s -X POST "$RPC_URL" -H "Content-Type: application/json" \ + -d "{\"jsonrpc\":\"2.0\",\"method\":\"eth_getBlockByNumber\",\"params\":[\"$block_tag_hex\", false],\"id\":74}") + + timestamp_hex=$(echo "$block_info" | jq -r .result.timestamp) + milli_timestamp_hex=$(echo "$block_info" | jq -r .result.milliTimestamp) + + timestamp_dec=$(hex_to_dec "$timestamp_hex") + milli_timestamp_dec=$(hex_to_dec "$milli_timestamp_hex") + + # Check if milliTimestamp is divisible by 1000 ，If we need to set a 500ms block time ( op 500ms need to be enabled in bsc testnet and mainnet ), it's important to note that the selected `milliTimestamp` must be divisible by 1000. + if (( milli_timestamp_dec % 1000 == 0 )); then + break + fi + + sleep 1 +done + +# Print final result +echo "l1StartingBlockTag=$block_tag_hex" +echo "l2GenesisBlockTimestamp=$timestamp_hex" +echo "l2OutputOracleStartingTimestamp=$timestamp_dec" +``` + +Once you have retrieved the values of the three variables, insert them into the configuration template. After updating the configuration file, assign its path to the `DEPLOY_CONFIG_PATH` environment variable. + + +## Review and change the configuration file (Optional) + +If you'd like, you can review the configuration file that was just generated by opening up `deploy-config/getting-started.json` in your favorite text editor. +You can change configuration values to fit your specific needs. Please refer the [Chain Configuration](./Chain-Configuration.md). +It's recommended to keep this file as-is for now so you don't run into any unexpected errors. + + +# Deploy the Create2 Factory (Optional) +If you're deploying opBNB to a network other than BSC testnet, you may need to deploy a Create2 factory contract to the L1 chain. This factory contract is used to deploy opBNB smart contracts in a deterministic fashion. + +## Check if the factory exists + +The Create2 factory contract will be deployed at the address `0x4e59b44847b379578588920cA78FbF26c0B4956C`. You can check if this contract has already been deployed to your L1 network with a block explorer or by running the following command: +``` +cast codesize 0x4e59b44847b379578588920cA78FbF26c0B4956C --rpc-url $L1_RPC_URL +``` +If the command returns 0 then the contract has not been deployed yet. If the command returns 69 then the contract has been deployed and you can safely skip this section. + +## Fund the factory deployer + +You will need to send some BNB to the address that will be used to deploy the factory contract, `0x3fAB184622Dc19b6109349B94811493BF2a45362`. This address can only be used to deploy the factory contract and will not be used for anything else. Send at least 1 BNB to this address on your L1 chain. + +## Deploy the factory +Using `cast`, deploy the factory contract to your L1 chain: +``` +cast publish --rpc-url $L1_RPC_URL 0xf8a58085174876e800830186a08080b853604580600e600039806000f350fe7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe03601600081602082378035828234f58015156039578182fd5b8082525050506014600cf31ba02222222222222222222222222222222222222222222222222222222222222222a02222222222222222222222222222222222222222222222222222222222222222 +``` + +## Wait for the transaction to be mined +Make sure that the transaction is included in a block on your L1 chain before continuing. + + +## Verify that the factory was deployed +Run the code size check again to make sure that the factory was properly deployed: +``` +cast codesize 0x4e59b44847b379578588920cA78FbF26c0B4956C --rpc-url $L1_RPC_URL +``` + +# Deploy the L1 contracts +Once you've configured your network, it's time to deploy the L1 contracts necessary for the functionality of the chain. + +## Deploy the L1 contracts + +Add .env file in the current directory where you run the script or export follow content to .envrc file to make sure the following info can be loaded. The most important variable is DEPLOY_CONFIG_PATH, which should point to the configuration file you generated above. For example: + +~~~bash +cat .env +``` +DEPLOYMENT_OUTFILE="./deployments/L1/.deploy" // The contract address information entered after deployment. +DEPLOY_CONFIG_PATH="./deploy-config/devnet.json" // config file +~~~ + +``` +forge script scripts/Deploy.s.sol:Deploy --private-key $GS_ADMIN_PRIVATE_KEY --with-gas-price 1000000000 --broadcast --rpc-url $L1_RPC_URL --slow +``` +If you see a nondescript error that includes `EvmError: Revert` and `Script failed` then you likely need to change the `IMPL_SALT` environment variable. This variable determines the addresses of various smart contracts that are deployed via [CREATE2](https://eips.ethereum.org/EIPS/eip-1014). If the same `IMPL_SALT` is used to deploy the same contracts twice, the second deployment will fail. You can generate a new `IMPL_SALT` by running `direnv` allow anywhere in the opbnb. + +You can check the DEPLOYMENT_OUTFILE after deployed successfully. The contract address will be printed when the script running and the address can searched in https://testnet.bscscan.com/ . + +### L1 Contracts + +| **Contracts** | **Description** | **comments** | +| ---------------------- | ------------------------------------------------------------ | ------------ | +| SystemConfig | Responsible for saving the system configuration and providing the ability to change it online.These configurations will be used by L2 block derivation process including overhead, scalar, batcherHash, gasLimit, resourceConfig,etc. | | +| L1StandardBridge | Responsible for the transfer of ERC20 tokens between L1 and L2. | | +| L1ERC721Bridge | Responsible for the transfer of ERC721 tokens between L1 and L2. | | +| L1CrossDomainMessenger | Responsible for delivering messages and being more user friendly. | | +| OptimismPortal | Responsible for passing messages between L1 and L2, which is equivalent to the portal of the optimistic network. Validate output root to execute L2 to L1 message call. | | +| L2OutputOracle | Responsible for storing the output root of each block of the L2 network. Other contracts or users can verify the validity of L2 data according to the output root. | | + +![image-20250411151438331](./image-20250411151438331.png) + +## Generate L2 Genesis Allocs + +A foundry script is used to generate the L2 genesis allocs. This is a JSON file that represents the L2 genesis state. The `CONTRACT_ADDRESSES_PATH` env var represents the deployment artifact that was generated during a contract deployment. The value should be same with DEPLOYMENT_OUTFILE. The `STATE_DUMP_PATH` env var represents the filepath at which the allocs will be written to on disk. You can set the value in .env or envrc. + +``` +DEPLOY_CONFIG_PATH="./deploy-config/devnetL1-v2.json" +CONTRACT_ADDRESSES_PATH="./deployments/L1/.deploy" // same with DEPLOYMENT_OUTFILE +STATE_DUMP_PATH="./deploy-config/state.json" +``` + +```bsch +CONTRACT_ADDRESSES_PATH= \ +DEPLOY_CONFIG_PATH= \ +STATE_DUMP_PATH= \ + forge script scripts/L2Genesis.s.sol:L2Genesis \ + --sig 'runWithStateDump()' +``` + +The L2 genesis allocs file will generated in the path of DEPLOY_CONFIG_PATH after the script beed deployed successfully. + +## Generate the L2 config files + +Now that you've set up the L1 smart contracts you can automatically generate several configuration files that are used within the Consensus Client and the Execution Client. + +You need to generate three important files: + +1. `genesis.json` includes the genesis state of the chain for the Execution Client (sequencer). +2. `rollup.json` includes configuration information for the Consensus Client (bridage node, rpcnode ,p2p node). +3. `jwt.txt` is a [JSON Web Token](https://jwt.io/introduction) that allows the Consensus Client and the Execution Client to communicate securely (the same mechanism is used in Ethereum clients). + +## Navigate to the op-node package +``` +cd ~/opbnb/op-node +``` + +## Create genesis files +Now you'll generate the `genesis.json` and `rollup.json` files within the op-node folder: + +--deploy-config and --l1-deployments flag info needs to be replaced by th DEPLOY_CONFIG_PATH and DEPLOYMENT_OUTFILE of .env or .envrc + +``` +go run cmd/main.go genesis l2 \ + --deploy-config $DEPLOY_CONFIG_PATH \ + --l1-deployments $DEPLOYMENT_OUTFILE \ + --outfile.l2 genesis.json \ + --outfile.rollup rollup.json \ + --l1-rpc $L1_RPC_URL \ + --l2-allocs $STATE_DUMP_PATH +``` + +Note that since op-geth does not support bsc 7702 yet, if the deployed l1 genesis height is after the bsc 7702 feature, the l1 hash in rollup.json is wrong and you need to manually execute rpc to get the correct value to replace it. + +Following is a example of rollup.json. + +```bash +{ + "genesis": { + "l1": { + "hash": "0x79060df30c6c3377962184f28f88340616b8bc737e6af79bc17da55ac78e41bd", + "number": 49953684 + }, + "l2": { + "hash": "0xb9d33b0e69bb67c857d59568f38011f4104e2747b6fcf8aff84fb4e419f73f4d", + "number": 0 + }, + "l2_time": 1744341397, + "system_config": { + "batcherAddr": "0xb6e487a3cecde5e0e1793c98c2de1999a1319a2b", + "overhead": "0x0000000000000000000000000000000000000000000000000000000000000834", + "scalar": "0x00000000000000000000000000000000000000000000000000000000000f4240", + "gasLimit": 100000000 + } + }, + "block_time": 1, + "max_sequencer_drift": 600, + "seq_window_size": 57600, + "channel_timeout": 1200, + "l1_chain_id": 97, + "l2_chain_id": 4255, + "regolith_time": 0, + "canyon_time": 0, + "delta_time": 0, + "ecotone_time": 0, + "fjord_time": 0, + "volta_time": 0, (advised) + "fermat": 0, + "snow_time": 0, + "batch_inbox_address": "0xff00000000000000000000000000000000000901", + "deposit_contract_address": "0xf098dadd3f3cfabd9e773c7639dbef5e57308683", + "l1_system_config_address": "0x644b2da606901ba67ff797168194708c0c3f7221", + "protocol_versions_address": "0x0000000000000000000000000000000000000000", + "da_challenge_contract_address": "0x0000000000000000000000000000000000000000" +} + + +``` + +You need to manually add `"volta_time": 0` to the configuration file to ensure the block time is set to 500ms. The latest op code supports the `volta_time` configuration to 0 support Volta fork which makes the block time as 500ms. Since the BSC L1 block time will be reduced to under 1 second, the 500ms configuration is required. + +## Create an authentication key + +Next you'll create a [JSON Web Token](https://jwt.io/introduction) that will be used to authenticate the Consensus Client and the Execution Client. This token is used to ensure that only the Consensus Client and the Execution Client can communicate with each other. You can generate a JWT with the following command: +``` +openssl rand -hex 32 > jwt.txt +``` + +## Copy genesis files into the op-geth directory +Finally, you'll need to copy the `genesis.json` file and `jwt.txt` file into `op-geth` so you can use it to initialize and run `op-geth`: +``` +cp genesis.json ~/op-geth +cp jwt.txt ~/op-geth +``` + +# Initialize `op-geth` +You're almost ready to run your chain! Now you just need to run a few commands to initialize `op-geth`. You're going to be running a Sequencer node, so you'll need to import the `Sequencer` private key that you generated earlier. This private key is what your Sequencer will use to sign new blocks. + +## Navigate to the op-geth directory +``` +cd ~/op-geth +``` + +## Create a data directory folder +``` +mkdir datadir +``` + +## Initialize op-geth +``` +build/bin/geth init --datadir=datadir --state.scheme path --db.engine pebble genesis.json +``` + +you can also init with hash scheme by "--state.schme hash" , we recommend pathdb for better performance + +# Start `Sequencer` + +Now you'll start `op-geth`, your Execution Client. Note that you won't start seeing any transactions until you start the Consensus Client in the next step. + +## Open up a new terminal +You'll need a terminal window to run `op-geth` in or you can run it in nohup m. + +## Navigate to the op-geth directory +``` +cd ~/op-geth +``` + +## Run op-geth +You're using `--gcmode=archive` to run `op-geth` here because this node will act as your Sequencer. It's useful to run the Sequencer in archive mode because the `op-proposer` requires access to the full state. Feel free to run other (non-Sequencer) nodes in full mode if you'd like to save disk space. +It's important that you've already initialized the geth node at this point as per the previous section. Failure to do this will cause startup issues between `op-geth` and `op-node`. The parameters related to metrics, logging levels, and txpool performance in the following startup configuration are optional. You may adjust them based on the specific requirements of your blockchain. + +```000 + ./build/bin/op-geth \ + --datadir ./datadir \ + --http \ + --http.corsdomain="*" \ + --http.vhosts="*" \ + --http.addr=0.0.0.0 \ + --http.api=web3,debug,eth,txpool,net,engine \ + --ws \ + --ws.addr=0.0.0.0 \ + --ws.port=8546 \ + --ws.origins="*" \ + --ws.api=debug,eth,txpool,net,engine \ + --syncmode=full \ + --gcmode=archive \ + --mine \ + --miner.newpayload-timeout=650ms \ + --miner.gaslimit=150000000 \ + --miner.gasprice=1 \ + --miner.etherbase=$GS_SEQUENCER_ADDRESS \ + --nodiscover \ + --maxpeers=10 \ + --networkid=$L2_CHAIN_ID \ + --authrpc.vhosts='*' \ + --authrpc.addr=0.0.0.0 \ + --authrpc.port=8551 \ + --txpool.globalslots=20000 \ + --txpool.globalqueue=10000 \ + --txpool.accountqueue=500 \ + --txpool.accountslots=500 \ + --txpool.pricelimit=1 \ + --txpool.nolocals=true \ + --txpool.reannouncetime=3m \ + --txpool.reannounceremotes=true \ + --cache=20000 \ + --cache.preimages \ + --authrpc.jwtsecret=./jwt.txt \ + --rollup.disabletxpoolgossip=false \ + --journalfile \ + --pathdb.nodebuffer=list \ + --pathdb.proposeblock=3600 \ + --pathdb.enableproofkeeper \ + --metrics \ + --metrics.port=6060 \ + --metrics.addr=0.0.0.0 \ + --verbosity=3 + + // replace with $L2_CHAIN_ID with your real chainid +``` + +Please note that if you set `--pathdb.proposeblock=3600`, the proposer processor must start within 3600 seconds after op-geth of sequencer is launched. The value of pathdb.proposeblock need to be same with l2OutputOracleSubmissionInterval of DEPLOY_CONFIG_PATH . If you are using hash db instead of pathdb , you can ignore the config begin with --pathdb. + +Once you've got `op-geth` running you'll need to run `op-node`. Like Ethereum, the opBNB has a Consensus Client (`op-node`) and an Execution Client (`op-geth`). The Consensus Client "drives" the Execution Client over the Engine API. Each of the Sequencer, Bridge, P2P, and RPC nodes runs both an op-node and an op-geth process—the only distinction is the set of startup parameters supplied to the op-node. + +## Navigate to the op-node directory + +``` +cd ~/opbnb/op-node +``` + +## Run op-node in miner mode + +``` +./bin/op-node \ + --l1.trustrpc \ + --l2=http://localhost:8551 \ + --l2.jwt-secret=./jwt.txt \ + --sequencer.enabled=true \ + --sequencer.l1-confs=15 \ + --sequencer.combined-engine \ + --verifier.l1-confs=15 \ + --l1.http-poll-interval=3s \ + --l1.epoch-poll-interval=3s \ + --l1.rpc-max-batch-size=20 \ + --rollup.config=./rollup.json \ + --rpc.addr=0.0.0.0 \ + --rpc.port=8547 \ + --rpc.enable-admin \ + --sequencer.priority \ + --l1.max-concurrency=20 \ + --p2p.sequencer.key=$GS_SEQUENCER_PRIVATE_KEY \ + --l1=$L1_RPC_URL \ + --l1.rpckind=$L1_RPC_KIND(optional) \ + --metrics.enabled \ + --metrics.port=7070 \ + --metrics.addr=0.0.0.0 +``` + +Once you run this command, you should start seeing the `op-node` begin to sync L2 blocks from the L1 chain. Once the `op-node` has caught up to the tip of the L1 chain, it'll begin to send blocks to `op-geth` for execution. At that point, you'll start to see blocks being created inside of `op-geth`. + +# Start `Bridge node` + +It is recommended to run the bridge node and the sequencer node on different machines or Kubernetes pods. Therefore, you need to copy the sequencer's `genesis.json` and `rollup.json` files to the corresponding runtime environment. + +## Run op-geth as bridge node + +You need to init op-geth datadir first the same way as the op-geth of sequencer and than start op-geth with full node mode. You can adjust the flags by your environment. + +``` + ./op-geth \ + --datadir ./datadir \ + --http \ + --http.corsdomain="*" \ + --http.vhosts="*" \ + --http.addr=0.0.0.0 \ + --http.api=web3,debug,eth,txpool,net,engine \ + --ws \ + --ws.addr=0.0.0.0 \ + --ws.port=8546 \ + --ws.origins="*" \ + --ws.api=debug,eth,txpool,net,engine \ + --syncmode=full \ + --gcmode=full \ + --nodiscover \ + --maxpeers=10 \ + --networkid=$L2_CHAIN_ID \ + --authrpc.vhosts="*" \ + --authrpc.addr=0.0.0.0 \ + --authrpc.port=8551 \ + --txpool.globalslots=10000 \ + --txpool.globalqueue=5000 \ + --txpool.accountqueue=500 \ + --txpool.accountslots=500 \ + --txpool.reannouncetime=3m \ + --txpool.reannounceremotes=true \ + --txpool.pricelimit=1 \ + --txpool.nolocals=true \ + --cache=10000 \ + --cache.preimages \ + --authrpc.jwtsecret=./jwt.txt \ + --rollup.disabletxpoolgossip=false \ + --history.transactions=0 \ + --journalfile \ + --metrics \ + --metrics.port=6060 \ + --metrics.addr=0.0.0.0 \ + --verbosity 4 + +``` + +## Run op-node + +To run a Bridge node , you can refer to this command, you need to adjust the flags by your environment.. + +```bash +./bin/op-node \ + --l1.trustrpc \ + --l2=http://localhost:8551 \ + --l2.jwt-secret=./jwt.txt \ + --verifier.l1-confs=15 \ + --l1.http-poll-interval=3s \ + --l1.epoch-poll-interval=3s \ + --l1.rpc-max-batch-size=20 \ + --rollup.config=./rollup.json \ + --rpc.addr=0.0.0.0 \ + --rpc.port=8547 \ + --rpc.enable-admin \ + --l1.max-concurrency=20 \ + --l1=$L1_RPC_URL \ + --metrics.enabled \ + --metrics.port=7070 \ + --metrics.addr=0.0.0.0 \ + --log.level=debug + +``` + +## Config p2p peer for op-node and op-geth + +By default, your `op-node` will try to use a peer-to-peer to speed up the synchronization process. Once you have multiple nodes, you may want to enable peer-to-peer synchronization. You can add the following options to the `op-node` command to enable peer-to-peer synchronization with specific nodes: + +``` +--p2p.no-discovery \ +--p2p.static= \ +--p2p.listen.ip=0.0.0.0 \ +--p2p.listen.tcp=9003 \ +--p2p.listen.udp=9003 \ +``` + +You can alternatively also remove the `--p2p.static` option. Through configuring `p2p static`, you can ensure: + +1. Transactions sent to bridge nodes or RPC nodes can be relayed to the sequencer via P2P, without needing to send them directly to the sequencer ( need also ensure that rollup.disabletxpoolgossip=false). This reduces traffic pressure on the sequencer. +2. The sync progress between the bridge node and the sequencer node will not lag + +below is an example of starting a node with `p2p` parameters： + +``` +./op-node --l1.trustrpc --l2=http://localhost:8551 --l2.jwt-secret=./jwt.txt --sequencer.enabled=true --sequencer.l1-confs=15 --verifier.l1-confs=15 --l1.http-poll-interval=3s --l1.epoch-poll-interval=3s --l1.rpc-max-batch-size=20 --rollup.config=./rollup.json --rpc.addr=0.0.0.0 --rpc.port=8547 --rpc.enable-admin --sequencer.priority --l1.max-concurrency=20 --p2p.sequencer.key=0x... --l1=https:/.. --metrics.enabled --metrics.port=7070 --metrics.addr=0.0.0.0 --log.level=debug --p2p.no-discovery --p2p.listen.ip=0.0.0.0 --p2p.listen.tcp=9003 --p2p.listen.udp=9003 --p2p.static=/ip4/10.180.41.12/tcp/9003/p2p/16Uiu2HAm1LN4CHrSj27HT64qeg4dQ7ZdS9WmPk6uTV7jVcpFU4e3,/ip4/10.180.41.97/tcp/9003/p2p/16Uiu2HAkw3os1Ynusda8TpEVNGHuzGj85gEiwwnHyEeY2Y6Df1HH +``` + +Before starting the node, we don’t yet know the `p2p static` addresses. You can first start all the nodes, then run the following `opp2p_self` command on each machine where the nodes are deployed to get each op-node’s corresponding P2P address: + +``` +curl localhost:8547 -X POST --data '{"jsonrpc":"2.0","method":"opp2p_self","params":[],"id":74}' -H 'Content-Type: application/json' + +{"jsonrpc":"2.0","id":74,"result":{"peerID":"..,"addresses":["/ip4/10.180.41.12/tcp/9003/p2p/16Uiu2HAm1LN4CHrSj27HT64qeg4dQ7ZdS9WmPk6uTV7jVcpFU4e3","/ip4/127.0.0.1/tcp/9003/p2p/16Uiu2HAm1LN4CHrSj27HT64qeg4dQ7ZdS9WmPk6uTV7jVcpFU4e3"],":0,"rejectedPayloads":0}}}} +``` + +Extract the first address under `addresses` in the JSON string, which is the corresponding P2P address of the node. Once we obtain the P2P addresses of all nodes deployed in the OP Stack, we can concatenate them together and use the result as the value of the `--p2p.static` parameter. After that, restart all `op-node` processes one by one with `--p2p.static`. + +`op-geth` also needs to be configured with `p2p` settings to ensure the whole system functions correctly. Below is an example `config.toml`. You need to restart `op-geth` with the `--config=config.toml` parameter to load the `Node.p2p` settings. + +``` +# cat config.toml +[Node.P2P] + StaticNodes = [ + "enode://23394b676e64450ed7c6f845c57adec339d62ac34d0116e73a847e8c694c1888e40f83dcadbc2f6a45e4f542564c560b00773a6f3aa2ae5d28e0504bc2e68ca0@127.0.0.1:30303", + "enode://1c69ec667509e84107c3758ff58a4618dd40b7912d019051265f10938b92228cad54906185ab1e4ffc00f3a025dd55580ff7e115c7b78aca264c4e99b940d331@127.0.0.1:30303", + ] +``` + +You can obtain the node’s `enode` ID by running the following command in the `op-geth` working directory. Then gather all nodes’ `enode` IDs and write them into `config.toml`: + +``` + ./op-geth attach -exec "admin.nodeInfo" /geth.ipc +{ + enode: "enode://23394b676e64450ed7c6f845c57adec339d62ac34d0116e73a847e8c694c1888e40f83dcadbc2f6a45e4f542564c560b00773a6f3aa2ae5d28e0504bc2e68ca0@127.0.0.1:30303?discport=0" //remove ?discport0 + +// we got the encode ID as "enode://23394b676e64450ed7c6f845c57adec339d62ac34d0116e73a847e8c694c1888e40f83dcadbc2f6a45e4f542564c560b00773a6f3aa2ae5d28e0504bc2e68ca0@127.0.0.1:30303" // You need to replace 127.0.0.1 with your real IP or domain name +``` + + After completing the configuration and restarting the op-geth and op-node of both sequencer and bridge node, you can execute the following command in the same directory as the `op-geth` data directory to retrieve peer information. + +``` + ./op-geth attach -exec "admin.peers" /geth.ipc +``` + + + +# Start `op-batcher` + +The `op-batcher` takes transactions from the Sequencer and publishes those transactions to L1. Once these Sequencer transactions are included in a finalized L1 block, they're officially part of the canonical chain. The `op-batcher` is critical! + +It's best to give the `Batcher` address at least 2 BNB to ensure that it can continue operating without running out of BNB for gas. Keep an eye on the balance of the `Batcher` address because it can expend BNB quickly if there are a lot of transactions to publish. + +## Open up a new terminal +You'll need a terminal window to run `op-batcher` in. + +## Navigate to the op-batcher directory +``` +cd ~/opbnb/op-batcher +``` + +## Run op-batcher + +``` +./bin/op-batcher \ + --l2-eth-rpc=http://localhost:8545 \ + --rollup-rpc=http://localhost:8547 \ + --poll-interval=5s \ + --sub-safety-margin=30 \ + --num-confirmations=4 \ + --safe-abort-nonce-too-low-count=3 \ + --resubmission-timeout=30s \ + --rpc.addr=0.0.0.0 \ + --rpc.port=8548 \ + --batch-type=1 \ + --data-availability-type=auto \ + --target-num-frames=2 \ + --rpc.enable-admin \ + --max-channel-duration=20 \ + --l1-eth-rpc=$L1_RPC_URL \ + --private-key=$GS_BATCHER_PRIVATE_KEY +``` +The `--max-channel-duration=n` setting tells the `batcher` to write all the data to L1 every n L1 blocks. When it is low, transactions are written to L1 frequently and other nodes can synchronize from L1 quickly. When it is high, transactions are written to L1 less frequently and the `batcher` spends less BNB. If you want to reduce costs, either set this value to 0 to disable it or increase it to a higher value. + +# Start `op-proposer` + +## Open up a new terminal +You'll need a terminal window to run `op-proposer` in. + +## Navigate to the op-proposer directory +``` +cd ~/opbnb/op-proposer +``` + +## Run op-proposer + +Please note that if you set `--pathdb.proposeblock=3600`, the proposer must start within 3600 seconds after op-geth is launched. + +``` +./bin/op-proposer \ + --poll-interval=1s \ + --rpc.port=8560 \ + --rollup-rpc=http://localhost:8547 \ + --l2oo-address=$(cat ../packages/contracts-bedrock/deployments/getting-started/.deploy | jq -r .L2OutputOracleProxy) \ + --private-key=$GS_PROPOSER_PRIVATE_KEY \ + --l1-eth-rpc=$L1_RPC_URL +``` + + + +# Check the status of blockchain + +You can use the following method to check the block height of a node. In OP Stack, there are different types of block heights: **safe**, **unsafe**, and **finalized**. + +> **The Safe Head** represents the most recent L2 block that has been confirmed on L1, while +> **The Unsafe Head** represents the highest unconfirmed L2 block that the rollup node is aware of. +> The `derivation` process gradually turns `unsafe` blocks into `safe` ones, and then promotes `safe` blocks to the `finalized` state. + +If all three heights are continuously increasing, and the lag between `safe` and `unsafe` is minimal, it indicates that your system is producing blocks normally. + +Run the following command on a **sequencer** or **bridge node**: + +``` + wget http://localhost:7070/debug/metrics + + cat metrics | grep op_node_default_refs_number + # TYPE op_node_default_refs_number gauge +op_node_default_refs_number{layer="l1",type="l1_derived"} 5.0707611e+07 +op_node_default_refs_number{layer="l1",type="l1_finalized"} 5.0707625e+07 +op_node_default_refs_number{layer="l1",type="l1_head"} 5.0707627e+07 +op_node_default_refs_number{layer="l1",type="l1_safe"} 5.0707626e+07 +op_node_default_refs_number{layer="l1_origin",type="l2_backup_unsafe"} 0 +op_node_default_refs_number{layer="l1_origin",type="l2_finalized"} 5.0707576e+07 +op_node_default_refs_number{layer="l1_origin",type="l2_pending_safe"} 5.0707583e+07 +op_node_default_refs_number{layer="l1_origin",type="l2_safe"} 5.0707583e+07 +op_node_default_refs_number{layer="l1_origin",type="l2_unsafe"} 5.070761e+07 +op_node_default_refs_number{layer="l2",type="l2_backup_unsafe"} 0 +op_node_default_refs_number{layer="l2",type="l2_finalized"} 170436 // finalized block height +op_node_default_refs_number{layer="l2",type="l2_pending_safe"} 170460 +op_node_default_refs_number{layer="l2",type="l2_safe"} 170460 // safe block height +op_node_default_refs_number{layer="l2",type="l2_unsafe"} 170543 // unsafe block height +``` + + + +# Connect Your Wallet to Your Chain + +You now have a fully functioning l2 rollup chain with a Sequencer node running on http://localhost:8545. You can connect your wallet to this chain the same way you'd connect your wallet to any other EVM chain. + +# Get BNB On Your Chain + +Once you've connected your wallet, you'll probably notice that you don't have any BNB to pay for gas on your chain. The easiest way to deposit BNB into your chain is to send BNB directly to the `L1StandardBridge` contract. + +## Navigate to the contracts-bedrock directory +``` +cd ~/opbnb/packages/contracts-bedrock +``` + +## Get the address of the L1StandardBridgeProxy contract +``` +cat deployments/getting-started/.deploy | jq -r .L1StandardBridgeProxy +``` + +## Send some BNB to the L1StandardBridgeProxy contract +Grab the L1 bridge proxy contract address and, using the wallet that you want to have BNB on your l2 rollup chain, send that address a small amount of BNB on L1. This will trigger a deposit that will mint BNB into your wallet on L2. It may take up to some minutes for that BNB to appear in your wallet on L2. + +# See Your opBNB in Action +You can interact with your l2 the same way you'd interact with any other EVM chain. Send some transactions, deploy some contracts, and see what happens! + + + +# Deploy config example + +```bash + +{ + "l1ChainID": 97, + "l2ChainID": 4274, + "l2BlockTime": 1, + "maxSequencerDrift": 600, + "sequencerWindowSize": 57600, + "channelTimeout": 1200, + "p2pSequencerAddress": "0x3224F068Fd97D2d4a91800D450EE19bfBCD6B6Ee", + "batchInboxAddress": "0xff00000000000000000000000000000000004274", + "batchSenderAddress": "0xB6e487a3cEcDe5e0E1793C98c2de1999a1319A2b", + "cliqueSignerAddress": "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266", + "l1UseClique": false, + "l1StartingBlockTag": "0x304dee2", + "l2OutputOracleSubmissionInterval": 3600, + "l2OutputOracleStartingBlockNumber": 0, + "l2OutputOracleStartingTimestamp": 1745389366, + "l2OutputOracleProposer": "0x254811af494550Ee5e0945C23EC5E4E17c9dF1bC", + "l2OutputOracleChallenger": "0x5E8fe030B465b448a78bA5Ef3c674Da25fDf67f5", + "l2GenesisBlockGasLimit": "0x5f5e100", + "l1BlockTime": 3, + "baseFeeVaultMinimumWithdrawalAmount": "0x8ac7230489e80000", + "l1FeeVaultMinimumWithdrawalAmount": "0x8ac7230489e80000", + "sequencerFeeVaultMinimumWithdrawalAmount": "0x8ac7230489e80000", + "baseFeeVaultWithdrawalNetwork": 0, + "l1FeeVaultWithdrawalNetwork": 0, + "sequencerFeeVaultWithdrawalNetwork": 0, + "proxyAdminOwner": "0x5E8fe030B465b448a78bA5Ef3c674Da25fDf67f5", + "baseFeeVaultRecipient": "0x5E8fe030B465b448a78bA5Ef3c674Da25fDf67f5", + "l1FeeVaultRecipient": "0x5E8fe030B465b448a78bA5Ef3c674Da25fDf67f5", + "sequencerFeeVaultRecipient": "0x5E8fe030B465b448a78bA5Ef3c674Da25fDf67f5", + "finalSystemOwner": "0x5E8fe030B465b448a78bA5Ef3c674Da25fDf67f5", + "superchainConfigGuardian": "0x5E8fe030B465b448a78bA5Ef3c674Da25fDf67f5", + "finalizationPeriodSeconds": 3, + "fundDevAccounts": true, + "l2GenesisBlockBaseFeePerGas": "0x5F5E100", + "gasPriceOracleOverhead": 2100, + "gasPriceOracleScalar": 1000000, + "gasPriceOracleBaseFeeScalar": 1368, + "gasPriceOracleBlobBaseFeeScalar": 810949, + "enableGovernance": false, + "governanceTokenSymbol": "OPBNB", + "governanceTokenName": "OPBNB", + "governanceTokenOwner": "0x5E8fe030B465b448a78bA5Ef3c674Da25fDf67f5", + "eip1559Denominator": 8, + "eip1559DenominatorCanyon": 8, + "eip1559Elasticity": 2, + "l1GenesisBlockTimestamp": "0x68088736", + "l2GenesisRegolithTimeOffset": "0x0", + "l2GenesisDeltaTimeOffset": "0x0", + "l2GenesisCanyonTimeOffset": "0x0", + "systemConfigStartBlock": 0, + "requiredProtocolVersion": "0x0000000000000000000000000000000000000000000000000000000000000000", + "recommendedProtocolVersion": "0x0000000000000000000000000000000000000000000000000000000000000000", + "faultGameAbsolutePrestate": "0x03c7ae758795765c6664a5d39bf63841c71ff191e9189522bad8ebff5d4eca98", + "faultGameMaxDepth": 50, + "faultGameClockExtension": 0, + "faultGameMaxClockDuration": 1200, + "faultGameGenesisBlock": 0, + "faultGameGenesisOutputRoot": "0xDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF", + "faultGameSplitDepth": 14, + "faultGameWithdrawalDelay": 604800, + "preimageOracleMinProposalSize": 10000, + "preimageOracleChallengePeriod": 120, + "proofMaturityDelaySeconds": 12, + "disputeGameFinalityDelaySeconds": 6, + "respectedGameType": 254, + "useFaultProofs": false, + "usePlasma": false, + "daCommitmentType": "KeccakCommitment", + "daChallengeWindow": 160, + "daResolveWindow": 160, + "daBondSize": 1000000, + "daResolverRefundPercentage": 0, + "fermat": 0, + "L2GenesisEcotoneTimeOffset": "0x0", + "l2GenesisFjordTimeOffset": "0x0", + "snowTimeOffset": "0x0", + "haberTimeOffset": "0x0", + "wrightTimeOffset": "0x0" +} + +``` + + + +# Configuration explain + +## Chain Configuration + +| **Item** | **Type** | **Description** | **中文补充描述** | **Default Value** | +| ----------------------- | ----------- | ------------------------------------- | -------------------------- | ----------------- | +| Chain ID | number | Chain id | 链id | | +| Gas limit | number | The maximum gas usage of the block | 区块最大gas使用量 | 100M | +| Public RPC | url | Rpc domain name | 公开的Rpc 域名 | | +| Internal RPC | URL | URL | 内部使用的RPC域名 | | +| l2BlockTime | number | L2 block time | l2 区块时间 | 0.5 second | +| Withdraw time | Time period | Withdraw challenge period | Withdraw的挑战期 | 7 days | +| Batcher Commit interval | Time period | Batcher interval for submitting data | Batcher 提交数据的最大间隔 | 1 mins | +| ProposerCommit interval | Time period | Proposer interval for submitting data | Proposer 提交数据的间隔 | 1 hour | + +## Gas fee Configuration + +| **Item** | **Type** | **Description** | **中文补充描述** | **Default Value** | +| ----------- | -------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ----------------- | +| l1FeeScalar | number | Gas fee to be Submitted to layer 1, can be configured by Layer 2 operators, which will decide whether layer 2 is profitable | 提交给 Layer 1 的 Gas 费用，可由 Layer 2 运营商配置，这将决定 Layer 2 是否盈利 | 1000000 | + +## Governance Configuration + +| **Item** | **Type** | **Description** | **中文补充描述** | **Default Value** | +| ------------------------ | ---------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | -------------------- | +| Support Governance Token | bool | Whether need to support Governance Token | 是否需要支持Governance Token | false | +| Governance Token Symbol | String | Symbol for the token deployed by default to each OP Stack chain. | 默认部署到每个 OP BNB 链的代币符号。 | | +| Governance Token Name | Governance Token Owner | L2 Address | Address that will own the token contract deployed by default to every OP Stack based chain.Multisig address supported | 管理Governance Token | + +## Custom Gas Token Configuration + +| **Item** | **Type** | **Description** | **中文补充描述** | **Default Value** | +| ---------------- | ---------- | ------------------------------------------------------------ | ------------------------------------------- | ----------------- | +| Token Name | String | Token name | Token 名称 | | +| Symbol | String | The symbol for the token is deployed by default. | Token 符号 | | +| Decimal | Number | decimal | 小数位 | 18 | +| Total Supply | Number | Total supply | 总供应量 | 100,000,000 | +| Token Owner | L2 Address | L2 Address that holds all the minted token Multisig address supported | 用于持有发行出来的token可以准备一个多签地址 | | +| Token icon image | | | | | + +## Address Configuration + +1） System Admin L1 Address multisig wallet address is needed + +2) Proposer Challenger L1 Address Reuse System Admin L1 Address + +| Item | Type | Description | 中文补充描述 | Value | +| --------------------- | ---------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------ | +| System Admin | L1 Address | Address that will own all ownable contracts on L1 once the deployment is finished, including the ProxyAdmin contract. aka finalSystemOwner. | 管理l1的合约 | 使用多签地址 | +| L2 Proxy Admin | L2 Address | Address that will own the ProxyAdmin contract on L2. The L2 ProxyAdmin contract owns all of the Proxy contracts for every predeployed contract in the range 0x42...0000 to 0x42..2048. This makes predeployed contracts easily upgradeable. aka proxyAdminOwner. | 管理l2的合约可以使用多签地址 | 使用多签地址 | +| Base Fee Recipient | L1 Address | L1 address that the base fees from all transactions on the L2 can be withdrawn to. aka baseFeeVaultRecipient. | Base fee的收款账户 | | +| Tip Fee Recipient | L1 Address | L1 address that the tip fees from all transactions on the L2 can be withdrawn to. aka sequencerFeeVaultRecipient. | 矿工费收款账户 | | +| L1 Data Fee Recipient | L1 Address | L1 address that the L1 data fees from all transactions on the L2 can be withdrawn to. aka l1FeeVaultRecipient. | 数据由l2提交到l1的收费，这笔收费接受的账户 | | +| Proposer Challenger | L1 Address | Address that is allowed to challenge output proposals submitted to the L2OutputOracle. aka l2OutputOracleChallenger. | 可以删除withdraw index可以使用多签，例如NR占有2/5席位，可以直接操作 | | +| portalGuardian | L1 Address | Address that has the ability to pause and unpause withdrawals | 可以停止withdraw *(和**Challenger共用一个地址**)* | | + +# diff --git a/docs/bnb-opbnb/core-concepts/raas.md b/docs/bnb-opbnb/core-concepts/raas.md index 30240e3844..b4b96f4024 100644 --- a/docs/bnb-opbnb/core-concepts/raas.md +++ b/docs/bnb-opbnb/core-concepts/raas.md @@ -14,11 +14,10 @@ The demand for RaaS within the BNB Chain ecosystem is not just a trend; it's a s # Building with RaaS Aligned with BNB Chain’s Future -Building with Rollup as a Service (RaaS) on the BNB Chain involves leveraging specialized services from providers like [NodeReal](https://nodereal.io/semita), [AltLayer](https://altlayer.io/), [Movement Labs](https://movementlabs.xyz/), [Lumoz](https://lumoz.org/rollups), and [4everland](https://docs.4everland.org/raas-beta/whats-rollups), each offering unique tools to enhance blockchain application development. By adopting these specialized RaaS solutions, developers can leverage the strengths of the BNB Chain ecosystem to create innovative, reliable, and user-centric blockchain applications. +Building with Rollup as a Service (RaaS) on the BNB Chain involves leveraging specialized services from providers like [AltLayer](https://altlayer.io/), [Movement Labs](https://movementlabs.xyz/), [Lumoz](https://lumoz.org/rollups), and [4everland](https://docs.4everland.org/raas-beta/whats-rollups), each offering unique tools to enhance blockchain application development. By adopting these specialized RaaS solutions, developers can leverage the strengths of the BNB Chain ecosystem to create innovative, reliable, and user-centric blockchain applications. | Service Provider | Developer tools and tech stack | How to Start | | ---------------- | ------------------------------------------------------------ | -------------------------------------------------- | -| NodeReal | E2E professional service with infrastructure support, including, indexing service, multi-sig wallet service, explorer, and other enterprise services. | https://nodereal.io/semita | | Altlayer | Versatile rollup-up stack support and no-code setup dashboard | https://altlayer.io/ | | Movement Labs | Move based L2 on BSC support | https://movementlabs.xyz/ | | Lumoz | Support zkevm on BSC | https://lumoz.org/rollups | diff --git a/docs/bnb-opbnb/developers/cheat-sheet.md b/docs/bnb-opbnb/developers/cheat-sheet.md index 47c57e2586..2c12ef4e03 100644 --- a/docs/bnb-opbnb/developers/cheat-sheet.md +++ b/docs/bnb-opbnb/developers/cheat-sheet.md @@ -62,7 +62,7 @@ Configure multiple L1 RPC endpoints for op-node setups on L2 solutions like opBN For example: ```bash export L1_RPC1=https://bsc-dataseed.bnbchain.org - export L1_RPC2=https://bsc.nodereal.io + export L1_RPC2=https://bsc-dataseed2.bnbchain.org --l1=rpc1,rpc2… ``` Optimize L1 receipt retrieval performance diff --git a/docs/bnb-opbnb/faq/build-on-opbnb-faqs.md b/docs/bnb-opbnb/faq/build-on-opbnb-faqs.md index cee9b1b980..b7bf3e8a08 100644 --- a/docs/bnb-opbnb/faq/build-on-opbnb-faqs.md +++ b/docs/bnb-opbnb/faq/build-on-opbnb-faqs.md @@ -14,10 +14,6 @@ With the [API key](https://nodereal.io/meganode) and smart contract address, you If the deployed contract is a proxy contract, then the info. will not be displayed as opBNBscan uses enhanced API to fetch the token details like name, symbol etc. In this case, enhanced API needs to call the implementation contract to fetch the token details. Currently, this feature is under development where enhanced API will make call to implementation contract when token info. returned from proxy contract is empty. -### What are the third-party provider services where we can purchase private RPC access? - -You can purchase private RPC access from [Nodereal](https://nodereal.io/meganode). - ### Are there any grants or financial support for projects on opBNB? Yes, we provide the same support for opBNB as for BNB Smart Chain when it comes to grants or financing projects. Check [here](https://www.bnbchain.org/en/developers/developer-programs) for the complete details. diff --git a/docs/bnb-opbnb/get-started/network-info.md b/docs/bnb-opbnb/get-started/network-info.md index c709096a83..bdebede2b0 100644 --- a/docs/bnb-opbnb/get-started/network-info.md +++ b/docs/bnb-opbnb/get-started/network-info.md @@ -21,15 +21,11 @@ You can use either public and private RPC endpoints to access opBNB. ### Public Testnet RPC Endpoints(WSS is supported) - https://opbnb-testnet-rpc.bnbchain.org/ - - https://opbnb-testnet.nodereal.io/v1/64a9df0874fb4a93b9d0a3849de012d3 - - https://opbnb-testnet.nodereal.io/v1/e9a36765eb8a40b9bd12e680a1fd2bc5 - https://opbnb-testnet.publicnode.com ### Public Mainnet RPC Endpoints(WSS is supported) - https://opbnb-mainnet-rpc.bnbchain.org - - https://opbnb-mainnet.nodereal.io/v1/64a9df0874fb4a93b9d0a3849de012d3 - - https://opbnb-mainnet.nodereal.io/v1/e9a36765eb8a40b9bd12e680a1fd2bc5 - https://opbnb.publicnode.com ### Private opBNB RPC Endpoints diff --git a/docs/bnb-opbnb/get-started/wallet-configuration.md b/docs/bnb-opbnb/get-started/wallet-configuration.md index afa5945624..21df36c5d1 100644 --- a/docs/bnb-opbnb/get-started/wallet-configuration.md +++ b/docs/bnb-opbnb/get-started/wallet-configuration.md @@ -22,7 +22,7 @@ To configure your wallet to work with opBNB, you will need to add both the BNB s *Mainnet* - Network Name: BSC Mainnet - - RPC URL: [https://bsc.nodereal.io](https://bsc.nodereal.io) + - RPC URL: [https://bsc-dataseed.bnbchain.org](https://bsc-dataseed.bnbchain.org) - ChainID: 56 - Symbol: BNB - Explorer: [https://bscscan.com/](https://bscscan.com/) diff --git a/docs/bnb-opbnb/img/image-20250411135104222 copy.png b/docs/bnb-opbnb/img/image-20250411135104222 copy.png new file mode 100644 index 0000000000..1df242f682 Binary files /dev/null and b/docs/bnb-opbnb/img/image-20250411135104222 copy.png differ diff --git a/docs/bnb-opbnb/img/image-20250411135104222.png b/docs/bnb-opbnb/img/image-20250411135104222.png new file mode 100644 index 0000000000..1df242f682 Binary files /dev/null and b/docs/bnb-opbnb/img/image-20250411135104222.png differ diff --git a/docs/bnb-opbnb/img/image-20250411135320376 copy.png b/docs/bnb-opbnb/img/image-20250411135320376 copy.png new file mode 100644 index 0000000000..7c479f34aa Binary files /dev/null and b/docs/bnb-opbnb/img/image-20250411135320376 copy.png differ diff --git a/docs/bnb-opbnb/img/image-20250411135320376.png b/docs/bnb-opbnb/img/image-20250411135320376.png new file mode 100644 index 0000000000..7c479f34aa Binary files /dev/null and b/docs/bnb-opbnb/img/image-20250411135320376.png differ diff --git a/docs/bnb-opbnb/img/image-20250411151438331 copy.png b/docs/bnb-opbnb/img/image-20250411151438331 copy.png new file mode 100644 index 0000000000..2c9287c39d Binary files /dev/null and b/docs/bnb-opbnb/img/image-20250411151438331 copy.png differ diff --git a/docs/bnb-opbnb/img/image-20250411151438331.png b/docs/bnb-opbnb/img/image-20250411151438331.png new file mode 100644 index 0000000000..2c9287c39d Binary files /dev/null and b/docs/bnb-opbnb/img/image-20250411151438331.png differ diff --git a/docs/bnb-smart-chain/benchmark/design-reference.md b/docs/bnb-smart-chain/benchmark/design-reference.md new file mode 100644 index 0000000000..c827be7eba --- /dev/null +++ b/docs/bnb-smart-chain/benchmark/design-reference.md @@ -0,0 +1,66 @@ +--- +title: Benchmark - Design +--- + +# Benchmark - Design + +The purpose of this document is to share the design adopted by BSC for characterizing its performance using close-to-real test scenarios. + +**Nodes Design** + +* A: Client(s) → Validator(s) +* B: Client(s) → FullNode(s) → Validator(s) + +Both are acceptable; but ***B is recommended***. + +**Scenarios Design** + +The ***default*** design mimics typical transactions in a DeFi application, and the weight parameters enhance the flexibility of adding/removing scenarios with minimal implementation effort. + +| Scenarios | Weight | +| ---| --- | +| Native token (BNB) transfer | 10 | +| Contract token (BEP20) transfer | 10 | +| Wrapped Native token (WBNB) deposit | 5 | +| Wrapped Native token (WBNB) withdraw | 5 | +| UniswapV2 - AddLiquidity | 5 | +| UniswapV2 - RemoveLiquidity | 5 | +| UniswapV2 - SwapExactTokensForTokens | 30 | +| UniswapV2 - SwapBNBForExactTokens | 30 | +| \[***Optional***\] ERC721 mint/transfer | 5 | +| \[***Optional***\] ERC1155 mint/Transfer | 5 | +| \[***Optional***\] Blob transaction | 1 | +| \[***Optional***\] EIP7702 transaction | 1 | +| \[***Optional***\] user-defined contract for the evaluation of _CPU intensive operations_ | 100 | + +**Data Design** + +* 16 BEP20 tokens are created. +* 24 trading pairs are created: + * 8 of them are among BEP20 tokens, e.g. T0←→T8, T1←→T9, etc; + * 16 of them are among native token and ERC20 tokens, e.g. BNB←→T0, BNB←→T1, etc; +* Each active user is allocated native tokens, wrapped native tokens, and two BEP20 tokens forming a trading pair. All tokens are distributed equally across active users based on modulo operation results. +* After token allocation, each active user can run any scenario listed above using their allocated tokens. +* A group of distinct test users is pre-selected from active users to serve as load generators. +* ***For transfer scenarios, we use either distinct "to" addresses to maximize the transaction parallelism or a limited set of "to" addresses to minimize it***. + +**Data Volume** + +* A: Generate 1M active users and set up the test scenarios with 100k+ blocks +* B: Generate 25M active users and set up the test scenarios with 1.0M-2.5M blocks + +Both are acceptable, but ***B is recommended as it includes more blocks, accounts and states changes, which provides insights into how storage growth impacts performance over time***. + +**Evaluation Criteria** + +* No node failures should occur during execution. +* The number of transactions per block should be consistent with the transaction propagation rate to validators' mempools and the sending rate from the test client. And there should be no backlog in validators' mempools after the test client stops. +* The empty block rate must be below 0.1%. +* The failed transaction rate, including send-errors and zero-receipt-status transactions, must be less than 0.1%; +* A block finality metric must be defined. For example, in BSC, the p90 block finality time must be less than 2 seconds; + +**Contract Code Reference** + +* BEP20: [https://bscscan.com/token/0x55d398326f99059ff775485246999027b3197955#code](https://bscscan.com/token/0x55d398326f99059ff775485246999027b3197955#code) +* WBNB: [https://bscscan.com/address/0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c#code](https://bscscan.com/address/0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c#code) +* UniswapV2: [https://github.com/Uniswap/v2-core](https://github.com/Uniswap/v2-core) diff --git a/docs/bnb-smart-chain/cross-chain-bridge.md b/docs/bnb-smart-chain/cross-chain-bridge.md new file mode 100644 index 0000000000..423762598b --- /dev/null +++ b/docs/bnb-smart-chain/cross-chain-bridge.md @@ -0,0 +1,91 @@ +--- +title: BNB Chain Bridge – Cross‑Chain Guide +--- + +# BNB Chain Cross-Chain Bridge Guide + +> **Status:** Draft · Last updated: 4 Jun 2025 +--- + +## 1 Who Is This Guide For? + +* 🧑‍💻 **Users** who want to transfer tokens in and out of BNB Chain from other chains like **Ethereum** or **Solana**. +* 🛠️ **Developers** who want to integrate a cross-chain bridge widget on their website using BNB Chain's **Canonical Bridge**. + +## 2 Why This Guide Matters + +Many users don’t realize that cross-chain transfers are possible or easy. BNB Chain offers a bridge aggregator that shows the **best route** for moving assets between chains using one of our **six route providers**: + +**Supported Route Providers**: + +* Stargate +* Celer +* deBridge +* Meson +* LayerZero +* Mayan + +> ✅ We help users **see available routes** for transferring assets **into or out of BNB Chain**, but we **do not operate the routes or control token availability**. + +## 3 How to Use the BNB Chain Bridge (User Guide) + +### Step-by-Step + +1. Visit [bnbchain.org/en/bnb-chain-bridge](https://www.bnbchain.org/en/bnb-chain-bridge). +2. Choose your **source chain** (e.g. Ethereum) and **destination chain** (e.g. BNB Chain). +3. Connect your wallet to source chain. +4. Choose a token to bridge and enter the amount. +5. The bridge tool will display **available routes** based on your token and chains. +6. Click **Send** (or **Approve** if required). +7. Wait for the transaction to complete. You’ll receive your tokens on the destination chain. + +## 4 Understanding Bridge Aggregation + +BNB Chain’s bridge tool is an **aggregator**. It finds available routes from partner bridge providers but: + +* ❌ We do not custody tokens. +* ❌ We cannot add tokens ourselves. +* ✅ We simplify access and offer visibility into supported routes. + +You can use the bridge for **all directions** – not just from BNB Chain to others, but also from Ethereum, Solana, and other supported chains **to BNB Chain**. + +## 5 Developer Guide: Integrate the Canonical Bridge Widget + +To integrate the same aggregator bridge experience in your own dApp or website: + +### 📦 Canonical Bridge Repository + +GitHub: [github.com/bnb-chain/canonical-bridge](https://github.com/bnb-chain/canonical-bridge) + +### Features + +* Embed cross-chain bridging into any website. +* Supports the same 6 route providers. +* React component + config options. +* Supports custom networks, tokens, style. +* Supports other chain to other chain transfer (e.g. Ethereum to Base) + +### Use Cases + +* DeFi dApps +* Wallet UIs +* NFT platforms offering cross-chain support + +## 6 FAQs + +| Question | Answer | +| --------------------------------------- | --------------------------------------------------------------------------------------- | +| I don’t see my token listed? | Route providers decide which tokens they support. You can contact them directly. | +| Is this a bridge just for BNB Chain? | No — it supports **all chains** connected via our 6 providers. | +| Can I use this from Solana to Ethereum? | Yes, as long as a route provider supports it. (Only available in Canonical Bridge Widget) | +| Can I embed this bridge in my dApp? | Yes — use the [Canonical Bridge widget](https://github.com/bnb-chain/canonical-bridge). | + +## 7 Final Notes + +* Users should always verify token addresses and routes. +* For token support, contact the respective bridge provider. +* BNB Chain simplifies access to existing infrastructure — we aggregate, not operate. + +## 8 Changelog + +* **2025-05-28** – Initial draft of user + developer combined guide. diff --git a/docs/bnb-smart-chain/developers/json_rpc/bsc-api-list.md b/docs/bnb-smart-chain/developers/json_rpc/bsc-api-list.md index d123c61a89..f8cd065c9b 100644 --- a/docs/bnb-smart-chain/developers/json_rpc/bsc-api-list.md +++ b/docs/bnb-smart-chain/developers/json_rpc/bsc-api-list.md @@ -7,9 +7,35 @@ Finality is a crucial aspect of blockchain security, ensuring that once a block ### Probabilistic Finality and Economic Finality -In probabilistic finality, the deeper a block is buried in the chain, the lower the likelihood of it being reverted. The more blocks follow a particular block, the more likely the chain containing that block will be the longest. **Typically, BSC users should wait for at least 11 or 15 different validators to seal a block. If validators are allowed to produce multiple consecutive blocks, the number of blocks required to achieve probabilistic finality is approximately 11\*n or 15\*n, where "n" is the number of consecutive blocks produced.** +BNB Smart Chain (BSC) implements a dual-layer finality mechanism combining Economic Finality and Probabilistic Finality to ensure transaction security and network efficiency. -Economic Finality refers to the high cost associated with reverting a block. In proof-of-stake systems that use a slashing mechanism (such as Casper FFG, Tendermint, or BSC Fast Finality), if validators violate the voting rules, part or all of their stake can be forfeited. This economic penalty makes it extremely expensive to undermine finality. Generally, block n achieves economic finality by block n+2, meaning that BSC Fast Finality reduces the confirmation time to two blocks in most cases. This improves the user experience by making transaction confirmation faster and more reliable. +#### Economic Finality (Fast Finality) + +The Fast Finality feature, introduced through **[BEP-126](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP126.md)**, enables Economic Finality using a slashing mechanism similar to Casper FFG and Tendermint. Key characteristics: + +- Block n achieves economic finality by block n+2 +- Transaction finality time: **~3.75 seconds** (with 1.5 seconds block time) +- Economic penalties make block reversal extremely expensive +- Validators violating voting rules forfeit part of their staked assets + +This significantly improves user experience through faster and more reliable transaction confirmations. + +#### Probabilistic Finality (Fallback Mechanism) + +When Fast Finality is unavailable, BSC falls back to Probabilistic Finality. Security increases as more blocks are added - the deeper a block is buried, the lower the probability of reversal. + +Network Parameters: + +- TurnLength: 8 (consecutive blocks per validator) +- ValidatorSize: 21 (total active validators) +- Block Time: ~1.5 seconds + +Finality Requirements: + +- Majority (>1/2) validator confirmations: 88 blocks (11 × 8) ≈ 132 seconds +- Supermajority (>2/3) validator confirmations: 120 blocks (15 × 8) ≈ 180 seconds + +This dual-layer approach ensures network security and finality guarantees even when Fast Finality encounters issues. ### Economic Finality API @@ -63,7 +89,12 @@ This will return block hashes: These methods allow you to handle block finality using a straightforward API. ### eth_getFinalizedHeader -* `verifiedValidatorNum` must be within the range [1, len(currentValidators)]. +* `verifiedValidatorNum` must be within the range `[1, len(currentValidators)]`,with the exception that: + - `-1` represents at least `len(currentValidators) * 1/2` + - `-2` represents at least `len(currentValidators) * 2/3` + - `-3` represents at least `len(currentValidators)` +* Using `-1`, `-2`, or `-3` provides a convenient way to select the desired security level according to your application and the corresponding waiting time. When one of these values is used as the parameter, the returned block is increasingly less likely to be reverted. **Historically, blocks returned by `eth_getFinalizedHeader` with `-1`, `-2`, or `-3` on BSC have never been reverted.** +* If the highest security level is required, you can choose `-3`. * This function calculates `probabilisticFinalizedHeight` as the highest height of the block verified by `verifiedValidatorNum` validators and then returns the block header with a height equal to `max(fastFinalizedHeight, probabilisticFinalizedHeight)`. * The height of the returned block header is guaranteed to increase monotonically. For example: @@ -72,7 +103,12 @@ curl -X POST "http://localhost:8545/" -H "Content-Type: application/json" --dat ``` ### eth_getFinalizedBlock -* `verifiedValidatorNum` must be within the range [1, len(currentValidators)]. +* `verifiedValidatorNum` must be within the range `[1, len(currentValidators)]`,with the exception that: + - `-1` represents at least `len(currentValidators) * 1/2` + - `-2` represents at least `len(currentValidators) * 2/3` + - `-3` represents at least `len(currentValidators)` +* Using `-1`, `-2`, or `-3` provides a convenient way to select the desired security level according to your application and the corresponding waiting time. When one of these values is used as the parameter, the returned block is increasingly less likely to be reverted. **Historically, blocks returned by `eth_getFinalizedHeader` with `-1`, `-2`, or `-3` on BSC have never been reverted.** +* If the highest security level is required, you can choose `-3`. * This function calculates `probabilisticFinalizedHeight` as the highest height of the block verified by `verifiedValidatorNum` validators and then returns the block header with a height equal to `max(fastFinalizedHeight, probabilisticFinalizedHeight)`. * If `fullTx` is true, the block includes all transactions; otherwise, only transaction hashes are included. * The height of the returned block is guaranteed to be monotonically increasing. diff --git a/docs/bnb-smart-chain/developers/node_operators/archive_node.md b/docs/bnb-smart-chain/developers/node_operators/archive_node.md index ee8e6aab72..d5aaffa4b4 100644 --- a/docs/bnb-smart-chain/developers/node_operators/archive_node.md +++ b/docs/bnb-smart-chain/developers/node_operators/archive_node.md @@ -29,13 +29,6 @@ Running an archive node will take a high cost as it includes all the block and s [Erigon](https://github.com/node-real/bsc-erigon) now supports the BSC mainnet. The latest version allows you to sync an archive node from scratch in just 3 days, using 4.3 TB of disk space. You can use Erigon to operate an archive node as shown below. - -### Run with a Reth client - -[Reth](https://github.com/bnb-chain/reth) now supports the BSC network and demonstrates superior performance compared to Geth and Erigon in recent benchmark tests. You can utilize reth to operate an archive node (as well as full node); for more information, refer to [Full Node](./full_node.md). - - - --- title: BSC Erigon Node Deployment Guide --- diff --git a/docs/bnb-smart-chain/developers/node_operators/fast_node.md b/docs/bnb-smart-chain/developers/node_operators/fast_node.md index 29236166d5..7860115f25 100644 --- a/docs/bnb-smart-chain/developers/node_operators/fast_node.md +++ b/docs/bnb-smart-chain/developers/node_operators/fast_node.md @@ -57,30 +57,7 @@ Fast node does not need trie data anymore, prune the trie data by the following ### Start Fast Node Without Snapshot Verification -You can start Fast Node without snapshot verification by verify nodes. - ```bash ## start a fast node ./geth --tries-verify-mode none --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --history.transactions 0 ``` - -Or start Fast Node With Snapshot Verification -1. Add verifyNodes peers in config.toml. - -``` -[Node.P2P] -MaxPeers = 1350 -NoDiscovery = false -BootstrapNodes = ["enode://...", "enode://...", ...] -VerifyNodes = ["enode://...", "enode://...", ...] -StaticNodes = ["enode://...", "enode://...", ...] -ListenAddr = ":30311" -EnableMsgEvents = false -``` - -2. Start your fast node with snapshot verification by verify nodes. - -```bash -## start a fast node -./geth --tries-verify-mode full --config ./config.toml --datadir ./node --cache 8000 --rpc.allow-unprotected-txs --history.transactions 0 -``` diff --git a/docs/bnb-smart-chain/developers/node_operators/full_node.md b/docs/bnb-smart-chain/developers/node_operators/full_node.md index 181c6ed17e..902f5c4725 100644 --- a/docs/bnb-smart-chain/developers/node_operators/full_node.md +++ b/docs/bnb-smart-chain/developers/node_operators/full_node.md @@ -14,10 +14,9 @@ Full node stores the full world state on disk and is capable of: Currently, there are 3 different clients to run a BSC full: * Geth: https://github.com/bnb-chain/bsc -* Reth: https://github.com/bnb-chain/reth * Erigon: https://github.com/node-real/bsc-erigon -Only Geth and Reth will be covered in this page, as Erigon is mainly to support archive mode, pls refer [archive_node.md](./archive_node.md) for its usage. +Only Geth will be covered in this page, as Erigon is mainly to support archive mode, pls refer [archive_node.md](./archive_node.md) for its usage. !!! tip If you want high performance and care little about state consistency, you can run a fast node, which is a full node with the flag `--tries-verify-mode none` set. @@ -125,74 +124,3 @@ Please read [this guide](node_maintenance.md) #### d.Upgrade Geth Please read [this guide](upgrade_geth.md) - -## 3.Run BSC Full Node: Reth - -BSC Reth is a cutting-edge Rust client developed in collaboration with Paradigm, designed to provide seamless support for BNB Smart Chain (BSC). It aims to enhance client diversity on the BNB Chain by offering a secure and efficient execution client. - -### 3.1.Hardware Specifications - -To run BSC Reth effectively, ensure your system meets the following hardware requirements: - -* CPU with 16+ cores -* 128GB RAM -* High-performance NVMe SSD with at least 4TB of free space for a full node and 8TB for an archive node -* Broadband internet connection with upload/download speeds of 25 MB/s - -### 3.2.Running BSC Reth - -1. Download source code and build binary. -```shell -git clone https://github.com/bnb-chain/reth.git -cd reth -make build-bsc -``` - -2. Start the reth node, it will run in archive mode by default. You can add the `--full` flag to start a full node. -```shell -# for mainnet -export network=bsc - -# for testnet -# export network=bsc-testnet - -./target/release/bsc-reth node \ - --datadir=./datadir \ - --chain=${network} \ - --http \ - --http.api="eth, net, txpool, web3, rpc" \ - --log.file.directory ./datadir/logs -``` - -3. Optionally, you can run the reth node with docker. -```shell -# for mainnet -export network=bsc - -# for testnet -# export network=bsc-testnet - -# check this for version of the docker image, https://github.com/bnb-chain/reth/pkgs/container/bsc-reth -export version=latest - -# the directory where reth data will be stored -export data_dir=/xxx/xxx - -docker run -d -p 8545:8545 -p 30303:30303 -p 30303:30303/udp -v ${data_dir}:/data \ - --name bsc-reth ghcr.io/bnb-chain/bsc-reth:${version} node \ - --datadir=/data \ - --chain=${network} \ - --http \ - --http.api="eth, net, txpool, web3, rpc" \ - --log.file.directory /data/logs -``` - -### 3.3.Snapshot - -To synchronize a BSC reth node from scratch to the current block height can be a time-consuming process. -As We benchmark [Reth(v1.0.0)](https://github.com/bnb-chain/reth/releases/tag/v1.0.0) on AWS [lm4gn.8xlarge](https://instances.vantage.sh/aws/ec2/im4gn.8xlarge)(32 core 128G) with 2 x 7500 NVMe SSD for BSC mainnet. -It may take approximately 30 days to sync the latest block on BSC mainnet for an archive node and 24 days for a full node. - -Given the extended duration required for stage synchronization of the BSC network, the BNB Chain team is developing a segmented snapshot download solution, scheduled for release in the near future. -Currently, developers seeking to expedite the process can obtain archive node snapshots from [community-maintained repositories](https://github.com/fuzzland/snapshots). -These snapshots offer a faster alternative to syncing from genesis, allowing for quicker node setup and network participation. diff --git a/docs/bnb-smart-chain/developers/quick-guide.md b/docs/bnb-smart-chain/developers/quick-guide.md index e0f7a78362..0eaa814e2e 100644 --- a/docs/bnb-smart-chain/developers/quick-guide.md +++ b/docs/bnb-smart-chain/developers/quick-guide.md @@ -41,6 +41,10 @@ Interacting with BSC requires sending requests to specific JSON-RPC API methods. - [Remix](https://remix.ethereum.org) - [Hardhat](https://hardhat.org) - [Foundry](https://book.getfoundry.sh/) +- Indexing + - [TheGraph](https://thegraph.com/) + - [Covalent](https://www.covalenthq.com) + - [Others](https://www.alchemy.com/dapps/list-of/indexing-tools-on-ethereum) - Wallets - [Binance Web3 Wallet](https://www.binance.com/en/web3wallet) - [Metamask](https://metamask.io/) @@ -64,4 +68,4 @@ Interacting with BSC requires sending requests to specific JSON-RPC API methods. - [CoinGecko](https://www.coingecko.com/en/chains/binance-smart-chain) - [DappBay](https://dappbay.bnbchain.org/ranking/chain/bnb-smart-chain) -For more tools and details, you can refer to [BSC Dev Tools](https://www.bnbchain.org/en/dev-tools). \ No newline at end of file +For more tools and details, you can refer to [BSC Dev Tools](https://www.bnbchain.org/en/dev-tools). diff --git a/docs/bnb-smart-chain/developers/wallet-configuration.md b/docs/bnb-smart-chain/developers/wallet-configuration.md index 61bd2bfafc..d18ea62bf5 100644 --- a/docs/bnb-smart-chain/developers/wallet-configuration.md +++ b/docs/bnb-smart-chain/developers/wallet-configuration.md @@ -18,7 +18,7 @@ You can use any Ethereum wallet with BSC. For instance, I will show you how to s *Mainnet* - Network Name: BSC Mainnet - - RPC URL: [https://bsc.nodereal.io](https://bsc.nodereal.io) + - RPC URL: [https://bsc-dataseed.bnbchain.org](https://bsc-dataseed.bnbchain.org) - ChainID: 56 - Symbol: BNB - Explorer: [https://bscscan.com/](https://bscscan.com/) diff --git a/docs/bnb-smart-chain/faq/index.md b/docs/bnb-smart-chain/faq/index.md new file mode 100644 index 0000000000..4353a36daa --- /dev/null +++ b/docs/bnb-smart-chain/faq/index.md @@ -0,0 +1,14 @@ +--- +title: Frequently Asked Questions (FAQ) +--- + +# Frequently Asked Questions (FAQ) + +Welcome to the FAQ section for BNB Smart Chain. Below are some common questions and helpful articles to guide you: + +- [Recovering Tokens Sent to Wrong Chain or Address](./recovering-tokens-sent-to-wrong-chain-or-address.md) +- [Tokens Not Showing in Wallet](./tokens-not-showing-in-wallet.md) +- [Transfer NEXO from Tangem into BSC](./transfer-nexo-from-tangem-into-bsc.md) +- [Lorentz Hard Fork Upgrade](./plorentz-hard-fork-upgrade.md) + +If your issue is not listed here, please explore our other documentation or open an issue. diff --git a/docs/bnb-smart-chain/faq/lorentz-hard-fork-upgrade.md b/docs/bnb-smart-chain/faq/lorentz-hard-fork-upgrade.md new file mode 100644 index 0000000000..5b532f24f6 --- /dev/null +++ b/docs/bnb-smart-chain/faq/lorentz-hard-fork-upgrade.md @@ -0,0 +1,84 @@ +--- +title: Lorentz Hard Fork - BSC FAQs +--- + +### What is the Lorentz upgrade and what does it aim to improve? + +The Lorentz upgrade is a major performance-focused hard fork on BNB Smart Chain (BSC), designed primarily to reduce block times and enhance validator synchronization. It sets the stage for sub-second block intervals and positions BNB Chain for real-time and AI-powered decentralized applications. + +--- + +### How does the Lorentz upgrade affect transaction finality and network security? Are there any trade-offs? + +The Lorentz upgrade improves block speed but does not change BNB Chain’s core security model. However, faster block times (1.5s and eventually 0.75s) make the network more sensitive to latency: + +- **Trade-off**: If block propagation is delayed and takes a significant portion of the block time, consensus stability can be impacted. +- **Mitigation**: To address this, BNB Chain is optimizing validator communication, messaging protocols, and overall network latency. + +--- + +### How was validator synchronization improved in this upgrade? + +Validator synchronization is now more efficient thanks to two key upgrades: + +1. **Block Fetching via bsc/2 Protocol** + - Nodes can now request a **range of recent blocks** in a single round trip. + - This replaces the slower, multi-step `eth/68` process, reducing latency. + +2. **Enhanced Validator Network** + - Validators can now **register public NodeIDs on-chain** via a system contract. + - This enables validators to form a direct, private communication mesh. + - Crucial messages like blocks and votes now **bypass slower public hops**. + +Together, these upgrades minimize synchronization delays and ensure robust consensus performance even with faster block times. + +--- + +### What metrics are being used to evaluate the success of the Lorentz upgrade? + +The core success metrics include: + +- **Block time stability** at 1.5 seconds (targeting 0.75s in future) +- **No degradation in network throughput** +- **Stable consensus and validator performance** + +These metrics help ensure performance gains do not come at the cost of network reliability. + +--- + +### With block times dropping to 1.5 seconds (and eventually 0.75s), how does BNB Chain compare to Solana? + +BNB Chain’s shorter block times and strong time-to-finality will make it competitive with high-performance chains like Solana. However, BNB Chain retains a key advantage: + +- **EVM compatibility**, which allows easier migration and development for projects familiar with Ethereum infrastructure. + +This combination offers the speed of Solana and the flexibility of EVM. + +--- + +### How do these upgrades support AI-powered and real-time decentralized applications? + +Lorentz (and the upcoming Maxwell upgrade) are foundational to BNB Chain’s "AI-First" strategy. Benefits include: + +- **Faster confirmations** for AI, gaming, and DeFi applications. +- **Lower latency**, enabling high-frequency interactions and near-instant finality. +- **Improved data throughput**, supporting AI models and real-time computations on-chain. + +This positions BNB Chain to be the infrastructure layer for next-gen decentralized applications. + +--- + +### Will BNB Chain open-source more infrastructure changes or benchmarks? + +Yes. All execution optimizations and consensus changes are: + +- **Open-sourced** +- Publicly discussed in improvement proposals like **BEP-520** and **BEP-524** + +BNB Chain encourages transparency and community collaboration in its performance roadmap. + +--- + +### Still Have Questions? + +Join the discussion or ask our team directly in the [official BNB Chain Discord](https://discord.com/invite/bnbchain). diff --git a/docs/bnb-smart-chain/faq/recovering-tokens-sent-to-wrong-chain-or-address.md b/docs/bnb-smart-chain/faq/recovering-tokens-sent-to-wrong-chain-or-address.md new file mode 100644 index 0000000000..b197567727 --- /dev/null +++ b/docs/bnb-smart-chain/faq/recovering-tokens-sent-to-wrong-chain-or-address.md @@ -0,0 +1,91 @@ +--- +title: Recovering Tokens Sent to the Wrong Chain or Address - BSC FAQs +--- + +### I accidentally sent my tokens to the wrong blockchain or wallet address. Can I recover them? + +This is a common issue, and recovery depends entirely on **whether you control the private key** of the address where the tokens were sent. + +--- + +### Step 1: Do You Control the Recipient Address? + +Ask yourself the following: + +- **Did you send tokens to an address you personally own (e.g., another one of your wallets)?** + - If yes: Continue to recovery steps. +- **Did you send tokens to an exchange address or someone else’s wallet?** + - If no private key access: You’ll need to **contact the owner/platform**. Recovery depends on their policies. + +--- + +### Step 2: If You **Do Not Own** the Address + +Unfortunately, there is no way to retrieve the tokens unless the recipient is willing to send them back. Here’s what you can try: + +1. **Contact the exchange or platform** (if it’s a known wallet). +2. **Share transaction details** (TxID, address, token name, network used). +3. **Explain the mistake** and request a manual recovery. + +> *Note: Not all platforms offer recovery services, and many will decline if the token was sent via an unsupported network.* + +--- + +### Step 3: If You **Do Own** the Recipient Address + +You can attempt token recovery using one of the following methods: + +#### A. Sent Tokens to the Wrong Chain (e.g., BSC → opBNB or vice versa) + +1. Open your wallet app (e.g. Trust Wallet). +2. Switch to the **network where the tokens were mistakenly sent** (e.g., opBNB). +3. If the token isn’t visible, **manually add the token** using its contract address. +4. You should now see the tokens in your wallet on the correct chain context. + +> *You have not lost the tokens — they are just on a different network!* + +#### B. Sent Tokens to a Different Address You Control + +1. Open the wallet app (MetaMask, Trust Wallet, etc.). +2. Import the address using the **private key or recovery phrase**. +3. Switch to the correct network (e.g., BNB Smart Chain). +4. Manually add the token contract if needed. +5. Once confirmed, you can send the tokens back to your main wallet. + +--- + +### How to Manually Add a Token in MetaMask or Trust Wallet + +You’ll need the token’s contract address on the network in question. + +1. Visit a blockchain explorer like [BscScan](https://bscscan.com). +2. Search for the token name (e.g., NEXO, USDT). +3. Copy the contract address. +4. In your wallet, select **“Add Token”** and paste the contract address. +5. Confirm the token appears and balance is shown. + +--- + +### Frequently Asked Questions + +**Q: What if I sent tokens from Binance to MetaMask using the wrong network?** +A: If you own the receiving address (MetaMask), follow the steps to switch to the network you used. If not, you’ll need Binance’s help. + +**Q: I used the wrong network and the tokens aren’t showing — are they lost?** +A: Not necessarily. Tokens are still on the blockchain, just under a different network context. + +**Q: Is it safe to import private keys into another wallet?** +A: Yes — **as long as you trust the app** and never share the key publicly. Always back it up securely offline. + +--- + +### Still Need Help? + +If you’re still stuck, please reach out via by [opening a ticket on discord](https://discord.com/invite/bnbchain). Please include the following: + +- The **transaction hash (TxID)** +- The **sending and receiving addresses** +- The **network used** +- The **token name** + +We’ll help guide you through the best next steps. diff --git a/docs/bnb-smart-chain/faq/tokens-not-showing-in-wallet.md b/docs/bnb-smart-chain/faq/tokens-not-showing-in-wallet.md new file mode 100644 index 0000000000..8de6594305 --- /dev/null +++ b/docs/bnb-smart-chain/faq/tokens-not-showing-in-wallet.md @@ -0,0 +1,110 @@ +--- +title: Tokens Not Showing in Wallet - BSC FAQs +--- + +### I can’t see my tokens in my wallet after a transfer or airdrop. What’s going on? + +This is a common situation and it can happen for various reasons — wrong network selected, token not added manually, unsupported token types, or the token hasn't been distributed yet. + +--- + +### Common Real User Queries This FAQ Addresses + +- **"I transferred USDT from Binance to my Phantom wallet, Binance says it’s done but I didn’t receive anything on Phantom."** +- **"My NFTs are displayed on BscScan as BEP-20 instead of BEP-721, so they don’t show up in Trust Wallet."** +- **"After bridging Aqualis Token from Ethereum to BSC via deBridge, it hasn’t appeared on the BNB Chain Bridge UI."** +--- + +### Step 1: Check the Transaction + +1. Go to [BscScan](https://bscscan.com). +2. Enter your wallet address or transaction hash. +3. Confirm the following: + - The transaction was **successful** + - The token was sent to the correct **address** + - The token exists on the **correct network** + +--- + +### Step 2: Are You on the Right Network? + +In your wallet (MetaMask, Trust Wallet, etc.): + +- Ensure you’ve selected the same network the token was sent on. + - For example, a token sent on **BNB Smart Chain** won’t show up under **Ethereum Mainnet** or **opBNB**. + +If needed, add the network manually: +- For BSC: + RPC URL: `https://bsc-dataseed.binance.org/` + Chain ID: `56` +- For opBNB: + RPC URL: `https://opbnb-mainnet-rpc.bnbchain.org/` + Chain ID: `204` + +--- + +### Step 3: Manually Add the Token + +Sometimes tokens won’t show until you manually import them. + +1. Go to [BscScan](https://bscscan.com). +2. Search for your token (e.g., USDT, KILO). +3. Copy the **token contract address**. +4. In your wallet: + - Click “Add Token” (MetaMask) or “Import Token” (Trust Wallet). + - Paste the contract address and confirm the token symbol and decimals. +5. Your balance should now appear. + +--- + +### Step 4: Token Not Distributed Yet? + +Some airdrops or reward tokens may show as “pending” — especially in early-phase campaigns. If this applies to your token: + +- Check the project’s **official announcement** or status page. +- Look for a **distribution timeline** or claim instructions. +- If tokens are marked as "pending" in Binance Web3 Wallet or event dashboard, you might just need to wait. + +--- + +### Step 5: NFT Not Displaying? + +- If your NFT shows on BscScan but not in your wallet: + - Make sure your wallet supports the token **standard** (e.g., BEP-721, not BEP-20). + - Try viewing your NFT on an NFT-specific platform or switch to a wallet with NFT support. + +--- + +### Step 6: Bridged Tokens Not Appearing? + +Tokens bridged using services like deBridge or LayerZero might not display until the final transaction is confirmed on both networks. + +- Revisit the bridge UI and check the status. +- Manually add the token if needed. +- Be patient — bridging can take a few minutes or longer, depending on the network load. + +--- + +### Frequently Asked Questions + +**Q: What if I used the wrong wallet type or chain?** +A: The token is likely still there — just on a different chain or wallet interface. Try switching networks or importing the token. + +**Q: I see my tokens on BscScan, why don’t they show in my wallet?** +A: You likely need to **manually add the token contract** in your wallet. + +**Q: Is it dangerous to add a token manually?** +A: No — as long as you use the official contract address from a trusted source like BscScan or the project team. + +--- + +### Still Need Help? + +If you're still having trouble, [open a support ticket on our Discord](https://discord.com/invite/bnbchain) and share the following details: + +- Your **wallet address** +- The **transaction hash (TxID)** +- The **token name** and **network** +- A short explanation of the issue + +We’ll do our best to assist you directly. diff --git a/docs/bnb-smart-chain/faq/transfer-nexo-from-tangem-into-bsc.md b/docs/bnb-smart-chain/faq/transfer-nexo-from-tangem-into-bsc.md new file mode 100644 index 0000000000..c0cf5900e5 --- /dev/null +++ b/docs/bnb-smart-chain/faq/transfer-nexo-from-tangem-into-bsc.md @@ -0,0 +1,50 @@ +--- +title: Migrating NEXO from Tangem Wallet - BSC FAQs +--- + +### Why can’t I migrate or withdraw my NEXO tokens from Tangem Wallet? + +If you held NEXO tokens on the Beacon Chain and missed the migration window last summer or fall, you might find that your NEXO tokens are stuck in your Tangem Wallet. Currently, the Tangem Wallet only provides options for **Trust Wallet** and **BNB Chain** migration, but doesn't support **WalletConnect**, which is typically needed to complete the migration process. + +### What’s the workaround if I can’t complete migration via Tangem Wallet? + +You can export your wallet’s **mnemonic phrase** from Tangem and then import it into **Trust Wallet**, which supports WalletConnect and gives you access to your NEXO tokens on the BNB Smart Chain. + +### How do I export my mnemonic phrase from Tangem? + +1. Open the **Tangem Wallet app**. +2. Go to **Wallet Settings**. +3. Find and select **Export Mnemonic** or **Backup Phrase**. +4. Save the 12 or 24-word phrase securely and **never share it** with anyone. + +### How do I import my mnemonic into Trust Wallet? + +1. Download and open **Trust Wallet**. +2. Choose **Import Wallet** > **Multi-Coin Wallet**. +3. Enter your mnemonic phrase. +4. Once imported, you will have access to your wallet via Trust Wallet. + +### How do I access and migrate my NEXO tokens on BSC using Trust Wallet? + +1. Enable the **BNB Smart Chain (BSC)** in Trust Wallet. +2. Add the **NEXO token manually** if it does not appear automatically. +3. Use **WalletConnect** to access the migration dApp or platform that supports Beacon Chain to BSC migration. +4. Follow the dApp's instructions to complete the migration. + +### Is there a specific contract address I need to use for NEXO on BSC? + +Yes. Make sure to use the **correct and official contract address** for NEXO on BNB Smart Chain to ensure your tokens are recognized and not lost. + +> **Tip:** You can find the official contract address on trusted sources such as [BNB Smart Chain explorers](https://bscscan.com/). + +### What if I don’t feel comfortable handling mnemonic phrases? + +If you're unsure or uncomfortable with this process, it's strongly advised to contact **Tangem support** or a qualified crypto advisor. Never share your recovery phrase publicly or with untrusted sources. + +### Is this issue specific to BSC? + +Yes, this FAQ addresses issues specifically related to NEXO migration to **BNB Smart Chain (BSC)**. + +### Need help? + +If you’re still stuck, please reach out via by [opening a ticket on discord](https://discord.com/invite/bnbchain). diff --git a/docs/bnb-smart-chain/img/evn/evn-sentry-mode.png b/docs/bnb-smart-chain/img/evn/evn-sentry-mode.png new file mode 100644 index 0000000000..7aab9a8d0e Binary files /dev/null and b/docs/bnb-smart-chain/img/evn/evn-sentry-mode.png differ diff --git a/docs/bnb-smart-chain/img/evn/evn-simple-mode.png b/docs/bnb-smart-chain/img/evn/evn-simple-mode.png new file mode 100644 index 0000000000..d51c9ff687 Binary files /dev/null and b/docs/bnb-smart-chain/img/evn/evn-simple-mode.png differ diff --git a/docs/bnb-smart-chain/img/evn/evn-topology.png b/docs/bnb-smart-chain/img/evn/evn-topology.png new file mode 100644 index 0000000000..0d7e585d55 Binary files /dev/null and b/docs/bnb-smart-chain/img/evn/evn-topology.png differ diff --git a/docs/bnb-smart-chain/overview.md b/docs/bnb-smart-chain/overview.md index 5dcee178c4..46b3099008 100644 --- a/docs/bnb-smart-chain/overview.md +++ b/docs/bnb-smart-chain/overview.md @@ -9,7 +9,7 @@ BNB Smart Chain (BSC) is a high-performance blockchain network. Officially launc ### Key Features and Advantages 1. **Ethereum Virtual Machine (EVM) Compatibility:** - BSC is fully compatible with the Ethereum Virtual Machine (EVM), enabling developers to port their Ethereum-based DApps and DeFi projects to BSC with minimal modifications. This compatibility extends to the use of popular Ethereum tools and applications, such as MetaMask, Truffle, and Remix. + BSC is fully compatible with the Ethereum Virtual Machine (EVM), enabling developers to port their Ethereum-based DApps and DeFi projects to BSC with minimal modifications. This compatibility extends to the use of popular Ethereum tools and applications, such as TrustWallet, MetaMask, Truffle, and Remix. 2. **Low Transaction Fees and Fast Block Times:** One of BSC's primary advantages is its low transaction fees. As of early 2024, the average transaction fee on BSC is around $0.10, significantly lower compared to Ethereum's average fee of $10-$20 during periods of high network congestion. Additionally, BSC block time of approximately is 3 seconds, ensuring rapid transaction confirmations and an overall smoother user experience. diff --git a/docs/bnb-smart-chain/slashing/monitor.md b/docs/bnb-smart-chain/slashing/monitor.md index 58df00d4b7..75950df8fc 100644 --- a/docs/bnb-smart-chain/slashing/monitor.md +++ b/docs/bnb-smart-chain/slashing/monitor.md @@ -14,7 +14,9 @@ Validators should consistently monitor for potential slashes due to node unavail As best practice, it is advisable to keep monitoring the event log of the slash contract on the BSC scanner at . -You can check your validator's slash indicator in the above contract. Pay attention to values above 30. If it goes over 50, the validator will be slashed. If it goes over 150, the validator will be jailed. +You can check your validator's slash indicator in the above contract. Pay attention to values above 50. If it goes over 200, the validator will be slashed. If it goes over 600, the validator will be jailed. + +Pls refer https://docs.bnbchain.org/bnb-smart-chain/slashing/slash-rules/ for more details. ## Unjail Validator diff --git a/docs/bnb-smart-chain/slashing/slash-rules.md b/docs/bnb-smart-chain/slashing/slash-rules.md index c8bedf86e2..7000728087 100644 --- a/docs/bnb-smart-chain/slashing/slash-rules.md +++ b/docs/bnb-smart-chain/slashing/slash-rules.md @@ -43,10 +43,10 @@ If the evidence is valid: There is an internal smart contract that records the missed blocking metrics of each validator. -If a validator misses over 50 blocks in 24 hours, they will not receive the block reward; instead, it will be shared among other validators. +If a validator misses over 200 blocks(governable) in 24 hours, they will not receive the block reward; instead, it will be shared among other validators. -If a validator misses more than 150 blocks in 24 hours: +If a validator misses more than 600 blocks(governable) in 24 hours: -1. **10BNB** would be slashed from the **self-delegated** BNB of the validator +1. **10BNB**(governable) would be slashed from the **self-delegated** BNB of the validator 2. The slashed BNB will be allocated to the credit addresses of validators participating in the next distribution -3. Set the validator `jailed` with a duration of **2 days**, and remove it from the active validator set +3. Set the validator `jailed` with a duration of **2 days**, and remove it from the active validator set \ No newline at end of file diff --git a/docs/bnb-smart-chain/validator/create-val.md b/docs/bnb-smart-chain/validator/create-val.md index aa1aab6cf3..a9fc223e11 100644 --- a/docs/bnb-smart-chain/validator/create-val.md +++ b/docs/bnb-smart-chain/validator/create-val.md @@ -115,7 +115,7 @@ A sample bls address is `b5fe571aa1b39e33c2735a184885f737a59ba689177f297cba67da9 Then you can get your bls proof by running the following command. ```shell -geth bls account generate-proof --chain-id ${BSC_CHAIN_ID} ${OPEATOR_ADDRESS} ${VOTE_ADDRESS} +geth bls account generate-proof --datadir ${DATA_DIR} --chain-id ${BSC_CHAIN_ID} ${OPEATOR_ADDRESS} ${VOTE_ADDRESS} ``` - `BSC_CHAIN_ID`: `56` for BSC mainnet, and `97` for BSC testnet. @@ -147,4 +147,4 @@ Identity is used to associate the new validator with the old validator created o Once you have filled out all the required information, click the `Submit` button to submit the transaction. -Note: Upon completing these steps, your node is not guaranteed to become an active validator. Selection is based on a ranking that reflects the total BNB staked, with only the top N nodes being chosen as active validators. The number N is determined by the "maxElectedValidators" parameter within the StakeHubContract (0x0000000000000000000000000000000000002002). As of November 4th, 2024, this number stands at 8 for the testnet and 45 for the mainnet. \ No newline at end of file +Note: Upon completing these steps, your node is not guaranteed to become an active validator. Selection is based on a ranking that reflects the total BNB staked, with only the top N nodes being chosen as active validators. The number N is determined by the "maxElectedValidators" parameter within the StakeHubContract (0x0000000000000000000000000000000000002002). As of November 4th, 2024, this number stands at 8 for the testnet and 45 for the mainnet. diff --git a/docs/bnb-smart-chain/validator/evn/best-practice.md b/docs/bnb-smart-chain/validator/evn/best-practice.md new file mode 100644 index 0000000000..e991c736f1 --- /dev/null +++ b/docs/bnb-smart-chain/validator/evn/best-practice.md @@ -0,0 +1,111 @@ +--- +title: EVN Best Practices - BSC EVN +--- +## Network Requirements +At the network layer, BSC requires minimal latency to maximize time available for critical operations like block packaging and verification. The BSC network maintains decentralization through validators distributed across diverse geographic locations worldwide. + +Taking AWS's network service as an example, the measured latency of some regions are: +- AP<->EU, latency ~100ms +- AP<->US, latency ~80ms +- US<->EU, latency ~35ms + +This data will be the theoretical best value of network message latency, and it is also the reference value for network environment testing between validators. + +## Configuration +There are two different modes to configure your node, depends on how your validator is connected to the network. +### Mode-1: Sentry Mode + +![evn sentry mode](../../img/evn/evn-sentry-mode.png){:style="width:500px; height:auto;"} + +In this mode, the operator could create multiple nodes, including multiple validator nodes, multiple sentry nodes, and fullnode nodes. + +The validator always remains in a secure intranet environment. Sentry is responsible for quickly exchanging messages with EVN Peer and forwarding them to the validator. Fullnode is a redundant path for additional transactions and other messages. + +Mainly introduces the configuration changes of validator and sentry, and the fullnode configuration remains unchanged. + +#### Validator Configuration + +The example of `Config.toml`. + +```toml +[Eth] +EVNNodeIDsToAdd = ["sentryNodeID1", "sentryNodeID2"] + +[Node] +EnableEVNFeatures = true +EnableQuickBlockFetching = true + +[Node.P2P] +StaticNodes = [ + "", + "", + "", + "..." +] +``` + +`EVNNodeIDsToAdd` fills in the sentry nodeID here. Because the validator is protected in the external network, sentry will act as an EVN Peer to help forward public EVN Peer messages. + +`EnableEVNFeatures` enables the EVN network. + +`EnableQuickBlockFetching` enables BEP-564, which will speed up block retrieval. + +#### Sentry Configuration + +The example of `Config.toml`. + +```toml +[Node] +EnableEVNFeatures = true +EnableQuickBlockFetching = true + +[Node.P2P] +EVNNodeIdsWhitelist = [""] +ProxyedValidatorAddresses = [""] +StaticNodes = [ + "enode://3dd9e7e22180cda7c2a7015d3582811327abb3bc5f330879be7bc3217be4ed7c4ec0d5117ab0fae6542d3e5d199f3d935b7bca108b565f07806ed7687af8d1b5@52.198.165.142:30311", + "enode://70aeb4f0cc52df44f4ef0c72ca0eca8a210b9916ad02bcd147cc58bbfee9259ee46dfa23e13512f98bdb3937d62d2d0a521a90c76161ccffd24bb10829d8d542@13.112.162.162:30311", + "enode://4af65e07b676e3634e4e2e6df01b23e32eb73fdc200b7f98a4807b16e8faefae4d3875bea4d88e203e319f6a61859b66c0b8254191a2058629a00fe6e42e7b18@54.155.24.228:30311", + "enode://2a6cfdbfc8f401d09a766efa53411bb5457fd5903331afee5363017f65623f0c0c43873c14bfb4001cf02811b1196f710bb3911a36e683cb557b11244cffe212@54.77.55.214:30311", + "enode://cc6d828a735db591cb2a0454a94b9602be6c0aca6c73f771efaabc7f68c46085b953c97f880efb17597578320444acc9e207042297689515c18e659d138bb393@23.23.111.240:30311", + "enode://5035ae74e04b4290885c3cea546ca179cb80c1461141b8c3124bb6707993c1e68dafd2f5fd9b13a8d076225412bf5bbefe81c16aa812a35e7c19bb1020b8c124@34.205.243.82:30311", + "" +] +``` + +`EVNNodeIdsWhitelist`: it is optional and is an EVN Peer whitelist that is only valid for the current node. In the transition period before enabling maxwell, the whitelist can be used to apply EVN in advance. At the same time, the operator can put the cooperating builder into the local whitelist. + +`ProxyedValidatorAddresses`: it is optional and is only for sentry to identify which blocks should be broadcast to all EVN Peers, it is configured as the protected validator address. + +`StaticNodes`: it includes a list of well maintained EVN nodes for validators to connect to, the list could be changed in the future. + +### Mode-2: Simple Mode + +![evn simple mode](../../img/evn/evn-simple-mode.png){:style="width:500px; height:auto;"} + +With simple mode, the operator could run a validator node by exposing it directly to the public network environment, so that they can directly connect to other nodes. + +#### Validator Configuration + +The example of `Config.toml`. + +```toml +[Eth] +EVNNodeIDsToAdd = ["validator NodeID", "other nodeids"] + +[Node] +EnableEVNFeatures = true +EnableQuickBlockFetching = true + +[Node.P2P] +EVNNodeIdsWhitelist = [""] +StaticNodes = [ + "enode://3dd9e7e22180cda7c2a7015d3582811327abb3bc5f330879be7bc3217be4ed7c4ec0d5117ab0fae6542d3e5d199f3d935b7bca108b565f07806ed7687af8d1b5@52.198.165.142:30311", + "enode://70aeb4f0cc52df44f4ef0c72ca0eca8a210b9916ad02bcd147cc58bbfee9259ee46dfa23e13512f98bdb3937d62d2d0a521a90c76161ccffd24bb10829d8d542@13.112.162.162:30311", + "enode://4af65e07b676e3634e4e2e6df01b23e32eb73fdc200b7f98a4807b16e8faefae4d3875bea4d88e203e319f6a61859b66c0b8254191a2058629a00fe6e42e7b18@54.155.24.228:30311", + "enode://2a6cfdbfc8f401d09a766efa53411bb5457fd5903331afee5363017f65623f0c0c43873c14bfb4001cf02811b1196f710bb3911a36e683cb557b11244cffe212@54.77.55.214:30311", + "enode://cc6d828a735db591cb2a0454a94b9602be6c0aca6c73f771efaabc7f68c46085b953c97f880efb17597578320444acc9e207042297689515c18e659d138bb393@23.23.111.240:30311", + "enode://5035ae74e04b4290885c3cea546ca179cb80c1461141b8c3124bb6707993c1e68dafd2f5fd9b13a8d076225412bf5bbefe81c16aa812a35e7c19bb1020b8c124@34.205.243.82:30311", + "" +] +``` \ No newline at end of file diff --git a/docs/bnb-smart-chain/validator/evn/faqs.md b/docs/bnb-smart-chain/validator/evn/faqs.md new file mode 100644 index 0000000000..f2a1e7f7b4 --- /dev/null +++ b/docs/bnb-smart-chain/validator/evn/faqs.md @@ -0,0 +1,23 @@ +--- +title: FAQs - BSC EVN +--- + +# FAQs + +### Q1: How to get node’s NodeID? + +you can use the following command to query your enode information. +```bash +./bsc --exec "admin.nodeInfo.id" attach ./geth.ipc +``` + +### Q2: Can multiple validators share sentry nodes? + +Yes, for service providers who act as agents for multiple validators, they can use fewer sentries to achieve the same function. It is worth noting that the combination of validators and sentry is best to be in the same region machine. + +### Q3: Can a validator use multiple sentry nodes? + +Of course, multiple sentries improve redundancy and reduce message delays caused by single sentry failures. It is also recommended that validators connect to multiple fullnodes and other P2P nodes to receive more transactions and improve message redundancy. + +### Q4: How to register other key ecosystem player into EVN network +As only validator can register evn nodeid, so they can ask validator's help to register for them. It could be useful for some key users like mev-builders, infra providers... But there is a limitation on the number of evn nodeids that each validator can register, by default it is 5, but it can be changed by governance. diff --git a/docs/bnb-smart-chain/validator/evn/network-monitor.md b/docs/bnb-smart-chain/validator/evn/network-monitor.md new file mode 100644 index 0000000000..db36091774 --- /dev/null +++ b/docs/bnb-smart-chain/validator/evn/network-monitor.md @@ -0,0 +1,64 @@ +--- +title: Network Monitoring - BSC EVN +--- + +# Network Monitoring + +In EVN, special metrics are provided to observe the message delay indicators of the EVN network and help analyze the causes of delay. + +## Peer Latency + +Peer Latency, it observes the message latency with remote peers, calculated by `RoundTripTime/2`. + +```bash +# Grafana query statement +p2p_peers_latency{quantile="$quantile", job=~"$jobs"} +``` + +Suggesting to monitor message delay under quantile=0.95. + +If the latency is too high under quantile=0.95, you need to optimize the network provider or connect to better static nodes to improve it. + +### The latency of each peer + +You can also query Peer Latency with this command: + +```bash +./bsc attach --exec "admin.peers" ./geth.ipc | grep -E "enode|latency" +``` + +The command will output the transient latency value, you can observe the latency of each node and analyze the slow nodes. + +## Core Message Latency + +These metrics represent the delay of the consensus core process, suggesting to monitor message delay under quantile=0.95. + +```bash +# Grafana query statement +# Delay relative to Header.MilliTimestamp when sending blocks +chain_delay_block_send{quantile="$quantile", job=~"$jobs"} + +# Delay relative to Header.MilliTimestamp when starting to import blocks +chain_delay_block_insert{quantile="$quantile", job=~"$jobs"} + +# Delay relative to Header.MilliTimestamp when receiving majority votes +chain_delay_vote_majority{quantile="$quantile", job=~"$jobs"} + +# Time relative to Header.MilliTimestamp when starting mining +chain_delay_block_mining{quantile="$quantile", job=~"$jobs"} +``` + +`chain_delay_block_insert` and `chain_delay_vote_majority` can help you troubleshoot the latency of receiving blocks or voting, and optimize in combination with Peer Latency. + +`chain_delay_block_send` and `chain_delay_block_mining` are related to validator mining and determine whether blocks are generated normally. + +## Recent Blocks + +Query the core process timestamp of the recent blocks. These are millisecond timestamps. + +```bash +# Grafana query statement +report_blocks{job=~"$jobs"} +``` + +This list can be used to troubleshoot problems and conduct detailed analysis of the performance of a certain validator. \ No newline at end of file diff --git a/docs/bnb-smart-chain/validator/evn/overview.md b/docs/bnb-smart-chain/validator/evn/overview.md new file mode 100644 index 0000000000..be2f6855ea --- /dev/null +++ b/docs/bnb-smart-chain/validator/evn/overview.md @@ -0,0 +1,34 @@ +--- +title: Overview - BSC EVN +--- +## Background + +After [Maxwell Hardfork](https://www.bnbchain.org/en/blog/bnb-chain-announces-maxwell-hardfork-bsc-moves-to-0-75-second-block-times), the block interval has be reduced to 0.75s, which is a huge improvement in user experience for BSC, and at the same time has greater performance requirements for the client's network, execution and other components. + +BSC introduced a new network layer optimization, Enhanced Validator Network, aka EVN. It is not a new P2P network, but based on the current P2P network to optimize the validator network and reduce the latency of core consensus messages as much as possible. You can also check [BEP-563](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP-563.md) and [BEP-564](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP-564.md) for more details. + +![evn topology](../../img/evn/evn-topology.png){:style="width:450px; height:auto; display: block; margin: 0 auto;"} + +## How EVN Works + +### NodeID Registration + +Node operator could add the validator’s EVN NodeIDs through the configuration file(config.toml), then the node will automatically sign a registration tx to register the node id on chain. + +It establishes the identity mapping from the consensus layer to the network layer. + +### EVN Peer Identification + +All validators/sentry will pull the on-chain registration information, identify whether the connected P2P Peer belongs to the NodeID of a validator, and mark it as an EVN Peer. + +### Broadcast Optimization + +Transaction broadcast is disabled between all EVN Peers, and mined blocks are broadcast to all connected EVN Peers. Non-mined blocks still use the old gossip broadcast mechanism. + +### EVN Whitelist + +This is an EVN whitelist that takes effect on this node. It will consider the whitelisted Peers to be EVN Peers as well and apply the EVN broadcast algorithm. + +### EVN Peer Connection + +Currently, EVN Peers are mainly connected directly through static nodes, allowing most EVN Peers to connect directly to each other. \ No newline at end of file diff --git a/docs/bnb-smart-chain/validator/mev/user-guide.md b/docs/bnb-smart-chain/validator/mev/user-guide.md index 6d5e07ea2b..2c5cd15178 100644 --- a/docs/bnb-smart-chain/validator/mev/user-guide.md +++ b/docs/bnb-smart-chain/validator/mev/user-guide.md @@ -20,12 +20,28 @@ Some DEX protocols or builder providers are keen to provide free protection feat | Role | Status and Comments | | ---------------------------- | ------------------------------------------------------------ | -| Free Privacy Protecting RPCs |
  • [Pancake Swap Private RPC](https://docs.pancakeswap.finance/products/pancakeswap-private-rpc)
  • [48 Club Private RPC](https://docs.48.club/privacy-rpc)
  • [Merkle Free BSC Private RPC](https://merkle.io/free-bsc-rpc)
| +| Free Privacy Protecting RPCs |
  • [Pancake Swap Private RPC](https://docs.pancakeswap.finance/products/pancakeswap-private-rpc)
  • [48 Club Private RPC](https://docs.48.club/privacy-rpc)
  • [Merkle Free BSC Private RPC](https://merkle.io/free-bsc-rpc)
  • [BlockRazor Private RPC with Refund](https://rpc.blockrazor.io/)
| + +### Builder Proxies + +The builder proxies act as a transaction broadcaster for builders. Instead of users' transactions being limited to a smaller set of pre-registered validators or specific builders, the proxies take each submitted transaction and broadcasts it to all registered builders across the network. This broader dissemination benefits users by significantly increasing the chances of their transaction being picked up by a builder and included in the next block, leading to faster transaction confirmation times. Furthermore, the increased competition among builders, who now have access to a larger pool of transactions, can potentially result in more efficient block construction and, indirectly, potentially lower transaction fees and improved censorship resistance for users. + +![img](../../img/mev/proxy.png) + +A transaction proxy sample code is built by NodeReal, You can find it in the open-source git repo here https://github.com/node-real/private-tx-sender + +| Builder Proxy | Associated Builders | Link | +|---|---|---| +| Blockrazor | 48Club, BloXroute, NodeReal | https://blockrazor.gitbook.io/blockrazor/builder/bsc +| Merkle | 48Club, BlockRazor | https://www.merkle.io/bsc-rpc + -Several wallets now offer built-in protection against malicious MEV (Miner Extractable Value) attacks, enhancing the security and fairness of users' transactions. This protection is often available as a feature that users can manually enable during their swap or trading activities. **Wallets with Manual MEV Protection:** +Several wallets now offer built-in protection against malicious MEV (Miner Extractable Value) attacks, enhancing the security and fairness of users' transactions. This protection is often available as a feature that users can manually enable during their swap or trading activities. + + - **Private Transaction Relays:** These relays hide transaction details from malicious actors, preventing them from front-running or sandwich attacking the user's trade. - **Specialized Builders:** Some wallets utilize builders that prioritize user protection and fair ordering of transactions, minimizing the potential for MEV exploitation. @@ -35,6 +51,9 @@ Several wallets now offer built-in protection against malicious MEV (Miner Extra | Wallet | Binance Web3 Wallet | Supported | [Binance Alpha tokens MEV Protection](https://www.binance.com/en/support/announcement/introducing-binance-alpha-discover-emerging-crypto-projects-c6499e95c15e408ca44ca5f6db975d4d) | | Wallet | OKX Wallet | Supported | [OKX Wallet Enable Swap MEV Protection](https://www.okx.com/help/okx-wallet-supports-flashbot-to-prevent-mev-attack) | | Wallet | TokenPocket Wallet | Supported | [TokenPocket Swap MEV Protection](https://help.tokenpocket.pro/en/security-knowledge/security-measure/mev-protection-tutorial) | +| Wallet | Safepal Wallet | Supported | [Safepal Swap MEV Protection](https://safepalsupport.zendesk.com/hc/en-us/articles/33892098077851-Use-SafePal-to-Protect-Your-Swaps-from-MEV-Attacks) | +| Wallet | Math Wallet | Supported | [Mathwallet Swap MEV Protection](https://blog.mathwallet.org/?p=4799) | + ## For Professional Traders and Service Providers @@ -59,9 +78,3 @@ You can check the number of validators integrated and the number of blocks of ea ![img](../../img/mev/mev-blocks-by-builders.png) -For those who are very sensitive to transaction confirmation time, to maximize the transaction speed, it is recommended to build a proxy to broadcast the transaction to multiple builders to **increase the transaction inclusion speed**. You need to build your own RPC proxy with multiple builder service providers. - -![img](../../img/mev/proxy.png) - -A transaction proxy sample code is built by NodeReal, You can find it in the open-source git repo here https://github.com/node-real/private-tx-sender - diff --git a/docs/bnb-smart-chain/validator/mev/validator-integration.md b/docs/bnb-smart-chain/validator/mev/validator-integration.md index 78a127d7f0..aade34521f 100644 --- a/docs/bnb-smart-chain/validator/mev/validator-integration.md +++ b/docs/bnb-smart-chain/validator/mev/validator-integration.md @@ -110,6 +110,7 @@ sections in the config.toml. Example: ```toml [Eth.Miner.Mev] Enabled = true # open bid receiving + GreedyMergeTx = true # merge local tx to the MEV bid block ValidatorCommission = 100 # validator claim 1% from block reward BidSimulationLeftOver = 50000000 # 50ms, the time left for bid simulation SentryURL = "http://bsc-mev-sentry.io" # it is used for the validator to access the sentry, it should be a private URL or IP:Port. diff --git a/docs/bnb-smart-chain/validator/overview.md b/docs/bnb-smart-chain/validator/overview.md index 2e7908b690..9f998733c3 100644 --- a/docs/bnb-smart-chain/validator/overview.md +++ b/docs/bnb-smart-chain/validator/overview.md @@ -44,9 +44,11 @@ Validator's rewards come from transaction fees and commission fees from delegato Let us also assume that the reward for a block is 100 BNB and that a certain validator has **20%** of self-bonded BNB and sets its commission rate to **20%**. These tokens do not go directly to the proposer. Instead, they are shared among validators and delegators. These **100 BNB** will be distributed according to each participant's stake: ``` -Commission: 80*20%= 16 BNB -Validator gets: 100\*20% + Commission = 36 BNB -All delegators get: 100\*80% - Commission = 64 BNB +Commission: 100 BNB × 20% = 20 BNB (goes directly to validator) +Remaining for All Delegators: 100 BNB - 20 BNB = 80 BNB (distributed proportionally) +Validator's Share of Remaining: 80 BNB × 20% = 16 BNB +Other Delegators' Share: 80 BNB × 80% = 64 BNB +Total Validator Reward: 20 BNB (commission) + 16 BNB (self-delegation share) = 36 BNB ``` The rewards for motivating validators to vote for Fast Finality also comes from transaction fees. The specific rules can refer to [BEP126](https://github.com/bnb-chain/BEPs/blob/master/BEPs/BEP126.md#43-reward) diff --git a/docs/bnb-smart-chain/validator/run-val.md b/docs/bnb-smart-chain/validator/run-val.md index 9f629ec2ba..a8920e30f3 100644 --- a/docs/bnb-smart-chain/validator/run-val.md +++ b/docs/bnb-smart-chain/validator/run-val.md @@ -8,17 +8,19 @@ title: Run BSC Validator - BNB Smart Chain ### Mainnet -- Instance Spec: Suggest r7a.4xlarge instance type on AWS. -- Memory: 64 GB -- Disk: **IMPORTANT** 4T GB, solid-state drive(SSD), gp3, 8k IOPS, 500 MB/S throughput, read latency <1ms (if start with snap sync, it will need NVMe SSD). -- Network Bandwidth: > 10 Gbps +- Instance Spec: + - Suggest i7i.8xlarge or i7ie.6xlarge instance type on AWS (better to disable HyperThread, which could have 10%+ performance gain). + - or other instance spec to meet >=400 mgasps +- Memory: 128 GB +- Disk: **IMPORTANT** 7TB, NVMe SSD, 40k IOPS, 500 MB/S throughput, read latency <1ms. +- Network Bandwidth: >= 512 Mbps ### Testnet - CPU: "AMD Gen 3 or newer" or "Intel Ice Lake or newer" - Memory: 16 GB - Disk: 1.5 TB, solid-state drive(SSD), gp3, 8k IOPS, 250 MB/S throughput. -- Network Bandwidth: > 2.5 Gbps +- Network Bandwidth: >= 128 Mbps ## Setup Validator Node @@ -135,10 +137,10 @@ There is a javascript in BSC repo to dump the slash status of each validator. ``` cd /cmd/jsutils # 1.To dump the slashes of the lates block: -node getslashcount.js --Rpc https://bsc-mainnet.nodereal.io/v1/454e504917db4f82b756bd0cf6317dce +node getslashcount.js --Rpc https://bsc-dataseed.bnbchain.org # 2.You may also specify the block number: -node getslashcount.js --Rpc https://bsc-mainnet.nodereal.io/v1/454e504917db4f82b756bd0cf6317dce --Num 39938351 +node getslashcount.js --Rpc https://bsc-dataseed.bnbchain.org --Num 39938351 ``` If your validator operates smoothly, you should expect minimal or even no penalties, known as "slashes," on a daily basis. Generally speaking, if your validator incurs more than three slashes within a single day, it would be prudent to investigate the cause for this anomaly. diff --git a/docs/showcase/img/1-open-settings-json.png b/docs/showcase/img/1-open-settings-json.png new file mode 100644 index 0000000000..f9ce5cc94b Binary files /dev/null and b/docs/showcase/img/1-open-settings-json.png differ diff --git a/docs/showcase/img/2-add-mcp-config.png b/docs/showcase/img/2-add-mcp-config.png new file mode 100644 index 0000000000..95baf50fb2 Binary files /dev/null and b/docs/showcase/img/2-add-mcp-config.png differ diff --git a/docs/showcase/img/3-start-mcp.png b/docs/showcase/img/3-start-mcp.png new file mode 100644 index 0000000000..affc18d1b5 Binary files /dev/null and b/docs/showcase/img/3-start-mcp.png differ diff --git a/docs/showcase/img/4-started-mcp.png b/docs/showcase/img/4-started-mcp.png new file mode 100644 index 0000000000..bb7fcdd0ec Binary files /dev/null and b/docs/showcase/img/4-started-mcp.png differ diff --git a/docs/showcase/img/5-launch-chat.png b/docs/showcase/img/5-launch-chat.png new file mode 100644 index 0000000000..22d9abc9a6 Binary files /dev/null and b/docs/showcase/img/5-launch-chat.png differ diff --git a/docs/showcase/img/6-select-agent.png b/docs/showcase/img/6-select-agent.png new file mode 100644 index 0000000000..c49494e688 Binary files /dev/null and b/docs/showcase/img/6-select-agent.png differ diff --git a/docs/showcase/img/7-query-chat.png b/docs/showcase/img/7-query-chat.png new file mode 100644 index 0000000000..d038495d8f Binary files /dev/null and b/docs/showcase/img/7-query-chat.png differ diff --git a/docs/showcase/img/8-prompt-for-mcp.png b/docs/showcase/img/8-prompt-for-mcp.png new file mode 100644 index 0000000000..7afc6bb1d1 Binary files /dev/null and b/docs/showcase/img/8-prompt-for-mcp.png differ diff --git a/docs/showcase/img/9-mcp-response.png b/docs/showcase/img/9-mcp-response.png new file mode 100644 index 0000000000..63c3fa56c4 Binary files /dev/null and b/docs/showcase/img/9-mcp-response.png differ diff --git a/docs/showcase/mcp/ask-ai-to-ide.md b/docs/showcase/mcp/ask-ai-to-ide.md new file mode 100644 index 0000000000..d765e8a04d --- /dev/null +++ b/docs/showcase/mcp/ask-ai-to-ide.md @@ -0,0 +1,105 @@ +--- +title: Integrate BNBChain Ask AI into your IDE +--- + +# Quick‑Start Tutorial + +Follow these steps to wire any IDE that supports the **Model Context Protocol (MCP)** to BNB Chain’s Ask AI knowledge base **and start querying documentation right away**. + +> **Time required:** ≈ 2 minutes +> **Prerequisites:** +> • IDE with an MCP client (e.g. VS Code MCP extension, Cursor ≥ 0.23.0, JetBrains plugin) + +--- + +## 1 Add the Ask AI MCP server + +1. Open your IDE’s **Settings / Preferences** and find the **MCP** section. +2. Choose **Add MCP server** (wording may vary). +3. Paste the JSON block below and save. + +```jsonc +{ + "mcpServers": { + "bnbchain-askai-mcp": { + "url": "https://mcp.inkeep.com/bnbchainorg/mcp", + "id": "cm9qsf01p00bss6016ry68oil" + } + } +} +``` + +4. Reload the IDE window if the MCP client does not restart automatically. + +A **Connected** status should now appear next to *bnbchain‑askai‑mcp*. + +--- + +## 2 What the MCP can do + +The Ask AI MCP lets you **query** BNB Chain’s public documentation corpus in natural language and receive the most relevant passages, with source links, inside your editor. +It is *read‑only* – no blockchain transactions are executed. + +--- + +## 3 Run queries inside your IDE + +Below are three common ways to interact with the Ask AI MCP once it is connected. + +### 3.1 Chat Panels (Copilot, Cursor Chat, etc.) + +1. Open your IDE’s AI/Chat pane (Copilot Chat, Cursor side‑chat, JetBrains AI Assistant…). +2. Locate the **agent / provider selector** at the top of the chat window. +3. Choose **bnbchain‑askai‑mcp**. +4. Ask questions in plain English – e.g. *“Summarise BEP‑20.”* + +> **Want a detailed step-by-step walkthrough for VS Code?** Check out the companion guide: [Ask AI in VS Code](ask-ai-vs-code-guide.md) – complete with annotated screenshots. + +### 3.2 Command Palette / Command Menu + +| IDE | How to open | Steps | +| ------------- | ----------------------------------------------------------- | ------------------------------------------------------------------------------ | +| **VS Code** | Ctrl/Cmd + Shift + P | Type **“MCP: Run Query”** → pick **bnbchain‑askai‑mcp** → enter your question. | +| **Cursor** | Cmd + K (mac) or Ctrl + K (win/linux) | Select **Ask MCP…** → choose **bnbchain‑askai‑mcp** → ask away. | +| **JetBrains** | Shift + Shift then “MCP Query” | Pick **bnbchain‑askai‑mcp** and type a question. | + +### 3.3 Terminal / cURL (optional) + +For quick tests outside the IDE you can hit the endpoint directly: + +```bash +curl -s -X POST \ + -H "Content-Type: application/json" \ + -d '{"query":"What is BEP‑20?"}' \ + https://mcp.inkeep.com/bnbchainorg/mcp +``` + +You’ll receive a JSON response containing an `answer` field and `sources` array. + +--- + +## 4 Example queries + +```text +What is the gas limit on BSC blocks? + +Summarise BEP‑336 in two sentences. + +List all fee tiers supported by opBNB. + +Explain the purpose of Greenfield buckets. +``` + +--- + +## 5 Troubleshooting + +| Symptom | Fix | +| -------------------------- | ---------------------------------------------------------------- | +| **400/401 response codes** | Verify the JSON snippet (no trailing commas). | +| **Long latency (> 10 s)** | Disable any *Throttle Streaming* or similar setting in your IDE. | +| **No answer returned** | Make sure you chose **bnbchain‑askai‑mcp** and asked a question. | + +Need more help? Ping us in **#ai‑tooling** on the BNB Chain Discord. + +Open an issue in the [docs repo](https://github.com/bnb-chain/docs-site/issues) if your favourite editor is missing. diff --git a/docs/showcase/mcp/ask-ai-vs-code-guide.md b/docs/showcase/mcp/ask-ai-vs-code-guide.md new file mode 100644 index 0000000000..79ca8c8f21 --- /dev/null +++ b/docs/showcase/mcp/ask-ai-vs-code-guide.md @@ -0,0 +1,105 @@ +--- +title: Ask AI in Visual Studio Code +--- + +Step‑by‑step walkthrough to query BNB Chain documentation from within VS Code using the Model Context Protocol (MCP). + +## 1 Install the MCP Client extension + +1. Open the **Extensions** view. +2. Search for **“MCP Client”** and hit **Install**. + +![VS Code Extensions view with MCP Client selected](/docs/showcase/img/1-open-settings-json.png) + +The extension adds MCP support to VS Code, letting you connect to external knowledge bases such as **BNB Chain Ask AI**. + +--- + +## 2 Add the Ask AI server + +1. Open **Settings** → **Preferences** → **Settings (JSON)**. + *Tip ▶* press Ctrl/⌘ +, then click the **`{}`** icon in the upper‑right corner. +2. Inside the JSON, locate (or create) the **`"mcpServers"`** section and paste the snippet below as a sibling property. + +```jsonc +"mcpServers": { + "bnbchain-askai-mcp": { + "url": "https://mcp.inkeep.com/bnbchainorg/mcp", + "id": "cm9qsf01p00bss6016ry68oil" + } +} +``` + +![Settings JSON with the Ask AI block added](/docs/showcase/img/2-add-mcp-config.png) + +3. Save the file. The MCP client should automatically reload; if not, restart the VS Code window. + +--- + +## 3 Start the MCP server + +Hover the new server block and click **▶ Start**. + +![Start badge before connection](/docs/showcase/img/3-start-mcp.png) + +When the badge flips to **✓ Running**, VS Code is now connected to **BNB Chain Ask AI**. + +![Server block indicating ✓ Running](/docs/showcase/img/4-started-mcp.png) + +--- + +## 4 Open the Chat panel + +From the menu bar choose **View → Chat** or press Ctrl + Alt + I. A chat window docks to the side of the editor. + +![Opening the Chat view from the View menu](/docs/showcase/img/5-launch-chat.png) + +--- + +## 5 Pick the **bnbchain‑askai‑mcp** agent + +At the bottom of the chat input you’ll find two dropdowns: + +* **Mode** (Ask / Edit / Agent) +* **Provider** (list of LLMs & MCP servers) + +Set **Mode** to **Agent**, then pick **bnbchain‑askai‑mcp** from the Provider list. + +![Dropdown showing Agent selected and bnbchain-askai-mcp highlighted](/docs/showcase/img/6-select-agent.png) + +--- + +## 6 Ask your first question + +1. Type a natural‑language query such as: + + ```text + What is BNB Greenfield? + ``` + + ![Chat input with sample question typed](/docs/showcase/img/7-query-chat.png) + +2. Press Enter. VS Code presents a confirmation card recommending the **bnbchain‑askai‑mcp** tool. + + ![Confirmation card asking to continue with the recommended MCP](/docs/showcase/img/8-prompt-for-mcp.png) + +3. Click **Continue** (or just press Enter again). Ask AI streams back a concise answer plus source links you can click to jump to the original docs. + + ![Answer streamed in the chat panel](/docs/showcase/img/9-mcp-response.png) + +--- + +## 7 Bonus: Command Palette quick‑queries + +Prefer keyboard? Hit Ctrl/⌘ + Shift + P, run **“MCP: Run Query”**, choose **bnbchain‑askai‑mcp**, and enter your question. + +This opens a transient results panel without leaving your current editor tab. + +--- + +### Need help? + +* Reach out on the BNB Chain Discord. +* File an issue in the [docs repo](https://github.com/bnb-chain/bnb-chain.github.io/issues). + +Happy building! 🎉 diff --git a/docs/showcase/mcp/index.md b/docs/showcase/mcp/index.md new file mode 100644 index 0000000000..891d307303 --- /dev/null +++ b/docs/showcase/mcp/index.md @@ -0,0 +1,63 @@ +--- +title: MCP - Model Context Protocol +--- + +# Model Context Protocol (MCP) + +The **Model Context Protocol** is an open interface that lets AI agents and developer tools share a rich execution context. In practice, that means you can: + +* Ask natural‑language questions about on‑chain data or documentation. +* Invoke blockchain‑aware tools (read‑only or state‑changing) without manual RPC calls. +* Plug the same back‑end into multiple IDEs, CLIs or chat front‑ends. + +> **Why use it?** +> *Unified access* – instantly switch between chat, code, and terminal workflows. +> *Extensibility* – add your own prompts & tools. +> *Open source* – fork, self‑host, or just `npx` it. + +--- + +## 1 Available MCP servers + +| Name | Endpoint / Install | Scope | Typical usage | +| ------------------------------------------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------- | +| [**bnbchain‑mcp**](https://github.com/bnb-chain/bnbchain-mcp) | `npx @bnb-chain/mcp@latest`
or self-host via Docker | Full toolkit: blocks, txs, wallets, Greenfield ops & more | Build, test, or automate on-chain actions from your IDE or scripts. | +| [**ask‑ai‑mcp**](./docs/showcase/mcp/ask-ai-to-ide.md) | `https://mcp.inkeep.com/bnbchainorg/mcp` | Read-only semantic search over BNB Chain docs, BEPs, blogs & FAQs | Quick answers in chat panes or command palettes. | + +Both servers speak the *same* MCP schema, so you can swap them in your settings with a single JSON change. + +--- + +## 2 What can MCP do? + +### Conversational queries + +```text +What is BEP‑20 and how does it differ from ERC‑20? +``` + +Answer arrives instantly with source links. + +### Tool execution (bnbchain‑mcp only) + +```text +get_block_by_number number=37000000 chain=bsc +``` + +Returns structured JSON for the requested block. Supply a `PRIVATE_KEY` to unlock write‑capable tools such as `transfer_erc20` or `write_contract`. + +### IDE‑agnostic integration + +* VS Code, Cursor, JetBrains: add a **servers.mcp** entry in settings → choose the agent in your chat panel. +* Terminal lovers: `curl` or your favourite HTTP client. +* Custom apps: import `@bnb-chain/mcp` as a library. + +--- + +## 3 Quick links & next steps + +* **GitHub – bnbchain‑mcp** – source, issues, self‑hosting guide: [https://github.com/bnb-chain/bnbchain-mcp](https://github.com/bnb-chain/bnbchain-mcp) +* **Ask AI Tutorial** – connect your IDE to the read‑only doc search endpoint: `ai/askai-tutorial.md` +* **AI Agent solution page** – see how MCP fits into BNB Chain’s broader AI strategy: [https://www.bnbchain.org/en/solutions/ai-agent](https://www.bnbchain.org/en/solutions/ai-agent) + +Have questions? Join **#ai‑tooling** on Discord or open a GitHub issue. PRs welcome! diff --git a/docs/showcase/tokenization/company-tokenization.md b/docs/showcase/tokenization/company-tokenization.md index 2e1ac7f72b..1037ab93c3 100644 --- a/docs/showcase/tokenization/company-tokenization.md +++ b/docs/showcase/tokenization/company-tokenization.md @@ -386,7 +386,7 @@ Once you have confirmed that all details are correct and finalized, press 'Confi ![](./company-tokenization-tutorial/Company Tokenization Tutorial 222.007.png) -This is the final step. You can review all the information one last time before submitting, after you have made sure that everything is perfect, or you can go back to the previous step to make any changes. Click “Approve” and "Confirm" on Metamask. After that, click "Submit". +This is the final step. You can review all the information one last time before submitting, after you have made sure that everything is perfect, or you can go back to the previous step to make any changes. Click “Approve” and "Confirm". After that, click "Submit". ##### Step 5: Check Your Presale Status @@ -683,7 +683,7 @@ You should ask your community members to give you their wallet address beforehan ![](./company-tokenization-tutorial/Company Tokenization Tutorial 4.005.png) -Click on “Add Allocations” when you are done inputting the addresses. MetaMask will now ask you to confirm the transaction. It will also show you the fee that you are required to pay for that transaction. If you agree, then click on the “Confirm” button to finish the process. +Click on “Add Allocations” when you are done inputting the addresses. The wallet will now ask you to confirm the transaction. It will also show you the fee that you are required to pay for that transaction. If you agree, then click on the “Confirm” button to finish the process. After successfully adding airdrop allocations, those allocations will be shown on the airdrop page. @@ -699,7 +699,7 @@ After clicking on “Set Vesting”, you will see a pop-up box. Below are some i ![](./company-tokenization-tutorial/Company Tokenization Tutorial 4.006.png) -Click on “Set Vesting” when you are done inputting the numbers, then MetaMask will now ask you to confirm the transaction. It will also show you the fee that you are required to pay for that transaction. If you agree, then click on the “Confirm” button to finish the process. +Click on “Set Vesting” when you are done inputting the numbers, then wallet will now ask you to confirm the transaction. It will also show you the fee that you are required to pay for that transaction. If you agree, then click on the “Confirm” button to finish the process. ##### Step 5: Start Airdrop diff --git a/docs/showcase/tokenization/nft-loyalty-programs.md b/docs/showcase/tokenization/nft-loyalty-programs.md index 29eab0bdc2..af0ab92726 100644 --- a/docs/showcase/tokenization/nft-loyalty-programs.md +++ b/docs/showcase/tokenization/nft-loyalty-programs.md @@ -42,7 +42,7 @@ We suggest these two service providers since they provide one-stop service with 1) **Connect your Wallet** Open NFTs2Me and select the “Connect Wallet” option. -Choose your wallet (e.g., MetaMask). The system will ask you to sign a message to verify account ownership. +Choose your wallet (e.g.,Turstwallet/MetaMask). The system will ask you to sign a message to verify account ownership. ![](./nft-loyalty-programs-tutorial/nfts2me09.jpg) @@ -94,7 +94,7 @@ Once the process is complete, a modal window will display all the information ab 1) **Connect your Wallet** Open Bitbond Token Tool and select the “Connect Wallet” option. -Choose your wallet (e.g., MetaMask). The system will ask you to sign a message to verify account ownership. +Choose your wallet (e.g., TrustWallet/MetaMask). The system will ask you to sign a message to verify account ownership. ![](./nft-loyalty-programs-tutorial/Create NFT 2.png) diff --git a/docs/showcase/tokenization/rwa-tokenization.md b/docs/showcase/tokenization/rwa-tokenization.md index 6514d524ea..92b90a8cc0 100644 --- a/docs/showcase/tokenization/rwa-tokenization.md +++ b/docs/showcase/tokenization/rwa-tokenization.md @@ -84,11 +84,11 @@ After you have successfully completed the asset preparation and account preparat Service providers you may choose: - Bitbond ( ) -- Brikken ( ) +- Brickken ( ) ### 3.1 Brickken -1) Go to the Token Suite sign up page and sigh up using your email account. +1) Go to the Token Suite sign up page and sigh up using your email account. ![](./rwa-tokenization-tutorial/RWA Tokenization Tutorial 2.001.png) @@ -189,7 +189,7 @@ In order to distribute your token toward your investors, you need to launch your Service providers you may choose: - Bitbond ( ) -- Brikken ( ) +- Brickken ( ) ### 4.1 Brickken diff --git a/docs/zkbnb/core-concept/overview.md b/docs/zkbnb/core-concept/overview.md deleted file mode 100644 index 8cd54a3a8a..0000000000 --- a/docs/zkbnb/core-concept/overview.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Overview - zkBNB Core Concepts ---- - -## Key Features - -### Digital Asset Management -The zkBNB will serve as an alternative marketplace for issuing, using, paying and exchanging digital assets in a -decentralized manner. zkBNB and BSC share the same token universe for BNB, BEP2 and NFT tokens. This defines: -- The same token can circulate on both networks, and flow between them bi-directionally via L1 <\> L2 communication. -- The total circulation of the same token should be managed across the two networks, i.e. the total effective supply - of a token should be the sum of the token's total effective supply on both BSC and BC. -- The tokens can only be initially created on BSC in BEP20, then pegged to the zkBNB. It is permissionless to peg token onto zkBNB. - -User can **deposit, transfer, and withdraw** both non-fungible token and fungible token on zkBNB. - -Users enter the zk-rollup by **depositing tokens** in the rollup's contract deployed on the BSC. The zkBNB monitor will track deposits and submit it as a layer2 transaction, once committer verifies the transaction, users get funds on their account, they can start transacting by sending transactions to the committer for processing. - -User can **transfer** any amount of funds to any existed accounts on zkBNB by sending a signed transaction to the network. - -**Withdrawing** from zkBNB to BSC is straightforward. The user initiates the withdrawal transaction, the fund will be -burned on zkBNB. Once the transaction in the next batch been rolluped, a related amount of token will be unlocked from -rollup contract to target account. - -### NFT Management and Marketplace -We target to provide an opensource NFT marketplace for users to browse, buy, sell or create their own NFT. -The meta-data of NFT on zkBNB sticks to the [BSC standard](https://docs.bnbchain.org/docs/nft-metadata-standard/). -The ERC721 standard NFT can be seamlessly deposited on zkBNB, or in reverse. - -![Marketplace framework](../static/NFT_Marketplace.png) - -Above diagram shows the framework of Nft Marketplace and zkBNB. All the buy/sell offer, meta-data of NFT/Collection, -medium resources, account profiles are store in the backend of NFT marketplace, only the **contendHash**, -**ownership**, **creatorTreasuryRate** and few other fields are recorded on zkBNB. To encourage price discovery, anyone -can place buy/sell offer in the marketplace without paying any fees since the offer is cached in the backend instead of -being sent to the zkBNB. Once the offer is matched, an **AtomicMatch** transaction that consist of buy and sell offer -will be sent to zkBNB to make the trade happen. Users can also cancel an offer manually by sending a cancel offer -transaction to disable the backend cached offer. - -### Seamless L1 Wallet Management -zkBNB natively supports ECDSA signatures and follows [EIP712](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-712.md) signing structure, which means most of the Ethereum wallets can seamless support zkBNB. There is no extra effort for BSC users to leverage zkBNB. diff --git a/docs/zkbnb/core-concept/zkbnb-arch.md b/docs/zkbnb/core-concept/zkbnb-arch.md deleted file mode 100644 index 9df323cd07..0000000000 --- a/docs/zkbnb/core-concept/zkbnb-arch.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -title: zkBNB Architecture - zkBNB ---- - -# zkBNB Architecture - -zkBNB is a zero-knowledge scalability solution, or L2, which focuses on straightforward token operations and built-in marketplaces for Gaming and Social use cases. It serves as a scalability solution for the BNB Smart Chain by bundling multiple transactions into a single transaction, reducing costs for on-chain transactions. The Zero Knowledge proof system used in zkBNB ensures a much faster finality time of the L2 transactions, that helps improve the user experience. zkBNB is essentially built on the zk-Rollup architecture. - -## zk-Rollup Architecture - -![Framework](../static/Frame_work.png) - -- **committer**. Committer executes transactions and produce consecutive blocks. -- **monitor**. Monitor tracks events on BSC, and translates them into **transactions** on zkBNB. -- **witness**. Witness re-executes the transactions within the block and generates witness materials. -- **prover**. Prover generates cryptographic proof based on the witness materials. -- **sender**. The sender rollups the compressed l2 blocks to L1, and submit proof to verify it. -- **api server**. The api server is the access endpoints for most users, it provides rich data, including - digital assets, blocks, transactions, gas fees. -- **recovery**. A tool to recover the sparse merkle tree in kv-rocks based on the state world in postgresql. - -## Maximum throughput -Pending benchmark... - -## Data Availability - -zkBNB publish state data for every transaction processed off-chain to BSC. With this data, it is possible for -individuals or businesses to reproduce the rollup’s state and validate the chain themselves. BSC makes this data -available to all participants of the network as calldata. - -zkBNB don't need to publish much transaction data on-chain because validity proofs already verify the authenticity -of state transitions. Nevertheless, storing data on-chain is still important because it allows permissionless, -independent verification of the L2 chain's state which in turn allows anyone to submit batches of transactions, -preventing malicious committer from censoring or freezing the chain. - -zkBNB will provide a default client to replay all state on Layer2 based on these call data. - -## Transaction Finality - -BSC acts as a settlement layer for zkBNB: L2 transactions are finalized only if the L1 contract accepts the validity -proof and execute the txs. This eliminates the risk of malicious operators corrupting the chain -(e.g., stealing rollup funds) since every transaction must be approved on Mainnet. Also, BSC guarantees that user -operations cannot be reversed once finalized on L1. - -zkBNB provides relative fast finality speed within 10 minutes. - -## Instant confirmation ZkBS - -Even though time to finality is about 10 minutes, it does not affect the usability of the network. The state transition -happens immediately once the block been proposed on zkBNB. The rollup operations are totally transparent to most users, -users can make further transfers without waiting. - -## Censorship resistance - -Committer will execute transactions, produce batches. While this ensures efficiency, it increases the risk of censorship -:malicious zk-rollup committer can censor users by refusing to include their transactions in batches. - -As a security measure, zkBNB allow users to submit transactions directly to the rollup contract on Mainnet if -they think they are being censored by the operator. This allows users to force an exit from the zk-rollup to BSC without -having to rely on the commiter's permission. diff --git a/docs/zkbnb/index.md b/docs/zkbnb/index.md deleted file mode 100644 index 317ec7e849..0000000000 --- a/docs/zkbnb/index.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -hide: -- toc - -title: zkBNB ---- - - - -
-
-

zkBNB

-

zkBNB is the launchpad to achieve infinite scaling for all things Web3 and GameFi. It offers incredible scalability, Layer-1 level security, and frictionless developer experience to build dApps that can onboard the next billion users.

-
-
- zkBNB -
-
- - - -
- -
Architecture
-

zkBNB is a zero-knowledge scalability solution

- - -
Resources
-

Providing a Wealth of Resources for Building zkBNB

- -
diff --git a/docs/zkbnb/overview.md b/docs/zkbnb/overview.md deleted file mode 100644 index c460c32cff..0000000000 --- a/docs/zkbnb/overview.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -title: zkBNB Overview - zkBNB ---- - -# What is zkBNB? -The zkBNB 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. - -zkBNB is built on zk-Rollup architecture. zkBNB bundle (or "roll-up") hundreds of transactions off-chain and generates cryptographic proof. These proofs can come in the form of SNARKs (succinct non-interactive argument of knowledge) which can prove the validity of every single transaction in the Rollup Block. - -## Problems zkBNB solves -Today BSC is experiencing network scalability problems and the core developer has proposed to use sidechains in their [Outlook 2022](https://forum.bnbchain.org/t/bsc-development-outlook-2022/44) paper to solve this problem because these sidechains can be designed for much higher throughput and lower gas fees. - -The [BEP100](https://github.com/bnb-chain/BEPs/pull/132/files) propose a modular framework for creating BSC-compatible side chains and connect them by native relayer hub. The security of native relayer hub is guaranteed by the side chain. - -According to [the analysis](https://blog.chainalysis.com/reports/cross-chain-bridge-hacks-2022/) of chainalysis, bridges are now a top target for the hackers and attacks on bridges account for 69% of total funds stolen in 2022. zkBNB can perfectly solve the problem! Thanks to zkSNARK proofs, zkBNB share the same security as BSC does. - -## What are the key features of zkBNB? - -BNB achieves the following goals: - -- **L1 security:** The zkBNB share the same security as BSC does. Thanks to zkSNARK proofs, the security is guaranteed by cryptographic. Users do not have to trust any third parties or keep monitoring the Rollup blocks in order to prevent fraud. - -- **L1<\>L2 Communication:** BNB, BEP20, BEP721 tokens can flow freely between BSC and zkBNB through our built-in bridging platform. - -_(BEP721 token must be created in zkBNB in order to transfer from L1 to L2)_ - -- **Built-in NFT marketplace:** Users can launch their NFT collections to their communities safely and securely on zkBNB’s built-in marketplace and store them in IPFS or GreenField. zkBNB provides a set of powerful REST APIs. New developers operating in the space will no longer need to interact directly with smart contracts or worry about security. Rich Functions, such as supporting GreenField and supporting modifiable NFT. - -- **Fast transaction speed and faster finality:** zkBNB puts up astonishing figures with an ability to support up to 4 billion addresses, 5k transactions per second (TPS), and minute level finality in the best case. - -- **Low gas fee:** The gas token on the zkBNB can be either BEP20 or BNB. - -- **"Full exit" on BSC:** At any time, a user can request an exit operation to withdraw funds. This means users can withdraw funds at any time within a few minutes. Even zkBNB stops running, user can still safely withdraw all assets. Each collection of NFTs will be withdrawn into a segregated smart contract. - -_**Note:** Full Exit and Exodus Exit are two different types of functionalities on zkBNB. Full exit is just about user can click a button and withdraw all his assets in one go. Exodus exit is about in emergency situation, say the whole zkBNB is down, user can still withdraw all this assets._ diff --git a/docs/zkbnb/resources.md b/docs/zkbnb/resources.md deleted file mode 100644 index ea5e098678..0000000000 --- a/docs/zkbnb/resources.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Resources - zkBNB ---- - -# Resources - -## 📔 Repos - -- [zkBNB Infra](https://github.com/bnb-chain/zkbnb) -- [zkBNB Smart Contract](https://github.com/bnb-chain/zkbnb-contract) - - -## 👨‍🔧 Building Dapps on zkBNB - -Start building dapps to create value based on the data assets and their related economy. -- Fund your zkBNB Wallet (_**Coming Soon**_⏰) -- Build a dapp with zkBNB API (_**Coming Soon**_⏰) - -## 🙋‍♀️ Help & Support -Check out the zkBNB Developer Discord for technical support. (**_TBA_** 📢) diff --git a/docs/zkbnb/static/Frame_work.png b/docs/zkbnb/static/Frame_work.png deleted file mode 100644 index 1738aab0be..0000000000 Binary files a/docs/zkbnb/static/Frame_work.png and /dev/null differ diff --git a/docs/zkbnb/static/NFT_Marketplace.png b/docs/zkbnb/static/NFT_Marketplace.png deleted file mode 100644 index 6a8eb3ebfd..0000000000 Binary files a/docs/zkbnb/static/NFT_Marketplace.png and /dev/null differ diff --git a/docs/zkbnb/static/zkBNB.png b/docs/zkbnb/static/zkBNB.png deleted file mode 100644 index fa8c8b245a..0000000000 Binary files a/docs/zkbnb/static/zkBNB.png and /dev/null differ diff --git a/mkdocs.yml b/mkdocs.yml index b264939ca4..84288a848a 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -62,7 +62,8 @@ nav: - Announcements: - Announcements: ./announce/index.md - Upcoming: - - Greenfield Savanna Hardfork: ./announce/savanna-greenfield.md + - Maxwell Hardfork(BSC): ./announce/maxwell-bsc.md + - Volta Upgrade of opBNB: ./announce/volta-opbnb.md - Passed: - Fjord Hardfork(opBNB): ./announce/fjord-opbnb.md @@ -79,6 +80,10 @@ nav: - Bohr Hardfork(BSC): ./announce/bohr-bsc.md - Altai Hardfork(Gnfd): ./announce/altai-gnfd.md - Final Sunset of BC (Mainnet): ./announce/final-sunset-bc-mainnet.md + - Greenfield Savanna Hardfork: ./announce/savanna-greenfield.md + - Pascal Hardfork(BSC): ./announce/pascal-bsc.md + - Lorentz Hardfork(BSC): ./announce/lorentz-bsc.md + - BNB Smart Chain: - BNB Smart Chain: ./bnb-smart-chain/index.md - Overview: ./bnb-smart-chain/overview.md @@ -97,10 +102,10 @@ nav: - Full Node: ./bnb-smart-chain/developers/node_operators/full_node.md - Archive Node: ./bnb-smart-chain/developers/node_operators/archive_node.md - Fast Node: ./bnb-smart-chain/developers/node_operators/fast_node.md - - Insfrastructure & Setup: + - Insfrastructure & Setup: - Boot Node: ./bnb-smart-chain/developers/node_operators/boot_node.md - Docker Image: ./bnb-smart-chain/developers/node_operators/docker.md - - Maintenance & Upgrades: + - Maintenance & Upgrades: - Upgrade Geth: ./bnb-smart-chain/developers/node_operators/upgrade_geth.md - Node Maintenance: ./bnb-smart-chain/developers/node_operators/node_maintenance.md - EOA Paymaster: @@ -108,7 +113,6 @@ nav: - Paymaster API Spec: ./bnb-smart-chain/developers/paymaster/paymaster-api.md - Wallet Integration: ./bnb-smart-chain/developers/paymaster/wallet-integration.md - Try Gasless Transaction: ./bnb-smart-chain/developers/paymaster/wallet-demo.md - - Staking: - Overview: ./bnb-smart-chain/staking/overview.md - User Guide: ./bnb-smart-chain/staking/user-guide.md @@ -131,10 +135,18 @@ nav: - Builder Guide: ./bnb-smart-chain/validator/mev/builder-integration.md - User Guide: ./bnb-smart-chain/validator/mev/user-guide.md - FAQs: ./bnb-smart-chain/validator/mev/faqs.md + - EVN: + - Overview: ./bnb-smart-chain/validator/evn/overview.md + - Best Practice: ./bnb-smart-chain/validator/evn/best-practice.md + - Network Monitor: ./bnb-smart-chain/validator/evn/network-monitor.md + - FAQs: ./bnb-smart-chain/validator/evn/faqs.md - Slashing: - Overview: ./bnb-smart-chain/slashing/overview.md - Slash Rules: ./bnb-smart-chain/slashing/slash-rules.md - Slash Monitor: ./bnb-smart-chain/slashing/monitor.md + - Cross Chain Bridge: ./bnb-smart-chain/cross-chain-bridge.md + - Benchmark: ./bnb-smart-chain/benchmark/design-reference.md + - FAQ: ./bnb-smart-chain/faq/index.md - opBNB: - opBNB: ./bnb-opbnb/index.md - Overview: ./bnb-opbnb/overview.md @@ -168,7 +180,8 @@ nav: - Node Best Practices: ./bnb-opbnb/advanced/node-best-practices.md - Local Node: ./bnb-opbnb/advanced/local-node.md - Run with PebbleDB and PBSS: ./bnb-opbnb/advanced/run-with-pebbledb-and-pbss.md - - Reth Node: ./bnb-opbnb/advanced/reth-node.md + - Run your own opBNB on BSC: ./bnb-opbnb/advanced/run-your-own-l2-with-opbnb.md + - FAQs: - Protocol FAQs: ./bnb-opbnb/faq/protocol-faqs.md - Gas and Fees FAQs: ./bnb-opbnb/faq/gas-and-fees-faqs.md @@ -268,14 +281,10 @@ nav: - Roadmap: - Roadmap: ./bnb-greenfield/roadmap/roadmap.md - Feature Lists: ./bnb-greenfield/roadmap/features.md - - zkBNB: - - zkBNB: ./zkbnb/index.md - - Overview: ./zkbnb/overview.md - - Core Concepts: - - Overview: ./zkbnb/core-concept/overview.md - - Architecture: ./zkbnb/core-concept/zkbnb-arch.md - - Resources: ./zkbnb/resources.md - Showcases: + - AI: + - Overview: ./showcase/mcp/index.md + - Integrating AskAI: ./showcase/mcp/ask-ai-to-ide.md - Name Service and Attestation: - Decentralized Identity: ./showcase/identity/did.md - Decentralized Name Service: @@ -298,7 +307,7 @@ nav: - BNB Chain Fusion: - BNB Chain Fusion: ./bc-fusion/index.md - Overview: ./bc-fusion/overview.md - - Post Fustion: + - Post Fusion: - Merkle Proof Verification: ./bc-fusion/post-fusion/merkle-tree-verify.md - Token Recovery: ./bc-fusion/post-fusion/token-recovery.md - FAQ: ./bc-fusion/post-fusion/faq.md @@ -646,54 +655,7 @@ plugins: 'opbnb-docs/docs/tutorials/run-nodes-best-practices.md': 'bnb-opbnb/overview.md' 'opbnb-docs/docs/tutorials/running-a-local-development-environment.md': 'bnb-opbnb/overview.md' 'opbnb-docs/docs/tutorials/running-a-local-node.md': 'bnb-opbnb/overview.md' - 'zkBNB-docs/docs/faqs/asset-management.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/faqs/contract.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/faqs/gas-and-fees.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/faqs/minting-and-royalities.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/faqs/onboarding.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/faqs/platform.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/faqs/tokenomics.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/faqs/zkbnb-faqs.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/build-on-zkbnb/deposit-to-zkbnb.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/build-on-zkbnb/developer-tools.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/build-on-zkbnb/hardware-reqs.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/build-on-zkbnb/network-faucet.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/build-on-zkbnb/resources.md': 'zkbnb/resources.md' - 'zkBNB-docs/docs/guide/build-on-zkbnb/software-reqs.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/build-on-zkbnb/zkbnb-api-example.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/contact-us.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/core-concepts/overview.md': "zkbnb/core-concept/overview.md" - 'zkBNB-docs/docs/guide/core-concepts/protocol.md': "zkbnb/core-concept/overview.md" - 'zkBNB-docs/docs/guide/core-concepts/zkbnb-arch.md': 'zkbnb/core-concept/zkbnb-arch.md' - 'zkBNB-docs/docs/guide/economics/gas-and-fees.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/economics/tokenomics.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/introduction/fee-structure.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/introduction/getting-started.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/introduction/overview.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/introduction/tech-zkBNB.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/introduction/usage-zkBNB.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/storage/storage-layout.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/troubleshooting/common-errors.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/tutorials/fund-zkbnb-wallet.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/tutorials/nft-minting.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/zkbnb-marketplace/create-collections.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/zkbnb-marketplace/create-nfts.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/zkbnb-marketplace/deposit-bnb.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/zkbnb-marketplace/overview.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/zkbnb-wallet/get-test-tokens.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/zkbnb-wallet/overview.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/guide/zkbnb-wallet/wallet-configuration.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/sdks/tutorials/index.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/sdks/tutorials/reactjs-integration-example/index.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/sdks/zkbnb-go-sdk/changelog.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/sdks/zkbnb-go-sdk/quickstart.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/sdks/zkbnb-js-sdk/changelog.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/sdks/zkbnb-js-sdk/quickstart.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/sdks/zkbnb-sdks.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/sdks/zkbnb-ts-sdk/changelog.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/sdks/zkbnb-ts-sdk/quickstart.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/sdks/zkbnb-web-sdk/changelog.md': 'zkbnb/overview.md' - 'zkBNB-docs/docs/sdks/zkbnb-web-sdk/quickstart.md': 'zkbnb/overview.md' + extra_css: - https://fonts.googleapis.com/css2?family=Space+Grotesk:wght@300..700&display=swap @@ -705,17 +667,19 @@ extra_css: - assets/style/components/footer-nav.css - assets/style/components/footer.css - https://unpkg.com/katex@0.16.10/dist/katex.min.css + - assets/style/components/ai-bot-button.css extra_javascript: - assets/js/mathjax.js - assets/js/custom.js - - https://unpkg.com/mathjax@3.2.2/es5/tex-mml-chtml.js - - https://unpkg.com/katex@0.16.10/dist/katex.min.js - - https://unpkg.com/katex@0.16.10/dist/contrib/auto-render.min.js + - assets/js/inkeep-custom-button.js + - assets/js/footer-menu.js extra: generator: false homepage: https://www.bnbchain.org + analytics: + provider: custom consent: title: Cookie consent description: >- diff --git a/overrides/main.html b/overrides/main.html index 31fbc2c521..961ff50544 100644 --- a/overrides/main.html +++ b/overrides/main.html @@ -20,51 +20,19 @@ {% block footer %} {% include "partials/footer.html" %} -
-
-
-
Explore
- -
-
-
Build
- -
-
-
Participate
- -
-
-
About
- -
-
-
-
-
- © 2024 Bnbchain.org. All rights reserved. -
+
+
{% endblock %} + +{% block scripts %} +{{ super() }} + + + +{% endblock %} diff --git a/overrides/partials/footer.html b/overrides/partials/footer.html new file mode 100644 index 0000000000..38c68e55a0 --- /dev/null +++ b/overrides/partials/footer.html @@ -0,0 +1,12 @@ + diff --git a/overrides/partials/integrations/analytics/custom.html b/overrides/partials/integrations/analytics/custom.html new file mode 100644 index 0000000000..3dc12d54a4 --- /dev/null +++ b/overrides/partials/integrations/analytics/custom.html @@ -0,0 +1,7 @@ + + +