diff --git a/public/locales/en/translation.json b/public/locales/en/translation.json index 3b90f3921..eccefa502 100644 --- a/public/locales/en/translation.json +++ b/public/locales/en/translation.json @@ -57,25 +57,6 @@ } }, "sidebar": { - "gettingStarted": { - "gettingStarted": "Getting Started", - "overview": "Overview", - "scrollSepoliaTestnet": "Scroll Sepolia Testnet", - "userGuide": "User Guide", - "setup": "Setup", - "faucet": "Faucet", - "bridge": "Bridge", - "transferTokens": "Transfer Tokens", - "commonErrors": "Common Errors", - "rollupExplorer": "Rollup Explorer", - "scrollSepoliaBlockExplorer": "Scroll Sepolia Explorer", - "scrollMainnet": "Scroll Mainnet", - "scrollscan": "Scrollscan Block Explorer", - "sepoliaBlockExplorer": "Sepolia Explorer", - "community": "Community", - "discord": "Discord", - "communityForum": "Community Forum" - }, "developers": { "developers": "Developers", "buildingOnScroll": "Building on Scroll", @@ -150,46 +131,16 @@ "security": "Security", "auditsAndBugBounty": "Audits & Bug Bounty", "l2BeatAssessment": "L2Beat Assessment", + "feynmanUpgrade": "Feynman Upgrade", "euclidUpgrade": "Euclid Upgrade", "darwinV2Upgrade": "Darwin v2 Upgrade", "darwinUpgrade": "Darwin Upgrade", "curieUpgrade": "Curie Upgrade", "bernoulliUpgrade": "Bernoulli Upgrade" }, - "learn": { - "ethereumAndProtocols": "Ethereum & Protocols", - "theScalabilityProblem": "The Scalability Problem", - "introToRollups": "Intro to Rollups", - "zeroKnowledge": "Zero Knowledge", - "introToZeroKnowledge": "Intro to Zero Knowledge", - "polynomialCommitmentSchemes": "Polynomial Commitment Schemes", - "kzgCommitmentScheme": "KZG Commitment Scheme", - "additionalResources": "Additional Resources" - }, - "sdk": { - "overview": "Overview", - "scrollSdk": "Scroll SDK Introduction", - "faq": "Scroll SDK FAQ", - "technicalStack": "Technical Stack", - "stackOverview": "Stack Overview", - "configuration": "Configuration", - "services": "Services", - "smartContracts": "Smart Contracts", - "proofGeneration": "Proof Generation", - "integrations": "Integrations", - "guides": "Guides", - "devnetDeployment": "Devnet Deployment", - "productionDeployment": "Production Deployment", - "digitalOcean": "Digital Ocean & ERC20 Gas Token Testnet", - "customizingSdkComponents": "Customizing SDK Components", - "awsDeployment": "AWS Deployment", - "operation": "Operating a Chain", - "contractsVerification": "Contracts Verification", - "gasAndFees": "Gas & Fee Management", - "monitoring": "Monitoring", - "security": "Security and Recovery", - "upgrades": "Upgrading", - "troubleshooting": "Troubleshooting" + "community": { + "community": "Community", + "faq": "Community FAQ" } }, "footer": { diff --git a/src/assets/images/developers/getting-started/wagmi-demo.png b/src/assets/images/developers/getting-started/wagmi-demo.png deleted file mode 100644 index 49e97f216..000000000 Binary files a/src/assets/images/developers/getting-started/wagmi-demo.png and /dev/null differ diff --git a/src/assets/svgs/home/home-learn.svg b/src/assets/svgs/home/home-learn.svg deleted file mode 100644 index b2ed73cba..000000000 --- a/src/assets/svgs/home/home-learn.svg +++ /dev/null @@ -1,9 +0,0 @@ - - - - - - - - - diff --git a/src/assets/svgs/home/home-sdk.svg b/src/assets/svgs/home/home-sdk.svg deleted file mode 100644 index d63c492c7..000000000 --- a/src/assets/svgs/home/home-sdk.svg +++ /dev/null @@ -1,3 +0,0 @@ - - - \ No newline at end of file diff --git a/src/config/menu.ts b/src/config/menu.ts index 7b426a6a3..e5e1737ce 100644 --- a/src/config/menu.ts +++ b/src/config/menu.ts @@ -8,44 +8,20 @@ type MenuItems = Record export const MENU: MenuItems = { en: [ - { - text: "Getting Started", - link: "/en/getting-started/overview", - section: "gettingStarted", - }, { text: "Developers", link: "/en/developers", section: "developers" }, { text: "Technology", link: "/en/technology", section: "technology" }, - { text: "Learn", link: "/en/learn", section: "learn" }, - { text: "SDK", link: "/en/sdk", section: "sdk" }, + { text: "Community", link: "/en/community/faq", section: "community" }, ], zh: [ - { - text: "入门", - link: "/zh/getting-started/overview", - section: "gettingStarted", - }, { text: "开发者", link: "/zh/developers", section: "developers" }, { text: "技术", link: "/zh/technology", section: "technology" }, - { text: "学习", link: "/zh/learn", section: "learn" }, ], es: [ - { - text: "¿Cómo empezar?", - link: "/es/getting-started/overview", - section: "gettingStarted", - }, { text: "Desarrolladores", link: "/es/developers", section: "developers" }, { text: "Tecnología", link: "/es/technology", section: "technology" }, - { text: "Aprende", link: "/es/learn", section: "learn" }, ], tr: [ - { - text: "Başla", - link: "/tr/getting-started/overview", - section: "gettingStarted", - }, { text: "Geliştiriciler", link: "/tr/developers", section: "developers" }, { text: "Teknoloji", link: "/tr/technology", section: "technology" }, - { text: "Öğren", link: "/tr/learn", section: "learn" }, ], } diff --git a/src/config/sidebar.ts b/src/config/sidebar.ts index 9819e1936..3531f28db 100644 --- a/src/config/sidebar.ts +++ b/src/config/sidebar.ts @@ -4,83 +4,12 @@ const formatUrl = (url) => `${i18next.language}/${url}` export const getSidebar = () => { return { - gettingStarted: [ - { - section: t("sidebar.gettingStarted.gettingStarted"), - contents: [ - { - title: t("sidebar.gettingStarted.overview"), - url: "getting-started/overview", - }, - { - title: t("sidebar.gettingStarted.userGuide"), - url: formatUrl("user-guide/"), - children: [ - { - title: t("sidebar.gettingStarted.setup"), - url: formatUrl("user-guide/setup"), - }, - { - title: t("sidebar.gettingStarted.faucet"), - url: formatUrl("user-guide/faucet"), - }, - { - title: t("sidebar.gettingStarted.bridge"), - url: formatUrl("user-guide/bridge"), - }, - { - title: t("sidebar.gettingStarted.transferTokens"), - url: formatUrl("user-guide/transfer-tokens"), - }, - { - title: t("sidebar.gettingStarted.commonErrors"), - url: formatUrl("user-guide/common-errors"), - }, - ], - }, - ], - }, - { - section: t("sidebar.gettingStarted.scrollSepoliaTestnet"), - contents: [ - { - title: t("sidebar.gettingStarted.scrollSepoliaBlockExplorer"), - url: "https://sepolia.scrollscan.com/", - }, - { title: t("sidebar.gettingStarted.sepoliaBlockExplorer"), url: "https://sepolia.etherscan.io/" }, - { title: t("sidebar.gettingStarted.rollupExplorer"), url: "https://sepolia.scroll.io/rollupscan" }, - ], - }, - { - section: t("sidebar.gettingStarted.scrollMainnet"), - contents: [ - { - title: t("sidebar.gettingStarted.scrollscan"), - url: "https://scrollscan.com/", - }, - { title: t("sidebar.gettingStarted.rollupExplorer"), url: "https://scroll.io/rollupscan" }, - ], - }, - { - section: t("sidebar.gettingStarted.community"), - contents: [ - { - title: t("sidebar.gettingStarted.discord"), - url: "https://discord.gg/scroll", - }, - { - title: t("sidebar.gettingStarted.communityForum"), - url: "https://community.scroll.io/", - }, - ], - }, - ], developers: [ { section: t("sidebar.developers.developers"), contents: [ - { title: t("sidebar.developers.buildingOnScroll"), url: formatUrl("developers") }, - { title: t("sidebar.developers.faq"), url: formatUrl("developers/faq") }, + { title: t("sidebar.developers.faq"), url: formatUrl("developers") }, + { title: t("sidebar.developers.buildingOnScroll"), url: formatUrl("developers/building-on-scroll") }, { title: t("sidebar.developers.scrollContracts"), url: formatUrl("developers/scroll-contracts"), @@ -200,6 +129,10 @@ export const getSidebar = () => { title: t("sidebar.technology.scrollUpgrades"), url: formatUrl("technology/overview/scroll-upgrades"), children: [ + { + title: t("sidebar.technology.feynmanUpgrade"), + url: formatUrl("technology/overview/scroll-upgrades/feynman-upgrade"), + }, { title: t("sidebar.technology.euclidUpgrade"), url: formatUrl("technology/overview/scroll-upgrades/euclid-upgrade"), @@ -327,136 +260,13 @@ export const getSidebar = () => { ], }, ], - learn: [ - { - section: t("sidebar.learn.ethereumAndProtocols"), - contents: [ - { - title: t("sidebar.learn.theScalabilityProblem"), - url: "learn/the-scalability-problem", - }, - { - title: t("sidebar.learn.introToRollups"), - url: "learn/intro-to-rollups", - }, - ], - }, - { - section: t("sidebar.learn.zeroKnowledge"), - contents: [ - { - title: t("sidebar.learn.introToZeroKnowledge"), - url: formatUrl("learn/zero-knowledge/introduction-to-zero-knowledge"), - }, - { - title: t("sidebar.learn.polynomialCommitmentSchemes"), - url: formatUrl("learn/zero-knowledge/polynomial-commitment-schemes"), - }, - { - title: t("sidebar.learn.kzgCommitmentScheme"), - url: formatUrl("learn/zero-knowledge/kzg-commitment-scheme"), - }, - { - title: t("sidebar.learn.additionalResources"), - url: formatUrl("learn/zero-knowledge/additional-zk-learning-resources"), - }, - ], - }, - ], - sdk: [ - { - section: t("sidebar.sdk.overview"), - contents: [ - { - title: t("sidebar.sdk.scrollSdk"), - url: "sdk/", - }, - { - title: t("sidebar.sdk.faq"), - url: "sdk/sdk-faq", - }, - ], - }, - { - section: t("sidebar.sdk.technicalStack"), - contents: [ - { - title: t("sidebar.sdk.stackOverview"), - url: formatUrl("sdk/technical-stack/"), - }, - { - title: t("sidebar.sdk.configuration"), - url: formatUrl("sdk/technical-stack/configuration"), - }, - { - title: t("sidebar.sdk.services"), - url: formatUrl("sdk/technical-stack/services"), - }, - { - title: t("sidebar.sdk.smartContracts"), - url: formatUrl("sdk/technical-stack/contracts"), - }, - { - title: t("sidebar.sdk.proofGeneration"), - url: formatUrl("sdk/technical-stack/proof-generation"), - }, - // { - // title: t("sidebar.sdk.integrations"), - // url: formatUrl("sdk/technical-stack/integrations"), - // }, - ], - }, - { - section: t("sidebar.sdk.guides"), - contents: [ - { - title: t("sidebar.sdk.devnetDeployment"), - url: formatUrl("sdk/guides/devnet-deployment"), - }, - // { - // title: t("sidebar.sdk.productionDeployment"), - // url: formatUrl("sdk/guides/production-deployment"), - // }, - { - title: t("sidebar.sdk.digitalOcean"), - url: formatUrl("sdk/guides/digital-ocean-alt-gas-token"), - }, - { - title: t("sidebar.sdk.awsDeployment"), - url: formatUrl("sdk/guides/aws-deployment"), - }, - { - title: t("sidebar.sdk.customizingSdkComponents"), - url: formatUrl("sdk/guides/customizing-sdk-components"), - }, - ], - }, + community: [ { - section: t("sidebar.sdk.operation"), + section: t("sidebar.community.community"), contents: [ { - title: t("sidebar.sdk.contractsVerification"), - url: formatUrl("sdk/operation/contracts-verification"), - }, - { - title: t("sidebar.sdk.gasAndFees"), - url: formatUrl("sdk/operation/gas-and-fees"), - }, - { - title: t("sidebar.sdk.monitoring"), - url: formatUrl("sdk/operation/monitoring"), - }, - { - title: t("sidebar.sdk.upgrades"), - url: formatUrl("sdk/operation/upgrades"), - }, - { - title: t("sidebar.sdk.troubleshooting"), - url: formatUrl("sdk/operation/troubleshooting"), - }, - { - title: t("sidebar.sdk.security"), - url: formatUrl("sdk/operation/security-and-recovery"), + title: t("sidebar.community.faq"), + url: "community/faq", }, ], }, diff --git a/src/content/docs/en/community/faq.mdx b/src/content/docs/en/community/faq.mdx new file mode 100644 index 000000000..94fe37f8b --- /dev/null +++ b/src/content/docs/en/community/faq.mdx @@ -0,0 +1,30 @@ +--- +section: community +date: Last Modified +title: "Community FAQ" +lang: "en" +permalink: "community/faq" +excerpt: "Frequently asked questions about the Scroll community" +--- + +import Aside from "../../../../components/Aside.astro" +import ToggleElement from "../../../../components/ToggleElement.astro" + +**What is Scroll, in plain terms?** + +Scroll is an Ethereum Layer 2 that makes transactions faster and cheaper without sacrificing security, using zero-knowledge proofs to verify everything on Ethereum. + +**What is Scroll's mission?** + +Scroll's mission is to remove the trade-offs between scalability and security. Fast finality, full Ethereum compatibility, and uncompromising security. + +**What is Scroll's vision?** + +Scroll aims to empower humanity—starting with developers and users—by making decentralized computing accessible to billions, while building in the open, fighting for decentralization and censorship resistance, and contributing improvements back to Ethereum. + +**What are Scroll's core values?** + +- Empower accessibility at global scale +- Build in the open with community collaboration +- Preserve decentralization and censorship resistance +- Advance Ethereum's end goal: "zk-SNARK everything" diff --git a/src/content/docs/en/community/index.mdx b/src/content/docs/en/community/index.mdx new file mode 100644 index 000000000..94fe37f8b --- /dev/null +++ b/src/content/docs/en/community/index.mdx @@ -0,0 +1,30 @@ +--- +section: community +date: Last Modified +title: "Community FAQ" +lang: "en" +permalink: "community/faq" +excerpt: "Frequently asked questions about the Scroll community" +--- + +import Aside from "../../../../components/Aside.astro" +import ToggleElement from "../../../../components/ToggleElement.astro" + +**What is Scroll, in plain terms?** + +Scroll is an Ethereum Layer 2 that makes transactions faster and cheaper without sacrificing security, using zero-knowledge proofs to verify everything on Ethereum. + +**What is Scroll's mission?** + +Scroll's mission is to remove the trade-offs between scalability and security. Fast finality, full Ethereum compatibility, and uncompromising security. + +**What is Scroll's vision?** + +Scroll aims to empower humanity—starting with developers and users—by making decentralized computing accessible to billions, while building in the open, fighting for decentralization and censorship resistance, and contributing improvements back to Ethereum. + +**What are Scroll's core values?** + +- Empower accessibility at global scale +- Build in the open with community collaboration +- Preserve decentralization and censorship resistance +- Advance Ethereum's end goal: "zk-SNARK everything" diff --git a/src/content/docs/en/developers/building-on-scroll.mdx b/src/content/docs/en/developers/building-on-scroll.mdx new file mode 100644 index 000000000..b3acc5371 --- /dev/null +++ b/src/content/docs/en/developers/building-on-scroll.mdx @@ -0,0 +1,91 @@ +--- +section: developers +date: Last Modified +title: "Building on Scroll" +lang: "en" +permalink: "developers/building-on-scroll" +excerpt: "Building on Scroll feels just like Ethereum, and you can bring your favorite tooling and contracts with you." +whatsnext: { "Scroll Contracts": "/en/developers/scroll-contracts/" } +--- + +import Aside from "../../../../components/Aside.astro" +import ToggleElement from "../../../../components/ToggleElement.astro" + +**Welcome to the Scroll developer documentation!** + +Scroll is its own Layer 2 network built on Ethereum (more specifically, a “zero knowledge rollup”). + +If you’re experienced in building on Ethereum, your code, dependencies, and tooling work with Scroll out of the box. This is possible because our network is compatible with EVM bytecode and designed to feel just like developing on Ethereum. + + + +## Getting Started + +**Looking to build on the Scroll?** + +- Check out our [FAQ](/developers/) for the essentials +- Follow our [guide](/developers/guides/running-a-scroll-node) to run Scroll L2geth Node +- Explore our [deployed contract addresses](/developers/scroll-contracts) to build on + +## Why Build on Scroll? + + +
Throughput — Scroll creates more secure blockspace for Ethereum.
+

+ ZK Rollups allow for more activity on the network, minimizing congestion. By inheriting the security of Ethereum, + which verifies the behavior of the network using zero knowledge proofs, Scroll can process more transactions without + compromising on decentralization. +

+ + + +
Cost — Scroll saves users gas fees.
+

+ On Ethereum, competition for blockspace results in higher costs per transaction, as each transaction makes a bid to + be included in the next block. Scroll leverages recent breakthroughs in zero knowledge proofs and hardware + acceleration to vastly increase secure blockspace and minimize transaction costs for users. +

+ + +
Speed — Scroll delivers feedback to users, faster.
+

+ After the merge, Ethereum blocks reliably confirm every 12 seconds. Scroll blocks are minted every 3 seconds, and + for the sake of lower-risk operations, transactions can be assumed to be final once included in a block. This opens + up new possibilities for on-chain interaction in social and gaming applications. +

+ + +
Alignment — Scroll builds on Ethereum's vision.
+

+ Scroll builds on Ethereum’s vision. Our ethos is to build Ethereum, not to splinter it. Decentralization, + permissionlessness, censorship-resistance, and community ownership are the core of what we do and the roadmap we’re + building. We believe in open-source software, and we work closely with the Ethereum Foundation’s Privacy and Scaling + Explorations team to support their work on a zkEVM that might someday be the heart of Ethereum. +

+

+ We also work with governance DAOs and other open-source protocols to make sure that as applications are deployed, + we’re working to grow their impact — whether that be in public goods, core infrastructure, or the next generation of + zero knowledge use cases. +

+ + +
Community — Scroll brings together users and builders.
+

+ We know the challenges of building in the open and getting user engagement! Scroll has a blossoming community of + users and builders, and with a Discord community of over 500,000 members eager to try out applications on our + testnet or mainnet, we’re excited to connect builders with users who can provide real-world feedback. +

+ + +## Thank you for building with us. + +Our mainnet is now live, and we're diligently working to bring more integrations and support infrastructure to the network. + +Join our growing developer community. You can find us on [Discord](https://discord.gg/scroll), join our [discussion forum](https://community.scroll.io/), or follow our progress on [Twitter](https://twitter.com/Scroll_ZKP). diff --git a/src/content/docs/en/developers/developer-ecosystem.mdx b/src/content/docs/en/developers/developer-ecosystem.mdx index e1324ddbd..5de90b918 100644 --- a/src/content/docs/en/developers/developer-ecosystem.mdx +++ b/src/content/docs/en/developers/developer-ecosystem.mdx @@ -13,7 +13,6 @@ import ClickToZoom from "../../../../components/ClickToZoom.astro" import networkSelection from "./_images/mmNetworkSelection.png" import injectedProviderMM from "./_images/injectedProviderMM.png" import ToggleElement from "../../../../components/ToggleElement.astro" -import wagmiDemo from "../../../../assets/images/developers/getting-started/wagmi-demo.png" Explore Scroll’s most active ecosystem tooling and integrate it into your projects. For detailed data, see our [our Dune dashboard](https://dune.com/scroll/developer-ecosystem). diff --git a/src/content/docs/en/developers/faq.mdx b/src/content/docs/en/developers/faq.mdx deleted file mode 100644 index 9217064bb..000000000 --- a/src/content/docs/en/developers/faq.mdx +++ /dev/null @@ -1,68 +0,0 @@ ---- -section: developers -date: Last Modified -title: "Developer Frequently Asked Questions" -lang: "en" -permalink: "developers/faq" -whatsnext: { "Scroll Contracts": "/en/developers/scroll-contracts/" } -excerpt: "." ---- - -## EVM Compatibility & Infrastructure - -**What are the opcode differences on Scroll compared to Ethereum?** - -Scroll is fully EVM-equivalent, but certain rollup-specific opcodes differ. A full breakdown can be found here: [Rollup Codes: Scroll Overview](https://www.rollup.codes/scroll#overview). - -## Testnet ETH - -**How do I get testnet ETH on Scroll?** - -You can request testnet ETH via the official Scroll telegram faucet bot by sending a message to @scroll_up_sepolia_bot who will provide access to the faucet. Once on the faucet telegram group chat, send your wallet address on a `/drop YOUR_ETHEREUM_ADDRESS` command and the bot will automatically send some funds to you. - -**Is there an alternative way to get testnet ETH?** - -Yes. Please refer to our list of [Unofficial Faucets](https://docs.scroll.io/en/user-guide/faucet/) on both Sepolia and Scroll Sepolia. Remember, you can either receive Scroll Sepolia ETH directly or trough the [Sepolia Testnet Bridge](https://sepolia.scroll.io/bridge). - -## Developer Tooling & Ecosystem - -**Where can I find the list of developer tooling available on Scroll?** - -See the full list here: [Scroll Developer Tooling](https://scroll.io/ecosystem). - -**Where can I explore the ecosystem of projects deployed on Scroll?** - -Use our [Dune dashboard](https://docs.scroll.io/en/developers/developer-ecosystem/) to explore live ecosystem data and visit the [Scroll Ecosystem Projects](https://scroll.io/ecosystem) for the full list. - - -## Node Questions - -**Where can i download Scroll node's snapshot?** - -Mainnet : https://scroll-geth-snapshot.s3.us-west-2.amazonaws.com/mpt/latest.tar - -Sepolia : https://scroll-sepolia-l2geth-snapshots.s3.us-west-2.amazonaws.com/mpt/latest.tar - -**Scroll snapshot size is too large, do you have pruned snapshot?** - -Unfortunately, pruned snapshots are not available for Scroll. You may consider changing the garbage collection mode from archive to full to reduce the size of the snapshot by changing flag from --gcmode archive to --gcmode full - -**Can I run my own node on Scroll?** - -Yes. Scroll provides a step-by-step tutorial for setting up and running your own node. See: [Running a Node](https://docs.scroll.io/en/developers/guides/running-a-scroll-node/). - -## Errors & Support - -**I have a question about my node, the faucet or developing on Scroll. What should I do?** - -Please join the Scroll Discord server and ask on the `#developers` or `#developer-support` discord channels. - -**I want to connect to the BD team. What should I do?** - -To connect with the BD team please fill the [Scroll BD Intake form](https://tally.so/r/wM2aaE). - -**How to keep track of any changes in Scroll?** - -You can follow our telegram announcement channel [here](https://t.me/scroll_tech_announcements). - -Or subscribe to our github [repo](https://github.com/scroll-tech/scroll), click watch, then custom, and tick releases. \ No newline at end of file diff --git a/src/content/docs/en/developers/index.mdx b/src/content/docs/en/developers/index.mdx index 43aa88df4..6517b2e32 100644 --- a/src/content/docs/en/developers/index.mdx +++ b/src/content/docs/en/developers/index.mdx @@ -1,91 +1,118 @@ --- section: developers date: Last Modified -title: "Building on Scroll" +title: "Developer Frequently Asked Questions" lang: "en" permalink: "developers/" -excerpt: "Building on Scroll feels just like Ethereum, and you can bring your favorite tooling and contracts with you." -whatsnext: { "Frequently Asked Questions": "/en/developers/faq" } +whatsnext: { "Building on Scroll": "/en/developers/building-on-scroll", "Scroll Contracts": "/en/developers/scroll-contracts/" } +excerpt: "." --- import Aside from "../../../../components/Aside.astro" -import ToggleElement from "../../../../components/ToggleElement.astro" -**Welcome to the Scroll developer documentation!** + - +Use the following configuration to connect your Ethereum tools to Scroll Mainnet: + +| Network Name | Scroll | Ethereum Mainnet | +| ------------------ | -------------------------------------------------- | ---------------------------------------------------- | +| RPC URL | [https://rpc.scroll.io/](https://rpc.scroll.io/) | [https://eth.llamarpc.com](https://eth.llamarpc.com) | +| Chain ID | 534352 | 1 | +| Currency Symbol | ETH | ETH | +| Block Explorer URL | [https://scrollscan.com/](https://scrollscan.com/) | [https://etherscan.io](https://etherscan.io) | + +**What are the network parameters for Scroll Sepolia Testnet?** + +Use the following configuration to connect your Ethereum tools to Scroll Sepolia Testnet: + +| Network Name | Scroll Sepolia | Ethereum Sepolia | +| ------------------ | ----------------------------------------------------------------- | ------------------------------------------------------------ | +| RPC URL | [https://sepolia-rpc.scroll.io/](https://sepolia-rpc.scroll.io/) | [https://rpc2.sepolia.org](https://rpc2.sepolia.org) | +| Chain ID | 534351 | 11155111 | +| Currency Symbol | ETH | ETH | +| Block Explorer URL | [https://sepolia.scrollscan.com](https://sepolia.scrollscan.com/) | [https://sepolia.etherscan.io](https://sepolia.etherscan.io) | + +**Where can I find additional RPC providers and infrastructure for Scroll Mainnet?** + +- [Scroll RPC Providers on ChainList.org](https://chainlist.org/chain/534352) +- [Ethereum RPC Providers on ChainList.org](https://chainlist.org/chain/1) +- [Scrollscan](https://scrollscan.com/) +- [Scroll Rollup Scanner](https://scroll.io/rollupscan) + +**Where can I find additional RPC providers and infrastructure for Scroll Sepolia?** + +- [Scroll Sepolia RPC Providers on ChainList.org](https://chainlist.org/chain/534351) +- [Ethereum Sepolia RPC Providers on ChainList.org](https://chainlist.org/chain/11155111) +- [Sepolia Scrollscan](http://sepolia.scrollscan.com/) +- [Scroll Sepolia Rollup Scanner](https://sepolia.scroll.io/rollupscan) + +## Testnet ETH + +**How do I get testnet ETH on Scroll?** + +You can request testnet ETH via the official Scroll telegram faucet bot by sending a message to @scroll_up_sepolia_bot who will provide access to the faucet. Once on the faucet telegram group chat, send your wallet address on a `/drop YOUR_ETHEREUM_ADDRESS` command and the bot will automatically send some funds to you. + +**Is there an alternative way to get testnet ETH?** + +Yes. Please refer to our list of [Unofficial Faucets](https://docs.scroll.io/en/user-guide/faucet/) on both Sepolia and Scroll Sepolia. Remember, you can either receive Scroll Sepolia ETH directly or trough the [Sepolia Testnet Bridge](https://sepolia.scroll.io/bridge). + +## EVM Compatibility & Infrastructure + +**What are the opcode differences on Scroll compared to Ethereum?** + +Scroll is fully EVM-equivalent, but certain rollup-specific opcodes differ. A full breakdown can be found here: [Rollup Codes: Scroll Overview](https://www.rollup.codes/scroll#overview). + +## Developer Tooling & Ecosystem + +**Where can I find the list of developer tooling available on Scroll?** + +See the full list here: [Scroll Developer Tooling](https://scroll.io/ecosystem). + +**Where can I explore the ecosystem of projects deployed on Scroll?** + +Use our [Dune dashboard](https://docs.scroll.io/en/developers/developer-ecosystem/) to explore live ecosystem data and visit the [Scroll Ecosystem Projects](https://scroll.io/ecosystem) for the full list. + + +## Node Questions + +**Where can i download Scroll node's snapshot?** + +Mainnet : https://scroll-geth-snapshot.s3.us-west-2.amazonaws.com/mpt/latest.tar + +Sepolia : https://scroll-sepolia-l2geth-snapshots.s3.us-west-2.amazonaws.com/mpt/latest.tar + +**Scroll snapshot size is too large, do you have pruned snapshot?** + +Unfortunately, pruned snapshots are not available for Scroll. You may consider changing the garbage collection mode from archive to full to reduce the size of the snapshot by changing flag from --gcmode archive to --gcmode full + +**Can I run my own node on Scroll?** + +Yes. Scroll provides a step-by-step tutorial for setting up and running your own node. See: [Running a Node](https://docs.scroll.io/en/developers/guides/running-a-scroll-node/). + +## Errors & Support + +**I have a question about my node, the faucet or developing on Scroll. What should I do?** + +Please join the Scroll Discord server and ask on the `#developers` or `#developer-support` discord channels. + +**I want to connect to the BD team. What should I do?** + +To connect with the BD team please fill the [Scroll BD Intake form](https://tally.so/r/wM2aaE). + +**How to keep track of any changes in Scroll?** + +You can follow our telegram announcement channel [here](https://t.me/scroll_tech_announcements). -## Getting Started - -**Looking to build on the Scroll?** - -- Check out our [FAQ](/developers/faq) for the essentials -- Follow our [guide](/developers/guides/running-a-scroll-node) to run Scroll L2geth Node -- Explore our [deployed contract addresses](/developers/scroll-contracts) to build on - -## Why Build on Scroll? - - -
Throughput — Scroll creates more secure blockspace for Ethereum.
-

- ZK Rollups allow for more activity on the network, minimizing congestion. By inheriting the security of Ethereum, - which verifies the behavior of the network using zero knowledge proofs, Scroll can process more transactions without - compromising on decentralization. -

- - - -
Cost — Scroll saves users gas fees.
-

- On Ethereum, competition for blockspace results in higher costs per transaction, as each transaction makes a bid to - be included in the next block. Scroll leverages recent breakthroughs in zero knowledge proofs and hardware - acceleration to vastly increase secure blockspace and minimize transaction costs for users. -

- - -
Speed — Scroll delivers feedback to users, faster.
-

- After the merge, Ethereum blocks reliably confirm every 12 seconds. Scroll blocks are minted every 3 seconds, and - for the sake of lower-risk operations, transactions can be assumed to be final once included in a block. This opens - up new possibilities for on-chain interaction in social and gaming applications. -

- - -
Alignment — Scroll builds on Ethereum's vision.
-

- Scroll builds on Ethereum’s vision. Our ethos is to build Ethereum, not to splinter it. Decentralization, - permissionlessness, censorship-resistance, and community ownership are the core of what we do and the roadmap we’re - building. We believe in open-source software, and we work closely with the Ethereum Foundation’s Privacy and Scaling - Explorations team to support their work on a zkEVM that might someday be the heart of Ethereum. -

-

- We also work with governance DAOs and other open-source protocols to make sure that as applications are deployed, - we’re working to grow their impact — whether that be in public goods, core infrastructure, or the next generation of - zero knowledge use cases. -

- - -
Community — Scroll brings together users and builders.
-

- We know the challenges of building in the open and getting user engagement! Scroll has a blossoming community of - users and builders, and with a Discord community of over 500,000 members eager to try out applications on our - testnet or mainnet, we’re excited to connect builders with users who can provide real-world feedback. -

- - -## Thank you for building with us. - -Our mainnet is now live, and we're diligently working to bring more integrations and support infrastructure to the network. - -Join our growing developer community. You can find us on [Discord](https://discord.gg/scroll), join our [discussion forum](https://community.scroll.io/), or follow our progress on [Twitter](https://twitter.com/Scroll_ZKP). +Or subscribe to our github [repo](https://github.com/scroll-tech/scroll), click watch, then custom, and tick releases. \ No newline at end of file diff --git a/src/content/docs/en/developers/scroll-contracts.mdx b/src/content/docs/en/developers/scroll-contracts.mdx index 279d19a78..67202b198 100644 --- a/src/content/docs/en/developers/scroll-contracts.mdx +++ b/src/content/docs/en/developers/scroll-contracts.mdx @@ -13,29 +13,6 @@ import ToggleElement from "../../../../components/ToggleElement.astro" In this article you'll find useful contract addresses for Scroll and commonly used protocols. See the section below for [Scroll Sepolia](#scroll-sepolia-testnet) info. -## Network Info - -Use the table below to configure your Ethereum tools to the Scroll mainnet. - -| Network Name | Scroll | Ethereum Mainnet | -| ------------------ | -------------------------------------------------- | ---------------------------------------------------- | -| RPC URL | [https://rpc.scroll.io/](https://rpc.scroll.io/) | [https://eth.llamarpc.com](https://eth.llamarpc.com) | -| Chain ID | 534352 | 1 | -| Currency Symbol | ETH | ETH | -| Block Explorer URL | [https://scrollscan.com/](https://scrollscan.com/) | [https://etherscan.io](https://etherscan.io) | - - -
Additional Scroll Mainnet RPCs and Infra
- - [Scroll Native Bridge](https://scroll.io/bridge) - - [Scroll Rollup Scanner](https://scroll.io/rollupscan) - - [Scroll RPC Providers on ChainList.org](https://chainlist.org/chain/534352) - - [Ethereum RPC Providers on ChainList.org](https://chainlist.org/chain/1) - {/* - Additional Block Explorers: - - [Dora](https://www.ondora.xyz/network/scroll/interactions) - - [L2Scan](https://scroll.l2scan.co/) */} - - - ## Scroll Contracts ### Rollup @@ -100,29 +77,6 @@ Use the table below to configure your Ethereum tools to the Scroll mainnet. ## Scroll Sepolia Testnet -### Network Info - -Use the table below to configure your Ethereum tools to the Scroll Sepolia Testnet. - -| Network Name | Scroll Sepolia | Ethereum Sepolia | -| ------------------ | ----------------------------------------------------------------- | ------------------------------------------------------------ | -| RPC URL | [https://sepolia-rpc.scroll.io/](https://sepolia-rpc.scroll.io/) | [https://rpc2.sepolia.org](https://rpc2.sepolia.org) | -| Chain ID | 534351 | 11155111 | -| Currency Symbol | ETH | ETH | -| Block Explorer URL | [https://sepolia.scrollscan.com](https://sepolia.scrollscan.com/) | [https://sepolia.etherscan.io](https://sepolia.etherscan.io) | - - -
Additional Scroll Sepolia RPCs and Infra
- - [Scroll Sepolia Native Bridge](https://sepolia.scroll.io/bridge) - - [Scroll Sepolia Rollup Scanner](https://sepolia.scroll.io/rollupscan) - - [Scroll Sepolia RPC Providers on ChainList.org](https://chainlist.org/chain/534351) - - [Ethereum Sepolia RPC Providers on ChainList.org](https://chainlist.org/chain/11155111) - - Additional Block Explorers: - - [Dora](https://www.ondora.xyz/network/scroll-sepolia/interactions) - - [L2Scan](https://scroll.l2scan.co/) - - - ### Scroll Sepolia Contracts #### Rollup diff --git a/src/content/docs/en/getting-started/overview.md b/src/content/docs/en/getting-started/overview.md deleted file mode 100644 index 53866abbe..000000000 --- a/src/content/docs/en/getting-started/overview.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Scroll Overview" -lang: "en" -permalink: "docs/conceptual-overview/" -excerpt: "ZK Rollups and Scroll" -whatsnext: { "User Guide": "/en/user-guide/", "Building on Scroll": "/en/developers/" } ---- - -#### Welcome to the Scroll docs! - -Scroll is a security-focused scaling solution for Ethereum, using innovations in scaling design and zero knowledge proofs to build a new layer on Ethereum. The Scroll network is more accessible, more responsive and can support more users at once than Ethereum alone. If you've ever used or developed an application on Ethereum, you'll be right at home on Scroll. - -Want to try out the Scroll Sepolia testnet with free assets before using Scroll? Check out our [User Guide](/user-guide/). - -## What is Scroll building? - -Scroll is building the technology to scale Ethereum. - -While Ethereum is the leading blockchain network for powering decentralized applications, its popularity also brings higher costs, creating a barrier to adoption for the next wave of users and developers. - -Leveraging cutting-edge research in zero knowledge (”zk”) proofs , Scroll is building a Layer 2 rollup network on Ethereum. The team, in open-source collaboration with others in the Ethereum community, has created a “zkEVM” that allows for all activity on the network, which behaves just like Ethereum, to be secured by smart contracts _on_ Ethereum. The network publishes all of the transactions to Ethereum, and the zkEVM creates and publishes cryptographic "proofs" that the Scroll network is following the rules of Ethereum. - -Ultimately, Ethereum smart contracts verify that every transaction on Scroll is valid for these proofs, lending the network incredible security, decentralization, and censorship resistance. This level of security and scalability for Ethereum is only possible with recent breakthroughs in zero knowledge cryptography, blockchain protocol design, and hardware acceleration. - - - -For more information on our architecture, see [Scroll Architecture](/technology/). - -## Can I use Scroll today? - -Scroll mainnet on Ethereum is live! We also have a testnet running on Ethereum Sepolia, the Scroll Sepolia testnet. Although we have a [comprehensive guide](/user-guide/), if you're familiar with using Ethereum, you can get started in minutes: - -- Visit our [Bridge](https://scroll.io/bridge) or [Scroll Sepolia Bridge](https://sepolia.scroll.io/bridge) and connect your wallet -- Send tokens from Ethereum mainnet to Scroll (or use a Scroll Sepolia [faucet](/user-guide/faucet)) -- Test out Scroll Sepolia testnet dapp like our [Uniswap Showcase](http://uniswap-showcase.sepolia.scroll.xyz/) or even [Aave](https://app.aave.com/) -- just be sure to select the Scroll Sepolia network! - -## Where is Scroll headed? - -We've released our mainnet on Ethereum, but there's still more work to do. Next up -- decentralizing each component of the stack. To stay up to date, check out [our blog](https://scroll.io/blog) or follow along in [our Discord](https://discord.gg/scroll) or on [Twitter](https://twitter.com/scroll_zkp). diff --git a/src/content/docs/en/learn/index.mdx b/src/content/docs/en/learn/index.mdx deleted file mode 100644 index ade566b4d..000000000 --- a/src/content/docs/en/learn/index.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -section: learn -title: "Learn" -lang: "en" -permalink: "learn/" -excerpt: "Learn more about Ethereum scalability and zero knowledge cryptography." ---- - -import NavCard from "../../../../components/NavCard.astro" -import TechnologySvg from "../../../../assets/svgs/home/home-technology.svg?raw" -import LearnSvg from "../../../../assets/svgs/home/home-learn.svg?raw" - -Scroll pulls together research and engineering from Blockchain Protocols and Zero Knowledge Cryptography. If you want to dive deeper, keep reading and check out the additional resources. - -Want to see a specific topic covered? Create [an issue](https://github.com/scroll-tech/scroll-documentation/issues/new?assignees=&labels=new+content%2Ctriage&projects=&template=new_content.yml&title=%5BNew+Content%5D%3A+%3Cyour-title-here%3E) in our Github repo. - -
- - -
diff --git a/src/content/docs/en/learn/intro-to-rollups.md b/src/content/docs/en/learn/intro-to-rollups.md deleted file mode 100644 index 990445c84..000000000 --- a/src/content/docs/en/learn/intro-to-rollups.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Intro to Rollups" -lang: "en" -permalink: "learn/intro-to-rollups" -excerpt: "Rollups are the most predominant layer 2 scaling solution in the Ethereum ecosystem." -whatsnext: { "Scroll Rollup Process": "/en/technology/chain/rollup" } ---- - -## What’s a rollup? - -Rollups are the most predominant layer 2 scaling solution in the Ethereum ecosystem and are viewed as a [central part](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) of the Ethereum roadmap. - -A rollup processes batches of transactions off-chain (i.e. not on layer 1), and then posts the resulting data on-chain (i.e. on layer 1). - -The execution of each transaction is performed off-chain, and does not need to be re-executed layer 1 nodes. This allows for high transaction throughput, without impacting the decentralization of layer 1. - -In order for a rollup to be secure, it must prove that its off-chain computation (the processing of transactions) was performed correctly. There are predominantly two mechanisms to prove the validity of off-chain computation: validity proofs and fraud proofs. - -## What’s an optimistic rollup? - -An optimistic rollup is a rollup that uses fraud proofs to assert the validity of its computation. - -Fraud proofs are a mechanism that allows users to challenge and prove the invalidity of any computation performed on the L2. If a fraud proof is successfully submitted, the L2 can be rolled back to a previous state and the invalid computation can be corrected. Fraud proofs depend on at least one honest party checking that the L2 transactions have been correctly executed. - -## What’s a ZK rollup? - -A ZK rollup is a rollup that uses validity proofs to assert the validity of its computation. - -When a ZK rollup executes a batch of transactions and posts the resulting state to L1, it also posts a validity proof. This mathematical proof proves that the resulting state is indeed the state that results from correctly executing the batch of transactions. - -Today, there are multiple types of ZK rollups, broadly defined as either zkVMs (zk Virtual Machines) or zkEVMs (zk Ethereum Virtual Machines). - -zkVMs are designed from the ground up to work well with ZK circuits and require different development workflows compared to a zkEVM. Some examples of these include Starkware and Aztec. - -zkEVMs are designed to emulate the EVM. There are two major types of zkEVMs: bytecode-compatible, and language-compatible. Bytecode-compatible zkEVMs emulate the EVM at a very low level, allowing for a near-identical development and user experience compared to Ethereum Layer 1. Language-compatible zkEVMs compile Solidity and other high-level languages down into different bytecode, which can result in changes to workflow. zkSync is the most popular language-compatible zkEVM. - -Scroll is bytecode-compatible. This approach was chosen because it brings certain benefits: - -- Solidity, Vyper, and Huff work out of the box -- No re-auditing necessary -- Most existing tooling is inherited -- Near-identical UX and DevX as Ethereum - -More detail on Scroll’s approach is found in the Technology section. - -## Further reading - -- [An Incomplete Guide to Rollups](https://vitalik.ca/general/2021/01/05/rollup.html) - Vitalik Buterin -- [Scaling](https://ethereum.org/en/developers/docs/scaling/) - Ethereum Docs diff --git a/src/content/docs/en/learn/the-scalability-problem.md b/src/content/docs/en/learn/the-scalability-problem.md deleted file mode 100644 index c5055fd6c..000000000 --- a/src/content/docs/en/learn/the-scalability-problem.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -section: learn -date: Last Modified -title: "The Scalability Problem" -lang: "en" -permalink: "learn/intro-to-rollups" -excerpt: "Ethereum’s strong decentralization and security come at the cost of sacrificing scalability: to ensure that all the participating nodes can keep up with the network, the network’s throughput is limited. This limit ultimately results in higher costs and latencies for users." -whatsnext: { "Intro to Rollups": "/en/learn/intro-to-rollups" } ---- - -## Ethereum’s scaling problem - -[Ethereum](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-is-ethereum) is a general-purpose blockchain that supports the deployment and execution of [smart contracts](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-are-smart-contracts). - -One of the defining features of Ethereum is its unwavering commitment to security and decentralization. Ethereum is designed such that computers all across the world (even cheap ones, like a [Raspberry Pi](https://ethereum-on-arm-documentation.readthedocs.io/)) can participate in the network, running local copies of the blockchain and processing new transactions. - -However, Ethereum’s strong decentralization and security come at the cost of sacrificing scalability: to ensure that all the participating nodes can keep up with the network, the network’s throughput is limited. This limit ultimately results in higher costs and latencies for users. - -## Scaling solutions - -Ethereum’s scaling solutions aim to increase the throughput of the network without sacrificing decentralization or security. - -There are primarily two types of scaling solutions: layer 1 scaling solutions and layer 2 scaling solutions. - -**Layer 1** (or **L1**) scaling solutions attempt to scale the network by making modifications to the Ethereum blockchain directly. The term “layer 1” here refers to the main Ethereum blockchain. In general, it is very difficult to design layer 1 scaling solutions that increase throughput and at the same time preserve high levels of security and decentralization. Thus, recent scaling efforts have shifted away from layer 1 solutions and towards layer 2 solutions. - -**Layer 2** (or **L2**) scaling solutions are networks that live **on top** of Ethereum layer 1 - they are essentially separate blockchains that are “anchored” to the underlying Ethereum blockchain in some way. These layer 2 networks can generally process transactions at a higher rate than the underlying layer 1 network, as they are not subject to the same limitations. The “anchoring” mechanism, the specifics of which differ across various layer 2s, enables the layer 2 network to inherit the strong security and decentralization properties of Ethereum layer 1. diff --git a/src/content/docs/en/learn/zero-knowledge/additional-zk-learning-resources.md b/src/content/docs/en/learn/zero-knowledge/additional-zk-learning-resources.md deleted file mode 100644 index 01ae590ba..000000000 --- a/src/content/docs/en/learn/zero-knowledge/additional-zk-learning-resources.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Additional ZK Learning Resources" -lang: "en" -permalink: "learn/zero-knowledge/additional-zk-learning-resources" -excerpt: "Looking to dive deeper into ZK? Here are some of our favorite resources." ---- - -Looking to dive deeper into ZK? Here are some of our favorite resources. - -## Video - -- [ZK Whiteboard Sessions](https://youtube.com/playlist?list=PLj80z0cJm8QErn3akRcqvxUsyXWC81OGq) - - These whiteboard sessions are a fantastic way to learn about ZK. The first three lectures by Dan Boneh provide a great foundational understanding, on which the following lectures build, discussing more recent developments. -- [Zero Knowledge Proofs MOOC](https://youtube.com/playlist?list=PLS01nW3Rtgor_yJmQsGBZAg5XM4TSGpPs) - - A MOOC that covers zero knowledge proofs from first principles, all the way to modern industry topics. -- [The 9th BIU Winter School on Cryptography - Zero Knowledge](https://youtube.com/playlist?list=PL8Vt-7cSFnw29cLUVqAIuMlg1QJ-szV0K) - - These lectures lay the theoretical foundations for zero knowledge - they are targeted toward academics and audiences with mathematical maturity. -- [ZK Symposium](https://www.youtube.com/playlist?list=PLrzRr7okCcmbAlgYpuFjzUJv8tAyowDQY) - - A mix of applied and theoretical presentations from some of the top researchers and product builders in the zero knowledge space. - -## Text - -- [Proofs, Arguments, and Zero Knowledge](https://people.cs.georgetown.edu/jthaler/ProofsArgsAndZK.html) - Justin Thaler - - A comprehensive textbook on the theory of zero knowledge. diff --git a/src/content/docs/en/learn/zero-knowledge/introduction-to-zero-knowledge.mdx b/src/content/docs/en/learn/zero-knowledge/introduction-to-zero-knowledge.mdx deleted file mode 100644 index 77c6817bf..000000000 --- a/src/content/docs/en/learn/zero-knowledge/introduction-to-zero-knowledge.mdx +++ /dev/null @@ -1,75 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Introduction to Zero Knowledge" -lang: "en" -permalink: "learn/zero-knowledge/introduction-to-zero-knowledge" -whatsnext: { "Polynomial Commitment Schemes": "/en/learn/zero-knowledge/polynomial-commitment-schemes" } -excerpt: 'Over the past decade, a field of cryptography called "zero knowledge" has been rapidly advancing. It promises new ways to build applications and enables protocols to increase efficiency, security, and privacy.' ---- - -import Aside from "../../../../../components/Aside.astro" - -Over the past decade, a field of cryptography called "zero knowledge" has been rapidly advancing. It promises new ways to build applications and enables protocols to increase efficiency, security, and privacy. - -Let's look at what makes the field of zero knowledge proofs so exciting and what problems it helps engineers solve. - -## Trustless Blockchains & Verifiability - -Blockchains generally work by processing transactions submitted by users. These transactions usually trigger some computation for the blockchain to perform. - -For the blockchain to be trustless (i.e. not reliant on trusting some individual party), participants in the network must verify that transactions are valid and that their resulting computations were performed correctly. - -Verifying that the transaction is valid generally requires digital signature verification - this verifies that the transaction’s reported sender is indeed the author of the transaction. Verifying that a transaction’s computation was performed correctly generally requires re-executing the transaction locally. - -## Limitations to Verifiability - -This methodology of verifying each transaction breaks down in situations where a participant can’t rerun the computation. A participant may not be able to re-execute the computation for a couple of reasons: (1) it could be that certain data shouldn’t be made available (for privacy reasons), or (2) it may be too expensive for a participating computer to re-execute all the transactions - this second reason is especially relevant when considering high-throughput blockchains with a large number of transactions per second. - -## The Power of Zero Knowledge Proofs - -Zero knowledge proofs (ZKPs) have the power to overcome these limitations. - -ZKPs allow participants to verify the results of a computation while (1) preserving the privacy of any sensitive data used in the computation, and (2) having the verification be significantly cheaper than re-executing the computation. These two properties of ZKPs are called **zero knowledge** and **succinctness**, respectively. - -The above properties of ZKPs are extremely useful in the context of verifiability for trustless blockchains. Without ZKPs, participants need to re-execute every transaction’s resulting computation. This requires all participants to see all the (potentially sensitive) data used in each computation, and it also limits the throughput of the entire system. With ZKPs, one party can perform the computation, and then generate a proof that the computation was performed correctly. Other participants can verify that the computation was performed correctly by _verifying that the proof is valid_, rather than re-executing the computation themselves. Verifying the proof (1) does not leak information about sensitive data used in the original computation, and (2) is significantly computationally cheaper than re-executing the original computation. These two properties have the potential to enable privacy and scalability for trustless blockchains. - -## Circuits, Proofs, and Verifiers - -In practice, ZKPs can be quite complex to implement into a system, but at a high level, you’ll want to understand that zero knowledge proofs have a few components: a circuit, a proof, and a verifier. - -The circuit is a program that takes in input data and asserts that the input data is valid according to some “constraints” that the input data must satisfy. The input data can be public (known to everyone), private (known to only the prover), or mixed (some inputs are public and some are private). - -A proof can be generated, claiming that an input satisfies the circuit. The proof reveals no information about the private inputs and is quite small in size. - -The verifier can check (1) that the proof is valid, (2) that the proof matches the constraints laid out by the circuit (and isn’t just a phony proof), and (3) that the public inputs used to generate the proof match those being used by the verifier. Note that this check performed by the verifier is generally a cheap computation. - - - -### Circuits, Proof, and Verifiers — an example - -Let’s take Sudoku as an example. Suppose that there’s a Sudoku puzzle, and Alice wants to prove to Bob that she knows a solution to the puzzle, but does not want to reveal what the solution is. - -In this case, the particular puzzle will be a public input (both Alice and Bob know about it), and the solution is a private input (Alice knows it, but will keep it private from Bob). The **circuit** would take both these inputs and assert that the solution is correct by checking it in the standard way, row-by-row, column-by-column, etc. The circuit in this way “constrains” that the private input solution really is a valid solution for the public input puzzle, and is “satisfied” only when the solution check passes. - -A **proof** can then be generated that states that Alice knows an input that satisfies the circuit for the particular puzzle (the public input). - -The proof, along with the puzzle, could be passed to Bob, who could then use a **verifier** corresponding to the Sudoku-checking circuit to assess if the proof is valid, and thereby that Alice indeed knows a solution to the puzzle. Critically, Bob doesn’t gain any knowledge of Alice’s solution, but he can still verify that she knows a valid solution! - -## Zero Knowledge Proofs and Blockchains - -One of the primary motivations for recent advances in ZKPs is its application to blockchains. Two of the key challenges that decentralized blockchains face are privacy and scalability - all the data is public, and every node in the network has to re-run every computation on the network. ZKPs can help solve both of these challenges. - -While there are several projects utilizing the zero knowledge property of ZKPs to build privacy-preserving applications, we at Scroll use only the succinctness property of ZKPs to scale Ethereum. - -## Scroll & Zero Knowledge Proofs - -The idea that powers Scroll is quite simple. What if we could use an Ethereum smart contract to verify all of the computation of another version of Ethereum? We could run another network that provides faster and cheaper access to an Ethereum Virtual Machine (”EVM”), and Ethereum itself would provide the security needed for validating all the computation and making sure this other network isn’t breaking the EVM rules. - -The rest of the Learn and Technology sections break down how this works in greater detail, but at a simple level, remember that zero knowledge relies on having a circuit, proof, and verifier. - -In our construction, the circuit (actually a set of circuits) encodes the rules of the EVM to “constrain” acceptable behavior for processing input transactions relative to the chain state. Using this “zkEVM”, a network of GPUs takes the transactions for a set of blocks and generates a proof. And back on Ethereum, a smart contract verifies that, for a set of transactions, this proof matches the circuit enshrined in the smart contract. If it does, those transactions can be considered “finalized,” the network moves forward, and we’ve created fast, secure, and affordable blockspace for growing Ethereum. diff --git a/src/content/docs/en/learn/zero-knowledge/kzg-commitment-scheme.md b/src/content/docs/en/learn/zero-knowledge/kzg-commitment-scheme.md deleted file mode 100644 index 6d25e00b7..000000000 --- a/src/content/docs/en/learn/zero-knowledge/kzg-commitment-scheme.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -section: learn -date: Last Modified -title: "KZG Commitment Scheme" -lang: "en" -permalink: "learn/zero-knowledge/kzg-commitment-scheme" -excerpt: "KZG is used Ethereum’s Proto-Danksharding, and is also used in Scroll’s proof system. This article will give an overview of the KZG commitment scheme." -whatsnext: { "Additional Resources": "/en/learn/zero-knowledge/additional-zk-learning-resources" } ---- - -One of the most widely used polynomial commitment schemes is the KZG commitment scheme. The scheme was originally [published](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf) in 2010 by Kate, Zaverucha, and Goldberg. - -KZG is used in Ethereum’s [Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq), and is also used in Scroll's proof system. - -This article will give an overview of the KZG commitment scheme. - -## Preliminaries and notation - -Recall the premise of polynomial commitment schemes. We have some polynomial $P(x)$ that we would like to commit to. We’ll assume the polynomial has a degree less than $l$. - -KZG commitments rely on [elliptic curve pairings](https://vitalik.ca/general/2017/01/14/exploring_ecp.html). Let $\mathbb{G}_1$ and $\mathbb{G}_2$ be two elliptic curve groups of order $p$, with a non-trivial [bilinear mapping](https://en.wikipedia.org/wiki/Bilinear_map) $e: \mathbb{G}_1 \times \mathbb{G}_2 \rightarrow \mathbb{G}_T$. Let $g$ be a generator of $\mathbb{G}_1$, and $h$ a generator of $\mathbb{G}_2$. We will use the notation $[x]_1 := x \cdot g$ and $[x]_2 := x \cdot h$, where $x \in \mathbb{F}_p$. - -## 1. Trusted setup - -Before computing any KZG commitments, a one-time trusted setup must be performed. Once the trusted setup is completed, it can be reused to commit and reveal as many different polynomials as desired. The trusted setup works as follows: - -- Pick some random field element $\tau \in \mathbb{F}_p$ -- Let $l \in \mathbb{Z}$ be the maximum degree of the polynomials we want to commit to - - The trusted setup will only enable commitments to polynomials of degree $\leq l$ -- Compute $([\tau^0]_1,[\tau^1]_1,[\tau^{2}]_1\ldots,[\tau^{l}]_1)$ and $([\tau]_2)$, and release these values publicly. - -Note that $\tau$ should not be revealed - it is a secret parameter of the setup, and should be discarded after the trusted setup ceremony is completed so that nobody can figure out its value. - -There are established methods of conducting trusted setup ceremonies with weak trust assumptions (1-out-of-N trust assumption) using [multi-party computation](https://en.wikipedia.org/wiki/Secure_multi-party_computation) (MPC). For more on how trusted setups work, see this [post](https://vitalik.ca/general/2022/03/14/trustedsetup.html) by Vitalik. - -## 2. Committing to a polynomial - -- Given a polynomial $P(x) = \sum_{i=0}^{l} p_i x^i$ -- Compute and output the commitment $c = [P(\tau)]_1$ - - Although the committer cannot compute $P(\tau)$ directly (since he doesn’t know $\tau$), he can compute it using the output of the trusted setup: - - $[P(\tau)]_1 = [\sum_{i=0}^{l} p_i \tau^i]_1 = \sum_{i=0}^{l} p_i [\tau^i]_1$ - -## 3. Prove an evaluation - -- Given an evaluation $P(a) = b$ -- Compute and output the proof $\pi = [Q(\tau)]_1$ - - Where $Q(x) := \frac{P(x)-b}{x-a}$ - - This is called the “quotient polynomial.”Note that such a $Q(x)$ exists if and only if $P(a) = b$. The existence of this quotient polynomial therefore serves as a proof of the evaluation. - -## 4. Verify an evaluation proof - -- Given a commitment $c = [P(\tau)]_1$, an evaluation $P(a) = b$, and a proof $\pi = [Q(\tau)]_1$ -- Verify that $e(\pi, [\tau - a]_2) = e(c - [b]_1, h)$ - - Some algebra shows that this is equivalent to checking that the quotient polynomial is correctly formed at $\tau$: $Q(\tau) = \frac{P(\tau) -b}{\tau-a}$ - $$ - \begin{align*} - & e(\pi, [\tau - a]_2) = e(c - [b]_1, h) \\ \iff - & e([Q(\tau)]_1, [\tau -a]_2) = e([P(\tau)]_1 - [b]_1, h) \\ \iff - & Q(\tau) \cdot (\tau - a) \cdot e(g, h) = (P(\tau)-b) \cdot e(g,h) \\ \iff - & Q(\tau) \cdot (\tau -a) = P(\tau) - b - \end{align*} - $$ - - The bilinear mapping $e$ enables us to check this property without knowing the secret setup parameter $\tau$ -- Once this verification is complete, we can conclude that (with overwhelmingly high probability) the quotient polynomial is correctly formed, and therefore that the evaluation is correct. - -## Learn more - -- [https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html) -- [https://alinush.github.io/2020/05/06/kzg-polynomial-commitments.html](https://alinush.github.io/2020/05/06/kzg-polynomial-commitments.html) -- [https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf) diff --git a/src/content/docs/en/learn/zero-knowledge/polynomial-commitment-schemes.md b/src/content/docs/en/learn/zero-knowledge/polynomial-commitment-schemes.md deleted file mode 100644 index 535c19104..000000000 --- a/src/content/docs/en/learn/zero-knowledge/polynomial-commitment-schemes.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Polynomial Commitment Schemes" -lang: "en" -permalink: "learn/zero-knowledge/polynomial-commitment-schemes" -excerpt: "Polynomial commitment schemes are a core building block of zero knowledge proof system" -whatsnext: { "KZG Commitment Scheme": "/en/learn/zero-knowledge/kzg-commitment-scheme" } ---- - -Polynomial commitment schemes are a core building block of zero knowledge proof systems (as well as other cryptographic protocols). - -As the name suggests, polynomial commitment schemes are commitment schemes where the object to be committed is a polynomial. These schemes also have a special property where an evaluation of the polynomial can be verified with access only to the polynomial’s commitment. - -## Commitment schemes - -A **[commitment scheme](https://en.wikipedia.org/wiki/Commitment_scheme)** is a cryptographic primitive involving two parties: a _committer_ and a _verifier_. The committer commits to a value $v$ by computing a commitment $c$ and revealing it to the verifier. At a later point in time, the committer can reveal the original value, and the verifier can verify that the commitment corresponds to this revealed value. - -Secure commitment schemes have two properties: - -1. **Binding**: once publishing the commitment $c$, the committer should not be able to find some other value $v’$ distinct from $v$ that also corresponds to $c$. I.e., the commitment $c$ binds the committer to the original value $v$. -2. **Hiding**: the verifier should not be able to learn any information about the original value $v$ from the commitment $c$. I.e., the commitment $c$ hides all information about the original value $v$. - -## Polynomial commitment schemes - -A **polynomial commitment scheme** is a commitment scheme where the committer commits to a polynomial $P(x)$ by computing a commitment $c$. As in normal commitment schemes, the committer can later reveal the original polynomial, and the verifier can check that the commitment corresponds to the revealed polynomial. However, polynomial commitment schemes have an additional property: the committer can prove particular evaluations of the committed polynomial without revealing the polynomial itself. For example, the committer can prove that $P(a) = b$, and the verifier can verify such a proof using just the commitment $c$. - -Polynomial commitment schemes are extremely useful for zero knowledge applications. A prover can use such a scheme to prove that he knows some polynomial which satisfies certain properties (e.g. that it passes through a certain point $(a,b)$), without revealing the underlying polynomial. - -Another reason why polynomial schemes are useful is that the commitment $c$ is generally much smaller than the polynomial it represents, and can thus be thought of as a **compression** of the polynomial $P(x)$. The magnitude of compression depends on the particular scheme. For example, in the KZG polynomial commitment scheme, a polynomial of arbitrarily large degree can be compressed down to a commitment consisting of a single group element. - -## Learn more - -- [https://en.wikipedia.org/wiki/Commitment_scheme](https://en.wikipedia.org/wiki/Commitment_scheme) -- [https://learn.0xparc.org/materials/halo2/miscellaneous/polynomial-commitment](https://learn.0xparc.org/materials/halo2/miscellaneous/polynomial-commitment) diff --git a/src/content/docs/en/sdk/guides/_images/AddNewWebhookToWorkspace.png b/src/content/docs/en/sdk/guides/_images/AddNewWebhookToWorkspace.png deleted file mode 100644 index 49b18b478..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/AddNewWebhookToWorkspace.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/CopyWebhookURL.png b/src/content/docs/en/sdk/guides/_images/CopyWebhookURL.png deleted file mode 100644 index d80e2822c..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/CopyWebhookURL.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/CreateSlackApp.png b/src/content/docs/en/sdk/guides/_images/CreateSlackApp.png deleted file mode 100644 index 5a9ad5bd5..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/CreateSlackApp.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/aws-cloudflare-dns-wildcards.png b/src/content/docs/en/sdk/guides/_images/aws-cloudflare-dns-wildcards.png deleted file mode 100644 index 663b99fef..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/aws-cloudflare-dns-wildcards.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/aws-cloudflare-dns.png b/src/content/docs/en/sdk/guides/_images/aws-cloudflare-dns.png deleted file mode 100644 index ac3dfa039..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/aws-cloudflare-dns.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/aws-ebs-driver.png b/src/content/docs/en/sdk/guides/_images/aws-ebs-driver.png deleted file mode 100644 index 3a7edf62f..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/aws-ebs-driver.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/cloudflare-dns-frontends.png b/src/content/docs/en/sdk/guides/_images/cloudflare-dns-frontends.png deleted file mode 100644 index 9d6f5e2df..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/cloudflare-dns-frontends.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/cloudflare-dns.png b/src/content/docs/en/sdk/guides/_images/cloudflare-dns.png deleted file mode 100644 index e8515bddf..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/cloudflare-dns.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/do-cluster-connection.png b/src/content/docs/en/sdk/guides/_images/do-cluster-connection.png deleted file mode 100644 index 468c7235f..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/do-cluster-connection.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/do-connection-info.png b/src/content/docs/en/sdk/guides/_images/do-connection-info.png deleted file mode 100644 index 03cffe47a..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/do-connection-info.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/do-connection-pools.png b/src/content/docs/en/sdk/guides/_images/do-connection-pools.png deleted file mode 100644 index e88bfb850..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/do-connection-pools.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/do-database-restrictions-ip.png b/src/content/docs/en/sdk/guides/_images/do-database-restrictions-ip.png deleted file mode 100644 index 37f095891..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/do-database-restrictions-ip.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/do-database-restrictions.png b/src/content/docs/en/sdk/guides/_images/do-database-restrictions.png deleted file mode 100644 index 3b4c2077b..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/do-database-restrictions.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/do-database-setup.png b/src/content/docs/en/sdk/guides/_images/do-database-setup.png deleted file mode 100644 index b933ba826..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/do-database-setup.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/do-kubernetes-cluster-2.png b/src/content/docs/en/sdk/guides/_images/do-kubernetes-cluster-2.png deleted file mode 100644 index c4cc59cfd..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/do-kubernetes-cluster-2.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/do-kubernetes-cluster.png b/src/content/docs/en/sdk/guides/_images/do-kubernetes-cluster.png deleted file mode 100644 index 410dbe253..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/do-kubernetes-cluster.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/do-load-balancer.png b/src/content/docs/en/sdk/guides/_images/do-load-balancer.png deleted file mode 100644 index ea3099ee2..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/do-load-balancer.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/do-marketplace-addons.png b/src/content/docs/en/sdk/guides/_images/do-marketplace-addons.png deleted file mode 100644 index 744c68bde..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/do-marketplace-addons.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/do-vpc-network.png b/src/content/docs/en/sdk/guides/_images/do-vpc-network.png deleted file mode 100644 index ae09279cf..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/do-vpc-network.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/_images/grafana.png b/src/content/docs/en/sdk/guides/_images/grafana.png deleted file mode 100644 index 147222599..000000000 Binary files a/src/content/docs/en/sdk/guides/_images/grafana.png and /dev/null differ diff --git a/src/content/docs/en/sdk/guides/aws-deployment.mdx b/src/content/docs/en/sdk/guides/aws-deployment.mdx deleted file mode 100644 index f10e11d8c..000000000 --- a/src/content/docs/en/sdk/guides/aws-deployment.mdx +++ /dev/null @@ -1,875 +0,0 @@ ---- -section: sdk -date: Last Modified -title: "AWS EKS Deployment" -lang: "en" -permalink: "sdk/guides/aws-deployment" -excerpt: "Learn how to deploy the Scroll SDK on AWS EKS." ---- - -import Aside from "../../../../../components/Aside.astro"; -import ClickToZoom from "../../../../../components/ClickToZoom.astro"; -import Steps from '../../../../../components/Steps/Steps.astro'; -import ToggleElement from "../../../../../components/ToggleElement.astro"; -import AWSCloudflareDNSWildcards from "./_images/aws-cloudflare-dns-wildcards.png"; -import AWSCloudflareDNS from "./_images/aws-cloudflare-dns.png"; -import AWSEBSDriver from "./_images/aws-ebs-driver.png"; -import CreateSlackApp from "./_images/CreateSlackApp.png" -import AddNewWebhookToWorkspace from "./_images/AddNewWebhookToWorkspace.png" -import CopyWebhookURL from "./_images/CopyWebhookURL.png" -import GrafanaDashboard from "./_images/grafana.png" - -This guide demonstrates how to deploy a Scroll SDK on Amazon Web Services (AWS) using Elastic Kubernetes Service (EKS) and other managed services. - -This guide is designed for chain owners and developers who may not be DevOps experts but want to understand the process of setting up a more sophisticated cloud deployment compared to a local devnet. - - - - - - -## Getting your machine ready - -### Installing Prerequisites - -Ensure you have the following tools installed on your local machine: - -- [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) -- [eksctl](https://eksctl.io/installation/) -- [kubectl](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html) -- [Helm](https://helm.sh/docs/intro/install/) -- [Docker](https://docs.docker.com/get-docker/) -- [Node.js](https://nodejs.org/en/download/) ≥ 18 -- [jq](https://jqlang.github.io/jq/download/) -- [scroll-sdk-cli](https://www.npmjs.com/package/@scroll-tech/scroll-sdk-cli) -- [k9s](https://k9scli.io/topics/install/) (optional, but recommended for cluster management) - - -Make sure to follow the installation instructions for each tool on their respective websites. For `kubectl`, you can refer to the detailed installation steps provided in the [Amazon EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html). - -To install the latest version of scroll-sdk-cli, run: - -```bash -npm install -g @scroll-tech/scroll-sdk-cli -``` - -{/* TODO: Replace with new command */} - -Verify your setup by running: - -```bash -scrollsdk test dependencies -``` - -### Configuring AWS CLI - -Before we begin, you need to configure your AWS CLI with your credentials: - -1. Create an IAM user in AWS with appropriate permissions (AdministratorAccess for simplicity, but you may want to restrict this in production). -2. Get the Access Key ID and Secret Access Key for this user. -3. Run the following command and enter your credentials when prompted: - -```bash -aws configure -``` - -This will create a `~/.aws/credentials` file with your AWS credentials. - -### Setting up your Owner Wallet - -The chain owner has the ability to upgrade essential contracts. We recommend setting up a Safe with at least 2 independently controlled signers required for managing upgrades. You may also consider adding as signers any external party that will help you execute upgrades, as they'll be able to propose new transactions. - -For this demo, we'll use a temporary development account created in MetaMask. Make sure to save the private key securely. - -## Setting up your infrastructure - -### Creating an EKS Cluster - -Let's create our EKS cluster using `eksctl`. Run the following command: - -```bash -eksctl create cluster \ - --name scroll-sdk-cluster \ - --region us-west-2 \ - --nodegroup-name standard-workers \ - --node-type t3.2xlarge \ - --nodes 3 \ - --nodes-min 1 \ - --nodes-max 4 \ - --managed -``` - -This will create a cluster with 3 t3.2xlarge nodes, which should be sufficient for our needs. Adjust the region and node type as needed. - -### Configuring Persistent Storage - -After creating your EKS cluster, you need to set up persistent storage using Amazon Elastic Block Store (EBS). This involves installing the EBS CSI driver, configuring IAM permissions, and setting a default storage class. - -#### Installing the EBS CSI Driver - -The EBS Container Storage Interface (CSI) driver allows your Kubernetes cluster to manage the lifecycle of Amazon EBS volumes for persistent storage. - -1. Navigate to the EKS console for your cluster. -2. Go to the "Add-ons" section and install the "Amazon EBS CSI Driver" add-on. - - - -#### Configuring IAM Permissions - -To allow your EKS nodes to interact with EBS volumes, attach the appropriate IAM policy: - -```bash -# Create an EBS policy file named ebs-policy.json: -{ - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": [ - "ec2:CreateVolume", - "ec2:DeleteVolume", - "ec2:AttachVolume", - "ec2:DetachVolume", - "ec2:DescribeVolumes", - "ec2:DescribeVolumesModifications", - "ec2:ModifyVolume" - ], - "Resource": "*" - } - ] -} - -# Create the IAM policy: -aws iam create-policy --policy-name EKSNodeEBSPolicy --policy-document file://ebs-policy.json - -# Identify your node group's IAM role: -aws eks describe-nodegroup --cluster-name scroll-sdk-cluster --nodegroup-name standard-workers --query "nodegroup.nodeRole" --output text --region us-west-2 - -# Attach the policy to the node group's role: -aws iam attach-role-policy --role-name --policy-arn arn:aws:iam:::policy/EKSNodeEBSPolicy -``` - -Be sure to replace `` and `` with your specific details. - -#### Setting the Default Storage Class - -To ensure that your Kubernetes pods can automatically provision EBS volumes: - -```bash -# Verify available storage classes: -kubectl get sc - -# Create a new gp3 storage class: -cat < \ - --allocated-storage 20 \ - --vpc-security-group-ids $SECURITY_GROUP_ID \ - --db-subnet-group-name scroll-sdk-subnet-group \ - --db-name scrolldb \ - --publicly-accessible \ - --region us-west-2 - -# Wait for the database to be available -aws rds wait db-instance-available --db-instance-identifier scroll-sdk-db --region us-west-2 -``` - -This command sequence does the following: -- Gets the VPC ID of our EKS cluster -- Creates a new security group for our RDS instance in the same VPC -- Gets the security group ID for the EKS cluster -- Allows inbound PostgreSQL traffic from the EKS cluster security group -- Gets the subnet IDs in the VPC -- Creates a DB subnet group using the VPC subnets -- Creates a PostgreSQL database named `scrolldb` -- Uses a `db.t3.2xlarge` instance (suitable for testing, adjust as needed) -- Sets the master username to `scrolladmin` (change this as desired) -- Allocates 20GB of storage -- Makes the database publicly accessible for initial setup (we'll restrict access later) -- Creates the database in the `us-west-2` region (adjust as needed) - -Make sure to replace `` with a strong password. - -After the database is created, you can retrieve its endpoint using: - -```bash -aws rds describe-db-instances --db-instance-identifier scroll-sdk-db --query "DBInstances[0].Endpoint.Address" --output text --region us-west-2 -``` -Make note of this endpoint, as you'll need it when configuring your Scroll SDK. - -### Setting up a Load Balancer - -When you install the NGINX Ingress Controller, it automatically creates an AWS Elastic Load Balancer (ELB) for you. This load balancer is used to route external traffic to your Kubernetes services. - -To view the created load balancer: - -1. Wait a few minutes after installing the NGINX Ingress Controller for the load balancer to be provisioned. - -2. You can check the status of the load balancer creation by running: - - ```bash - kubectl get services -n kube-system - ``` - - Look for a service named something like `nginx-ingress-ingress-nginx-controller`. The `EXTERNAL-IP` column will show the DNS name of your load balancer once it's ready. - -3. You can also view the load balancer in the AWS Console: - - Go to the EC2 dashboard - - Click on "Load Balancers" in the left sidebar - - You should see a new load balancer created for your NGINX Ingress Controller - -Remember the DNS name of this load balancer, as you'll need to point your domain to this address when configuring DNS. - - - -We'll configure the routing rules for this load balancer when we set up our ingress resources later in this guide. - -### Configuring your DNS with Cloudflare - -We'll use Cloudflare for DNS management, setting up a subdomain and a wildcard record. Here's how to set it up: - -1. If you haven't already, create a Cloudflare account and add your domain to Cloudflare. - -2. In the Cloudflare dashboard, go to the DNS settings for your domain. - -3. Add two new DNS records: - - a. Subdomain record: - - Type: CNAME - - Name: scrollsdk - - Target: Paste the DNS name of your AWS load balancer (the EXTERNAL-IP you noted earlier) - - Proxy status: Set to "DNS only" (grey cloud icon) to bypass Cloudflare's proxy - - b. Wildcard record: - - Type: CNAME - - Name: *.scrollsdk - - Target: scrollsdk.yourdomain.xyz - - Proxy status: Set to "DNS only" (grey cloud icon) - -4. Save your changes. - - - - - - - -Remember to update your Scroll SDK configuration to use these new subdomains. For example, you might use: - -- frontends.scrollsdk.yourdomain.xyz for your frontend -- l2-rpc.scrollsdk.yourdomain.xyz for your API - -Make sure to update these in your `config.toml` file and any other relevant configuration files. - - - -### Connecting to your Cluster - -After creating the cluster, `eksctl` should have automatically updated your kubeconfig. Verify the connection by running: - -```bash -kubectl get nodes -``` - -You should see your cluster nodes listed. - -### Adding External Secrets Operator - -Scroll SDK uses [External Secrets](https://external-secrets.io/latest/introduction/getting-started/) to manage sensitive information. Once you have `kubectl` working with your cluster, run the following: - -```bash -helm repo add external-secrets https://charts.external-secrets.io -helm repo update -helm install external-secrets external-secrets/external-secrets -n external-secrets --create-namespace -``` - -## Setup your local repo - -Create a directory for your project and initialize a git repository: - -```bash -mkdir aws-scroll-sdk && cd aws-scroll-sdk && git init -``` - -## Configuration - -### Grabbing Files from `scroll-sdk` - -We'll want two files from the `scroll-sdk` repo. You can either copy-paste the contents from GitHub or copy the files from another location you've cloned. - -Here, I'll copy them from a local repo copy. - -```bash -cp ../scroll-sdk/examples/config.toml.example ./config.toml -``` - -```bash -cp ../scroll-sdk/examples/Makefile.example ./Makefile -``` - -```bash -cp -r ../scroll-sdk/examples/values values -``` - -`Config.toml` will be used to set up the base configuration of our chain, from which each service's independent config files will be generated. `Makefile` will allow us to directly run `helm` commands in an automated way. The `values` directory contains the starter values for each service's `production.yaml` file, where we'll customize the behavior of each chart. - -### Preparing our Config.toml file - -Although these values can be set manually, we have a number of "setup" methods in the `scroll-sdk-cli` to help you quickly configure your stack. - -### Setting Domains - -We want to set up our ingress hosts and the URLs used by our frontend sites. These will often be the same, but are defined separately to allow flexibility in architecture and usage of HTTP while in development. - -If you're using a public testnet like Scroll Sepolia, please have a private L1 RPC URL ready for HTTPS and WSS. Public RPC endpoints are too unreliable for supporting the SDK backend services. - -First, run `scrollsdk setup domains` to begin an interactive session for setting the values. - -``` -Current domain configurations: -EXTERNAL_RPC_URI_L1 = "http://l1-devnet.scrollsdk" -EXTERNAL_RPC_URI_L2 = "http://l2-rpc.scrollsdk" -BRIDGE_API_URI = "http://bridge-history-api.scrollsdk/api" -ROLLUPSCAN_API_URI = "http://rollup-explorer-backend.scrollsdk/api" -EXTERNAL_EXPLORER_URI_L1 = "http://l1-explorer.scrollsdk" -EXTERNAL_EXPLORER_URI_L2 = "http://blockscout.scrollsdk" -ADMIN_SYSTEM_DASHBOARD_URI = "http://admin-system-dashboard.scrollsdk" -GRAFANA_URI = "http://grafana.scrollsdk" - -Current ingress configurations: -FRONTEND_HOST = "frontends.scrollsdk" -BRIDGE_HISTORY_API_HOST = "bridge-history-api.scrollsdk" -ROLLUP_EXPLORER_API_HOST = "rollup-explorer-backend.scrollsdk" -COORDINATOR_API_HOST = "coordinator-api.scrollsdk" -RPC_GATEWAY_HOST = "l2-rpc.scrollsdk" -BLOCKSCOUT_HOST = "blockscout.scrollsdk" -ADMIN_SYSTEM_DASHBOARD_HOST = "admin-system-dashboard.scrollsdk" -L1_DEVNET_HOST = "l1-devnet.scrollsdk" -L1_EXPLORER_HOST = "l1-explorer.scrollsdk" -? Select the L1 network: Anvil (Local) -? Enter the L1 Chain Name: l1-devnet -? Enter the L1 Chain ID: 31337 -Using l1-devnet network: -L1 Chain Name = "l1-devnet" -L1 Chain ID = "31337" -Updated [general] L1_RPC_ENDPOINT = "http://l1-devnet:8545" -Updated [general] L1_RPC_ENDPOINT_WEBSOCKET = "ws://l1-devnet:8546" -? Do you want all external URLs to share a URL ending? yes -? Enter the shared URL ending: scrollsdk.yourdomain -? Choose the protocol for the shared URLs: HTTPS -? Do you want the frontends to be hosted at the root domain? (No will use a "frontends" subdomain) no - -New domain configurations: -EXTERNAL_RPC_URI_L2 = "https://l2-rpc.scrollsdk.yourdomain.xyz" -BRIDGE_API_URI = "https://bridge-history-api.scrollsdk.yourdomain/api" -ROLLUPSCAN_API_URI = "https://rollup-explorer-backend.scrollsdk.yourdomain/api" -EXTERNAL_EXPLORER_URI_L2 = "https://blockscout.scrollsdk.yourdomain" -ADMIN_SYSTEM_DASHBOARD_URI = "https://admin-system-dashboard.scrollsdk.yourdomain" -EXTERNAL_RPC_URI_L1 = "https://l1-devnet.scrollsdk.yourdomain" -EXTERNAL_EXPLORER_URI_L1 = "https://l1-explorer.scrollsdk.yourdomain" - -New ingress configurations: -FRONTEND_HOST = "frontends.scrollsdk.yourdomain" -BRIDGE_HISTORY_API_HOST = "bridge-history-api.scrollsdk.yourdomain" -ROLLUP_EXPLORER_API_HOST = "rollup-explorer-backend.scrollsdk.yourdomain" -COORDINATOR_API_HOST = "coordinator-api.scrollsdk.yourdomain" -RPC_GATEWAY_HOST = "l2-rpc.scrollsdk.yourdomain" -BLOCKSCOUT_HOST = "blockscout.scrollsdk.yourdomain" -ADMIN_SYSTEM_DASHBOARD_HOST = "admin-system-dashboard.scrollsdk.yourdomain" -L1_DEVNET_HOST = "l1-devnet.scrollsdk.yourdomain" -L1_EXPLORER_HOST = "l1-explorer.scrollsdk.yourdomain" - -New general configurations: -CHAIN_NAME_L1 = "l1-devnet" -CHAIN_ID_L1 = "31337" -L1_RPC_ENDPOINT = "http://l1-devnet:8545" -L1_RPC_ENDPOINT_WEBSOCKET = "ws://l1-devnet:8546" -? Do you want to update the config.toml file with these new confi -{/* TODO: The prompt seems to be cut off. Ensure the instruction is complete. */} -``` - - - -### Initializing our Databases and Database Users - -We need to temporarily allow public access to our RDS instance to run the initial setup. After setup, we'll revert these changes to maintain security. - -1. Update the security group to allow inbound traffic from any IP: - -```bash -aws ec2 authorize-security-group-ingress \ ---group-id $SECURITY_GROUP_ID \ ---protocol tcp \ ---port 5432 \ ---cidr 0.0.0.0/0 \ ---region us-west-2 -``` - -2. Get the public endpoint of your RDS instance: - -```bash -aws rds describe-db-instances \ ---db-instance-identifier scroll-sdk-db \ ---query 'DBInstances[0].Endpoint.Address' \ ---output text \ ---region us-west-2 -``` - -3. Run the database initialization: - -```bash -scrollsdk setup db-init -``` - -Next, follow the prompts to create the new database users and passwords. - -When prompted “Do you want to connect to a different database cluster for this database?”, type “no”. - -Lastly, when asked “Do you want to update the config.toml file with the new DSNs?” select “yes” to update your config. - -4. Reverting RDS to Private Access: - -After initializing your databases, it's important to revert the RDS instance to private access for improved security. Follow these steps: - -```bash -# 1. Remove the public accessibility: -aws rds modify-db-instance \ - --db-instance-identifier scroll-sdk-db \ - --no-publicly-accessible \ - --apply-immediately \ - --region us-west-2 - -# 2. Remove the temporary security group rule that allowed public access: -aws ec2 revoke-security-group-ingress \ - --group-id $SECURITY_GROUP_ID \ - --protocol tcp \ - --port 5432 \ - --cidr 0.0.0.0/0 \ - --region us-west-2 - -# 3. Wait for the changes to take effect: -aws rds wait db-instance-available --db-instance-identifier scroll-sdk-db --region us-west-2 -``` - -These steps ensure that your RDS instance is only accessible from within your VPC, enhancing the security of your deployment. - -### Generate Keystore Files - -Next, we need to generate new private keys for the sequencer signer and the SDK accounts used for on-chain activity. The prompt will also ask if you want to set up backup sequencers. These will be standby full nodes ready to take over the sequencer role if needed for recovery or key rotation. This step will also allow you to set up pre-defined bootnodes. - -This step will also update `L2_GETH_STATIC_PEERS` to point to all sequencers as well. - -Follow the prompt by running `scrollsdk setup gen-keystore`. Use the Owner wallet address of the multi-sig generated in the first step, or for testing, allow the script to generate a wallet for you. But, be sure to save the private key, as it should not be stored in config.toml! - -### Generate Configuration Files - -Now, we'll do the last steps for generating each service's configuration files based on our values in `config.toml`. - -Run `scrollsdk setup configs`. - -You'll see a few prompts to update a few remaining values, like the L1 height at contract deployment and the "deployment salt" which should be unique per new deployment with a deployer address. - -Now, we'll simulate contract deployment to get contract addresses and build the config files and secrets files for all SDK services. Secrets will be written to `./secrets` and config files to `./values`. If you want the config files written to a different directory, pass the `--configs-dir` flag. - -### Pull Charts and Move Config Files - -Now, we need to prepare the Helm charts. We will check access to charts, review the Makefile, and check the values files for any missing values. - -To do this, run `scrollsdk setup prep-charts` - - - -After pulling the charts, the CLI tool will try to auto-fill each chart's `production.yaml` file. - -You will be prompted with each update and even flagged for empty values. Be sure to sanity check these values to make sure you didn't set up something incorrectly earlier. If you did, re-run any earlier steps, being sure to rerun the `setup configs` command before running `setup prep-charts`. - -### Push Secrets - -Lastly, we need to take the configuration values that are sensitive and publish them to wherever we're deploying "secrets." - -We'll use AWS Secrets Manager to store our secrets. First, let's set up the necessary permissions and create a ServiceAccount: - -1. Create an IAM policy for accessing Secrets Manager: - -```bash -cat < secretsmanager-policy.json -{ - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": [ - "secretsmanager:GetSecretValue", - "secretsmanager:DescribeSecret", - "secretsmanager:PutSecretValue", - "secretsmanager:CreateSecret", - "secretsmanager:DeleteSecret", - "secretsmanager:TagResource" - ], - "Resource": "*" - } - ] -} -EOF - -aws iam create-policy --policy-name ExternalSecretsPolicy --policy-document file://secretsmanager-policy.json -``` - -2. Associate an IAM OIDC provider with your cluster: - -```bash -eksctl utils associate-iam-oidc-provider --region=us-west-2 --cluster=scroll-sdk-cluster --approve -``` - -3. Create a ServiceAccount and associate it with the IAM role: - -```bash -eksctl create iamserviceaccount \ - --name external-secrets \ - --namespace default \ - --cluster scroll-sdk-cluster \ - --attach-policy-arn arn:aws:iam::YOUR_AWS_ACCOUNT_ID:policy/ExternalSecretsPolicy \ - --approve \ - --region us-west-2 -``` - -Remember to replace `YOUR_AWS_ACCOUNT_ID` with your actual AWS account ID. - -4. Create a SecretStore: - -```yaml -apiVersion: external-secrets.io/v1beta1 -kind: SecretStore -metadata: - name: aws-secretsmanager -spec: - provider: - aws: - service: SecretsManager - region: us-west-2 - auth: - jwt: - serviceAccountRef: - name: external-secrets -``` - -Apply this configuration: - -```bash -kubectl apply -f secretstore.yaml -``` - -Now, push your secrets: - -```bash -scrollsdk setup push-secrets -``` - -Select "AWS" when prompted. - -You'll be asked to update your `production.yaml` files, and we'll be ready to deploy! - -### Enable TLS & HTTPS - -Next, we'll want to enable HTTPS access. You should have already enabled Cert Manager in the previous step. - -Now, save the following file as `cluster-issuer.yaml` (being sure to use your own email address) then run `kubectl apply -f cluster-issuer.yaml` - -```yaml -apiVersion: cert-manager.io/v1 -kind: ClusterIssuer -metadata: - name: letsencrypt-prod -spec: - acme: - server: https://acme-v02.api.letsencrypt.org/directory - email: replace.this@email.com - privateKeySecretRef: - name: letsencrypt-prod - solvers: - - http01: - ingress: - class: nginx -``` - -Next, run `scrollsdk setup tls` and walk through the instructions to update each of your `production.yaml` files that define an external hostname. - -## Deployment - -### Fund the Deployer - -We need to send some Anvil Devnet ETH to the Deployer — 2 ETH should do it. Run the following if you want to use your mobile wallet or have forgotten the account. - -```bash -scrollsdk helper fund-accounts -i -f 2 -``` - -`-i` is used for funding the deployer. Later we'll run this with different params to fund other SDK accounts. - -Now, let's fund the other L1 accounts. - -```bash -scrollsdk helper fund-accounts -f 0.2 -l 1 -``` - -Here, we pass `-l 1` to only fund the L1 accounts. Any L2 funding will fail at this point since we haven't launched the chain yet! - -### Installing the Helm Charts - -Run `make install` to install (or later, to upgrade) all the SDK charts needed. It may help to run the commands one-by-one the first time and check the deployment status. - -`k9s` is a useful tool for this. The sample Makefile also doesn't include Blockscout, but feel free to add it as well. -{/* TODO: Fix this once blockscout is official and added to Makefile */} - -### Fund L2 accounts - -Let's fund our L1 Gas Oracle Sender (an account on L2 😅) with some funds. - -```bash -scrollsdk helper fund-accounts -f 0.2 -l 2 -``` - -This will fund it with 0.2 of our gas token. Select "Directly fund L2 Wallet" for now, since our Deployer starts with 1 token on L2. But now we have a working chain, so we can start bridging funds! - -## Testing - -`scroll-sdk-cli` has a number of tools built in for testing your new network. These commands should be run from the same directory as your `config.toml` and `config-contracts.toml` files. - -### Ingress - -Run `scrollsdk test ingress` to check all ingresses and that they match the expected value. If you're not using the default namespace, add `-n [namespace]`. - -### Contracts - -Run `scrollsdk test contracts` to check all contract deployments, initialization, and owner updates. - -### e2e Test - -Run `scrollsdk test e2e` to try end-to-end testing. Without any flags, the test will create and fund a new wallet, but depending on Sepolia gas costs, you may need to manually fund the generated account with additional ETH. If the tests stop at any time, just run `scrollsdk test e2e -r` to resume from the saved file. - -We recommend opening up another terminal and running `scrollsdk helper activity -i 1` to generate traffic and produce more blocks — otherwise, finalization will be stopped. - -### Frontends - -Go visit the frontends, connect your wallet, and try to bridge some funds! - -## Next Steps - -### Optimize EKS Node Groups for Specific Services - -As you work with your network, you might want to be more selective about the node groups you provide to services. - -One example is that the `l2-sequencer` may want additional CPU resources and the `coordinator-api` has RAM requirements far greater than other services. - -If you'd like to give this a try, create a new node group in your EKS cluster -- perhaps selecting instances with higher CPU and RAM. - -Now, in your `values/l2-sequencer-production-0.yaml` file, add the following section: - -```yaml -affinity: - nodeAffinity: - requiredDuringSchedulingIgnoredDuringExecution: - nodeSelectorTerms: - - matchExpressions: - - key: eks.amazonaws.com/nodegroup - operator: In - values: - - high-performance-nodegroup -resources: - requests: - memory: "450Mi" - cpu: "80m" - limits: - memory: "14Gi" - cpu: "7.5" -``` - -Here, we're asking it to only select nodes that are in the "high-performance-nodegroup" and increasing the resources of the pod to allow up to 7.5 CPU cores. - -To apply this, run: - -```bash -helm upgrade -i l2-sequencer-0 oci://ghcr.io/scroll-tech/scroll-sdk/helm/l2-sequencer \ - --version=0.0.11 \ - --values values/l2-sequencer-production-0.yaml -``` - -Replace with the version value from your Makefile. Add `-n [namespace]` if you're not using the default namespace. - -For more info, see the Kubernetes page on [Assigning Pods to Nodes](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/). - -### Add Redundancy with Replicas - -Soon, we'll add more information about quickly adding Replicas. - -For some components (like `l2-rpc` and all `-api` services), this is as easy as adding or modifying the following value in your production.yaml file: - -```yaml -controller: - replicas: 2 -``` - -Some services do not support this without additional configurations (for example, `l2-sequencer` and `l2-bootnode`). We are working on additional info on how to properly run multiple services for load balancing between or for having redundant backups available. - -{/* TODO: Fix this comment once we add this documentation */} - - -### Monitoring -You can monitor the cluster's running status through Grafana. -Additionally, you can send alerts via email and Slack using Alertmanager. -If you have configured a domain for Grafana in the previous steps, you can access it by opening http://grafana.yourdomain, where you will see two sets of dashboards. The defalt password of user `admin` is `scroll-sdk`. - - -#### send alert to slack -1. **Create a Slack App** - - Open [https://api.slack.com/apps](https://api.slack.com/apps) and click **`Create New App`** if you don't have one already. Select **`From scratch`**, enter a name, and select the workspace. - -2. **Activate Incoming Webhooks** - - Click the **`Incoming Webhooks`** label on the right side of the page, then turn on **`Activate Incoming Webhooks`**. - - - Click the **`Add New Webhook to Workspace`** button. - - - Select the channel you want to send alerts to, then copy the Webhook URL. - - - -3. **Edit the Config File** - - Edit `./values/alert-manager.yaml` to replace it with your webhook URL and your Slack channel name. - ``` - kube-prometheus-stack: - alertmanager: - config: - global: - resolve_timeout: 5m - slack_api_url: 'https://hooks.slack.com/services/xxxxxxxxxxx/xxxxxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxx' # your webhook url - receivers: - - name: 'slack-alerts' - slack_configs: - - channel: '#scroll-webhook' #your channel name - send_resolved: true - text: '{{ .CommonAnnotations.description }}' - title: '{{ .CommonAnnotations.summary }}' - route: - group_by: ['alertname'] - receiver: 'slack-alerts' - routes: - - matchers: [] - receiver: 'slack-alerts' - ``` - This configuration file will send all alerts to your Slack channel. If you need more complex rules, refer to the [Prometheus Alerting Configuration Documentation](https://prometheus.io/docs/alerting/latest/configuration/). - -4. **Update to alertmanager** - - Use the following command to update Alertmanager: - ``` - helm upgrade --reuse-values -i scroll-monitor oci://ghcr.io/scroll-tech/scroll-sdk/helm/scroll-monitor -n $(NAMESPACE) \ - --values ./values/alert-manager.yaml - ``` diff --git a/src/content/docs/en/sdk/guides/customizing-sdk-components.mdx b/src/content/docs/en/sdk/guides/customizing-sdk-components.mdx deleted file mode 100644 index 667d00cac..000000000 --- a/src/content/docs/en/sdk/guides/customizing-sdk-components.mdx +++ /dev/null @@ -1,123 +0,0 @@ ---- -section: sdk -date: Last Modified -title: "Customizing SDK Components" -lang: "en" -permalink: "sdk/guides/customizing-sdk-components" -excerpt: "Learn to make custom changes to Scroll SDK services" ---- - -import Aside from "../../../../../components/Aside.astro" -import ToggleElement from "../../../../../components/ToggleElement.astro" -import Steps from '../../../../../components/Steps/Steps.astro'; -import ClickToZoom from "../../../../../components/ClickToZoom.astro" - -## Overview - -This guide documents how to run customized components in your own Scroll SDK deployment. We'll see how to modify a service, build a custom Docker image, and deploy your changes to an existing Scroll SDK deployment. - -## Prerequisites - - -1. Clone the [scroll-sdk repo](https://github.com/scroll-tech/scroll-sdk) to your local machine -2. Install dependencies: - - [Docker](https://docs.docker.com/desktop/install/linux/) - - [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/) - - [minikube](https://minikube.sigs.k8s.io/docs/start/) - - [Helm](https://helm.sh/docs/intro/install/) -3. Verify installations by running: - - `docker -v` - - `kubectl version` - - `minikube status` - - `helm version` - - - - -## Modifying a Service - - -1. Clone the repository of the service you want to modify -2. Make your desired code modifications -3. Test your changes locally - - -#### Available Services - -| Service | Repository | -|---------|------------| -| bridge-history-api | [scroll-tech/scroll/bridge-history-api](https://github.com/scroll-tech/scroll/tree/develop/bridge-history-api/cmd/api) | -| bridge-history-fetcher | [scroll-tech/scroll/bridge-history-fetcher](https://github.com/scroll-tech/scroll/tree/develop/bridge-history-api/cmd/fetcher) | -| chain-monitor | [scroll-tech/chain-monitor](https://github.com/scroll-tech/chain-monitor) | -| contracts | [scroll-tech/scroll-contracts](https://github.com/scroll-tech/scroll-contracts/tree/feat-deterministic-deployment) | -| coordinator-api | [scroll-tech/scroll/coordinator-api](https://github.com/scroll-tech/scroll/tree/develop/coordinator/cmd/api) | -| coordinator-cron | [scroll-tech/scroll/coordinator-cron](https://github.com/scroll-tech/scroll/tree/develop/coordinator/cmd/cron) | -| frontends | [scroll-tech/frontends](https://github.com/scroll-tech/frontends) | -| gas-oracle | [scroll-tech/scroll/gas-oracle](https://github.com/scroll-tech/scroll/tree/develop/rollup/cmd/gas_oracle) | -| l1-devnet | [scroll-tech/scroll-sdk/l1-devnet](https://github.com/scroll-tech/scroll-sdk/blob/develop/custom-images/l1-devnet/Dockerfile) | -| l2-bootnode | [scroll-tech/go-ethereum](https://github.com/scroll-tech/go-ethereum) | -| l2-rpc | [scroll-tech/go-ethereum](https://github.com/scroll-tech/go-ethereum) | -| l2-sequencer | [scroll-tech/go-ethereum](https://github.com/scroll-tech/go-ethereum) | -| rollup-explorer-backend | [scroll-tech/rollup-explorer-backend](https://github.com/scroll-tech/rollup-explorer-backend) | -| rollup-node | [scroll-tech/scroll/rollup-node](https://github.com/scroll-tech/scroll/tree/develop/rollup/cmd/rollup_relayer) | - -## Building a Custom Docker Image - - -1. Locate the Dockerfile for your service -2. Build the image: - ```bash - docker build -f -t : . - ``` -3. Choose one of two options for making the image available: - - **Option 1: Publish to Docker Hub** - ```bash - docker login - docker push /: - ``` - - **Option 2: Load Directly to Minikube** - ```bash - minikube image load : - ``` - - - - -## Updating the Service Configuration - - -1. Locate the `values.yaml` file for your service in `devnet/scroll-sdk/charts//values.yaml` - -2. Update the `image` field based on your chosen deployment method: - - **For published Docker Hub images:** - ```yaml - image: - repository: / - pullPolicy: Always - tag: - ``` - - **For local Minikube images:** - ```yaml - image: - repository: - tag: - ``` - -3. Apply your changes: - ```bash - make install - ``` - -4. Verify the deployment: - ```bash - kubectl get pods - ``` - \ No newline at end of file diff --git a/src/content/docs/en/sdk/guides/devnet-deployment.mdx b/src/content/docs/en/sdk/guides/devnet-deployment.mdx deleted file mode 100644 index 8e5e7371d..000000000 --- a/src/content/docs/en/sdk/guides/devnet-deployment.mdx +++ /dev/null @@ -1,548 +0,0 @@ ---- -section: sdk -date: Last Modified -title: "Running Scroll SDK Devnet" -lang: "en" -permalink: "sdk/guides/devnet-deploymnet" -excerpt: "Run the Scroll SDK devnet locally to get started." ---- - -import Aside from "../../../../../components/Aside.astro" -import ToggleElement from "../../../../../components/ToggleElement.astro" -import Steps from '../../../../../components/Steps/Steps.astro'; -import { Tabs, TabsContent } from "../../../../../components/Tabs" - -## Overview - -This guide should get you started with running a local Scroll SDK devnet. Additionally, it has specific asides for running on macOS and Ubuntu. - -We've written this guide because local deployments of Kubernetes clusters can be finicky. Even the prerequisites can be tricky without help. - -By the end of the guide, you should have a Scroll SDK running with a block explorer, RPC, webUI, monitoring and metrics, and a local L1. These are all accessible to wallets, browsers, and applications running on your local machine. - - - - - - -
Updates to the Guide
- - - October 30, 2024 - - Updated for Scroll SDK v0.1.0 - - - -## Prerequisites - - -macOS -Ubuntu - - -1. Install dependencies (using `brew` is strongly recommended): - - [Brew](https://brew.sh/) (optional) - - `/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"` - - Docker ([Docker Desktop](https://docs.docker.com/desktop/install/mac-install/)) - - `brew install --cask docker` - - [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl-macos/) - - `brew install kubectl` - - [minikube](https://minikube.sigs.k8s.io/docs/start/?arch=%2Fmacos%2Farm64%2Fstable%2Fhomebrew) - - `brew install minikube` - - [Helm](https://helm.sh/docs/intro/install/#from-homebrew-macos) - - `brew install helm` - - [docker-mac-net-connect](https://github.com/chipmk/docker-mac-net-connect) (macOS ARM64 only) - - `brew install chipmk/tap/docker-mac-net-connect` - -2. *Optional:* Install dependencies for support CLI tool: - - [node >=18](https://nodejs.org/en/download/package-manager) - - `brew install nvm` - - `nvm install node` - - scroll-sdk-cli *(Experimental, APIs may change)* - - `npm install -g @scroll-tech/scroll-sdk-cli` -3. You should now be able to open a terminal and run the following: - - `docker -v` - - `kubectl version` - - `minikube status` - - `helm version` - - `node -v` - - `scrollsdk` - - Or, in one step: `scrollsdk test dependencies --dev` - - - - - -1. Update system packages: - ```bash - sudo apt update - sudo apt-get install make - ``` - -2. Install [Docker](https://docs.docker.com/engine/install/ubuntu/): - ```bash - # Add Docker's official GPG key - sudo apt-get install ca-certificates curl - sudo install -m 0755 -d /etc/apt/keyrings - sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc - sudo chmod a+r /etc/apt/keyrings/docker.asc - - # Add repository to Apt sources - echo \ - "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ - $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ - sudo tee /etc/apt/sources.list.d/docker.list > /dev/null - - sudo apt-get update - sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin - ``` - -3. Install [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/): - ```bash - curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" - sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl - ``` - -4. Install [minikube](https://minikube.sigs.k8s.io/docs/start/#linux): - ```bash - curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64 - sudo install minikube-linux-amd64 /usr/local/bin/minikube - rm minikube-linux-amd64 - ``` - -5. Install [Helm](https://helm.sh/docs/intro/install/#from-script): - ```bash - curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash - ``` - -6. Install [Node](https://github.com/nvm-sh/nvm#installing-and-updating) and [scroll-sdk-cli](https://github.com/scroll-tech/scroll-sdk-cli): - ```bash - curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash - # Re-login or source your shell configuration - nvm install 20 - npm install -g @scroll-tech/scroll-sdk-cli - ``` - {/* TODO: Update the cli command to use the new `scrollsdk` install command */} - -7. You should now be able to open a terminal and run the following: - - `docker -v` - - `kubectl version` - - `minikube status` - - `helm version` - - `node -v` - - `scrollsdk` - - Or, in one step: `scrollsdk test dependencies --dev` - - - - -### Starting minikube - -First, we need to allow minikube sufficient resources to run the devnet. - -```bash -minikube config set cpus 8 -minikube config set memory 8192 -``` - -Next, we start minikube. - - - - -macOS -Ubuntu - - -Mac requires extra commands as a work-around for `ingress-dns` not working correctly on arm64 MacOS. Hopefully the issue will be resolved in later versions of minikube. - -```bash -minikube start --driver=docker -minikube addons enable ingress -minikube addons enable ingress-dns - -# Additional steps for MacOS DNS resolution -minikube ssh "sudo apt-get update && sudo apt-get -y install qemu-user-static" -sudo brew services start chipmk/tap/docker-mac-net-connect -``` - - - - - -Add your user to the docker group. - -```bash -sudo usermod -aG docker $USER && newgrp docker -``` - -Now you are ready to start minikube. - -```bash -minikube start --driver=docker -minikube addons enable ingress -minikube addons enable ingress-dns -``` - - - -## Installing Scroll SDK - -{/* */} - - - -1. **Clone the `scroll-sdk` repo and find `devnet` directory** - - ```bash - git clone git@github.com:scroll-tech/scroll-sdk.git - cd scroll-sdk/devnet - ``` - -1. **Bootstrap** - - Now we'll install Helm chart dependencies, generate additional config files for our services, and create our `genesis.yaml` file. - - ```bash - make bootstrap - ``` - - {/* */} - -1. Optional: **Configure `values.yaml` and `config.toml`** - - This is the time to adjust what services run on your stack and their configuration. We suggest not altering these on your first installation, but see `charts/scroll-sdk/values.yaml` ([view on Github](https://github.com/scroll-tech/scroll-sdk/blob/develop/charts/scroll-sdk/values.yaml)) and `config.toml` ([view on Github](https://github.com/scroll-tech/scroll-sdk/blob/develop/charts/scroll-sdk/config.toml)). - - If you do make changes, you’ll need to run `make config` after to regenerate the additional configuration files. No services directly read from the `config.toml` file. - - -1. **Launch the chain!** - - ```bash - make install - ``` - - Your chain is now starting! Run `kubectl get pods` to check in on their progress. In the next section we'll expose the chain to your local machine so you can interact with the stack. - - The install process for the various containers can take several minutes as new docker images are downloaded and services wait on others to be online to start. - - - - - - -## After Launching the Stack - -### Configuring DNS - -Running `kubectl get ingress` should show all the domains setup within the cluster, like the following: - -``` -➜ scroll-sdk git:(develop) ✗ kubectl get ingress -NAME CLASS HOSTS ADDRESS PORTS AGE -admin-system-dashboard nginx admin-system-dashboard.scrollsdk 192.168.49.2 80 5h3m -blockscout-backend-ingress nginx blockscout-backend.scrollsdk 192.168.49.2 80 5h3m -blockscout-frontend-ingress nginx blockscout.scrollsdk 192.168.49.2 80 5h3m -bridge-history-api nginx bridge-history-api.scrollsdk 192.168.49.2 80 5h3m -frontends nginx frontends.scrollsdk 192.168.49.2 80 5h3m -grafana nginx grafana.scrollsdk 192.168.49.2 80 5h3m -l1-devnet nginx l1-devnet.scrollsdk 192.168.49.2 80 5h3m -l1-explorer-blockscout-ingress nginx l1-explorer-backend.scrollsdk 192.168.49.2 80 5h3m -l1-explorer-frontend-ingress nginx l1-explorer.scrollsdk 192.168.49.2 80 5h3m -l2-rpc nginx l2-rpc.scrollsdk 192.168.49.2 80 5h3m -l2-rpc-websocket nginx l2-rpc-ws.scrollsdk 192.168.49.2 80 5h3m -rollup-explorer-backend nginx rollup-explorer-backend.scrollsdk 192.168.49.2 80 5h3m -``` - - -macOS -Ubuntu - - - -Now, we'll follow the instructions from [the minikube docs](https://minikube.sigs.k8s.io/docs/handbook/addons/ingress-dns/#Mac) for setting up our local machine to use our cluster to resolve all `.scrollsdk` domain requests. - -Take note of the `ADDRESS` in your output (it should match the result of running `minikube ip`). - - -1. Create the following file at `/etc/resolver/minikube-scrollsdk` (will require `sudo` access). - - ``` - domain scrollsdk - nameserver - search_order 1 - timeout 5 - ``` - - Alternatively, this can be done in one command that creates the directory and file and then outputs the required info: - - ```bash - sudo mkdir -p /etc/resolver && sudo touch /etc/resolver/minikube-scrollsdk && sudo sudo sh -c "cat >>/etc/resolver/minikube-scrollsdk" <<-EOF - - domain scrollsdk - nameserver $(minikube ip) - search_order 1 - timeout 5 - EOF - ``` - -2. Flush your DNS: - - ```bash - sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - ``` - - - - - - -To resolve the ingress domains, we need to add the minikube IP and our service hostnames to the hosts file. - - -1. Get your minikube IP address: - - ```bash - minikube ip - ``` - - This should return something like `192.168.49.2`. - -2. Add this IP and our service hostnames to the hosts file: - - ```bash - # Open the hosts file in nano - sudo nano /etc/hosts - ``` - -3. Add the following entries to the file, replacing `192.168.49.2` with your minikube IP if different: - - ``` - 192.168.49.2 admin-system-dashboard.scrollsdk - 192.168.49.2 blockscout-backend.scrollsdk - 192.168.49.2 blockscout.scrollsdk - 192.168.49.2 bridge-history-api.scrollsdk - 192.168.49.2 frontends.scrollsdk - 192.168.49.2 grafana.scrollsdk - 192.168.49.2 l1-devnet.scrollsdk - 192.168.49.2 l1-explorer-backend.scrollsdk - 192.168.49.2 l1-explorer.scrollsdk - 192.168.49.2 l2-rpc.scrollsdk - 192.168.49.2 l2-rpc-ws.scrollsdk - 192.168.49.2 rollup-explorer-backend.scrollsdk - ``` - -4. Save the file by pressing `Ctrl+X`, then `Y`, then `Enter`. - - - - - -#### Testing Ingress DNS - -Now, test ingress and your access to the services by running `scrollsdk test ingress`. - -If you aren't using the CLI tool, you can manually test the ingress DNS by running: - -1. `nslookup frontends.scrollsdk $(minikube ip)` -2. `curl frontends.scrollsdk` -3. If those work, visit [`http://frontends.scrollsdk`](http://frontends.scrollsdk) in your browser. - -4. If those do not work: - - **For MacOS:** Try resetting your machine and running through the DNS setup instructions again. It may help to run `minikube stop` and `minikube start` again. - - **For Ubuntu:** Double check that your minikube IP matches what's in your `/etc/hosts` file by running `minikube ip`. - - -### Funding SDK Addresses - -You will need to provide funds to the following accounts: - - - `DEPLOYER_ADDR` *(only needs funded on L1)* - - In the default configuration, this account is pre-funded by Anvil. If changed, you'll need to relaunch the contracts pod after funding to deploy the contracts. - - `L1_COMMIT_SENDER_ADDR` - - `L1_FINALIZE_SENDER_ADDR` - - `L1_GAS_ORACLE_SENDER_ADDR` - - `L2_GAS_ORACLE_SENDER_ADDR` *(funded after L2 chain deployment)* - -If you installed the necessary prerequisites, you can run the CLI helper command to fund the accounts. - -```bash -cd scroll-sdk -scrollsdk helper fund-accounts --dev -``` - - - -### Other Useful Commands - -`kubectl get pods` will show all the active pods and their status. - -`kubectl get ingress` will show all the exposed services and URIs. - -`make delete` will stop all services. You wil also need to run `kubectl delete pvc data-l2-rpc-0` to delete the remaining pvc. - -`minikube dashboard` launches a WebUI for exploring the kubernetes cluster and the various pods, volumes and ingresses without learning all the CLI commands. `k9s` is also a CLI great tool for exploring running pods and quickly looking at their logs. - -If you need to update a specific service's config file (not the original `config.toml`): - 1. Make any necessary changes to the config files or helm charts - 2. Run `make install` - 3. Delete the running pod by running `kubectl delete pod [pod-name]`. Kubernetes will restart the pod with the updated config. - - -## Testing & Interacting with the Chain - -### scroll-sdk-cli - -The scroll-sdk-cli tool has many helper commands. Run it in the same directory as your `config.toml` file in the `./devnet/scroll-sdk` folder. - -- `scrollsdk test ingress` will test if your ingress is configured correctly and host urls are accessible from your machine. -- `scrollsdk test contracts` will check that essential contracts are deployed, initialized and have the correct owner. -- `scrollsdk helper fund-accounts --dev -a [account-address]` will fund any account. -- `scrollsdk helper activity -o -t` will generate activity on both layer one and layer two to help produce blocks and batches. - -#### End-To-End Test - -The `scrollsdk test e2e` command will walk you through generating the following tests on your chain: - -- Generate a new wallet -- Fund it from the Deployer address on L1 -- Deposit funds to the L2 -- Deploying an ERC20 and depositing them to the L2 -- Deploying an ERC20 on the L2 -- Bridging ETH and ERC20 from L2 back to L1 -- Executing the withdrawal claim on L1 - -If any step fails, you can restart where you left off by adding the `--resume` flag. - - - - -### Web UIs - -You should now be able to explore the stack on your local machine and using your web browser. All links below assume default configuration and working Ingress DNS. - -- Block Explorers (Blockscout) - - [L2 Explorer](http://blockscout.scrollsdk/) - - [L1 Explorer](http://l1-devnet-explorer.scrollsdk/) (this is scanning Anvil and can be a bit buggy) -- [Bridge](http://frontends.scrollsdk/bridge) - - Until some activity on the network has started, gas errors may occur. -- [Rollup Explorer](http://frontends.scrollsdk/rollupscan?page=1&per_page=10) - - Shows committed batches and finalized batches -- [Granfana Dashboards](http://grafana.scrollsdk/) - - Login - - User: `admin` - - Pass: `scroll-sdk` - - See “Scroll” dashboards on [this page](http://grafana.scrollsdk/dashboards). - -### Connecting to the RPC using a Wallet - -To connect directly to an RPC or using MetaMask, use: - -| Network | Scroll SDK Chain | Scroll SDK L1 | -|-------------|-------------|-------------| -| RPC URL | `http://l2-rpc.scrollsdk` | `http://l1-devnet.scrollsdk` | -| Chain ID | `221122` | `111111` | -| Currency Symbol | `ETH` | `ETH` | -| Block Explorer URL | [`http://blockscout.scrollsdk`](http://blockscout.scrollsdk/) | [`http://l1-devnet-explorer.scrollsdk`](http://l1-devnet-explorer.scrollsdk/) | - - - -## What's Next? - -If you're a developer, you might want to try [customizing specific sdk components](/sdk/guides/customizing-sdk-components). - -If you're looking to learn more about running a public testnet, try out a production deployment with our [Digital Ocean guide](/sdk/guides/production-deployment-digital-ocean) or our [AWS guide](/sdk/guides/production-deployment-aws). - -### Helpful Commands - -Anvil has a lot of [useful methods](https://book.getfoundry.sh/reference/anvil/#custom-methods) that can manipulate the L1. Proper documentation for using them is available in the [Hardhat docs](https://hardhat.org/hardhat-network/docs/reference#hardhat-network-methods) (replacing `hardhat_` with `anvil_`) - -#### Set L1 Token Balance of an Account - -In params, change first item to a wallet, and second to hex of wei. This config uses 1000 ETH. - -See [docs](https://hardhat.org/hardhat-network/docs/reference#hardhat_setbalance) for details. - -```bash -curl --location 'http://l1-devnet.scrollsdk/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc":"2.0", - "method":"anvil_setBalance", - "params":["0x98110937b5D6C5FCB0BA99480e585D2364e9809C","0x3635C9ADC5DEA00000"], - "id":0 -}' -``` - -#### Mine some L1 Block - -See [docs](https://hardhat.org/hardhat-network/docs/reference#hardhat_mine) for details. - -```bash -curl --location 'http://l1-devnet.scrollsdk/' \ ---header 'Content-Type: application/json' \ ---data '{ - "jsonrpc":"2.0", - "method":"anvil_mine", - "params":["0x10000000", "0xc"], - "id":0 -}' -``` - -## Troubleshooting - -### `ingress-dns` issues - -Getting `ingress-dns` can be tricky across different machines, operating systems and network configurations. - -**Directly editing `etc/hosts` has worked for some users, adding all ingress hosts pointing to the minikube IP address.** - -Follow the template below, being sure to create one value for every ingress in your configuration. Also, be sure to try the IP of your minikube deployment. - -For VPN users, we've seen the following work: - - -1. Execute command `sudo minikube tunnel` - -1. Open file `/etc/hosts` and add: - ``` - 127.0.0.1 l1-devnet.scrollsdk - 127.0.0.1 bridge-history.scrollsdk - 127.0.0.1 frontends.scrollsdk - 127.0.0.1 grafana.scrollsdk - 127.0.0.1 l1-devnet-explorer.scrollsdk - 127.0.0.1 l2-rpc.scrollsdk - 127.0.0.1 blockscout.scrollsdk - 127.0.0.1 bridge-history-api.scrollsdk - ``` - -1. Turn off VPN when visiting in browser - \ No newline at end of file diff --git a/src/content/docs/en/sdk/guides/digital-ocean-alt-gas-token.mdx b/src/content/docs/en/sdk/guides/digital-ocean-alt-gas-token.mdx deleted file mode 100644 index ad9632bd3..000000000 --- a/src/content/docs/en/sdk/guides/digital-ocean-alt-gas-token.mdx +++ /dev/null @@ -1,789 +0,0 @@ ---- -section: sdk -date: Last Modified -title: "Digital Ocean Deployment using an ERC20 Gas Token" -lang: "en" -permalink: "sdk/guides/digital-ocean-alt-gas-token" -excerpt: "Get accustomed to the process of running an SDK deployment." ---- - -import Aside from "../../../../../components/Aside.astro" -import ToggleElement from "../../../../../components/ToggleElement.astro" -import Steps from '../../../../../components/Steps/Steps.astro'; -import ClickToZoom from "../../../../../components/ClickToZoom.astro" - -import DOKubernetesCluster from "./_images/do-kubernetes-cluster.png" -import DOKubernetesCluster2 from "./_images/do-kubernetes-cluster-2.png" -import DOMarketplaceAddons from "./_images/do-marketplace-addons.png" -import DODatabaseSetup from "./_images/do-database-setup.png" -import DODatabaseRestrictions from "./_images/do-database-restrictions.png" -import DODatabaseRestrictionsIP from "./_images/do-database-restrictions-ip.png" -import DOLoadBalancer from "./_images/do-load-balancer.png" -import CloudflareDNS from "./_images/cloudflare-dns.png" -import CloudflareDNSFrontends from "./_images/cloudflare-dns-frontends.png" -import DOKubernetesConnect from "./_images/do-cluster-connection.png" -import DOConnectionPools from "./_images/do-connection-pools.png" -import DOConnectionInfo from "./_images/do-connection-info.png" -import DOVPCNetwork from "./_images/do-vpc-network.png" -import CreateSlackApp from "./_images/CreateSlackApp.png" -import AddNewWebhookToWorkspace from "./_images/AddNewWebhookToWorkspace.png" -import CopyWebhookURL from "./_images/CopyWebhookURL.png" -import GrafanaDashboard from "./_images/grafana.png" - -This guide documents getting a Scroll SDK deployment working on Digital Ocean's Kubernetes and managed databases, using Cloudflare for DNS. - -Though this isn't the most "sophisticated" cloud setup, it is a step more complicated than a local devnet. - -This guide is intended for chain owners and those that aren't DevOps professionals, to see what's involved and show the additional considerations that need to be made. - -Because using an alternative gas token introduces another element of complexity, we will use it here as well. - - - - - -## Getting your machine ready - -### Installing Prerequisites - -- kubectl -- helm -- docker -- node ≥ 18 -- [scroll-sdk-cli](https://www.npmjs.com/package/@scroll-tech/scroll-sdk-cli) *(see below)* -- doctl *(optional)* -- k9s *(optional)* - - -To install the latest version of scroll-sdk-cli, run `npm install -g @scroll-tech/scroll-sdk-cli` - -Then, run `scrollsdk test dependencies` to test that the tool works and to check the required dependencies listed above. - -### Setting up your Owner Wallet - -The chain owner has the ability to upgrade essential contracts. We recommend setting up a Safe with at least 2 independently controlled signers required for managing upgrades. You may also consider adding as signers any external party that will help you execute upgrades, as they'll be able to propose new transactions. - -For this demo, I'll use a temporary development account created in MetaMask. - -## Setting up your infrastructure - -### Creating a Kubernetes Cluster - -First, we need to setup the cluster of machines that our services will be deployed on. - -Here, we will opt for simplicity — you may want to have specific machines better catered to specific services. But, we've chosen 10Gbps to handle the heavy testing load and 32GB RAM machines to accommodate the Coordinator, which requires > 20GB. - - - - -### Installing Marketplace Add-Ons - -We know we'll want a Ingress Controller for handling in-bound requests, a monitoring stack and a certificate manager to support HTTPS connections. - -All of these can be installed and configured manually, but that falls outside the scope of this guide. Be sure to wait for the new cluster to be fully deployed before trying to install add-ons. - -We'll choose: - -- NGINX Ingress Controller -- Kubernetes Monitoring Stack -- Cert-Manager - - - -### Creating a Managed Database - -`scroll-sdk` uses 3 distinct databases, with 2 additional databases used for L1 and L2 Blockscout instances if needed. We'll setup a single database cluster that we'll host each database and user inside (more on the setup later). - -Although Digital Ocean supports a Database Service as part of its Kubernetes clusters, we'll instead just deploy a managed database. - -We'll select the same datacenter as our cluster, PostgresSQL latest version (v16), and start with a Basic - Shared CPU plan. We can always upgrade this configuration easily later on. The default 10GB of storage is okay for now as well. - - - -To better secure your database, restrict inbound connections. First, select your new Kubernetes cluster: - - - -Next, select your current IP so you can run the setup scripts locally later in this guide. - - - - -### Creating a Load Balancer - -DigitalOcean's NGINX Ingress Controller automatically deploys and configures a load balancer and give it an IP address, viewable in the "Networking" area of your dashboard. We'll use this IP for setting up DNS. - - - -### Configuring your DNS - -We've already [added a domain](https://developers.cloudflare.com/learning-paths/get-started-free/onboarding/add-and-activate/#_top) to be managed by Cloudflare. - -Here, we use a subdomain and wildcard to point to our load balancer. Because we don't have SSL certificates setup and Cloudflare requires additional configuration for wildcards and nested subdomains, we'll bypass the Proxy. The proxy also has limited support for traffic outside of HTTP & HTTPS traffic. - - - -Here, we'll also make one without the wildcard so that our frontends URL can live at that domain: - - - -### Connecting to your Cluster - -Next, we need to connect our local machine to the cluster in order to manage it. - -DigitalOcean provides two ways of doing this — we'll use the `doctl` based version. - -Run `doctl kubernetes cluster kubeconfig save [credential]` - -``` -Notice: Adding cluster credentials to kubeconfig file found in "/home/user/.kube/config" -Notice: Setting current-context to do-nyc1-scroll-sdk-alt-gas-demo -``` - - - -### Adding External Secrets Operator - -Scroll SDK uses [External Secrets](https://external-secrets.io/latest/introduction/getting-started/) to manage sensitive information. Once you have `kubctl` working with your cluster, please run the following: - -```bash -helm repo add external-secrets https://charts.external-secrets.io -helm repo update -helm install external-secrets external-secrets/external-secrets -n external-secrets --create-namespace -``` - -## Setup your local repo - -Let's now create a directory to host our local files and setup our git repo. - -```bash -mkdir do-alt-gas-demo && cd do-alt-gas-demo && git init -``` - -## Configuration - -### Grabbing Files from `scroll-sdk` - -We'll want two files from the `scroll-sdk` repo. You can either copy paste the contents from GitHub, or copy the files from another location you've cloned. - -Here, I'll copy them from a local repo copy. - -```bash -cp ../scroll-sdk/examples/config.toml.example ./config.toml -``` - -```bash -cp ../scroll-sdk/examples/Makefile.example ./Makefile -``` - -```bash -cp -r ../scroll-sdk/examples/values values -``` - -`Config.toml` will be used to setup our base configuration of our chain, from which each service's independent config files will be generated. `Makefile` will allow us to directly run `helm` commands in an automated way. The `values` directory contains the starter values for each service's `production.yaml` file, where we'll customize the behavior of each chart. - -### Preparing our Config.toml file - -Although these values can be set manually, we have a number of "setup" methods in the `scroll-sdk-cli` to help you quickly configure your stack. - -### Setting Domains - -We want to setup our ingress hosts and the URLs used by our frontend sites. These will often be the same, but are defined separately to allow flexibility in architecture and usage of HTTP while in development. - -If you're using a public testnet like Scroll Sepolia, please have a private L1 RPC URL ready for HTTPS and WSS. Public RPC endpoints are too unreliable for supporting the SDK backend services. - -First, run `scrollsdk setup domains` to begin an interactive session for setting the values. - -``` -Current domain configurations: -EXTERNAL_RPC_URI_L1 = "http://l1-devnet.scrollsdk" -EXTERNAL_RPC_URI_L2 = "http://l2-rpc.scrollsdk" -BRIDGE_API_URI = "http://bridge-history-api.scrollsdk/api" -ROLLUPSCAN_API_URI = "http://rollup-explorer-backend.scrollsdk/api" -EXTERNAL_EXPLORER_URI_L1 = "http://l1-explorer.scrollsdk" -EXTERNAL_EXPLORER_URI_L2 = "http://blockscout.scrollsdk" -? Are you using a public L1 network? yes -? Select the L1 network: Ethereum Sepolia Testnet -Using sepolia network: -L1 Explorer URL: https://sepolia.etherscan.io -L1 RPC URL: https://rpc.ankr.com/eth_sepolia -? Do you want to set custom L1 RPC endpoints for the SDK backend? yes -? Enter the L1 RPC HTTP endpoint for SDK backend: -https://xxxx.quiknode.pro/xxxxx/ -? Enter the L1 RPC WebSocket endpoint for SDK backend: -wss://xxxx.quiknode.pro/xxxxx/ -? Do you want all L2 external URLs to share a URL ending? yes -? Enter the shared URL ending: do-alt-gas-demo.scroll.xyz -? Choose the protocol for the shared URLs: HTTPS -? Do you want the frontends to be hosted at the root domain? (No will use a "frontends" subdomain) yes - -New domain configurations: -EXTERNAL_EXPLORER_URI_L1 = "https://sepolia.etherscan.io" -EXTERNAL_RPC_URI_L1 = "https://rpc.ankr.com/eth_sepolia" -EXTERNAL_RPC_URI_L2 = "https://l2-rpc.do-alt-gas-demo.scroll.xyz" -BRIDGE_API_URI = "https://bridge-history-api.do-alt-gas-demo.scroll.xyz/api" -ROLLUPSCAN_API_URI = "https://rollup-explorer-backend.do-alt-gas-demo.scroll.xyz/api" -EXTERNAL_EXPLORER_URI_L2 = "https://l2-explorer.do-alt-gas-demo.scroll.xyz" - -New ingress configurations: -FRONTEND_HOST = "do-alt-gas-demo.scroll.xyz" -BRIDGE_HISTORY_API_HOST = "bridge-history-api.do-alt-gas-demo.scroll.xyz" -ROLLUP_EXPLORER_API_HOST = "rollup-explorer-backend.do-alt-gas-demo.scroll.xyz" -COORDINATOR_API_HOST = "coordinator-api.do-alt-gas-demo.scroll.xyz" -RPC_GATEWAY_HOST = "l2-rpc.do-alt-gas-demo.scroll.xyz" -BLOCKSCOUT_HOST = "blockscout.do-alt-gas-demo.scroll.xyz" -? Do you want to update the config.toml file with these new configurations? yes -config.toml has been updated with the new domain configurations. -``` - - - -### Initializing our Databases and Database Users - -Return to DigitalOcean and get your admin connection information: - - - -Run `scrollsdk setup db-init`, select "yes" to Blockexplorer, "no" to L1 Explorer, then enter the public network host value from DigitalOcean, followed by the port, admin username and password, and default database. - -Now, input the information from the VPC Network panel, which is how pods will connect to the database from inside the virtual private network. - - - -Next, follow the prompts to create the new database users and passwords. - -When prompted "Do you want to connect to a different database cluster for this database?", type "no". - -Lastly, when asked "Do you want to update the config.toml file with the new DSNs?" select "yes" to update your config. - -### Dealing with Connections & Connection Pools - -DigitalOcean limits the number of incoming connections and we'll quickly reach this limitation for the basic cluster we've deployed. We'll setup "Connection Pools" so that services can leave their connections open, but share the "bandwidth" of number of active db transactions. - -In the DigitalOcean "Connection Pool" tab, create the following pools and choose their corresponding database, using "Transaction" Pool Mode. Pool size can be 4 for each. - -In the end, your Connection Pools page should look like this: - - - -Notice, these pool names use a different port to connect, so we need to modify `config.toml` to use this port number (for me, `25061`), or, if you altered the pool name, use it instead of the database name in the DSN string. - -You can do this manually or run `scrollsdk setup db-init --update-port 25061` - -### Generate Keystore Files - -Next, we need to generate new private keys for the sequencer signer and the SDK accounts used for on-chain activity. The prompt will also ask if you want to setup backup sequencers. These will be standby fullnodes ready to take over the sequencer role if needed for recovery or key rotation. This step will also allow you to setup pre-defined bootnodes. - -This step will also update `L2_GETH_STATIC_PEERS` to point to all sequencer as well. - -Follow the prompt by running `scrollsdk setup gen-keystore`. Use the Owner wallet address of the multi-sig generated in the first step, or for testing, allow the script to generate a wallet for you. But, be sure to save the private key, as it should not be stored in config.toml! - -### Define Gas Token Details - -If no token address specified, a new ERC20 will be deployed on L1. The Example decimal is only used for this deployed contract. - -Below configuration uses Aave DAI, see their faucet [here](https://staging.aave.com/faucet/). - -```toml -[gas-token] -ALTERNATIVE_GAS_TOKEN_ENABLED = true -L1_GAS_TOKEN = "0xFF34B3d4Aee8ddCd6F9AFFFB6Fe49bD371b8a357" -``` - -You can follow the prompt by running `scrollsdk setup gas-token` - - - -{/* TODO: Document using CLI for advanced configuration here. */} - -### Generate Configuration Files - -Now, we'll do the last steps for generating each service's configuration files based on our values in `config.toml`. - -Run `scrollsdk setup configs`. - -You'll see a few prompts to update a few remaining values, like the L1 height at contract deployment and the "deployment salt" which should be unique per new deployment with a deployer address. - -Now, we'll simulate contract deployment to get contract addresses and build the config files and secrets files for all SDK services. Secrets will be written to `./secrets` and config files to `./values`. If you want the config files written to a different directory, pass the `--configs-dir` flag. - -### Prep Charts Values - -Now, we need to prepare the Helm charts. We will check access to charts, review the Makefile and check the values files for any missing values. - -To do this, run `scrollsdk setup prep-charts` and the CLI tool will try to auto-fill each chart's `production.yaml` file. - -You will be prompted with each update, and even flagged for empty values. Be sure to sanity check these values to make sure you didn't setup something incorrectly earlier. If you did, re-run any earlier steps, being sure to rerun the `setup configs` command before running `setup prep-charts` . - -### Push Secrets - -Lastly, we need to take the configuration values that are sensitive and publish them to wherever we're deploying "secrets." - -Since DigitalOcean doesn't natively host a Secret Management tool like AWS or Azure, we'll use Hashicorp Vault to store our sensitive data like database connection strings and private keys. - -For the purposes of this demo, we will not host an independent version of Hashicorp vault, but instead launch a service in our cluster, and push values to this vault. Then, items from the store are made available to pods using [External Secrets](https://external-secrets.io/latest/). - -First, let's setup a local development setup of Hashicorp Vault. - -```bash -helm repo add hashicorp https://helm.releases.hashicorp.com -helm repo update -helm install vault hashicorp/vault --set "server.dev.enabled=true" -``` - -Next, we'll create a secret to store our access token and a SecretStore — copy paste the following text to `vault-secret-store.yaml` - -```bash -apiVersion: external-secrets.io/v1beta1 -kind: SecretStore -metadata: - name: vault-backend -spec: - provider: - vault: - server: "http://vault.default.svc.cluster.local:8200" - path: "scroll" - version: "v2" - auth: - tokenSecretRef: - name: vault-token - key: token ---- -apiVersion: v1 -kind: Secret -metadata: - name: vault-token -type: Opaque -stringData: - token: "root" # This is the default token in dev mode. Don't use in production! -``` - -Now, run `kubectl apply -f ./vault-secret-store.yaml` - -Next, run `scrollsdk setup push-secrets` and select "Hashicorp Vault - Dev". If you need guidance with another Secret Provider, please reach out. - -You'll be asked to update your `production.yaml` files, and we'll be ready to deploy! - -### Enable TLS & HTTPS - -Next, we'll want to enable HTTPS access. You should have already enabled Cert Manager through the DigitalOcean backend. - -Now, save the following file as `cluster-issuer.yaml` (being sure to use your own email address) then run `kubectl apply -f cluster-issuer.yaml` - -```bash -apiVersion: cert-manager.io/v1 -kind: ClusterIssuer -metadata: - name: letsencrypt-prod -spec: - acme: - server: https://acme-v02.api.letsencrypt.org/directory - email: replace.this@email.com - privateKeySecretRef: - name: letsencrypt-prod - solvers: - - http01: - ingress: - class: nginx -``` - -Next, run `scrollsdk setup tls` and walk through the instructions to update each of your `production.yaml` files that define an external hostname. - -## Deploying - -### Fund the Deployer - -We need to send some Sepolia ETH to the Deployer — 2 ETH should do it. Run the following if you want to use your mobile wallet or have forgotten the account. - -`scrollsdk helper fund-accounts -i -f 2` - -`-i` is used for funding the deployer. Later we'll run this with different params to fund other SDK accounts. - - - -Now, let's fund the other L1 accounts. - -`scrollsdk helper fund-accounts -f 0.2 -l 1` - -Here, we pass `-l 1` to only fund the L1 accounts. Any L2 funding will fail at this point since we haven't launched the chain yet! - -### Installing the Helm Charts - -Run `make install` to install (or later, to upgrade) all the SDK charts needed. It may help to run the commands one-by-one the first time, and check the deployment status. `k9s` is a useful tool for this. The sample Make file also doesn't include Blockscout, but feel free to add it as well. - -### Fund L2 accounts - -Let's fund our L1 Gas Oracle Sender (an account on L2 😅) with some funds. - -`scrollsdk helper fund-accounts -f 0.2 -l 2` will fund it with 0.2 of our gas token. Select "Directly fund L2 Wallet" for now, since our Deployer starts with 1 token starts with 1 token on L2. But now we have a working chain, so we can start bridging funds! - -## Testing - -`scroll-sdk-cli` has a number of tools built in for testing your new network. These commands should be run from the same directory as your `config.toml` and `config-contracts.toml` files. - -### Ingress - -Run `scrollsdk test ingress` to check all ingresses and that they match the expected value. If you're not using the default namespace, add `-n [namespace]`. - -### Contracts - -Run `scrollsdk test contracts` to check all contract deployments, initialization and owner updates. - -### e2e Test - -Run `scrollsdk test e2e` to try end-to-end testing. Without any flags, the test with create and fund a new wallet, but depending on Sepolia gas costs, you may need to manually fund the generated account with additional ETH. If the tests stop at any time, just run `scrollsdk test e2e -r` to resume from the saved file. - -We recommend opening up another terminal and running `scrollsdk helper activity -i 1` to generate traffic and produce more blocks — otherwise, finalization will be stopped. - -### Frontends - -Go visit the frontends, connect your wallet and try to bridge some funds! - -## Next Steps - -### Disable L1 Data Fee -On Scroll, transactions on L2 have two components -- the gas costs for execution and an L1 data fee. When gas on your network is paid in a token that has no standard relationship to the currency being used to pay for data fees on the L1, you will need to introduce tooling that can set the gas caluclation "scalar" values. - -At the moment, we have not built any automated tooling for this, and instead of viewing the ERC20 value as 1:1 with Sepolia Ether, we suggest setting the scalars to 0 to eliminate these overheads. - -To do so, you can run the following commands using your L2 RPC URL and Owner account private key: - -```bash -cast send --rpc-url http://l2-rpc.scrollsdk 0x5300000000000000000000000000000000000002 "setCommitScalar(uint256)" 0 --private-key [private-key] -cast send --rpc-url http://l2-rpc.scrollsdk 0x5300000000000000000000000000000000000002 "setBlobScalar(uint256)" 0 --private-key [private-key] -``` - -Or, if your Owner is just a test account, you can use it's private key to call this method: - -```bash -scrollsdk helper set-scalars -k [private-key] -``` - -### Deploy Blockscout - - - -As long as you setup the databases in the `scrollsdk setup db-init` step, you can download the chart, extract it, and run `helm upgrade -i blockscout blockscout --values blockscout/values/production.yaml` - -{/* Todo: return with instructions that add this directly as a Makefile command. */} - -### Optimize Machine Configuration with Node Affinity - -As you work with your network, you might want to be more selective about the pools you provide to services. - -One example is that the `l2-sequencer` may want additional CPU-resources and the `coordinator-api` has RAM requirements far greater than other services. - -If you'd like to give this a try, create a new "Node Pool" in DigitalOcean -- perhaps selecting "CPU Intensive - 8vCPU 16 GB RAM" and naming it "pool-sequencer". - -Now, in your `values/l2-sequencer-production-0.yaml` file, add the following section: - -```yaml -affinity: - nodeAffinity: - requiredDuringSchedulingIgnoredDuringExecution: - nodeSelectorTerms: - - matchExpressions: - - key: doks.digitalocean.com/node-pool - operator: In - values: - - pool-sequencer -resources: - requests: - memory: "450Mi" - cpu: "80m" - limits: - memory: "14Gi" - cpu: "7.5" -``` - -Here, we're adding asking it to only select nodes that are in the "pool-sequencer" and increasing the resources of the pod to allow up to 7.5 CPU cores. - -To apply this, run: - -```bash -helm upgrade -i l2-sequencer-0 oci://ghcr.io/scroll-tech/scroll-sdk/helm/l2-sequencer \ - --version=0.0.11 \ - --values values/l2-sequencer-production-0.yaml -``` - -Replace with the version value from your Makefile. Add `-n [namespace]` if you're not using the default namespace. - -For more info, see the Kubernetes page on [Assigning Pods to Nodes](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/). - -### Add Redundancy with Replicas - -Soon, we'll add more information about quickly adding Replicas. - -For some components (like `l2-rpc` and all `-api` services), this is as easy as adding or modifying the following value in your production.yaml file: - -```yaml -controller: - replicas: 2 -``` - -Some services do not support this without additional configurations (for example, `l2-sequencer` and `l2-bootnode`). We are working on additional info on how to properly run multiple services for loadbalancing between or for having redunant backups available. - -### Enable Proof Generation using External Providers - -The Scroll team has been collaborating closely with teams specializing in proof generation to enable plug-and-play proof generation for SDK networks. - -In this example, we'll use a sample chart from the `scroll-proving-sdk` repo to generate proofs with [Sindri](https://sindri.app/docs/introduction/). In the future, teams will publish their own charts for chains to easily enable one or external providers. - -Because this feature is not directly built into the Scroll SDK, there will be quite a bit of copy-pasting. - -#### Creating Values Files for each type of Provider - -In Scroll, we have 3 types of provers: chunk (type-1), batch (type-2), and bundle (type-3). We'll deploy 3 sets of the chart, each with a different type of prover. - -Create the following files in your `values` directory: - -`prover-chunk-production.yaml`: -```yaml -global: - nameOverride: &app_name prover-chunk - fullnameOverride: *app_name - -persistence: - config: - enabled: true - type: configMap - mountPath: /sdk_prover/ - name: prover-chunk-config - -scrollConfig: | - { - "prover_name_prefix": "sindri_chunk_", - "keys_dir": "keys", - "coordinator": { - "base_url": "http://coordinator-api:80", - "retry_count": 3, - "retry_wait_time_sec": 5, - "connection_timeout_sec": 60 - }, - "l2geth": { - "endpoint": "http://l2-rpc:8545" - }, - "prover": { - "circuit_type": 1, - "circuit_version": "v0.13.1", - "n_workers": 1, - "cloud": { - "base_url": "https://sindri.app/api/v1/", - "api_key": "", - "retry_count": 3, - "retry_wait_time_sec": 5, - "connection_timeout_sec": 60 - } - } - } -``` - -`prover-batch-production.yaml`: -```yaml -global: - nameOverride: &app_name prover-batch - fullnameOverride: *app_name - -persistence: - config: - enabled: true - type: configMap - mountPath: /sdk_prover/ - name: prover-batch-config - -scrollConfig: | - { - "prover_name_prefix": "sindri_batch_", - "keys_dir": "keys", - "coordinator": { - "base_url": "http://coordinator-api:80", - "retry_count": 3, - "retry_wait_time_sec": 5, - "connection_timeout_sec": 60 - }, - "l2geth": { - "endpoint": "http://l2-rpc:8545" - }, - "prover": { - "circuit_type": 2, - "circuit_version": "v0.13.1", - "n_workers": 1, - "cloud": { - "base_url": "https://sindri.app/api/v1/", - "api_key": "", - "retry_count": 3, - "retry_wait_time_sec": 5, - "connection_timeout_sec": 60 - } - } - } - -``` - -`prover-bundle-production.yaml`: -```yaml -global: - nameOverride: &app_name prover-bundle - fullnameOverride: *app_name - -persistence: - config: - enabled: true - type: configMap - mountPath: /sdk_prover/ - name: prover-bundle-config - -scrollConfig: | - { - "prover_name_prefix": "sindri_bundle_", - "keys_dir": "keys", - "coordinator": { - "base_url": "http://coordinator-api:80", - "retry_count": 3, - "retry_wait_time_sec": 5, - "connection_timeout_sec": 60 - }, - "l2geth": { - "endpoint": "http://l2-rpc:8545" - }, - "prover": { - "circuit_type": 3, - "circuit_version": "v0.13.1", - "n_workers": 1, - "cloud": { - "base_url": "https://sindri.app/api/v1/", - "api_key": "", - "retry_count": 3, - "retry_wait_time_sec": 5, - "connection_timeout_sec": 60 - } - } - } - -``` - -Be sure to set `prover.api_key` to the value created in Sindri's user dashboard. - -Notice that each file is similar, with only the `prover.circuit_type` and few name values changing. - -Lastly, set `prover.n_workers` to the number of provers you'd like to dedicate to proof generation. We recommend starting at 1 for each during testing, but scaling up as needed. - -#### Adding Provers to your Makefile - -Now, let's add the prover services to the bottom of your `Makefile`. - -``` -install-provers: - helm upgrade -i prover-chunk oci://ghcr.io/scroll-tech/scroll-sdk/helm/scroll-proving-sdk -n $(NAMESPACE) \ - --version=0.0.5 \ - --values values/prover-chunk-production.yaml - - helm upgrade -i prover-batch oci://ghcr.io/scroll-tech/scroll-sdk/helm/scroll-proving-sdk -n $(NAMESPACE) \ - --version=0.0.5 \ - --values values/prover-batch-production.yaml - - helm upgrade -i prover-bundle oci://ghcr.io/scroll-tech/scroll-sdk/helm/scroll-proving-sdk -n $(NAMESPACE) \ - --version=0.0.5 \ - --values values/prover-bundle-production.yaml - -delete-provers: - helm delete -n $(NAMESPACE) prover-chunk - helm delete -n $(NAMESPACE) prover-batch - helm delete -n $(NAMESPACE) prover-bundle -``` - -Now, simply run `make install-provers` to deploy the provers. - - - -{/* TODO: Update to point at actual charts once available. */} - - -{/* ### TODO: Add Graphana charts for Monitoring - -To quickly get started with Grafana, run the following command: - - -Now, visit the localhost URL in [your browser](http://localhost:3000/). The default password for the `admin` user is `prom-operator`. - -Adding an ingress URL, changing the default password or adding LDAP login are all suggested if you use this stack in production. */} - - -### Monitoring -You can monitor the cluster's running status through Grafana. -Additionally, you can send alerts via email and Slack using Alertmanager. -If you have configured a domain for Grafana in the previous steps, you can access it by opening http://grafana.yourdomain, where you will see two sets of dashboards. The defalt password of user `admin` is `scroll-sdk`. - - -#### send alert to slack -1. **Create a Slack App** - - Open [https://api.slack.com/apps](https://api.slack.com/apps) and click **`Create New App`** if you don't have one already. Select **`From scratch`**, enter a name, and select the workspace. - -2. **Activate Incoming Webhooks** - - Click the **`Incoming Webhooks`** label on the right side of the page, then turn on **`Activate Incoming Webhooks`**. - - - Click the **`Add New Webhook to Workspace`** button. - - - Select the channel you want to send alerts to, then copy the Webhook URL. - - - -3. **Edit the Config File** - - Edit `./values/alert-manager.yaml` to replace it with your webhook URL and your Slack channel name. - ``` - kube-prometheus-stack: - alertmanager: - config: - global: - resolve_timeout: 5m - slack_api_url: 'https://hooks.slack.com/services/xxxxxxxxxxx/xxxxxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxx' # your webhook url - receivers: - - name: 'slack-alerts' - slack_configs: - - channel: '#scroll-webhook' #your channel name - send_resolved: true - text: '{{ .CommonAnnotations.description }}' - title: '{{ .CommonAnnotations.summary }}' - route: - group_by: ['alertname'] - receiver: 'slack-alerts' - routes: - - matchers: [] - receiver: 'slack-alerts' - ``` - This configuration file will send all alerts to your Slack channel. If you need more complex rules, refer to the [Prometheus Alerting Configuration Documentation](https://prometheus.io/docs/alerting/latest/configuration/). - -4. **Update to alertmanager** - - Use the following command to update Alertmanager: - ``` - helm upgrade --reuse-values -i scroll-monitor oci://ghcr.io/scroll-tech/scroll-sdk/helm/scroll-monitor -n $(NAMESPACE) \ - --values ./values/alert-manager.yaml - ``` - - -{/* TODO: Add guide for disabling testnet finalization without proofs. */} \ No newline at end of file diff --git a/src/content/docs/en/sdk/guides/production-deployment.mdx b/src/content/docs/en/sdk/guides/production-deployment.mdx deleted file mode 100644 index ac74562e5..000000000 --- a/src/content/docs/en/sdk/guides/production-deployment.mdx +++ /dev/null @@ -1,62 +0,0 @@ ---- -section: sdk -date: Last Modified -title: "Running Scroll SDK in Production" -lang: "en" -permalink: "sdk/guides/production-deploymnet" -excerpt: "Run the Scroll SDK in production." ---- - -import Aside from "../../../../../components/Aside.astro" -import ToggleElement from "../../../../../components/ToggleElement.astro" -import Steps from '../../../../../components/Steps/Steps.astro'; - - - -## Overview - -This guide will support DevOps teams in running Scroll SDK in a production environment. This requires many considerations beyond a local [Devnet deployment](/en/sdk/guides/devnet-deployment). - -For a more hands-on guide looking at specifics, see our [Digital Ocean guide](/en/sdk/guides/digital-ocean-alt-gas-token), which walks through a full Kubernetes deployment using an easy-to-understand interface. We also have an [AWS guide](/en/sdk/guides/aws-deployment) available. - -### Monitoring - -See the [Monitoring](/en/sdk/operation/monitoring) section for more information. - -### Ingress - -We're using Nginx and Cert Manager. More info later. - -### Secrets - -We use External Secret Manager to store secrets. This is a Kubernetes-native solution that allows you to store secrets in a separate repository. This is a more secure way to store secrets than in the Scroll SDK repository, but you will still need to bring your own secret management tool. This could be Hashicorp Vault, AWS Secret Manager, or similar. - -Our CLI tool currently supports a development mode Hashicorp Vault and AWS Secret Manager. The [Digital Ocean guide](/en/sdk/guides/digital-ocean-alt-gas-token) uses Hashicorp vault, while the [AWS guide](/en/sdk/guides/aws-deployment) uses AWS Secret Manager. - -### Machine Resources - -In addition to 3 databases (and an optional database for Blockscout), we'll be providing guidance on the resources needed for each Scroll service. - -#### Sepolia Configuration - -For Scroll's Sepolia environment, we use the following resources: - -|Service | Quantity (sepolia) | vCPU (sepolia) | Mem in Mi (sepolia) | -|----------|------------------|------------------|------------------| -| balance-checker| 1 | 0.1 |500| -| bridge-history-api | 2 | 0.2 |200| -| bridge-history-fetcher | 1| 0.2 |200| -| coordinator-api| 2 | 0.2 |20000| -| coordinator-cron| 1 | 0.1 |200| -| chain-monitor| 1 | 0.2 |200| -| frontends 1|| 0.1 |500| -| gas-oracle| 1| 0.1 |200| -| l2-bootnode| 3 | 2 |16000| -| l2-rpc| 4 | 0.5 |4000| -| l2-sequencer| 1 | 0.1 |1500| -| rollup-explorer-backend | 2 | 3 |6000| -| rollup-node| 1 | 0.1 |200| -| rpc-gateway| 1 | 0.1 |100| -| Total | 22| 15.9 |120000| \ No newline at end of file diff --git a/src/content/docs/en/sdk/index.mdx b/src/content/docs/en/sdk/index.mdx deleted file mode 100644 index fabebca45..000000000 --- a/src/content/docs/en/sdk/index.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -section: sdk -title: "Scroll SDK" -lang: "en" -permalink: "sdk/" -excerpt: "Learn more about how to depoly your own rollup using Scroll's zkEVM" ---- - -import NavCard from "../../../../components/NavCard.astro" -import StartSvg from "~/assets/svgs/home/home-start.svg?raw" -import TechnologySvg from "../../../../assets/svgs/home/home-technology.svg?raw" -import LearnSvg from "../../../../assets/svgs/home/home-learn.svg?raw" -import DevelopSvg from "../../../../assets/svgs/home/home-develop.svg?raw" -import Aside from "../../../../components/Aside.astro" - -## Introduction - -Scroll SDK allows anyone to quickly deploy an instance of the Scroll zkEVM and its rollup architecture for deploying an L2 on Ethereum. - -For an introduction on why, and how it fits into our broader multichain vision, read [Scroll SDK & Gadgets: Building the Foundation for Ethereum's Multichain Future](https://scroll.io/blog/scroll-sdk-and-gadgets-building-the-foundation-for-ethereums-multichain-future). - -We're working with a number of clients, technology parters, and service providers to build the most robust ZK stack for Ethereum. - -If you want to dive deeper and try launching your own L2, keep reading and check out the additional resources. - -## Current Feature Set - -- Fully functional local devnet or Sepolia testnet deployment of Scroll's current zkEVM and protocol -- Configurable deployment using Docker, Kubernetes, and Helm -- Choose between Ether or any ERC20 token as the native gas token -- Plug-and-play proof generation using various service providers, allowing for failover and elastic capacity -- Adaptable finality time, allowing custom trade-offs between finality time and on-chain costs -- Tools for interacting and exploring your chain, including a CLI tool, Blockscout, Grafana dashboards, our Rollup Explorer, and a demo Bridge UI - -## Planned Feature Set - -- Rollup or Validium Mode (Modular DA using 4844, callData, or Alt-DA Layers) -- Base layer flexibility (Ethereum mainnet, Scroll, or any EVM-compatible environment) -- Customization of the sequencer node to add additional features to the EVM -- Out-of-the-box, contract auto-deployments for various commonly used protocols - - - -
- - - -
diff --git a/src/content/docs/en/sdk/operation/_images/admin-system-dashboard-batch-view.png b/src/content/docs/en/sdk/operation/_images/admin-system-dashboard-batch-view.png deleted file mode 100644 index 5341421a5..000000000 Binary files a/src/content/docs/en/sdk/operation/_images/admin-system-dashboard-batch-view.png and /dev/null differ diff --git a/src/content/docs/en/sdk/operation/_images/alertmanager.png b/src/content/docs/en/sdk/operation/_images/alertmanager.png deleted file mode 100644 index e4d67861f..000000000 Binary files a/src/content/docs/en/sdk/operation/_images/alertmanager.png and /dev/null differ diff --git a/src/content/docs/en/sdk/operation/_images/grafana.png b/src/content/docs/en/sdk/operation/_images/grafana.png deleted file mode 100644 index 20f594734..000000000 Binary files a/src/content/docs/en/sdk/operation/_images/grafana.png and /dev/null differ diff --git a/src/content/docs/en/sdk/operation/contracts-verification.mdx b/src/content/docs/en/sdk/operation/contracts-verification.mdx deleted file mode 100644 index cc83dd420..000000000 --- a/src/content/docs/en/sdk/operation/contracts-verification.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -section: sdk -title: "Upgrading Scroll SDK" -lang: "en" -permalink: "sdk/operation/contracts-verification" -excerpt: "Learn more about verify smart contract scource code on blockchain explorer" ---- - -import Steps from '../../../../../components/Steps/Steps.astro'; - -## Overview - -This guide documents how to verify the smart contract source code of your own Scroll SDK deployment on blockchain explorers. - -### Devnet deployment - - -1. Go to the `devnet` folder of `scroll-sdk` repository -2. Configurate `[contracts.verification]` section of your config.toml file as described [here](/en/sdk/technical-stack/configuration#contracts-verification) -3. To start the verification process, run the following command: - - `make verify` - - -### Production deployment - - -1. Go to the root directory of your local workspace repo -2. Configurate `[contracts.verification]` section of your config.toml file as described [here](/en/sdk/technical-stack/configuration#contracts-verification) -3. To start the verification process, run the following command: - - `scrollsdk setup verify-contracts` - \ No newline at end of file diff --git a/src/content/docs/en/sdk/operation/gas-and-fees.mdx b/src/content/docs/en/sdk/operation/gas-and-fees.mdx deleted file mode 100644 index ad8eb2eea..000000000 --- a/src/content/docs/en/sdk/operation/gas-and-fees.mdx +++ /dev/null @@ -1,237 +0,0 @@ ---- -section: sdk -title: "Gas & Fee Management in Scroll SDK" -lang: "en" -permalink: "sdk/operation/gas-and-fees" -excerpt: "Learn more about gas and fee management in Scroll SDK" ---- - -import Aside from "../../../../../components/Aside.astro" - -Scroll SDK provides a comprehensive gas and fee management system to ensure the efficient operation of the network. This section provides an overview of the gas and fee management tools and best practices for using them. - -## Transaction Fees on an SDK Chain - -Transaction fees for users on Scroll are split between an L2 Fee and an L1 Fee. For more information on how transaction fees work, see [Transaction Fees on Scroll](/en/developers/transaction-fees-on-scroll). - -Paid network fees are collected in the `L2FeeVault` contract. Any user can trigger the movement of funds to L1, where they can be claimed by the `OWNER` role. - -### Configuring L2 Execution Fees - -L2 transaction fees are set as a minimum "floor" for the execution component of the fee, beyond which normal mechanisms for EIP1559 adjustment apply. - -This is set with `--miner.gasprice` on the sequencer. You can modify this value and `--gpo.ignoreprice` in the chart by overriding the `L2GETH_MIN_GAS_PRICE` environment variable [here](https://github.com/scroll-tech/scroll-sdk/blob/main/charts/l2-sequencer/values.yaml#L106). - -Additionally, you could modify the `--gpo.percentile` and `--gpo.blocks` arguements, but will need to manually modify the `l2-sequencer` chart. - -Lastly, RPC nodes (or any node that accepts transactions) should set `--gpo.congestionthreshold`, which we default to 500. This configuration allows nodes to provide more accurate fee estimate. The value is the number of pending transactions to consider the network congested and suggest a minimum tip cap if there are fewer pending transactions in the txpool.[^congestion-threshold] - -[^congestion-threshold]: See these [`l2geth` code comments](https://github.com/scroll-tech/go-ethereum/blob/develop/eth/gasprice/gasprice.go#L197) for more info. - -For additional information, see the [geth documentation](https://geth.ethereum.org/docs/fundamentals/command-line-options). - -### Configuring L1 Fees - -The `L1GasOracle` pre-deployed contract holds the values used to calculate the L1 fee for transactions. - -The following fields are set by the Gas Oracle service, specifically by transactions submitted by the `L2GasOracleSender`: -- `l1BaseFee`: the base fee for the L1 transaction -- `l1BlobBaseFee`: the base fee for the L1 blob data - -The following fields are set by the Owner using setter functions in the `L1GasOracle` contract: -- `commitScalar` -- `blobScalar` -- `overhead` -- `scalar` - -{/* TODO: Just suggest sensible defaults for these values. */} - -To see these on Scroll's mainnet deployment, view the [L1GasOracle contract](https://scrollscan.com/address/0x5300000000000000000000000000000000000002#writeContract). - -For more information on how gas fees on Scroll are calculated, see the [Calculating the L1 Data Fee with Gas Oracle](/en/developers/transaction-fees-on-scroll/#calculating-the-l1-data-fee-with-gas-oracle). - -#### Calculating and Setting Gas Oracle Fields - -`L1GasPriceOracle` has two variables `commitScalar` and `blobScalar` which are used to calculate L1 fee for a L1 transaction. - -To calculate the scalars, you can use the following formula: - -```jsx -// fixed values -compression_ratio = 2.887 -blob_util_ratio = 87.1% - -// formula to calculate scalars -// tx_per_block: average transaction number per L2 block -// tx_per_batch: average transaction number per batch -// fluctuation_multiplier: multiplier used to pervent loss from transaction number and L1 gas price fluctuation -commitScalar = (1382.58 / tx_per_block + 71621.32 / tx_per_batch) * fluctuation_multiplier * 1e9 -blobScalar = fluctuation_multiplier / compression_ratio / blob_util_ratio * 1e9 -``` - -To set the scalars on `L1GasPriceOracle`, you can run this command with `cast`: - -```jsx -cast send --rpc-url 0x5300000000000000000000000000000000000002 "setCommitScalar(uint256)" --private-key -cast send --rpc-url 0x5300000000000000000000000000000000000002 "setBlobScalar(uint256)" --private-key -``` - - - -### Claiming Fees from the Vault - -As L2 Fees accumulate in the L2FeeVault, any user can call the `withdrawl` method to "claim" these fees. This will bridge the funds to the `L1_FEE_VAULT_ADDR` address (configured in `config.toml`) on the L1 chain. - -After the funds are bridged, the bridged funds will still need to be claimed on L1 with a proof that can be easily obtained using the `bridge-history-api`. To see this process on Scroll, see [Finalizing Transactions on L1](/en/developers/l1-and-l2-bridging/the-scroll-messenger/#finalizing-transactions-on-l1) - - - -## Alternative Gas Token - -Beyond using Ethereum as the native gas token, Scroll SDK also supports alternative gas tokens. This customization allows users to use their preferred gas token for transactions. - -Because transaction fees are calculated by not just charging a gas fee, but also an L1 fee, conversion is needed between the L1's native token and the SDK's gas token, additional configuration and logic is needed in the gas oracle. - -#### Gas Oracle Fields for Alternative Gas Tokens - -{/* TODO: What's the latest here? */} - -Instead of introducing another variable to the `L1GasPriceOracle` contract which requires manual updates from the owner, operators should modify the Gas Oracle to include the ETH/ERC20 conversion rate. - -### Configuring Gas Oracle for Alternative Gas Tokens - -Basic configuration for the Gas Oracle can be made in the `config.toml` file before generating the service's config values. - -#### config.toml [gas-token] values - -- `GAS_ORACLE_INCORPORATE_TOKEN_EXCHANGE_RATE_ENANBLED` - - if `true`, includes the L2/L1 exchange rate into gas price. *Should only set to true when alternative gas token enabled.* - - Default: `false` -- `EXCHANGE_RATE_UPDATE_MODE` - - The mode used to set L2/L1 gas token exchange rate. Options supported are `Fixed` and `BinanceApi`. - - Default: `Fixed` -- `FIXED_EXCHANGE_RATE` - - When using "Fixed" exchange rate mode, the number of native token on L1 required to exchange for 1 native token on L2 - - Devnet Default: `0.01` -- `TOKEN_SYMBOL_PAIR` - - When using "BinanceApi" exchange rate mode, the pair should be L2 gas token symbol + L1 native token symbol. For instance, if using UNI token as the gas token on L2, the pair should be “UNIETH”. Token pair should be supported by Binance and included in their [ticker list API](https://api.binance.com/api/v3/ticker/price) - - **NOTE:** This API is not accessible in some regions, including the US. Confirm access eligibility before using. - -#### `gas-oracle` config values - -For more complicated configurations, you'll want to make manual adjustments to the your Gas Oracle config values, specifically the `alternative_gas_token_config` sections. - -```json -// L1 gas oracle config -"gas_oracle_config": { - "min_gas_price": 0, - "gas_price_diff": 50000, - "l1_base_fee_weight": 0.132, - "l1_blob_base_fee_weight": 0.145, - "check_committed_batches_window_minutes": 5, - "l1_base_fee_default": 15000000000, - "l1_blob_base_fee_default": 1, - "alternative_gas_token_config": { - "enabled": false, - "mode": "BinanceAp", - "fixed_exchange_rate": 0.001, - "token_symbol_pair": "UNIETH" - } -} - -// L2 gas oracle config -"gas_oracle_config": { - "min_gas_price": 0, - "gas_price_diff": 50000, - "alternative_gas_token_config": { - "enabled": false, - "mode": "BinanceAp", - "fixed_exchange_rate": 0.001, - "token_symbol_pair": "UNIETH" - } -}, -``` - -**L1 gas oracle config** - -- `min_gas_price` - - The minimal gas price set to contract `L1GasPriceOracle` *(for both baseFee and blobBaseFee)* -- `gas_price_diff` - - The minimum percentage of gas price difference to update gas oracle *(for both baseFee and blobBaseFee)* -- `l1_blob_base_fee_weight` - - The weight for L1 blob base fee *(deprecated after curie upgrade)* -- `check_committed_batches_window_minutes` - - The time frame to check if we committed batches to decide to update gas oracle or not in minutes. If we are not committing batches due to high fees then we shouldn't update fees to prevent users from paying high l1_data_fee, so we should set fees to some default value - - Should be set it to the same or slightly larger value as `batch_timeout_sec`, remembering to convert second to minutes -- `l1_base_fee_default` - - The default base cost value set when a batch is not committed for longer than `check_committed_batches_window_minutes`. -- `l1_blob_base_fee_default` - - The default blob base cost value set when a batch is not committed for longer than `check_committed_batches_window_minutes`. -- `alternative_gas_token_config`: - - `enabled` - - If enabled, incorporates L2/L1 gas token exchange rate into gas price. *(Should only set to true when alternative gas token enabled)* - - `mode` - - The mode to retrieve L2/L1 gas token exchange rate. (`Fixed` || `BinanceApi`) - - `fixed_exchange_rate` - - When using "Fixed" exchange rate mode, the number of native tokens on L1 required to exchange for 1 native token on L2 - - `token_symbol_pair` - - When using "BinanceApi" exchange rate mode, the pair should be L2 gas token symbol + L1 native token symbol. For instance, if using UNI token as the gas token on L2, the pair should be “UNIETH”. Token pair should be supported by Binance and included in their [ticker list API](https://api.binance.com/api/v3/ticker/price) - - **NOTE:** This API is not accessible in some regions, including the US. Confirm access eligibility before using. - -**L2 gas oracle config** - -- `min_gas_price` - - The minimal gas price set to contract L1GasPriceOracle. -- `gas_price_diff` - - The minimum percentage of gas price difference to update gas oracle. -- `alternative_gas_token_config` - - Refer to `alternative_gas_token_config` on L1 gas oracle config above. - -## Security Considerations for Alternative Gas Tokens - -When implementing alternative gas tokens, operators should be aware of several important security considerations to prevent potential loss of funds and user errors. - -The contract and gas oracle changes for Scroll SDK are not used on Scroll mainnet, but have been audited by Trail of Bits. - -{/* TODO: Add link to audit report */} - -### L2 to L1 Message Queue Restrictions - - - -The L2 Message Queue system has strict requirements for handling native token transfers: - -- Messages with non-zero value **must** be sent to the `L1GasTokenGateway` address -- Messages sent to any other address with non-zero value will fail to relay on L1, resulting in burned tokens -- Ideally, custom gateway implementations should validate destination addresses on L2 before allowing transfers - -### Token Decimal Scaling Issues - -When bridging ERC-20 tokens to be used as native L2 tokens: - -- Tokens are automatically scaled to 18 decimals on L2 -- Example: If using USDT (6 decimals) as gas token: - - 1 USDT on L1 = 1012 native tokens on L2 - - This maintains UI display values but can affect base unit calculations - - - -### Contract Interface Naming - - - -Operators should be aware of potentially confusing contract interfaces: - -- `L1GasTokenGateway.depositETH()` - Actually deposits ERC-20 gas tokens, not ETH -- L2-side functions reference "ETH" even when using alternative tokens -- `L1WrappedTokenGateway` handles wrapped ETH, not wrapped gas tokens diff --git a/src/content/docs/en/sdk/operation/index.mdx b/src/content/docs/en/sdk/operation/index.mdx deleted file mode 100644 index 93db5d1ba..000000000 --- a/src/content/docs/en/sdk/operation/index.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -section: sdk -title: "Operating Scroll SDK" -lang: "en" -permalink: "sdk/operation" -excerpt: "Learn more about running and operating Scroll SDK" ---- - -import NavCard from "../../../../../components/NavCard.astro" -import TechnologySvg from "../../../../../assets/svgs/home/home-technology.svg?raw" -import LearnSvg from "../../../../../assets/svgs/home/home-learn.svg?raw" -import DevelopSvg from "../../../../../assets/svgs/home/home-develop.svg?raw" - -After familiarizing yourself with the technical stack, you can proceed to the following sections to learn more about running and operating Scroll SDK, along with some best practices and reference information. - -{/*
- - - -
*/} diff --git a/src/content/docs/en/sdk/operation/monitoring.mdx b/src/content/docs/en/sdk/operation/monitoring.mdx deleted file mode 100644 index 04de712dc..000000000 --- a/src/content/docs/en/sdk/operation/monitoring.mdx +++ /dev/null @@ -1,451 +0,0 @@ ---- -section: sdk -title: "Monitoring Scroll SDK" -lang: "en" -permalink: "sdk/operation/monitoring" -excerpt: "Learn more about monitoring Scroll SDK" ---- - -import Aside from "../../../../../components/Aside.astro" -import ClickToZoom from "../../../../../components/ClickToZoom.astro"; -import AdminSystemDashboard from "./_images/admin-system-dashboard-batch-view.png" -import Alertmanager from "./_images/alertmanager.png" -import Grafana from "./_images/grafana.png" - -Scroll SDK provides a comprehensive monitoring system to ensure the health and performance of the network. This section provides an overview of the monitoring tools and best practices for using them. - -## `scroll-monitor` Service - -The Scroll Monitor service provides a starting point for adding observability and monitoring to your Scroll SDK deployment. It brings together Grafana, Loki, Prometheus, and AlertManager to provide a comprehensive monitoring solution, or can serve as a template for implementing Scroll SDK into your existing monitoring stack. - -### Service Dashboards - -We've build and made available a few Grafana dashboards for Scroll SDK chains. These include views for the following services: -- `bridge-history-api` -- `bridge-history-fetcher` -- `chain-monitor` -- `coordinator-api` -- `coordinator-cron` -- `gas-oracle` -- `l2geth` instances (including `l2-sequencer`, `l2-bootnode` and `l2-rpc`) -- `rollup-node` - -You can access these from the `scroll-sdk` repo [here](https://github.com/scroll-tech/scroll-sdk/tree/develop/charts/scroll-monitor/grafana/scroll-dashboards). - - -{/* */} - -{/* */} - -{/* TODO: List important views from various dashboards. */} - -### Notifications with Alertmanager - -The `scroll-monitor` services configuration file also supports Slack webhooks for easy integration with your existing Slack workspace. - - - - -{/* TODO: Document what we have alerts setup for. */} - -For a detailed guide on configuring and setting up AlertManager, you can refer to the [official documentation](https://prometheus.io/docs/alerting/latest/configuration/). - -## Scroll Admin System - -The Scroll Admin System Dashboard provides a web interface for managing and monitoring proof production in Scroll SDK deployments. It includes features for viewing the status of chunks, batches and bundles, along with all registered provers and assigned tasks. - - - -{/* TODO: Consider describing what you can do in each view */} - -{/* ## Balance Checker */} - -{/* TODO: Return with simple overview of balance-checker, how to set it up, and what it does. */} - -## Chain Monitor - -Chain Monitor can be configured to send Slack notifications if: -- deposit and withdraw messages from L1 and L2 don't match -- asset value on escrow contracts doesn't match the deposit or withdraw messages -- WithdrawRoots don't match - -To set this up, set a Webhook URL in the `slack_webhook_config` section of the `chain-monitor` config. - -## Prometheus Metrics - -Below are tables of Prometheus metrics for each service in the Scroll SDK: - -### chain-monitor - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| chain_monitor_request_body_total | The server received request body size, unit byte | Counter | -| chain_monitor_request_duration_bucket | Cumulative counters for the observation buckets (the time server took to handle the request.) | Counter | -| chain_monitor_request_duration_count | Count of events that have been observed for the histogram metric (the time server took to handle the request.) | Counter (Histogram) | -| chain_monitor_request_duration_sum | Total sum of all observed values for the histogram metric (the time server took to handle the request.) | Counter (Histogram) | -| chain_monitor_request_total | All the server received request num. | Counter | -| chain_monitor_request_uv_total | All the server received ip num. | Counter | -| chain_monitor_response_body_total | The server send response body size, unit byte | Counter | -| chain_monitor_uri_request_total | All the server received request num with every uri. | Counter | -| contract_controller_block_number | The block number of controller running. | Gauge | -| contract_controller_running_total | The total number of controllers running. | Counter | -| cross_chain_check_controller_running_total | The total number of cross chain controllers running. | Counter | -| gateway_batch_finalized_failed_total | The total number of gateway batch finalized failed. | Counter | -| messenger_batch_finalized_failed_total | The total number of messenger batch finalized failed. | Counter | -| slack_alert_cross_chain_eth_event_balance_not_match_total | The total number of alert cross chain eth event balance not match total. | Counter | -| slack_alert_cross_chain_eth_event_not_match_total | The total number of alert cross chain eth event not match total. | Counter | -| slack_alert_cross_chain_gateway_event_not_match_total | The total number of alert cross chain gateway event not match total. | Counter | -| slack_alert_gateway_event_duplicated_total | The total number of alert gateway event duplicated. | Counter | -| slack_alert_gateway_transfer_not_match_total | The total number of alert gateway transfer event not match total. | Counter | -| slack_alert_messenger_event_duplicated_total | The total number of alert messenger event duplicated. | Counter | -| slack_alert_withdraw_root_not_match_total | The total number of alert withdraw root not match total. | Counter | - -### rollup-node - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| rollup_l2_block_l1_commit_calldata_size | The l1 commitBatch calldata size of the l2 block | Gauge | -| rollup_l2_watcher_blocks_fetched_gap | The gap of l2 fetch | Gauge | -| rollup_l2_watcher_fetch_running_missing_blocks_height | The total number of l2 watcher fetch running missing blocks height | Gauge | -| rollup_l2_watcher_fetch_running_missing_blocks_total | The total number of l2 watcher fetch running missing blocks | Counter | -| rollup_layer2_bundles_finalized_confirmed_failed_total | Total number of failed confirmations for finalized bundles on layer2. | Counter | -| rollup_layer2_bundles_finalized_confirmed_total | Total number of finalized bundles confirmed on layer2. | Counter | -| rollup_layer2_chain_monitor_latest_failed_batch_call | The total number of failed call chain_monitor api | Counter | -| rollup_layer2_chain_monitor_latest_failed_batch_status | The total number of failed batch status get from chain_monitor | Counter | -| rollup_layer2_gas_price_latest_gas_price | The latest gas price of rollup relayer l2 | Gauge | -| rollup_layer2_gas_price_oracler_total | The total number of layer2 gas price oracler run total | Counter | -| rollup_layer2_process_committed_batches_confirmed_failed_total | The total number of layer2 process committed batches confirmed failed total | Counter | -| rollup_layer2_process_committed_batches_confirmed_total | The total number of layer2 process committed batches confirmed total | Counter | -| rollup_layer2_process_committed_batches_finalized_success_total | The total number of layer2 process committed batches finalized success total | Counter | -| rollup_layer2_process_committed_batches_finalized_total | The total number of layer2 process committed batches finalized total | Counter | -| rollup_layer2_process_committed_batches_total | The total number of layer2 process committed batches run total | Counter | -| rollup_layer2_process_finalized_batches_confirmed_failed_total | The total number of layer2 process finalized batches confirmed failed total | Counter | -| rollup_layer2_process_finalized_batches_confirmed_total | The total number of layer2 process finalized batches confirmed total | Counter | -| rollup_layer2_process_pending_batch_err_too_many_pending_blob_txs_total | The total number of layer2 process pending batch failed on too many pending blob txs | Counter | -| rollup_layer2_process_pending_batch_success_total | The total number of layer2 process pending success batch | Counter | -| rollup_layer2_process_pending_batch_total | The total number of layer2 process pending batch | Counter | -| rollup_layer2_relayer_process_pending_bundles_finalized_success_total | Total number of times the layer2 relayer has successful finalized proven bundle processes. | Counter | -| rollup_layer2_relayer_process_pending_bundles_finalized_total | Total number of times the layer2 relayer has finalized proven bundle processes. | Counter | -| rollup_layer2_relayer_process_pending_bundles_total | Total number of times the layer2 relayer has processed pending bundles. | Counter | -| rollup_layer2_update_layer1_gas_oracle_confirmed_failed_total | The total number of updating layer2 gas oracle confirmed failed | Counter | -| rollup_layer2_update_layer1_gas_oracle_confirmed_total | The total number of updating layer2 gas oracle confirmed | Counter | -| rollup_propose_batch_chunks_number | The number of chunks in the batch | Gauge | -| rollup_propose_batch_chunks_propose_not_enough_total | Total number of batch chunk propose not enough | Counter | -| rollup_propose_batch_circle_total | Total number of propose batch total. | Counter | -| rollup_propose_batch_due_to_compressed_data_compatibility_breach_total | Total number of propose batch due to compressed data compatibility breach. | Counter | -| rollup_propose_batch_estimate_blob_size_time | Time taken to estimate blob size for the chunk. | Gauge | -| rollup_propose_batch_estimate_calldata_size_time | Time taken to estimate calldata size for the chunk. | Gauge | -| rollup_propose_batch_estimate_gas_time | Time taken to estimate gas for the chunk. | Gauge | -| rollup_propose_batch_failure_circle_total | Total number of propose batch total. | Counter | -| rollup_propose_batch_first_block_timeout_reached_total | Total times of batch's first block timeout reached | Counter | -| rollup_propose_batch_total_l1_call_data_size | The total l1 call data size | Gauge | -| rollup_propose_batch_total_l1_commit_blob_size | The total l1 commit blob size | Gauge | -| rollup_propose_batch_total_l1_commit_gas | The total l1 commit gas | Gauge | -| rollup_propose_batch_update_info_failure_total | Total number of propose batch update info failure total. | Counter | -| rollup_propose_batch_update_info_total | Total number of propose batch update info total. | Counter | -| rollup_propose_bundle_batches_number | The number of batches in the current bundle. | Gauge | -| rollup_propose_bundle_batches_propose_not_enough_total | Total number of times there were not enough batches to propose a bundle. | Counter | -| rollup_propose_bundle_circle_total | Total number of propose bundle attempts. | Counter | -| rollup_propose_bundle_failure_total | Total number of propose bundle failures. | Counter | -| rollup_propose_bundle_first_block_timeout_reached_total | Total times the first block in a bundle reached the timeout. | Counter | -| rollup_propose_bundle_update_info_failure_total | Total number of propose bundle update info failures. | Counter | -| rollup_propose_bundle_update_info_total | Total number of propose bundle update info attempts. | Counter | -| rollup_propose_chunk_blocks_propose_not_enough_total | Total number of chunk block propose not enough | Counter | -| rollup_propose_chunk_chunk_block_number | The number of blocks in the chunk | Gauge | -| rollup_propose_chunk_circle_total | Total number of propose chunk total. | Counter | -| rollup_propose_chunk_due_to_compressed_data_compatibility_breach_total | Total number of propose chunk due to compressed data compatibility breach. | Counter | -| rollup_propose_chunk_estimate_blob_size_time | Time taken to estimate blob size for the chunk. | Gauge | -| rollup_propose_chunk_estimate_calldata_size_time | Time taken to estimate calldata size for the chunk. | Gauge | -| rollup_propose_chunk_estimate_gas_time | Time taken to estimate gas for the chunk. | Gauge | -| rollup_propose_chunk_estimate_l1_commit_gas | The chunk estimate l1 commit gas | Gauge | -| rollup_propose_chunk_failure_circle_total | Total number of propose chunk failure total. | Counter | -| rollup_propose_chunk_first_block_timeout_reached_total | Total times of chunk's first block timeout reached | Counter | -| rollup_propose_chunk_max_tx_consumption | The max tx consumption | Gauge | -| rollup_propose_chunk_total_l1_commit_blob_size | The total l1 commit blob size | Gauge | -| rollup_propose_chunk_total_l1_commit_call_data_size | The total l1 commit call data size | Gauge | -| rollup_propose_chunk_tx_num | The chunk tx num | Gauge | -| rollup_propose_chunk_update_info_failure_total | Total number of propose chunk update info failure total. | Counter | -| rollup_propose_chunk_update_info_total | Total number of propose chunk update info total. | Counter | -| rollup_sender_blob_gas_fee_cap | The blob gas fee cap of current transaction. | Gauge | -| rollup_sender_check_pending_transaction_total | The total number of check pending transaction. | Counter | -| rollup_sender_gas_fee_cap | The gas fee cap of current transaction. | Gauge | -| rollup_sender_gas_limit | The gas limit of current transaction. | Gauge | -| rollup_sender_gas_tip_cap | The gas tip cap of current transaction. | Gauge | -| rollup_sender_send_transaction_send_tx_failure_total | The total number of sending transactions failure for sending tx. | Counter | -| rollup_sender_send_transaction_total | The total number of sending transactions. | Counter | - -### bridge-history-api - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| bridge_history_api_cache_hits_total | The total number of cache hits | Counter | -| bridge_history_api_cache_misses_total | The total number of cache misses | Counter | -| bridge_history_api_request_body_total | The server received request body size, unit byte | Counter | -| bridge_history_api_request_duration_bucket | Cumulative counters for the observation buckets (the time server took to handle the request.) | Counter | -| bridge_history_api_request_duration_count | Count of events that have been observed for the histogram metric (the time server took to handle the request.) | Counter (Histogram) | -| bridge_history_api_request_duration_sum | Total sum of all observed values for the histogram metric (the time server took to handle the request.) | Counter (Histogram) | -| bridge_history_api_request_total | All the server received request num. | Counter | -| bridge_history_api_request_uv_total | All the server received ip num. | Counter | -| bridge_history_api_response_body_total | The server send response body size, unit byte | Counter | -| bridge_history_api_uri_request_total | All the server received request num with every uri. | Counter | - -### bridge-history-fetcher - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| L1_fetcher_logic_fetched_total | The total number of events or failed txs fetched in L1 fetcher logic. | Counter | -| L1_message_fetcher_reorg_total | Total count of blockchain reorgs encountered by the L1 message fetcher. | Counter | -| L1_message_fetcher_running_total | Current count of running L1 message fetcher instances. | Counter | -| L1_message_fetcher_sync_height | Latest blockchain height the L1 message fetcher has synced with. | Gauge | -| L2_fetcher_logic_fetched_total | The total number of events or failed txs fetched in L2 fetcher logic. | Counter | -| L2_message_fetcher_reorg_total | Total count of blockchain reorgs encountered by the L2 message fetcher. | Counter | -| L2_message_fetcher_running_total | Current count of running L2 message fetcher instances. | Counter | -| L2_message_fetcher_sync_height | Latest blockchain height the L2 message fetcher has synced with. | Gauge | -| event_update_logic_L1_finalize_batch_event_L2_block_update_height | L2 block height of the latest L1 batch event that has been finalized and updated in the message_table. | Gauge | -| event_update_logic_L2_message_nonce_update_height | L2 message nonce height in the latest L1 batch event that has been finalized and updated in the message_table. | Gauge | - -### coordinator-api - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| coordinator_submit_proof_failure_total | Total number of submit proof failure. | Counter | -| coordinator_submit_proof_total | Total number of submit proof. | Counter | -| coordinator_task_prove_duration_seconds_bucket | Cumulative counters for the observation buckets (Time spend by prover prove task.) | Counter | -| coordinator_task_prove_duration_seconds_count | Count of events that have been observed for the histogram metric (Time spend by prover prove task.) | Counter (Histogram) | -| coordinator_task_prove_duration_seconds_sum | Total sum of all observed values for the histogram metric (Time spend by prover prove task.) | Counter (Histogram) | -| coordinator_validate_failure_submit_have_been_verifier | Total number of submit proof validate failure proof have been verifier. | Counter | -| coordinator_validate_failure_submit_status_not_ok | Total number of submit proof validate failure proof status not ok. | Counter | -| coordinator_validate_failure_submit_timeout | Total number of submit proof validate failure timeout. | Counter | -| coordinator_validate_failure_submit_twice_total | Total number of submit proof validate failure submit twice. | Counter | -| coordinator_validate_failure_total | Total number of submit proof validate failure. | Counter | - -### coordinator-cron - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| coordinator_batch_prover_task_timeout_total | Total number of batch timeout prover task. | Counter | -| coordinator_batch_timeout_checker_run_total | Total number of batch timeout checker run. | Counter | -| coordinator_bundle_prover_task_timeout_total | Total number of bundle timeout prover task. | Counter | -| coordinator_bundle_timeout_checker_run_total | Total number of bundle timeout checker run. | Counter | -| coordinator_chunk_prover_task_timeout_total | Total number of chunk timeout prover task. | Counter | -| coordinator_chunk_timeout_checker_run_total | Total number of chunk timeout checker run. | Counter | - -### gas-oracle - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| rollup_l1_watcher_fetch_block_header_processed_block_height | The current processed block height of l1 watcher fetch block header | Gauge | -| rollup_l1_watcher_fetch_block_header_total | The total number of l1 watcher fetch block header total | Counter | -| rollup_layer1_gas_price_oracler_total | The total number of layer1 gas price oracler run total | Counter | -| rollup_layer1_latest_base_fee | The latest base fee of l1 rollup relayer | Gauge | -| rollup_layer1_latest_blob_base_fee | The latest blob base fee of l1 rollup relayer | Gauge | -| rollup_layer1_update_gas_oracle_confirmed_failed_total | The total number of updating layer1 gas oracle confirmed failed | Counter | -| rollup_layer1_update_gas_oracle_confirmed_total | The total number of updating layer1 gas oracle confirmed | Counter | -| rollup_layer2_bundles_finalized_confirmed_failed_total | Total number of failed confirmations for finalized bundles on layer2. | Counter | -| rollup_layer2_bundles_finalized_confirmed_total | Total number of finalized bundles confirmed on layer2. | Counter | -| rollup_layer2_chain_monitor_latest_failed_batch_call | The total number of failed call chain_monitor api | Counter | -| rollup_layer2_chain_monitor_latest_failed_batch_status | The total number of failed batch status get from chain_monitor | Counter | -| rollup_layer2_gas_price_latest_gas_price | The latest gas price of rollup relayer l2 | Gauge | -| rollup_layer2_gas_price_oracler_total | The total number of layer2 gas price oracler run total | Counter | -| rollup_layer2_process_committed_batches_confirmed_failed_total | The total number of layer2 process committed batches confirmed failed total | Counter | -| rollup_layer2_process_committed_batches_confirmed_total | The total number of layer2 process committed batches confirmed total | Counter | -| rollup_layer2_process_committed_batches_finalized_success_total | The total number of layer2 process committed batches finalized success total | Counter | -| rollup_layer2_process_committed_batches_finalized_total | The total number of layer2 process committed batches finalized total | Counter | -| rollup_layer2_process_committed_batches_total | The total number of layer2 process committed batches run total | Counter | -| rollup_layer2_process_finalized_batches_confirmed_failed_total | The total number of layer2 process finalized batches confirmed failed total | Counter | -| rollup_layer2_process_finalized_batches_confirmed_total | The total number of layer2 process finalized batches confirmed total | Counter | -| rollup_layer2_process_pending_batch_err_too_many_pending_blob_txs_total | The total number of layer2 process pending batch failed on too many pending blob txs | Counter | -| rollup_layer2_process_pending_batch_success_total | The total number of layer2 process pending success batch | Counter | -| rollup_layer2_process_pending_batch_total | The total number of layer2 process pending batch | Counter | -| rollup_layer2_relayer_process_pending_bundles_finalized_success_total | Total number of times the layer2 relayer has successful finalized proven bundle processes. | Counter | -| rollup_layer2_relayer_process_pending_bundles_finalized_total | Total number of times the layer2 relayer has finalized proven bundle processes. | Counter | -| rollup_layer2_relayer_process_pending_bundles_total | Total number of times the layer2 relayer has processed pending bundles. | Counter | -| rollup_layer2_update_layer1_gas_oracle_confirmed_failed_total | The total number of updating layer2 gas oracle confirmed failed | Counter | -| rollup_layer2_update_layer1_gas_oracle_confirmed_total | The total number of updating layer2 gas oracle confirmed | Counter | -| rollup_sender_check_pending_transaction_total | The total number of check pending transaction. | Counter | -| rollup_sender_gas_fee_cap | The gas fee cap of current transaction. | Gauge | -| rollup_sender_gas_limit | The gas limit of current transaction. | Gauge | -| rollup_sender_gas_tip_cap | The gas tip cap of current transaction. | Gauge | -| rollup_sender_send_transaction_get_fee_failure_total | The total number of sending transactions failure for getting fee. | Counter | -| rollup_sender_send_transaction_total | The total number of sending transactions. | Counter | - -### l2geth - -L2Geth has an extensive list of metrics. Below are tables grouped by metric name prefixes, highlighting important metrics and those not inherited from geth. For a complete list, please refer to the Prometheus metrics explorer. - -#### eth_db_chaindata - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| eth_db_chaindata_disk_size | Size of the chaindata on disk | Gauge | -| eth_db_chaindata_ancient_size | Size of the ancient chaindata on disk | Gauge | - -#### miner - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| miner_commit_gas | Gas used in the last commit | Gauge | -| miner_ccc_stall | | Summary | -| miner_ccc_stall_count | Count of events that have been observed for the base metric | Counter | -| miner_ccc_stall_total_count | | Counter | -| miner_collect_l1_msgs | | Summary | -| miner_collect_l1_msgs_count | Count of events that have been observed for the base metric | Counter | -| miner_collect_l1_msgs_total_count | | Counter | -| miner_collect_l2_txns | | Summary | -| miner_collect_l2_txns_count | Count of events that have been observed for the base metric | Counter | -| miner_collect_l2_txns_total_count | | Counter | -| miner_commit | | Summary | -| miner_commit_count | Count of events that have been observed for the base metric | Counter | -| miner_commit_reason_ccc | | Gauge | -| miner_commit_reason_deadline | | Gauge | -| miner_commit_total_count | | Counter | -| miner_idle | | Summary | -| miner_idle_count | Count of events that have been observed for the base metric | Counter | -| miner_idle_total_count | | Counter | -| miner_prepare | | Summary | -| miner_prepare_count | Count of events that have been observed for the base metric | Counter | -| miner_prepare_total_count | | Counter | -| miner_skipped_txs_l1 | | Gauge | -| miner_skipped_txs_l2 | | Gauge | - -#### p2p - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| p2p_peers | Number of connected peers | Gauge | - -#### txpool - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| txpool_pending | Number of pending transactions in the pool | Gauge | -| txpool_queued | Number of queued transactions in the pool | Gauge | - -#### ccc - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| ccc_async_active_workers | | Gauge | -| ccc_async_check | | Summary | -| ccc_async_check_count | Count of events that have been observed for the base metric | Counter | -| ccc_async_check_total_count | | Counter | -| ccc_async_fail | | Gauge | -| ccc_encode | | Summary | -| ccc_encode_count | Count of events that have been observed for the base metric | Counter | -| ccc_encode_total_count | | Counter | - -#### chain - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| chain_account_commits | | Summary | -| chain_account_commits_count | Count of events that have been observed for the base metric | Counter | -| chain_account_commits_total_count | | Counter | -| chain_account_hashes | | Summary | -| chain_account_hashes_count | Count of events that have been observed for the base metric | Counter | -| chain_account_hashes_total_count | | Counter | -| chain_account_reads | | Summary | -| chain_account_reads_count | Count of events that have been observed for the base metric | Counter | -| chain_account_reads_total_count | | Counter | -| chain_account_updates | | Summary | -| chain_account_updates_count | Count of events that have been observed for the base metric | Counter | -| chain_account_updates_total_count | | Counter | -| chain_execution | | Summary | -| chain_execution_count | Count of events that have been observed for the base metric | Counter | -| chain_execution_total_count | | Counter | -| chain_fees_l2basefee | | Gauge | -| chain_head_block | Current head block number | Gauge | -| chain_head_header | Current head header number | Gauge | -| chain_head_receipt | Current head receipt number | Gauge | -| chain_head_timegap | Time gap between current time and the head block timestamp | Gauge | -| chain_inserts | | Summary | -| chain_inserts_count | Count of events that have been observed for the base metric | Counter | -| chain_inserts_total_count | | Counter | -| chain_prefetch_executes | | Summary | -| chain_prefetch_executes_count | Count of events that have been observed for the base metric | Counter | -| chain_prefetch_executes_total_count | | Counter | -| chain_prefetch_interrupts | | Gauge | -| chain_reorg_add | | Gauge | -| chain_reorg_drop | | Gauge | -| chain_reorg_executes | | Gauge | -| chain_reorg_invalidTx | | Gauge | -| chain_snapshot_account_reads | | Summary | -| chain_snapshot_account_reads_count | Count of events that have been observed for the base metric | Counter | -| chain_snapshot_account_reads_total_count | | Counter | -| chain_snapshot_commits | | Summary | -| chain_snapshot_commits_count | Count of events that have been observed for the base metric | Counter | -| chain_snapshot_commits_total_count | | Counter | -| chain_snapshot_storage_reads | | Summary | -| chain_snapshot_storage_reads_count | Count of events that have been observed for the base metric | Counter | -| chain_snapshot_storage_reads_total_count | | Counter | -| chain_storage_commits | | Summary | -| chain_storage_commits_count | Count of events that have been observed for the base metric | Counter | -| chain_storage_commits_total_count | | Counter | -| chain_storage_hashes | | Summary | -| chain_storage_hashes_count | Count of events that have been observed for the base metric | Counter | -| chain_storage_hashes_total_count | | Counter | -| chain_storage_reads | | Summary | -| chain_storage_reads_count | Count of events that have been observed for the base metric | Counter | -| chain_storage_reads_total_count | | Counter | -| chain_storage_updates | | Summary | -| chain_storage_updates_count | Count of events that have been observed for the base metric | Counter | -| chain_storage_updates_total_count | | Counter | -| chain_validation | | Summary | -| chain_validation_count | Count of events that have been observed for the base metric | Counter | -| chain_validation_total_count | | Counter | -| chain_write | | Summary | -| chain_write_count | Count of events that have been observed for the base metric | Counter | -| chain_write_total_count | | Counter | - -#### rawdb - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| rawdb_l1_message_iterator_inner_next_called | | Gauge | -| rawdb_l1_message_iterator_length_mismatch | | Gauge | -| rawdb_l1_message_iterator_next_called | | Gauge | -| rawdb_l1_message_iterator_next_time | | Summary | -| rawdb_l1_message_iterator_next_time_count | Count of events that have been observed for the base metric | Counter | -| rawdb_l1_message_iterator_next_time_total_count | | Counter | -| rawdb_l1_message_size | | Gauge | - -#### rollup - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| rollup_l1_message | | Gauge | -| rollup_tracing_feed_tx_to_tracer | | Summary | -| rollup_tracing_feed_tx_to_tracer_count | Count of events that have been observed for the base metric | Counter | -| rollup_tracing_feed_tx_to_tracer_total_count | | Counter | -| rollup_tracing_fill_block_trace | | Summary | -| rollup_tracing_fill_block_trace_count | Count of events that have been observed for the base metric | Counter | -| rollup_tracing_fill_block_trace_total_count | | Counter | -| rollup_tracing_get_tx_result | | Summary | -| rollup_tracing_get_tx_result_apply_message | | Summary | -| rollup_tracing_get_tx_result_apply_message_count | Count of events that have been observed for the base metric | Counter | -| rollup_tracing_get_tx_result_apply_message_total_count | | Counter | -| rollup_tracing_get_tx_result_count | Count of events that have been observed for the base metric | Counter | -| rollup_tracing_get_tx_result_total_count | | Counter | -| rollup_tracing_get_tx_result_tracer_result | | Summary | -| rollup_tracing_get_tx_result_tracer_result_count | Count of events that have been observed for the base metric | Counter | -| rollup_tracing_get_tx_result_tracer_result_total_count | | Counter | -| rollup_tracing_get_tx_result_zk_trie_build | | Summary | -| rollup_tracing_get_tx_result_zk_trie_build_count | Count of events that have been observed for the base metric | Counter | -| rollup_tracing_get_tx_result_zk_trie_build_total_count | | Counter | - -#### validator - -| METRIC | DESCRIPTION | TYPE | -|--------|-------------|------| -| validator_async | | Summary | -| validator_async_count | Count of events that have been observed for the base metric | Counter | -| validator_async_total_count | | Counter | -| validator_l1msg | | Summary | -| validator_l1msg_count | Count of events that have been observed for the base metric | Counter | -| validator_l1msg_total_count | | Counter | - -Note: This is not an exhaustive list. There are many more metrics available for eth_downloader, eth_fetcher, les_client, les_server, miner, p2p, processor, rpc, state, system, trie, txpool, and other components. \ No newline at end of file diff --git a/src/content/docs/en/sdk/operation/security-and-recovery.mdx b/src/content/docs/en/sdk/operation/security-and-recovery.mdx deleted file mode 100644 index 54ebac622..000000000 --- a/src/content/docs/en/sdk/operation/security-and-recovery.mdx +++ /dev/null @@ -1,302 +0,0 @@ ---- -section: sdk -title: "Security & Recovery in Scroll SDK" -lang: "en" -permalink: "sdk/operation/security-and-recovery" -excerpt: "Learn more about security and recovery in Scroll SDK" ---- - -import Aside from "../../../../../components/Aside.astro" -import ToggleElement from "../../../../../components/ToggleElement.astro" -import Steps from "../../../../../components/Steps/Steps.astro" - - - -## Protocol Security & Risks - -For a comprehensive overview of the security of the protocol, L2Beat's [overview of Scroll](https://l2beat.com/scaling/projects/scroll#risk-summary) is a great place to understand the risks, centalization points and permissioned operators on Scroll chain. Because Scroll is a single entity (who also built the tech), the risk factors may increase as you coordinate with external parties (ie RaaS providers). - - - -### Audits - -For a list of independent audits of the Scroll protocol, see [Audits & Bug Bounty](en/technology/security/audits-and-bug-bounty#independent-audits). - -Additionally, Scroll SDK has undergone the following audits: - -- Alternative Gas Token Contracts and Gas Oracle - - Trail of Bits *(Report to be released)* - -{/* TODO: Add audit report URL */} - - - -## Owner Role & Safe Management - -Because the Owner Role has the ability to upgrade smart contracts, it can compromise the bridge and user funds. This account should be a multi-sig wallet, and we encourage you to review the best practices for [creating a Security Council](https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52). - -If a RaaS provider is used, create a plan for multi-sig upgrades where the provider cannot arbitrarily upgrade the contracts. - -## Privileged Smart Contract Roles - -The following accounts are given roles that have special permissions and should be managed with extra care: - -- `DEPLOYER` - - Used to deploy initial contracts and has permissions to set the initial `OWNER` - - Private key held in `contracts` service -- `OWNER` - - Can upgrade contracts, set important parameters, whitelist accounts to grant them roles. - - Should be a multi-sig wallet, with the RaaS provider having no more signing authority than the other signers. -- `L1_GAS_ORACLE_SENDER` - - Permissioned to report L2 gas prices to L1 `L1_SCROLL_MESSENGER` contract - - Private key held in `gas-oracle` service (unless using Web3Signer) -- `L2_GAS_ORACLE_SENDER` - - Permissioned to report L1 gas prices to L2 `L1_GAS_PRICE_ORACLE` contract - - Private key held in `gas-oracle` service (unless using Web3Signer) -- `L1_COMMIT_SENDER_ADDR` - - Permissioned to submit batches to the L1 `ScrollChain` contract - - Private key held in `rollup-node` service (unless using Web3Signer) -- `L1_FINALIZE_SENDER` - - Permissioned to submit proofs and finalize batches on L1 `ScrollChain` contract - - Private key held in `rollup-node` service (unless using Web3Signer) - - -For additional assessments on protocol permissions and to see how Scroll manages multisigs and timelocks, see [L2Beat's Scroll permissions](https://l2beat.com/scaling/projects/scroll#permissions). - -## Handling Private Keys and Secrets - -By default, Scroll SDK's production deployments are configured to store "hot" private keys in the service and a secret manager service. We use ExternalSecrets to support a variety of secret manager services, but by default, the CLI tool only automates AWS Secrets Manager and an insecure, development-only deployment of HashiCorp Vault. - -We intend to add support for Web3Signer in the future as well, allowing more restricted access to apply to a single service. - -For more information on implemententing access control to specific parts of your cluster, see [Kubernetes: Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/). - -## Pausing the Bridge - -In extreme security instances, you may need to pause the bridge. The easiest way to do this quickly from the infrastructure operator is to bring the rollup node offline. This way, even if blocks contine to be produced, finalization (and thus new withdrawals) will not be processed until the `rollup-node` is back online. - -## Key Rotation for Rollup Accounts - -Rotating the keys for the `gas-oracle` and `rollup-node` accounts is a manual process requiring involvement from the `OWNER` role. - -At a high level, you simply need to add the new key to the whitelist, restart your services, and then remove the old key from the whitelist. - -{/* TODO: Provide cast commands for doing this process. */} - -## Rotating Sequencer Keys - -Rotating sequencer keys requires careful coordination to ensure continuous block production. The process involves running two sequencer nodes temporarily - the active sequencer and a new sequencer with the new keys. - -#### Prerequisites - - -1. Update your L2 Geth nodes to the latest version -2. Prepare a second value file for the new sequencer with: - - New keystore and password - - New nodekey - - Updated peer list -3. Ensure all L2 Geth services have both sequencers in their `L2GETH_PEER_LIST` - - -#### Rotation Process - - -1. Deploy the new sequencer node with the new keys -2. Verify the new sequencer is fully synced and connected to peers -3. On the active sequencer, connect to the Geth console: - ```bash - geth attach /l2geth/data/geth.ipc - ``` - - or, if using `kubectl`: - ```bash - kubectl exec -it l2-sequencer-0 -- geth attach /l2geth/data/geth.ipc - ``` - -4. Check current active signer: - ```bash - clique.getSigners() - ``` - -5. Propose the new signer (replace with your new signer address): - ```bash - clique.propose("0xNEW_SIGNER_ADDRESS", true) - ``` - -6. Wait for one block to be generated, then verify both signers are active: - ```bash - clique.getSigners() // Should show both addresses - ``` - -7. Remove the old signer from both nodes: - - On the old sequencer: - ```bash - clique.propose("0xOLD_SIGNER_ADDRESS", false) - ``` - - On the new sequencer: - ```bash - clique.propose("0xOLD_SIGNER_ADDRESS", false) - ``` - -8. After two blocks are generated, verify only the new signer remains: - ```bash - clique.getSigners() // Should show only new signer - ``` - - -#### Post-Rotation Verification - - -1. Monitor block production on the new sequencer -2. Verify blocks are being properly signed with the new key -3. Monitor network health metrics -4. Once confirmed working, decommission the old sequencer - - - - -## Recovering from a Infrastructure Failure - -Recoving from an infrastructure failure will depend on what components are affected. - -#### Database Failure - -For a managed database recovery, we recommend maintaining backups, ideally in an alternate region. If you operate your own database, be sure to take snapshots, and consider backups to alternate cloud providers. We plan to provide further guidance for database recovery in the future. - -#### Sequencer Failure - -**If your sequencer host goes down:** - -We recommend having at least one hot standby sequencer to take its place. This sequencer can be configured with different keys than the original sequencer (and be fully synced in case you need to [rotate the sequencer keys](#rotating-sequencer-keys)), but a simple configuration change will allow it to reboot using the original sequencer's keys to immediately resume block production. - -**If all of your sequencer machines are lost:** - -You will need either: - - Sync a new full node from gensis (assuming there are full nodes remaining somewhere in your p2p network). - - Repurpose a synced RPC node. "Converting" it to be the sequencer by creating a new sequencer chart that takes over the RPC node's Persistent Volume Claim. - -**If all full nodes in the network are lost:** - -If you cannot sync from other network nodes, you will need to sync from L1 data. As of version 0.1.0, this is unsupported, but we plan to add support for this in the near future. - -Please reach out to the Scroll team if you need assistance reviewing your recovery plan. - -## Planning for your Incident Response & Recovery - -It is important to plan for your incident response and recovery before an incident occurs. Here is a list of potential issues, their implications, and things to consider as a team. - -### Bug Categories and Response Plans - -#### 1. Liveness Issues -- **Symptoms**: Delays in block production or finalization -- **Impact**: - - Write operations may be temporarily unavailable - - Bridge withdrawals may be delayed - - Read operations remain functional -- **Response**: - - Monitor block production metrics - - Engage backup systems if necessary - - Communicate status to users - -#### 2. Safety Issues - -##### Scenario A: Invalid Block Production -- **Symptoms**: RPC nodes rejecting blocks -- **Impact**: Chain appears offline for writes -- **Response**: - - Investigate sequencer logs - - Prepare for potential rollback - - Maintain read-only access - -##### Scenario B: Unprovable Batch -- **Symptoms**: Proof generation failures -- **Response**: - - Coordinate with Scroll team - - Potential prover upgrade - - Possible L1 batch revocation - - Prepare for L2 reorg - -##### Scenario C: ZK System Bug -- **Highest Risk Scenario** -- **Required Actions**: - - Immediate escalation to Scroll team - - Potential emergency shutdown - - Review of all recent proofs - - External party verification - -#### 3. Gas Oracle Issues -- **Monitoring**: Track gas price anomalies -- **Impact Assessment**: - - Transaction cost implications - - Potential chain usability issues -- **Resolution Steps**: - - Oracle parameter adjustment - - Emergency price override if necessary - -### Disaster Recovery - -#### Cross-Region Resilience -1. **Backup Infrastructure** - - Maintain 1-2 fullnodes in alternate regions - - Regular database snapshots - - Off-site backup storage - - Cross-region K8s cluster capability - -2. **Recovery Procedures** - - Sequencer Role Recovery: - 1. Deploy new sequencer with original keys - 2. Verify chain sync status - 3. Resume block production - - Signer Change Process: - 1. Follow documented key rotation - 2. Update necessary configurations - 3. Verify new signer functionality - -#### Cloud Provider Failover - -1. **Temporary Outages** - - Maintain hot standby in alternate region - - Automated DNS failover configuration - - Regular failover testing - - Document recovery procedures - -2. **Permanent Migration** - - Platform-agnostic deployment readiness - - Alternative cloud provider prerequisites: - - Pre-configured K8s clusters - - Network configuration templates - - DNS management strategy - - Migration checklist: - - Sequencer deployment - - RPC node setup - - Database migration - - DNS updates - - Security configuration verification - -### Security Monitoring and Response Checklist - -#### Continuous Monitoring -- Monitor all privileged key usage -- Track gas oracle values for anomalies -- Watch for unusual block proposal patterns -- Monitor bridge activity for suspicious patterns -- Track system resource utilization -- Monitor network latency and availability - -#### Incident Response -- Maintain an up-to-date incident response plan -- Document escalation procedures -- Keep backup RaaS provider details readily available -- Regular testing of recovery procedures -- Maintain communication templates for various scenarios \ No newline at end of file diff --git a/src/content/docs/en/sdk/operation/troubleshooting.mdx b/src/content/docs/en/sdk/operation/troubleshooting.mdx deleted file mode 100644 index 226b89a6c..000000000 --- a/src/content/docs/en/sdk/operation/troubleshooting.mdx +++ /dev/null @@ -1,162 +0,0 @@ ---- -section: sdk -title: "Troubleshooting a Scroll SDK Deployment" -lang: "en" -permalink: "sdk/operation/troubleshooting" -excerpt: "Troubleshooting issues you may encounter when running Scroll SDK" ---- - -import Steps from '../../../../../components/Steps/Steps.astro'; -import Aside from '../../../../../components/Aside.astro'; - -The Scroll SDK is a complex system with many interdependent services. This document covers common issues you may encounter when running the SDK and how to resolve them. - -### Rollup node isn't committing batches or finalizing - - - -1. Check if the accounts have funds - - Verify public addresses and send them funds on L1 - -2. Look for logs about "check chain monitor" - - If present, check chain monitor logs. You may not have enough blocks *after* the batch to finalize. - - Generate more network activity to produce blocks, or change the `chain-monitor-config.json` value: - - ```json - "l2_config": { - ... - "confirm": "0x80", - ... - } - ``` - -3. If your logs include something like "replacement transaction underpriced: new tx blob gas fee cap 1000000000000 ≤ 574376045900 queued + 100% replacement penalty": - - Update these values in `rollup-config.json`: - - ```json - "l2_config": { - ... - "max_gas_price": 5000000000000, - "max_blob_gas_price": 5000000000000, - ... - } - ``` - -4. If you see "Failed to finalize timeout batch without proof": - ``` - ERROR[08-29|18:40:37.366|scroll-tech/rollup/internal/controller/relayer/l2_relayer.go:465] Failed to finalize timeout batch without proof ││ index=6 hash=0x05bc419ecb59e9566554ddb716ee4b69fbe3b103a84e1c714656190c5af5028c err="failed to get batch status, errCode: 40001, errMsg: " ││ WARN [08-29|18:40:52.273|scroll-tech/rollup/internal/controller/relayer/l2_relayer.go:506] failed to get batch status, please check chain_ ││ monitor api server batch_index=6 err="failed to get batch status, errCode: 40001, errMsg: " - ``` - - Confirm that chain monitor's Layer 2 "start block" is higher than the block in the batch. See the change for `chain-monitor-config.json` value above. - - - -### Unable to withdraw funds - - - -1. Check if the withdrawal block is finalized - - If not, wait for finalization - -2. Verify if bridge-history-fetcher is still syncing - - Check its 'fetch and save L1 events" height - - You may need to wait for it to catch up before the bridge history API can create a withdrawal proof - - - -### Didn't receive funds on Layer 2 after deposit on Layer 1 - - - -1. Check if the deposit transaction block is finalized on Layer 1 - - If not, wait (or send a transaction on Layer 1 to force block generation if using anvil) - -2. Verify if there's a transaction on Layer 2 - - If not, send a transaction on Layer 2 to force block generation - - - -### Rollup node failed to get batch status - -Error from rollup node pod: - -``` -ERROR[09-18|07:52:21.515|scroll-tech/rollup/internal/controller/relayer/l2_relayer.go:489] Failed to finalize timeout batch without proof index=1 hash=0x43b0e21561d60b052c14eeb53f04c4f797b6c1532fae207fcb03f7da3ea819dd err="failed to get batch status, errCode: 40001, errMsg: " -``` - -This occurs because there are not enough L2 blocks generated. Continue sending transactions on L2 to force block generation, which should resolve the issue. - -### Gas-oracle/rollup-relayer failed to get fee data - -Error: `max fee per gas less than block base fee` - -This is a bug from the l2-geth node. A workaround is to manually send a legacy transaction with a high gas price. - -### Rollup node failed to commit a batch, and batch status on rollup-explorer is unknown - -#### Issue context - -``` -ERROR[10-15|09:04:42.873|scroll-tech/rollup/internal/controller/relayer/l2_relayer.go:476] -Failed to send commitBatch tx to layer1 index=191 hash=0x80c87236e31dd2b33cb03909905e7ccdf070ea879b8e7f5c91542fd1a1ad7d6f RollupContractAddress=0xE518eD8A0568c99Be066ecEDcf29e0C1315E4b77 err="failed to get fee data, err: execution reverted -``` - -#### Analysis - -**Issue 1:** The failed commit transaction (txhash: 0x1ca3fb4ed1688d7aa43d65f3d8ef0a98ff6afb03dc9cff69924f77fd1f06e432) reverted with error code 0x12137ab0, which stands for `"ErrorBatchIsAlreadyCommitted()"`. The rollup node is attempting to commit an already committed batch. This likely occurred because the rollup node stopped while sending a commit transaction to L1. L1 received the transaction, but the rollup node didn't save it in the pending_transaction table of the database. - -**Issue 2:** After fixing Issue 1, another issue arose where the rollup node failed to commit a later batch, reverting with the error `ErrorIncorrectBatchHash()`. This was caused by updating the batch rollup_status in the database without shutting down the rollup node, leading to the rollup fetching incorrect batch information. - -#### Solutions - -**Issue 1:** - - - -1. Debug the failed commit transaction using the `debug_traceTransaction` RPC method: - - ```bash - curl l1_rpc_url -X POST -H "Content-Type: application/json" --data '{"method":"debug_traceTransaction","params":["0x1ca3fb4ed1688d7aa43d65f3d8ef0a98ff6afb03dc9cff69924f77fd1f06e432", {"tracer": "callTracer"}], "id":1,"jsonrpc":"2.0"}' - ``` - - If the output is `0x12137ab0` (`ErrorBatchIsAlreadyCommitted()`), it confirms Issue 1. - -2. Shut down the rollup-node and gas-oracle. - -3. In the PostgreSQL database, select the `batch` table and update the `rollup_status` of the corresponding failing commit batch to `3` (representing rollup committed). - -4. Restart the rollup-node and gas-oracle. - - - -**Issue 2:** - - - -Issue 2 typically shouldn't occur unless the rollup-node wasn't shut down when solving Issue 1. If it happens anyway: - - - -1. Debug the failed commit transaction using the `debug_traceTransaction` RPC method: - - ```bash - curl l1_rpc_url -X POST -H "Content-Type: application/json" --data '{"method":"debug_traceTransaction","params":["0x1ca3fb4ed1688d7aa43d65f3d8ef0a98ff6afb03dc9cff69924f77fd1f06e432", {"tracer": "callTracer"}], "id":1,"jsonrpc":"2.0"}' - ``` - - If the output is `0x2a1c1442` (`ErrorIncorrectBatchHash()`), it confirms Issue 2. - -2. Revert the incorrect batch (the previous batch of the current failing commit batch): - `revert_batch_number = current_failing_batch_number - 1` - -3. Shut down the rollup-node and gas-oracle. In the PostgreSQL database, select the `batch` table and delete batches where `batch_index ≥ revert_batch_number`. - -4. Revert the batch on the scrollChain contract: - - ```bash - cast send --rpc-url "revertBatch(bytes, bytes)" --private-key - ``` - -5. Restart the rollup-node and gas-oracle. - - diff --git a/src/content/docs/en/sdk/operation/upgrades.mdx b/src/content/docs/en/sdk/operation/upgrades.mdx deleted file mode 100644 index cf915a144..000000000 --- a/src/content/docs/en/sdk/operation/upgrades.mdx +++ /dev/null @@ -1,15 +0,0 @@ ---- -section: sdk -title: "Upgrading Scroll SDK" -lang: "en" -permalink: "sdk/operation/upgrades" -excerpt: "Learn more about upgrading Scroll SDK" ---- - -Scroll SDK will include a comprehensive upgrade system to ensure the smooth operation of a network during upgrades. - -With our current `scroll-sdk 0.1.x` release, we haven't had any breaking changes that would require manual intervention beyond upgrading a chart's version. There may be some upgrades that will require re-syncing a sequencer from genesis, upgrading smart contracts, or even database migrations. - -When that time comes, we will provide thorough documentation on upgrade paths for bringing the latest features to your Scroll SDK chain. - -{/* TODO: Add upgrade information here */} \ No newline at end of file diff --git a/src/content/docs/en/sdk/sdk-faq.mdx b/src/content/docs/en/sdk/sdk-faq.mdx deleted file mode 100644 index e1913e0f7..000000000 --- a/src/content/docs/en/sdk/sdk-faq.mdx +++ /dev/null @@ -1,35 +0,0 @@ ---- -section: sdk -date: Last Modified -title: "Scroll SDK FAQ" -lang: "en" -permalink: "sdk/early-access-program" -excerpt: "Help us sculpt the Scroll SDK by trying it out and giving us early feedback!" -# whatsnext: { "Scroll Rollup Process": "/en/technology/chain/rollup" } ---- - -## Troubleshooting / FAQ - -### How long is finality on Scroll chain? - -Finality depends on the parameterization of how often your chain wants to finalize to Ethereum. Roughly, a batch is created every minute (containing ~20 blocks or 200 txs), and takes about 50 minutes to finalize on L1. - -Our next upgrade with increase the variability on block speed, but also increase how many batches will fit in a proof. We may decide to lengthen finality in order to reduce on-chain costs and lower transaction fees. _(At 556k gas to finalize, each finalize tx costs ~$9.80 as of June 3, 2024)._ - -If you want to explore more, check out [https://scroll.io/rollupscan](https://scroll.io/rollupscan) - -### Does Scroll SDK support a mock prover? How does finality work without running a prover? - -The Scroll SDK defaults to the behavior seen on Scroll Sepolia, which does not require proofs to finalize. - -In the default testnet configuration, the contracts deployed to L1 allow the `rollup-node` (the service that submits proofs to the verification contract on L1) to submit "empty" proofs and the L1 contract will accept it. - -The rollup-node is configured to submit these after a "timeout" period if the service does not receive a valid proof. This mode doesn't require a literal "mock prover" service — if fact, even the `coordinator`, the service which typically assigns works to provers and verifies proofs before storing them for the rollup-node, is not required to run. - -The suggested testnet timeout for this finalization is 3600 seconds, to approximate mainnet's finalization latency. To alter this behavior in Scroll SDK or learn more, see [Mock Finalization](/en/sdk/technical-stack/proof-generation#mock-finalization). - -### Is Kubernetes a requirement? Do you support docker-compose, ansible, etc? - -We do not provide templates for deploying with tooling outside of Kubernetes and Helm. That said, every Helm chart points to a docker image, and we are happy to help teams that need support understanding service configuration. We may explore providing these by default if enough teams need this support, but it's not how we manage Scroll chain in its production environment. - -{/* TODO: Add a few more questions here */} \ No newline at end of file diff --git a/src/content/docs/en/sdk/technical-stack/configuration.mdx b/src/content/docs/en/sdk/technical-stack/configuration.mdx deleted file mode 100644 index bc49f16a5..000000000 --- a/src/content/docs/en/sdk/technical-stack/configuration.mdx +++ /dev/null @@ -1,243 +0,0 @@ ---- -section: sdk -date: Last Modified -title: "Scroll SDK Configuration" -lang: "en" -permalink: "sdk/technical-stack/configuration" -excerpt: "Information on configuring and customizing a Scroll SDK deployment." ---- - -import Aside from "../../../../../components/Aside.astro" - -Initial change configuration is made by modifying `config.toml`. All other config files are auto-generated from this file. For automating changes to your configuration for production deployments, see the [scroll-sdk-cli](https://www.npmjs.com/package/@scroll-tech/scroll-sdk-cli) tool. - -For new production deployments, we recommend using the [example template](https://github.com/scroll-tech/scroll-sdk/blob/develop/examples/config.toml.example), which the `scroll-sdk-cli` tool is designed to work with. You can reference the default devnet configuration [here](https://github.com/scroll-tech/scroll-sdk/blob/develop/charts/scroll-sdk/config.toml). - - - -## `config.toml` Variables -Local Devnet defaults shown. - -### General - -Contained in the `[general]` section. - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| L1_RPC_ENDPOINT | Specifies the HTTP endpoint for the L1 RPC server. | `http://l1-devnet:8545` | -| L1_RPC_ENDPOINT_WEBSOCKET | Specifies the WebSocket endpoint for the L1 RPC server. | `ws://l1-devnet:8546` | -| L2_RPC_ENDPOINT | Specifies the HTTP endpoint for the L2 RPC server. | `http://l2-rpc:8545` | -| CHAIN_NAME_L1 | Labels the chain name for the L1 network. | Ethereum | -| CHAIN_NAME_L2 | Labels the chain name for the L2 network. | Scroll SDK | -| CHAIN_ID_L1 | Defines the chain ID for the L1 network. | 111111 | -| CHAIN_ID_L2 | Defines the chain ID for the L2 network. | 221122 | -| L1_CONTRACT_DEPLOYMENT_BLOCK | Specifies the block number at which L1 contracts were deployed. | 0 | - -### Accounts - -Contained in the `[accounts]` section. - -{/* TODO: Add link to where these roles are documented. */} - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| DEPLOYER_PRIVATE_KEY | Private key for the deployer account. | `0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80` | -| L1_COMMIT_SENDER_PRIVATE_KEY | Private key for the L1 commit sender account. | `0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d` | -| L1_FINALIZE_SENDER_PRIVATE_KEY | Private key for the L1 finalize sender account. | `0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a` | -| L1_GAS_ORACLE_SENDER_PRIVATE_KEY | Private key for the L1 gas oracle sender account. | `0x7c852118294e51e653712a81e05800f419141751be58f605c371e15141b007a6` | -| L2_GAS_ORACLE_SENDER_PRIVATE_KEY | Private key for the L2 gas oracle sender account. | `0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80` | -| DEPLOYER_ADDR | Address of the deployer account. | `0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266` | -| OWNER_ADDR | Address of the owner account. Should be a multi-sig wallet. | `0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266` | -| L1_COMMIT_SENDER_ADDR | Address of the L1 commit sender account. | `0x70997970C51812dc3A010C7d01b50e0d17dc79C8` | -| L1_FINALIZE_SENDER_ADDR | Address of the L1 finalize sender account. | `0x3C44CdDdB6a900fa2b585dd299e03d12FA4293BC` | -| L1_GAS_ORACLE_SENDER_ADDR | Address of the L1 gas oracle sender account. | `0x90F79bf6EB2c4f870365E785982E1f101E93b906` | -| L2_GAS_ORACLE_SENDER_ADDR | Address of the L2 gas oracle sender account. | `0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266` | - -### Database - -Contained in the `[db]` section. - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| ADMIN_SYSTEM_DB_CONNECTION_STRING | Connection string for the Admin System database. | `""` | -| BLOCKSCOUT_DB_CONNECTION_STRING | Connection string for the Blockscout database. | `postgresql://postgres:qwerty12345@postgresql:5432/blockscout` | -| BRIDGE_HISTORY_DB_CONNECTION_STRING | Connection string for the Bridge History database. | `postgres://postgres:qwerty12345@postgresql:5432/scroll?sslmode=disable` | -| CHAIN_MONITOR_DB_CONNECTION_STRING | Connection string for the Chain Monitor database. | `postgres://postgres:qwerty12345@postgresql:5432/scroll?sslmode=disable` | -| GAS_ORACLE_DB_CONNECTION_STRING | Connection string for the Gas Oracle database. | `postgres://postgres:qwerty12345@postgresql:5432/scroll?sslmode=disable` | -| COORDINATOR_DB_CONNECTION_STRING | Connection string for the Coordinator database. | `""` | -| L1_EXPLORER_DB_CONNECTION_STRING | Connection string for the L1 Explorer database. | `postgresql://postgres:qwerty12345@postgresql:5432/l1-explorer` | -| ROLLUP_NODE_DB_CONNECTION_STRING | Connection string for the Rollup Node database. | `postgres://postgres:qwerty12345@postgresql:5432/scroll?sslmode=disable` | -| ROLLUP_EXPLORER_DB_CONNECTION_STRING | Connection string for the Rollup Explorer database. | `""` | - -### Gas Token - -Contained in the `[gas-token]` section. - -{/* TODO: Add link to where these modes are documented. */} - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| ALTERNATIVE_GAS_TOKEN_ENABLED | Enables using an alternative gas token instead of ETH. | false | -| EXAMPLE_GAS_TOKEN_DECIMAL | Decimal places for the example gas token. | 6 | -| L1_GAS_TOKEN | Address of the L1 ERC20 gas token contract. | `0x68a041e7c20Afa4784b5d9C63246c89545Ac0E66` | -| GAS_ORACLE_INCORPORATE_TOKEN_EXCHANGE_RATE_ENANBLED | Enables incorporating token exchange rates in gas oracle. | false | -| EXCHANGE_RATE_UPDATE_MODE | Mode for updating exchange rates. | `Fixed` | -| FIXED_EXCHANGE_RATE | Fixed exchange rate value when using Fixed mode. | `0.01` | -| TOKEN_SYMBOL_PAIR | Symbol pair for the token exchange. | `UNIETH` | - -### Sequencer - -Contained in the `[sequencer]` section. - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| L2_GETH_STATIC_PEERS | Static peers for L2 Geth nodes, as an array of sequencer enode URLs. | `[""]` | -| L2GETH_SIGNER_ADDRESS | Address of the primary sequencer's L2 Geth signer account. | `""` | -| L2GETH_KEYSTORE | Keystore file for the primary sequencer's L2 Geth signer account. | `""` | -| L2GETH_PASSWORD | Password for the primary sequencer's L2 Geth keystore. | `""` | -| L2GETH_NODEKEY | Node key for the primary sequencer's L2 Geth node. | `""` | - -### Additional Sequencer Instances - -Contained in the `[sequencer.sequencer-1]` section and incrementing for each additional sequencer instance. - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| L2GETH_SIGNER_ADDRESS | Address of the L2 Geth signer account for this sequencer instance. | `0xE8fFE623460e54e546E54B1a0C93A968aF6295bb` | -| L2GETH_KEYSTORE | Keystore file for this sequencer instance's signer account. | `{"address":"e8ffe623460e54e546e54b1a0c93a968af6295bb","id":"deef9b4a-a085-4f02-af36-afaa19da4132",...}` | -| L2GETH_PASSWORD | Password for this sequencer instance's keystore. | `second` | -| L2GETH_NODEKEY | Node key for this sequencer instance. | `bd347890c9d308957207379679e8ed548d015ef05588c228d13f92ea0288a35b` | - -### Bootnode Instances - -Contained in the `[bootnode.bootnode-0]` section and incrementing for each additional bootnode instance. - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| L2GETH_NODEKEY | Node key for this bootnode instance. | `""` | - - -### Rollup - -Contained in the `[rollup]` section. - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| MAX_TX_IN_CHUNK | Sets the maximum number of transactions in a chunk. | 100 | -| MAX_BLOCK_IN_CHUNK | Sets the maximum number of blocks in a chunk. | 100 | -| MAX_CHUNK_IN_BATCH | Sets the maximum number of chunks in a batch. | 15 | -| MAX_BATCH_IN_BUNDLE | Sets the maximum number of batches in a bundle. | 30 | -| MAX_L1_MESSAGE_GAS_LIMIT | Defines the maximum gas limit for L1 messages. | 10000000 | -| TEST_ENV_MOCK_FINALIZE_ENABLED | Enables mock finalization for testing environments. | true | -| TEST_ENV_MOCK_FINALIZE_TIMEOUT_SEC | Sets the timeout for mock finalization in seconds. | 300 | - -### Frontend - -Contained in the `[frontend]` section. - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| EXTERNAL_RPC_URI_L1 | External RPC URI for L1. | `http://l1-devnet.scrollsdk` | -| EXTERNAL_RPC_URI_L2 | External RPC URI for L2. | `http://l2-rpc.scrollsdk` | -| BRIDGE_API_URI | URI for the Bridge API. | `http://bridge-history-api.scrollsdk/api` | -| ROLLUPSCAN_API_URI | URI for the Rollupscan API. | `http://rollup-explorer-backend.scrollsdk/api` | -| EXTERNAL_EXPLORER_URI_L1 | External Explorer URI for L1. | `http://l1-explorer.scrollsdk` | -| EXTERNAL_EXPLORER_URI_L2 | External Explorer URI for L2. | `http://blockscout.scrollsdk` | -| ADMIN_SYSTEM_DASHBOARD_URI | URI for the Admin System Dashboard. | `http://admin-system-dashboard.scrollsdk` | -| GRAFANA_URI | URI for Grafana. | `http://grafana.scrollsdk` | - -### Genesis - -Contained in the `[genesis]` section. - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| L2_MAX_ETH_SUPPLY | Sets the maximum ETH supply for the L2 network. | `226156424291633194186662080095093570025917938800079226639565593765455331328` | -| L2_DEPLOYER_INITIAL_BALANCE | Sets the initial balance for the L2 deployer account. | 1000000000000000000 | - -### Contracts - -Contained in the `[contracts]` section. - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| DEPLOYMENT_SALT | Salt used for contract deployment. | `salt-000` | -| L1_FEE_VAULT_ADDR | Address of the L1 fee vault contract. | `0x0000000000000000000000000000000000000001` | -| L1_PLONK_VERIFIER_ADDR | Address of the L1 PLONK verifier contract. | `0x0000000000000000000000000000000000000001` | - -### Contracts Overrides - -Contained in the `[contracts.overrides]` section. - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| L2_MESSAGE_QUEUE | Override address for the L2 message queue contract. | `0x5300000000000000000000000000000000000000` | -| L1_GAS_PRICE_ORACLE | Override address for the L1 gas price oracle contract. | `0x5300000000000000000000000000000000000002` | -| L2_WHITELIST | Override address for the L2 whitelist contract. | `0x5300000000000000000000000000000000000003` | -| L2_WETH | Override address for the L2 WETH contract. | `0x5300000000000000000000000000000000000004` | -| L2_TX_FEE_VAULT | Override address for the L2 transaction fee vault contract. | `0x5300000000000000000000000000000000000005` | - -### Contracts Verification - -Contained in the `[contracts.verification]` section. - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| VERIFIER_TYPE_L1 | Verifier type for the L1 contracts. supports `blockscout`, `etherscan` and `sourcify`. | `blockscout` | -| VERIFIER_TYPE_L2 | Verifier type for the L2 contracts. supports `blockscout`, `etherscan` and `sourcify`. | `blockscout` | -| EXPLORER_URI_L1 | Homepage URL of L1 explorer. | `http://l1-explorer.scrollsdk` | -| EXPLORER_URI_L2 | Homepage URL of L2 explorer. | `http://blockscout.scrollsdk` | -| RPC_URI_L1 | RPC URL of L1 network. | `http://l1-devnet.scrollsdk` | -| RPC_URI_L2 | RPC URL of L1 network. | `http://l1-devnet.scrollsdk` | -| EXPLORER_API_KEY_L1 | Explorer API key for L1 contracts verification. Leave it blank if verifier type is `blockscout`. | | -| EXPLORER_API_KEY_L2 | Explorer API key for L2 contracts verification. Leave it blank if verifier type is `blockscout`. | | - -### Coordinator - -Contained in the `[coordinator]` section. - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| CHUNK_COLLECTION_TIME_SEC | Time in seconds for chunk collection. | 3600 | -| BATCH_COLLECTION_TIME_SEC | Time in seconds for batch collection. | 1800 | -| BUNDLE_COLLECTION_TIME_SEC | Time in seconds for bundle collection. | 600 | -| COORDINATOR_JWT_SECRET_KEY | Secret key used for JWT authentication in the coordinator. | `e788b62d39254928a821ac1c76b274a8c835aa1e20ecfb6f50eb10e87847de44` | - - -### Ingress - -Contained in the `[ingress]` section. - -Ingress values are not used by the configuration generation scripts, but used by the `scroll-sdk-cli` to configure hosts and TLS settings in the values files for each chart. - -| Config Variable | Description | Default Value | -|-----------------|-------------|---------------| -| FRONTEND_HOST | Host for the frontend. | `frontends.scrollsdk` | -| BRIDGE_HISTORY_API_HOST | Host for the Bridge History API. | `bridge-history-api.scrollsdk` | -| ROLLUP_EXPLORER_API_HOST | Host for the Rollup Explorer API. | `rollup-explorer-backend.scrollsdk` | -| COORDINATOR_API_HOST | Host for the Coordinator API. | `coordinator-api.scrollsdk` | -| RPC_GATEWAY_HOST | Host for the RPC Gateway. | `l2-rpc.scrollsdk` | -| BLOCKSCOUT_HOST | Host for Blockscout. | `blockscout.scrollsdk` | -| BLOCKSCOUT_BACKEND_HOST | Host for Blockscout Backend. | `blockscout-backend.scrollsdk` | -| ADMIN_SYSTEM_DASHBOARD_HOST | Host for the Admin System Dashboard. | `admin-system-dashboard.scrollsdk` | -| L1_DEVNET_HOST | Host for the L1 Devnet. | `l1-devnet.scrollsdk` | -| L1_EXPLORER_HOST | Host for the L1 Explorer. | `l1-explorer.scrollsdk` | -| GRAFANA_HOST | Host for the Grafana frontend. | `grafana.scrollsdk` | - -{/* TODO: Check Blockscout backend host after PR is merged. */} - -## Sepolia Deployment - -For using Sepolia as the basechain of a testnet deployment, you will need to generate new wallets for the various missing accounts and provide a Sepolia RPC endpoint with generous limits. - -The `scroll-sdk-cli` tool has a command for generating new accounts setting the values for various basechain networks. - -### Generating Accounts - -To generate new test accounts quickly without using the `scroll-sdk-cli`, run the following command on a machine with Foundry installed. - -```bash -cast wallet new --number 6 --json -``` diff --git a/src/content/docs/en/sdk/technical-stack/contracts.mdx b/src/content/docs/en/sdk/technical-stack/contracts.mdx deleted file mode 100644 index ac0d81e6f..000000000 --- a/src/content/docs/en/sdk/technical-stack/contracts.mdx +++ /dev/null @@ -1,194 +0,0 @@ ---- -section: sdk -date: Last Modified -title: "Scroll SDK Contracts" -lang: "en" -permalink: "sdk/technical-stack/contracts" -excerpt: "Documents the contracts deployed to support the Scroll SDK." ---- - -import Aside from "../../../../../components/Aside.astro" - -{/* TODO: Review full page before launch */} - -## Overview - -Contracts deployed for a Scroll SDK chain include both contracts on the L1 (or basechain), and contracts deployed on the L2 (or SDK chain). Additionally, the L2 has "pre-deployed" contracts, matching those on [Scroll](/en/developers/scroll-contracts#l2-predeploys). - -## Primary Contracts - -Although there are many contracts deployed during a new chain deployment, the most important contracts to understand are below. - -### Rollup Contract - -- Deployed to L1 using a proxy and also called "Scroll Chain" -- Accepts new batches and proofs posted by the `rollup-relayer` service by calling "Commit Batch" and "Finalize Batch" methods. -- Keeps track of finalized State Roots and Withdraw Roots. -- [View on Etherscan](https://etherscan.io/address/0xa13BAF47339d63B743e7Da8741db5456DAc1E556) | [View Source](https://github.com/scroll-tech/scroll-contracts/blob/main/src/L1/rollup/ScrollChain.sol) - -### Scroll Message Queues - -- Deployed to L1 with a proxy and pre-deployed to L2 -- On L1, every depost to the bridge is added as a message to the L1 message queue. - - Messages are read by `l2geth` instances, including the sequencer, and brought into the Scroll chain via L1Message transaction types. -- On L2, every withdrawal sent through the bridge is added as a message, and each block's resulting withdraw root is made available after finalization on the L1 Rollup Contract. - - At any time, a user can permissionlessly generate proof to [finish relaying the message on L1](/en/developers/l1-and-l2-bridging/the-scroll-messenger#finalizing-transactions-on-l1). -- Messages are added to the queues exclusively by the Messenger contracts on [L1](https://github.com/scroll-tech/scroll-contracts/blob/main/src/L1/L1ScrollMessenger.sol) and [L2](https://github.com/scroll-tech/scroll-contracts/blob/main/src/L2/L2ScrollMessenger.sol). -- [View L1 Deployment on Etherscan](https://etherscan.io/address/0x0d7E906BD9cAFa154b048cFa766Cc1E54E39AF9B) | [View Source](https://github.com/scroll-tech/scroll-contracts/blob/main/src/L1/rollup/L1MessageQueue.sol) -- [View L2 Deployment on Scrollscan](https://scrollscan.com/address/0x5300000000000000000000000000000000000000) | [View Source](https://github.com/scroll-tech/scroll-contracts/blob/main/src/L2/predeploys/L2MessageQueue.sol) - -### Gas Oracle Contracts - -- Deployed on L1 (as part of L1 Message Queue) and pre-deployed on L2 -- On L1, it tracks the gas fees on L2. This is needed since L1 transactions need to pay for their L2 gas upfront. - - Stored `l2BaseFee` can only be updated by whitelisted addresses, _TODO: is this done by `gas-oracle` on L1 and L2?_ -- On L2, the contract keeps track of the fees on L1, allowing other contracts to know how the cost required to send a transaction back to L1 - - Stored `l1BaseFee` can only be updated by whitelisted addresses, _TODO: is this done by `gas-oracle` on L1 and L2?_ -- [View L1 Deployment on Etherscan](https://etherscan.io/address/0x0d7E906BD9cAFa154b048cFa766Cc1E54E39AF9B) | [View Source](https://github.com/scroll-tech/scroll-contracts/blob/main/src/L1/rollup/L2GasPriceOracle.sol) -- [View L2 Deployment on Scrollscan](https://scrollscan.com/address/0x5300000000000000000000000000000000000002) | [View Source](https://github.com/scroll-tech/scroll-contracts/blob/main/src/L2/predeploys/L1GasPriceOracle.sol) - -## Deployment Process - -Contracts are deployed by the `contracts` chart. Deterministic addresses are used, with a salt used to generate the address of the contract. For every new deployment, a unique salt should be configured in `config.toml`. - -During the configuration generation step, a simulation is first done to determine what address a contract will deploy to. This step is done during the creation of the config files for each service's chart and when the `genesis.json` file is created. Contract addresses are then used to set each service's configuration (see [`gen-configs.sh`](https://github.com/scroll-tech/scroll-contracts/blob/feat-robust-deployment/docker/scripts/gen-configs.sh)). - -Then, before the `contracts` chart is installed, you will need to fund your SDK `DEPLOYER` account to deploy all contracts on L1 and L2 using actual transactions. - -The `contracts` pod will connect to the L2 RPC and deploy the necessary contracts from the `DEPLOYER` account. - - - -### Funding Deployment Accounts - -In production deployments, you will need to manually fund the following wallet addresses from `config.toml`: - -- `DEPLOYER_ADDR` *(only needs funded on L1)* - {/* - Suggested funds: `(L1 basefee * VARIABLE * 10e-9) ETH` */} -- `L1_COMMIT_SENDER_ADDR` - {/* - Suggested funds: `(L1 basefee * VARIABLE * 10e-9) ETH` */} -- `L1_FINALIZE_SENDER_ADDR` - {/* - Suggested funds: `(L1 basefee * VARIABLE * 10e-9) ETH` */} -- `L1_GAS_ORACLE_SENDER_ADDR` - {/* - Suggested funds: `(L1 basefee * VARIABLE * 10e-9) ETH` */} -- `L2_GAS_ORACLE_SENDER_ADDR` *(funded after L2 chain deployment)* - {/* - Suggested funds: `(L1 basefee * VARIABLE * 10e-9) ETH` */} - -{/* TODO: Consider recommending an initial funding amount. */} - - - - - - -## Contracts Deployed - -In the table below, we document every contract deployed for Scroll, including a link to the deployment for Scroll's mainnet. Not all of these are used by default for Scroll SDK. - -{/* */} - -| Contract Name | Description | -| -------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | -| [L1_WETH_ADDR](https://etherscan.io/address/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2) | The WETH contract on L1. | -| [L2_WETH_ADDR](https://scrollscan.com/address/0x5300000000000000000000000000000000000004) | The WETH contract on L2. | -| [L1_PLONK_VERIFIER_V0_ADDR](https://etherscan.io/address/0x4B8Aa8A96078689384DAb49691E9bA51F9d2F9E1) | The PLONK verifier version 0 on L1. | -| [L1_ZKEVM_VERIFIER_V0_ADDR](https://etherscan.io/address/0x585DfaD7bF4099E011D185E266907A8ab60DAD2D) | The zkEVM verifier version 0 on L1. | -| [L1_PLONK_VERIFIER_V1_ADDR](https://etherscan.io/address/0x2293cd12e8564e8219d314b075867c2f66ac6941) | The PLONK verifier version 1 on L1. | -| [L1_ZKEVM_VERIFIER_V1_ADDR](https://etherscan.io/address/0x4b289E4A5331bAFBc6cCb2F10C39B8EDceCDb247) | The zkEVM verifier version 1 on L1. | -| [L1_PLONK_VERIFIER_V2_ADDR](https://etherscan.io/address/0x03a72B00D036C479105fF98A1953b15d9c510110) | The PLONK verifier version 2 on L1. | -| [L1_ZKEVM_VERIFIER_V2_ADDR](https://etherscan.io/address/0x63FB51C55d9605a75F8872C80De260a00fACfaA2) | The zkEVM verifier version 2 on L1. | -| [L1_MULTIPLE_VERSION_ROLLUP_VERIFIER_ADDR](https://etherscan.io/address/0xf94AfBD9370E25Dd6Ca557d5D67634aeFDA2416B) | The multiple version rollup verifier on L1. | -| [L1_PROXY_ADMIN_ADDR](https://etherscan.io/address/0xEB803eb3F501998126bf37bB823646Ed3D59d072) | The proxy admin contract on L1. | -| [L1_PROXY_IMPLEMENTATION_PLACEHOLDER_ADDR](https://etherscan.io/address/0xFAf8f72e54d1089fa1882b6f597BfDFF59a8AFca) | The proxy implementation placeholder on L1. | -| [L1_WHITELIST_ADDR](https://etherscan.io/address/0x259204DDd2bA29bD9b1B9A5c9B093f73d7EAcf37) | The whitelist contract on L1. | -| [L1_MESSAGE_QUEUE_IMPLEMENTATION_ADDR](https://etherscan.io/address/0xeBaed7A81c298B24EE6d59c22698A951dc448E01) | The message queue implementation on L1. | -| [L1_MESSAGE_QUEUE_PROXY_ADDR](https://etherscan.io/address/0x0d7E906BD9cAFa154b048cFa766Cc1E54E39AF9B) | The message queue proxy on L1. | -| [L2_GAS_PRICE_ORACLE_IMPLEMENTATION_ADDR](https://etherscan.io/address/0xfDF1eE0098168eaa61BF87Db68C39c85151a4E9E) | The gas price oracle implementation on L1. | -| [L2_GAS_PRICE_ORACLE_PROXY_ADDR](https://etherscan.io/address/0x987e300fDfb06093859358522a79098848C33852) | The gas price oracle proxy on L1. | -| [L1_SCROLL_CHAIN_IMPLEMENTATION_ADDR](https://etherscan.io/address/0x4F250B05262240C787a1eE222687C6eC395C628A) | The Scroll chain implementation on L1. | -| [L1_SCROLL_CHAIN_PROXY_ADDR](https://etherscan.io/address/0xa13BAF47339d63B743e7Da8741db5456DAc1E556) | The Scroll chain proxy on L1. | -| [L1_ETH_GATEWAY_IMPLEMENTATION_ADDR](https://etherscan.io/address/0x546E0bF31FB6e7babD493452e4e6999191367B42) | The ETH gateway implementation on L1. | -| [L1_ETH_GATEWAY_PROXY_ADDR](https://etherscan.io/address/0x7F2b8C31F88B6006c382775eea88297Ec1e3E905) | The ETH gateway proxy on L1. | -| [L1_WETH_GATEWAY_IMPLEMENTATION_ADDR](https://etherscan.io/address/0xa4F400593DFfc0ae02F940ab58f6e3Cc6fb9FB49) | The WETH gateway implementation on L1. | -| [L1_WETH_GATEWAY_PROXY_ADDR](https://etherscan.io/address/0x7AC440cAe8EB6328de4fA621163a792c1EA9D4fE) | The WETH gateway proxy on L1. | -| [L1_STANDARD_ERC20_GATEWAY_IMPLEMENTATION_ADDR](https://etherscan.io/address/0x4015Fc868C06689ABEba4a9dC8FA43B804F6239c) | The standard ERC20 gateway implementation on L1. | -| [L1_STANDARD_ERC20_GATEWAY_PROXY_ADDR](https://etherscan.io/address/0xD8A791fE2bE73eb6E6cF1eb0cb3F36adC9B3F8f9) | The standard ERC20 gateway proxy on L1. | -| [L1_GATEWAY_ROUTER_IMPLEMENTATION_ADDR](https://etherscan.io/address/0xb93Ac04010Bd61F45BF492022A5b49a902F798F3) | The gateway router implementation on L1. | -| [L1_GATEWAY_ROUTER_PROXY_ADDR](https://etherscan.io/address/0xF8B1378579659D8F7EE5f3C929c2f3E332E41Fd6) | The gateway router proxy on L1. | -| [L1_SCROLL_MESSENGER_IMPLEMENTATION_ADDR](https://etherscan.io/address/0x72981fD00087fF4F60aBFdE9f353cB1912A37fb6) | The Scroll messenger implementation on L1. | -| [L1_SCROLL_MESSENGER_PROXY_ADDR](https://etherscan.io/address/0x6774Bcbd5ceCeF1336b5300fb5186a12DDD8b367) | The Scroll messenger proxy on L1. | -| [L1_ENFORCED_TX_GATEWAY_IMPLEMENTATION_ADDR](https://etherscan.io/address/0x642af405bF64660665B37977449C9C536B806318) | The enforced transaction gateway implementation on L1. | -| [L1_ENFORCED_TX_GATEWAY_PROXY_ADDR](https://etherscan.io/address/0x72CAcBcfDe2d1e19122F8A36a4d6676cd39d7A5d) | The enforced transaction gateway proxy on L1. | -| [L1_CUSTOM_ERC20_GATEWAY_IMPLEMENTATION_ADDR](https://etherscan.io/address/0x7F512E2E9dfC4552941D99A5b2405BBcF5781C2c) | The custom ERC20 gateway implementation on L1. | -| [L1_CUSTOM_ERC20_GATEWAY_PROXY_ADDR](https://etherscan.io/address/0xb2b10a289A229415a124EFDeF310C10cb004B6ff) | The custom ERC20 gateway proxy on L1. | -| [L1_ERC721_GATEWAY_IMPLEMENTATION_ADDR](https://etherscan.io/address/0xd1841c5756428812233eEA78afC17cb2D3e392bb) | The ERC721 gateway implementation on L1. | -| [L1_ERC721_GATEWAY_PROXY_ADDR](https://etherscan.io/address/0x6260aF48e8948617b8FA17F4e5CEa2d21D21554B) | The ERC721 gateway proxy on L1. | -| [L1_ERC1155_GATEWAY_IMPLEMENTATION_ADDR](https://etherscan.io/address/0x244BF7aEf29F03916569470a51fA0794B62F8cd7) | The ERC1155 gateway implementation on L1. | -| [L1_ERC1155_GATEWAY_PROXY_ADDR](https://etherscan.io/address/0xb94f7F6ABcb811c5Ac709dE14E37590fcCd975B6) | The ERC1155 gateway proxy on L1. | -| [L1_SCROLL_OWNER_ADDR](https://etherscan.io/address/0x798576400F7D662961BA15C6b3F3d813447a26a6) | The Scroll owner contract on L1. | -| [L1_1D_TIMELOCK_ADDR](https://etherscan.io/address/0x0e58939204eEDa84F796FBc86840A50af10eC4F4) | The 1-day timelock contract on L1. | -| [L1_7D_TIMELOCK_ADDR](https://etherscan.io/address/0xDC1d1189Da69Ae2016E4976A43De20972D349B1b) | The 7-day timelock contract on L1. | -| [L1_14D_TIMELOCK_ADDR](https://etherscan.io/address/0x1A658B88fD0a3c82fa1a0609fCDbD32e7dd4aB9C) | The 14-day timelock contract on L1. | -| [L1_GAS_PRICE_ORACLE_ADDR](https://scrollscan.com/address/0x5300000000000000000000000000000000000002) | The gas price oracle contract on L2. | -| [L2_MESSAGE_QUEUE_ADDR](https://scrollscan.com/address/0x5300000000000000000000000000000000000000) | The message queue contract on L2. | -| [L2_TX_FEE_VAULT_ADDR](https://scrollscan.com/address/0x5300000000000000000000000000000000000005) | The transaction fee vault contract on L2. | -| [L2_WHITELIST_ADDR](https://scrollscan.com/address/0x5300000000000000000000000000000000000003) | The whitelist contract on L2. | -| [L2_PROXY_ADMIN_ADDR](https://scrollscan.com/address/0xA76acF000C890b0DD7AEEf57627d9899F955d026) | The proxy admin contract on L2. | -| [L2_PROXY_IMPLEMENTATION_PLACEHOLDER_ADDR](https://scrollscan.com/address/0xF8a069d9230238763Fc574157fa39a78396bd26c) | The proxy implementation placeholder on L2. | -| [L2_SCROLL_MESSENGER_IMPLEMENTATION_ADDR](https://scrollscan.com/address/0x6fa66EeD8e8086f4c77204B5484D26F4e9AB7772) | The Scroll messenger implementation on L2. | -| [L2_SCROLL_MESSENGER_PROXY_ADDR](https://scrollscan.com/address/0x781e90f1c8Fc4611c9b7497C3B47F99Ef6969CbC) | The Scroll messenger proxy on L2. | -| [L2_ETH_GATEWAY_IMPLEMENTATION_ADDR](https://scrollscan.com/address/0x191770c52309dff2c52FfEcf059ECC3862f5D721) | The ETH gateway implementation on L2. | -| [L2_ETH_GATEWAY_PROXY_ADDR](https://scrollscan.com/address/0x6EA73e05AdC79974B931123675ea8F78FfdacDF0) | The ETH gateway proxy on L2. | -| [L2_WETH_GATEWAY_IMPLEMENTATION_ADDR](https://scrollscan.com/address/0x86c5CBfC03ffFC7faf5dfC7D781A9adfA9f47dD1) | The WETH gateway implementation on L2. | -| [L2_WETH_GATEWAY_PROXY_ADDR](https://scrollscan.com/address/0x7003E7B7186f0E6601203b99F7B8DECBfA391cf9) | The WETH gateway proxy on L2. | -| [L2_STANDARD_ERC20_GATEWAY_IMPLEMENTATION_ADDR](https://scrollscan.com/address/0x3ffe801a43D25d0288683237A848e14f73a226f0) | The standard ERC20 gateway implementation on L2. | -| [L2_STANDARD_ERC20_GATEWAY_PROXY_ADDR](https://scrollscan.com/address/0xE2b4795039517653c5Ae8C2A9BFdd783b48f447A) | The standard ERC20 gateway proxy on L2. | -| [L2_GATEWAY_ROUTER_IMPLEMENTATION_ADDR](https://scrollscan.com/address/0x3808d0F2F25839E73e0Fbf711368fC4aE80c7763) | The gateway router implementation on L2. | -| [L2_GATEWAY_ROUTER_PROXY_ADDR](https://scrollscan.com/address/0x4C0926FF5252A435FD19e10ED15e5a249Ba19d79) | The gateway router proxy on L2. | -| [L2_SCROLL_STANDARD_ERC20_ADDR](https://scrollscan.com/address/0xC7d86908ccf644Db7C69437D5852CedBC1aD3f69) | The Scroll standard ERC20 contract on L2. | -| [L2_SCROLL_STANDARD_ERC20_FACTORY_ADDR](https://scrollscan.com/address/0x66e5312EDeEAef6e80759A0F789e7914Fb401484) | The Scroll standard ERC20 factory contract on L2. | -| [L2_CUSTOM_ERC20_GATEWAY_IMPLEMENTATION_ADDR](https://scrollscan.com/address/0x1D40306EEfCF6EBd496d6048F6edf8892346e558) | The custom ERC20 gateway implementation on L2. | -| [L2_CUSTOM_ERC20_GATEWAY_PROXY_ADDR](https://scrollscan.com/address/0x64CCBE37c9A82D85A1F2E74649b7A42923067988) | The custom ERC20 gateway proxy on L2. | -| [L2_ERC721_GATEWAY_IMPLEMENTATION_ADDR](https://scrollscan.com/address/0x0894150DB82B912105F6D0907B5c69E72F1Df279) | The ERC721 gateway implementation on L2. | -| [L2_ERC721_GATEWAY_PROXY_ADDR](https://scrollscan.com/address/0x7bC08E1c04fb41d75F1410363F0c5746Eae80582) | The ERC721 gateway proxy on L2. | -| [L2_ERC1155_GATEWAY_IMPLEMENTATION_ADDR](https://scrollscan.com/address/0xAc92E88bAc1848A5FeEA5cf5A60e0abc3bD5Df94) | The ERC1155 gateway implementation on L2. | -| [L2_ERC1155_GATEWAY_PROXY_ADDR](https://scrollscan.com/address/0x62597Cc19703aF10B58feF87B0d5D29eFE263bcc) | The ERC1155 gateway proxy on L2. | -| [L2_SCROLL_OWNER_ADDR](https://scrollscan.com/address/0x13D24a7Ff6F5ec5ff0e9C40Fc3B8C9c01c65437B) | The Scroll owner contract on L2. | -| [L2_1D_TIMELOCK_ADDR](https://scrollscan.com/address/0x2b14d0E4b042d11C7e3Fc653132a2c82EFa7d376) | The 1-day timelock contract on L2. | -| [L2_7D_TIMELOCK_ADDR](https://scrollscan.com/address/0x98DE219A50584be7ca16A065f7714D220c0105F6) | The 7-day timelock contract on L2. | -| [L2_14D_TIMELOCK_ADDR](https://scrollscan.com/address/0xf6069DB81239E5194bb53f83aF564d282357bc99) | The 14-day timelock contract on L2. | -| [SCROLL_CHAIN_COMMITMENT_VERIFIER_ADDR](https://etherscan.io/address/0xC4362457a91B2E55934bDCb7DaaF6b1aB3dDf203) | The Scroll chain commitment verifier contract. | -| [POSEIDON_UNIT2_ADDR](https://etherscan.io/address/0x3508174Fa966e75f70B15348209E33BC711AE63e) | The Poseidon unit 2 contract. | -| [L1_BATCH_BRIDGE_GATEWAY_PROXY_ADDR](https://etherscan.io/address/0x5Bcfd99c34cf7E06fc756f6f5aE7400504852bc4) | The Batch Deposit proxy contract on L1. | -| [L1_BATCH_BRIDGE_GATEWAY_IMPLEMENTATION_ADDR](https://etherscan.io/address/0x7999cdD5E2893475D89211A2E3FdA67a841E3233) | The Batch Deposit implementation on L1. | -| [L2_BATCH_BRIDGE_GATEWAY_PROXY_ADDR](https://scrollscan.com/address/0xa1a12158bE6269D7580C63eC5E609Cdc0ddD82bC) | The Batch Deposit proxy contract on L2. | -| [L2_BATCH_BRIDGE_GATEWAY_IMPLEMENTATION_ADDR](https://scrollscan.com/address/0x2c51f93E3075A007A746aa91F4BA07Aee8423b6f) | The Batch Deposit implementation on L2. | diff --git a/src/content/docs/en/sdk/technical-stack/index.mdx b/src/content/docs/en/sdk/technical-stack/index.mdx deleted file mode 100644 index 2eefe5810..000000000 --- a/src/content/docs/en/sdk/technical-stack/index.mdx +++ /dev/null @@ -1,129 +0,0 @@ ---- -section: sdk -title: "Overview of Scroll SDK Stack" -lang: "en" -permalink: "sdk/technical-stack" -excerpt: "An overview of the architecture and components making up Scroll SDK" ---- - -import Steps from '../../../../../components/Steps/Steps.astro'; -import Aside from "../../../../../components/Aside.astro" - -## Stack Technical Overview - -The architecture of a Scroll SDK chain is based on Scroll, and the architecture specifics of a Scroll SDK chain will match the base behavior of Scroll's network. For more information on how Scroll works, please see the [Technology](/en/technology) section. - -The articles in this section will be focus on the various parts a Scroll SDK chain operator will need to deploy and run. - -## Tooling - -### Scroll SDK Repo & Charts - -Scroll SDK can be found [on GitHub](https://github.com/scroll-tech/scroll-sdk). The SDK built is leveraging Kubernetes and is designed to be easy to launch and maintain for anyone familiar with Kubernetes and Helm. - -The repo consists of these major components: -1. Example config files for preparing your network *(see [Configuration](/en/sdk/technical-stack/configuration))* -1. Helm charts for deploying the necessary services and contracts *(see [Services](/en/sdk/technical-stack/services))* -1. A docker image for building the correct configuration files for these services and gathering smart contract addresses before deployment *(see [Smart Contracts](/en/sdk/technical-stack/contracts))* -1. An Ansible playbook for setting up a zk prover if not using a third party proof generation service *(see [Proof Generation](/en/sdk/technical-stack/proof-generation))* - - - -### Scroll SDK CLI - -Additionally, the [scroll-sdk-cli](https://github.com/scroll-tech/scroll-sdk-cli) tool is available to help with common automations and testing tasks. It greatly simplifies the process of creating a new Scroll SDK chain and includes a number of helpful commands for interacting with your chain. - -It also supports custom plugins using the [oclif framework](https://oclif.com/docs/plugins). - -## Scroll Proving SDK - -The Scroll Proving SDK is a Rust crate for integrating Scroll SDK support into your prover services. The proof generation providers should use this SDK to build their own Helm charts, allowing SDK operators to out-source proof generation. - -For an example service built using `scroll-proving-sdk`, see the `cloud.rs` example in the[Scroll Proving SDK](https://github.com/scroll-tech/scroll-proving-sdk/blob/haoyu/sindri_tokio/examples/cloud.rs) repo. - -{/* TODO: check if this branch has been merged into main */} - -## Deployment Process - -Scroll SDK has two deployment options: a local devnet and a production deployment. - -When deploying a local Devnet, all services are deployed by a single "chart". Configuration is minimal, and the deployment includes additional services like a hosting a database in the cluster. We assume users are working inside the `devnet` directory of a `scroll-sdk` cloned repo. - -In production deployments, each service is deployed as an independent chart. This is often more natural for tight control over upgrades and configuration. Production deployments assume that services like a database or monitoring stacks will be provided by the chain operator. Because of the additional modularity and flexibility, additional configuration is needed and some knowledge of Kubernetes is required. We also assume users will create a new repo for storing their production workflow and configuration files. - -### Devnet - -For a full devnet deployment walkthrough, see the [Devnet Deployment](/en/sdk/guides/devnet-deployment) guide. - -#### PreReqs - -To run a local devnet with all services running on a single machine (using minikube), you'll want the following items installed: - -- [Docker Engine](https://docs.docker.com/engine/install/) (or Docker Desktop) -- [kubectl](https://kubernetes.io/docs/tasks/tools/) -- [minikube](https://minikube.sigs.k8s.io/docs/start/) (for local dev cluster) -- [Helm](https://helm.sh/docs/intro/install/) - -Docker and minikube will need to be running before starting the deployment process. - - -#### Deployment - - -1. Clone the Scroll SDK repo and navigate to the `./devnet` directory. - - ```bash - git clone git@github.com:scroll-tech/scroll-sdk.git && cd scroll-sdk/devnet - ``` - -1. Fetch all charts and create configuration files. - - ```bash - make bootstrap - ``` - -1. *(Optional)* Modify `./scroll-sdk/config.toml` with your settings and accounts. - - For more information on modifying config.toml, see [Customization](/en/sdk/technical-stack/customization). - -1. *(Optional)* Modify `./scroll-sdk/values.yaml` to disable any unneeded services. - - For more information on which services to set `enable:true`, see [Services](/en/sdk/technical-stack/services). - -1. *(Optional)* If modifications were made, run `make config` to update the configuration files. - - -1. Launch the Scroll SDK services by running: - ```bash - make install - ``` - -1. Wait for services to start and contracts to deploy, and you've got a new Scroll SDK chain! - - - - -### Production - -For a full production deployment walkthrough, see the guides for [Digital Ocean](/en/sdk/guides/production-deployment/digital-ocean) and [AWS](/en/sdk/guides/production-deployment/aws). - -#### PreReqs - -Before getting started, be sure to install the following: - -- [Docker Engine](https://docs.docker.com/engine/install/) (or Docker Desktop) -- [kubectl](https://kubernetes.io/docs/tasks/tools/) -- [Helm](https://helm.sh/docs/intro/install/) - -For a production environment, you'll want to have a working Kubernetes cluster and `kubectl` configured to point to it. We assume users will create a new repo for storing their production workflow. Docker will be used locally in the configuration preparation workflow. - -In addition, you'll want to prepare the following items: -- A PostgreSQL-compatible database with an admin user - - Up to 3 for chain services, optionally 1 more for Blockscout -- A Kubernetes Monitor Service (i.e. Prometheus) -- A Kubernetes Ingress Controller (i.e. Nginx) -- A Secret Store for storing sensitive information (i.e. AWS Secrets, Hashicorp Vault) and a way to access it from Kubernetes using [External Secrets](https://external-secrets.io/latest/) - -More information on choosing and setting up these services for various cloud providers is provided in the [Guides](/en/sdk/guides) section. \ No newline at end of file diff --git a/src/content/docs/en/sdk/technical-stack/integrations.mdx b/src/content/docs/en/sdk/technical-stack/integrations.mdx deleted file mode 100644 index afb12d0f7..000000000 --- a/src/content/docs/en/sdk/technical-stack/integrations.mdx +++ /dev/null @@ -1,13 +0,0 @@ ---- -section: sdk -title: "Scroll SDK Integrations" -lang: "en" -permalink: "sdk/integrations" -excerpt: "An look at those building with Scroll SDK" ---- - -import Aside from "../../../../../components/Aside.astro" - -Scroll is collaborating with a number of projects to integrate their technologies with Scroll SDK. - -We'll continue to expand this list as we onboard more partners, but the best place to see our launch collaborators is on the [Scroll SDK Launch Announcement](https://scroll.io/blog/scroll-sdk-and-gadgets-building-the-foundation-for-ethereums-multichain-future). \ No newline at end of file diff --git a/src/content/docs/en/sdk/technical-stack/proof-generation.mdx b/src/content/docs/en/sdk/technical-stack/proof-generation.mdx deleted file mode 100644 index 4b4d41611..000000000 --- a/src/content/docs/en/sdk/technical-stack/proof-generation.mdx +++ /dev/null @@ -1,99 +0,0 @@ ---- -section: sdk -date: Last Modified -title: "Proof Generation" -lang: "en" -permalink: "sdk/technical-stack/proof-generation" -excerpt: "Documents how zk proof generation is done on Scroll SDK." ---- - -import Aside from "../../../../../components/Aside.astro" - -{/* TODO: Review full page before launch */} -Generating ZK Proofs is a key component for any ZK Rollup, and it can often be the most painful part of operating a zk rollup. - -## Proof Generation Flow - - -## Mock Finalization - -Scroll SDK supports being run in two modes -- one using mock finalization, the other requiring valid zk proofs to finalize. Mock finalization is useful for devnets and testnets, where the zk proof generation is an unnecessary cost beyond brief testing periods. - -In its default configuration, testnets are without a ZK provers and simulate finalization. The L1 contract allows finalizing a batch without a valid proof, and the `rollup-relay` is configured to call the finalize method after 1 hour without a proof in the default configuration. - -To change this mock finalization delay, adjust `config.toml` to change `rollup.TEST_ENV_MOCK_FINALIZE_TIMEOUT` from `3600` to the number of seconds you want to delay. - -To disable mock finalization entirely, adjust `config.toml` to change `TEST_ENV_MOCK_FINALIZE_ENABLED` to `false`. - - - -## Outsourcing Proof Generation to External Service Providers - -Teams shouldn't need to become ZK infrastructure experts (or professional GPU sourcers) to run a chain. We've partnered with proof generation specialists to make outsoucing proof generation as easy as deploying one more chart. - -Using a proof generation service offers the following benefits: -- Generate proofs on-demand through API-based services -- Choose between enterprise solutions or proof marketplaces -- Scale proof generation elastically based on your actual usage instead of reserving a specific capacity -- Maintain flexibility to switch between providers, distribute load between them, or run your own GPUs - -The following providers already support generating Scroll SDK proofs: -- Sindri - - [Chart Repo](https://github.com/Sindri-Labs/sindri-scroll-sdk) - - [Docs](https://sindri.app/docs/introduction/) -- Snarkify - - [Chart Repo](https://github.com/snarkify/snarkify-scroll-proving-sdk/tree/main) - - [Docs](https://docs.snarkify.io/) - -{/* TODO: Confirm links to charts and docs */} - - - -See the [Enable Proof Generation using External Providers](/en/sdk/guides/digital-ocean-alt-gas-token#enable-proof-generation-using-external-providers) section of the Digital Ocean guide for an example of how to enable chunk, batch and bundle proofs using external providers. - -## Self-host a Prover - - - - - -Our automation code for deploying a prover differs from the rest of the stack. Because Kubernetes is designed to automatically manage resources, it doesn't fit as well as [Ansible](https://www.ansible.com/) for larger clusters of machines needing specific machine requirements. - -The Ansible playbook for running a prover is available in the GitHub repo [here](https://github.com/scroll-tech/scroll-sdk/tree/develop/ansible/playbooks). - -### Prequisities - -- One ubuntu server with at least 256GB memory, 32 cores, and a GPU with at least 20GB memory. -- One user with `sudo` access, no password, and all permissions -- or you can change the [shared-vars.yaml](https://github.com/scroll-tech/scroll-sdk/blob/develop/ansible/playbooks/vars/shared-vars.yaml) to add the `ansible_become_password` variable in your file. - -### Configuration - -- Change the values of `rpc` for `mainnet` or `sepolia` in [shared-vars.yaml](https://github.com/scroll-tech/scroll-sdk/blob/develop/ansible/playbooks/vars/shared-vars.yaml) to your own. -- Set the values of `release_version` and `docker_tag` -- this is determined by the `coordinator` service. -- Set the values in [inventory](https://github.com/scroll-tech/scroll-sdk/blob/develop/ansible/playbooks/inventory/provers) for your `sepolia|mainnet' and 'chunk|batch' provers. -- Optionally, set the values of `pj_path` in [shared-vars.yaml](https://github.com/scroll-tech/scroll-sdk/blob/develop/ansible/playbooks/vars/shared-vars.yaml) -- the default is `/prover/go-prover-docker`, but can be changed to the value you want to customize. - -### How to deploy your prover - -Be sure to set the correct value for the `export` statements below when setting environmental variables. _Do not include brackets._ - -```bash -export env=[mainnet|sepolia] -export type=[chunk|batch] -export user=[your_ssh_user] - -ansible-playbook --ssh-extra-args='-o StrictHostKeyChecking=no' --private-key $your_key prover-bootstrap.yaml -u $user -e env=$env -e type=$type -i inventory/provers - -# Reboot your prover manually, and finally launch this playbook -ansible-playbook --ssh-extra-args='-o StrictHostKeyChecking=no' --private-key $your_key prover-deploy.yaml -u $user -e env=$env -e type=$type -i inventory/provers -``` diff --git a/src/content/docs/en/sdk/technical-stack/services.mdx b/src/content/docs/en/sdk/technical-stack/services.mdx deleted file mode 100644 index 463051222..000000000 --- a/src/content/docs/en/sdk/technical-stack/services.mdx +++ /dev/null @@ -1,366 +0,0 @@ ---- -section: sdk -date: Last Modified -title: "Scroll SDK Services" -lang: "en" -permalink: "sdk/technical-stack/services" -excerpt: "The various components running to support the Scroll SDK." ---- - -import Aside from "../../../../../components/Aside.astro" - -{/* TODO: Review full page before launch */} - -## Overview - -Scroll SDK is composed of various services that work together to create a functional rollup. This article provides an overview of these services, their roles, and how they contribute to the overall architecture of Scroll SDK. - -We'll start by listing the services required for a minimal deployment, followed by a detailed description of each service. This information will help you understand the components of Scroll SDK and make informed decisions about which services to enable or disable based on your specific needs. - -In a devnet environment, services are enabled using the [values.yaml](https://github.com/scroll-tech/scroll-sdk/blob/develop/charts/scroll-sdk/values.yaml). Production environments deploy charts individually, and each service corresponds to a helm chart, as seen in this example [Makefile](https://github.com/scroll-tech/scroll-sdk/blob/develop/examples/Makefile.example). - -**New to Scroll’s Architecture?** Check out [this article](/en/technology/chain/rollup/) for more general info. - -## Helm & Kubernetes - -The Scroll SDK uses Helm charts and Kubernetes manifests to manage service deployments. Each service has its own configuration files that are automatically generated from the main `config.toml` file using the `scroll-sdk-cli` tool (described in [Configuration](/en/sdk/technical-stack/configuration)). - -The configuration flow works like this: - -1. Modify the main `config.toml` file with your deployment settings. -2. The `scroll-sdk-cli` tool processes this file and generates service-specific config files -3. These config files are mounted into the appropriate services as Kubernetes ConfigMaps -4. Helm uses these configs along with the values files to deploy the services - -The key configuration files for each service are located in: - -- `charts/[service-name]/templates/` - Kubernetes manifests and Helm templates -- `charts/[service-name]/values.yaml` - Default values for the service -- `charts/[service-name]/values/production.yaml` - Production-specific values for the service, matching `examples/values/[service-name]-production.yaml`. - -For cloud deployments, we suggest using the `Makefile`, `config.toml` and chart values files found in the [examples directory](https://github.com/scroll-tech/scroll-sdk/tree/develop/examples) as a starting point. - - -### Service-specific Config Values - -The `config.toml` file is used to generate various service-specific configuration files. When using the `scroll-sdk-cli`, these have the name `[service]-config.yaml` and are passed to charts as a value override of `scrollConfig` alongside the `production.yaml` files mentioned above. - -{/* TODO: Double check if this is how devnet works. */} - -Each service has a number configuration values -- some quite nuanced. - -In most instances, if it is not directly set or calculated from values in the `config.toml`, a sensible default is used. Occassionally, a feature most operators do not need during their initial deployment is here as well (for example LDAP configuration for the `admin-system-backend`). If you manually change these values, keep in mind that the `config.toml` processing script may overwrite your customizations -- please use git commits track changes. - -### Ingress - -By default, our charts use the `ingress-nginx` helm chart, which automatically creates ingress resources. - -The following services need to be exposed to clients outside of the cluster and have ingresses setup by default. In devnet, the host values end in `.scrollsdk`. If using Ingress DNS, these URLs should be accessible from the host machine, assuming a properly configured `etc/hosts` file: - -| Name | Host | Port | -|---------------------|-------------------------------|------| -| admin-system-dashboard | [admin-system-dashboard.scrollsdk](http://admin-system-dashboard.scrollsdk) | 80 | -| blockscout | [blockscout.scrollsdk](http://blockscout.scrollsdk) | 80 | -| blockscout *(backend)* | [blockscout-backend.scrollsdk](http://blockscout.scrollsdk) | 80 | -| bridge-history-api | [bridge-history-api.scrollsdk](http://bridge-history-api.scrollsdk) | 80 | -| frontends | [frontends.scrollsdk](http://frontends.scrollsdk) | 80 | -| grafana | [grafana.scrollsdk](http://grafana.scrollsdk) | 80 | -| l1-devnet | [l1-devnet.scrollsdk](http://l1-devnet.scrollsdk) | 80 | -| l1-explorer | [l1-devnet-explorer.scrollsdk](http://l1-devnet-explorer.scrollsdk) | 80 | -| l2-rpc | [l2-rpc.scrollsdk](http://l2-rpc.scrollsdk) | 80 | - -When using the example values files for production deployments, these hosts (and any corresponding TLS settings) are set in the service's `production.yaml` file, which is automatically configured by the `scroll-sdk-cli` tool. You will need to configure your host domain's DNS settings to point to the ingress controller or load balancer. - -We recommend using TLS for all services in production deployments, which can be configured in the `ingress.tls` section of the `values.yaml` file. - -### Secrets - -Scroll SDK uses a combination of [secrets](https://kubernetes.io/docs/concepts/configuration/secret/) and [configmaps](https://kubernetes.io/docs/concepts/configuration/configmap/) to manage configuration. Additionally, we use External Secrets to support storing secrets in a secret manager tools like AWS Secrets Manager or HashiCorp Vault. - -# Deployment Configurations - -Below, we describe three configurations for services: -- **Default**: a robust, local test environment and the default `values.yaml` used by the devnet. -- **Minimal**: the minimal required components for a testnet (with notes on possible replacements) -- **Production**: the minimal recommended components for a mainnet, including ZK proof generation - -> ✅: Required -> -> ⚠️: Hosted options or substitutions are available. -> - -| Service | Default | Minimal | Production | -| ----------------------- | :-----: | :-----: | :--------: | -| admin-system-backend | ✅ | | | -| admin-system-cron | ✅ | | | -| admin-system-dashboard | ✅ | | | -| balance-checker | | | ⚠️ | -| blockscout | ✅ | | | -| bridge-history-api [^1] | ✅ | ✅ | ✅ | -| bridge-history-fetcher [^1] | ✅ | ✅ | ✅ | -| chain-monitor | | ✅ | ✅ | -| contracts | ✅ | ✅ | ✅ | -| coordinator-api [^2] | | | ✅ | -| coordinator-cron [^2] | | | ✅ | -| frontends | ✅ | | ⚠️ | -| gas-oracle | ✅ | ✅ | ✅ | -| grafana | ✅ | | ⚠️ | -| kube-prometheus-stack | ✅ | | | -| l1-devnet | ✅ | | | -| l1-explorer | ✅ | | | -| l2-bootnode | ✅ | | ✅ | -| l2-rpc | ✅ | | ✅ | -| l2-sequencer | ✅ | ✅ | ✅ | -| loki-stack | ✅ | | ⚠️ | -| postgresql | ✅ | ⚠️ | ⚠️ | -| rollup-explorer-backend | ✅ | | | -| rollup-node | ✅ | ✅ | ✅ | -| rpc-gateway | | | ️ | -{/* | scroll-monitor | ✅ | | | */} - -{/* TODO: add scroll-monitor and remove grafana + kube stack after PR is merged and devnet updated. */} - -[^1]: Services necessary for claiming funds bridged from L2 to L1 and used by bridge frontend. Could be replaced by [Bridge History SDK](https://github.com/scroll-tech/scroll-bridge-sdk) for other usage. -[^2]: Only necessary for chains after testnet, when proof generation is needed. - - -## Services Overview - -#### Anvil (`l1-devnet`) - -*Devnet only.* - -Foundry [Anvil](https://book.getfoundry.sh/reference/anvil/) serves as the default local base chain for devnet deployments. It provides a simulated Ethereum environment for testing and development purposes. - -#### Admin System Dashboard (`admin-system-dashboard`) - -The Admin System Dashboard is a simple Web UI for monitoring proofs in the Scroll SDK chain. Beyond giving insight into proof jobs and registered provers, it provides a high-level overview of the network's health and status, including the number of transactions, blocks, chunks, batches, and bundles. - -#### Admin System Backend (`admin-system-backend`) - -Handles the backend API for the Admin System Dashboard. Supports LDAP and 2FA. - -#### Admin System Cron (`admin-system-cron`) - -Handles the cron jobs for the Admin System. - -#### Blockscout (`blockscout`) - -[Blockscout](https://docs.blockscout.com/) is an open-source block explorer with an Indexer and WebUI configured specifically for the Scroll SDK chain. It allows users to view and interact with blockchain data in a user-friendly interface. We're working with the Blockscout team to implement more Scroll SDK specific features to better support new chain deployments. - -#### Bridge History API (`bridge-history-api`) - -The [Bridge History API](https://github.com/scroll-tech/scroll/tree/develop/bridge-history-api) is used by frontends for reporting a user's bridging history and generating withdrawal proofs for L2 → L1 bridge claims. It provides essential functionality for cross-chain operations. - -This service supports parallel deployments by setting the `controller.replicas` value. - -#### Bridge History Fetcher (`bridge-history-fetcher`) - -The [Bridge History Fetcher](https://github.com/scroll-tech/scroll/tree/0fd7a877cebc3be74aa4d5d2e1592a83f45ed75a/bridge-history-api) is an indexer that continuously collects all user bridging transactions. It ensures that bridging data is up-to-date and readily available for the Bridge History API. - -#### Balance Checker (`balance-checker`) - -The Balance Checker is a simple service to track and monitor the balances of some operator accounts and contracts, such as fee vaults and commit senders. Alerts happen via Slack notification. - -#### Chain Monitor (`chain-monitor`) - -The [Chain Monitor](https://github.com/scroll-tech/chain-monitor) is a security service that short-circuits batch finalization if certain invariants are not satisfied. While optional, it is recommended for enhanced security. - -#### Contracts (`contracts`) - -The Contracts service contains scripts to deploy necessary [chain contracts](https://github.com/scroll-tech/scroll-contracts) (rollup and bridge) on both L1 and L2. It ensures that the required smart contracts are in place for the Scroll SDK to function properly. - -#### Coordinator API (`coordinator-api`) - -The [Coordinator API](https://github.com/scroll-tech/scroll/tree/develop/coordinator) allows Provers to register as being open for work and manages scheduling and storage of proofs. It requires significant RAM to run and is disabled by default in the devnet. - -This service supports parallel deployments by setting the `controller.replicas` value. - -#### Coordinator Cron (`coordinator-cron`) - -The [Coordinator Cron](https://github.com/scroll-tech/scroll/tree/develop/coordinator) is a background job that monitors proving tasks for timeout and marks batches (aggregation tasks) as ready once all sub-proofs are ready. - -#### Frontends (`frontends`) - -[Frontends](https://github.com/scroll-tech/frontends/tree/scroll-stack) provide generic Web UIs for the Rollup Explorer, Bridge, and basic links for setting up your wallet. They offer user-friendly interfaces for interacting with the Scroll SDK chain and viewing its rollup progress. - -#### Gas Oracle (`gas-oracle`) - -The [Gas Oracle](https://github.com/scroll-tech/scroll/tree/develop/rollup) is a backend service that relays up-to-date fee information between L1 and L2 by updating the gas oracle contract on both layers. It helps maintain accurate gas pricing across the network. - -#### Grafana (`grafana`) - -*Devnet only.* - -{/* TODO: Remove after scroll-monitor is merged. */} - -[Grafana](https://grafana.com/docs/grafana/latest/) is an open-source tool for providing a Web UI for viewing metrics dashboards. It allows for visual monitoring and analysis of various system metrics and is pre-packaged with dashboards for viewing Scroll SDK information and logs from Loki. - - - -#### Rollup Explorer Backend (`rollup-explorer-backend`) - -The [Rollup Explorer Backend](https://github.com/scroll-tech/rollup-explorer-backend) is the backend indexer and API for supporting the Rollup Explorer page served by the Frontends service. It allows querying to see chunk and batch information from the rollup, including numbers of transactions and a batch's current finalization status. - -#### Rollup Node (`rollup-node`) - -The Rollup Node (also called the [Rollup Relayer](https://github.com/scroll-tech/scroll/tree/develop/rollup)) is a core component of the Scroll SDK architecture. It plays a crucial role in managing the rollup process, by proposing chunks and batches, commiting those to the basechain and relaying proofs for finalization. - -#### L1 Explorer (`l1-explorer`) - -*Devnet only.* - -The L1 Explorer is a [Blockscout]((https://docs.blockscout.com/)) instance for providing a block explorer interface for the L1 devnet service. It allows users to inspect transactions and blocks on the base layer when deployments are made to local networks. - - - -#### L2 Sequencer (`l2-sequencer`) - -The L2 Sequencer is the node responsible for producing L2 blocks using Clique Proof of Authority (PoA) consensus. It maintains the order of transactions on the L2 chain. It is an archive node of the network, running [`l2geth`](https://github.com/scroll-tech/go-ethereum), Scroll's fork of geth. - -In production deployments, we recommend running a backup sequencer node that can quickly take over for the primary sequencer in case of failure. - -#### L2 RPC (`l2-rpc`) - -The [L2 RPC node](https://github.com/scroll-tech/go-ethereum) is set up to be exposed to external RPC API consumers. It allows interaction with the L2 chain through standard Ethereum JSON-RPC calls, and incoming transactions are propogated to the mempool, to be picked up and included in blocks by the L2 Sequencer. For more information, see [Running a Scroll Node](/en/developers/guides/running-a-scroll-node/). - -This service supports parallel deployments by setting the `controller.replicas` value. - -#### L2 Bootnode (`l2-bootnode`) - -The [L2 Bootnode](https://github.com/scroll-tech/go-ethereum) is a dedicated node that helps synchronize additional follower nodes. It facilitates network discovery and connectivity, without being exposed to open RPC traffic. - -#### Loki Stack (`loki-stack`) - -*Devnet only.* - -The [Loki Stack](https://grafana.com/docs/loki/latest/) is a log aggregation system. It collects and manages logs from various services within the Scroll SDK ecosystem. By default, these logs are exposed through the Grafana UI. - -{/* TODO: Remove after scroll-monitor is merged. */} - -#### RPC Gateway (`rpc-gateway`) - -The RPC Gateway is a simple RPC load balancer that distributes requests among multiple L2 geth RPC nodes. It helps manage incoming RPC traffic efficiently. This does not replace the need for working with an RPC Infrastructure provider for mainnet deployments. - -#### PostgreSQL Database (`postgresql`) - -*Devnet only.* - -The [PostgreSQL Database](https://www.postgresql.org/) is used across services to coordinate data and tools. It provides a reliable and scalable database solution for the Scroll SDK, but can be replaced with compatible databases. - -{/* TODO: Remove after scroll-monitor is merged. */} - -#### Kube Prometheus Stack (`kube-prometheus-stack`) - -*Devnet only.* - -The Kube Prometheus Stack is a collection of Kubernetes manifests, Grafana dashboards, and Prometheus rules combined with documentation and scripts to provide easy to operate end-to-end Kubernetes cluster monitoring with Prometheus using the Prometheus Operator. It provides comprehensive monitoring and alerting capabilities for the Kubernetes cluster running the Scroll SDK. - -{/* TODO: Remove after scroll-monitor is merged. */} - -#### Database Configuration (`db`) - -*Devnet only.* - -Allows configurations for a DB outside of the default postgres service included in the stack. This provides flexibility in database setup and management for various services within the Scroll SDK ecosystem. - -{/* TODO: Is this even still used in devnet? */} - -## Cross-Service Communication - -The Scroll SDK uses a variety of techniques to pass information between services, with some data being onchain (both L1 and L2) and some being offchain (via p2p connections and database storage). The diagram below provides a visual overview of how services interact with one another. - - -```mermaid -graph LR - subgraph K[Key] - direction LR - SS[Single Service] - RL1{{"Hex Shape: Reads from L1"}} - RL2[Dashed Border: Reads from L2 Sequencer]:::L2S - SS -.p2p connection.- RL1 - RL1 <-- "Writes to L1" --> RL2 - end - - classDef L2S stroke:#77b,stroke-width:2px,stroke-dasharray: 7 4 2 4 -``` -```mermaid -%%{ init: { 'flowchart': { 'curve': 'monotoneX' } } }%% -flowchart LR - L1[l1-devnet / L1 Full Node] - - L1 <----> GO - L1 <----> RN - L1 <-.via browser and wallet.-> F - - subgraph SSC["Scroll SDK Chain"] - direction LR - - DB[(DB)] - L2{{L2-sequencer}} - RN{{rollup-node}}:::L2S - GO{{gas-oracle}}:::L2S - - CM{{chain-monitor}}:::L2S - BHF{{bridge-history-fetcher}}:::L2S - CC[coordinator-cron] - - L2R{{l2-rpc}} - L2B{{l2-bootnode}} - L2 -.- L2R - L2 -.- L2B - - DB --> GO - DB --> CC - DB --> CM - DB --> BHF - DB --> RN - DB --> REB - - CC --> CA - BHF --> BHA - - subgraph EXT["External APIs"] - BHA{{bridge-history-api}}:::L2S - CA[coordinator-api] - REB[rollup-explorer-backend] - RG - BHA - end - end - - - - - L2R --> RG[rpc-gateway] - - - - F{{frontends}}:::L2S - PR[prover] - - BHA --> F - REB --> F - RG --> F - CA --> PR - - classDef L2S stroke:#77b,stroke-width:2px,stroke-dasharray: 7 4 2 4 - style EXT fill:#FFE0B2 - -``` - -{/* TODO: Assess is we want Aux services here */} - {/* subgraph AUX["Aux Services"] - direction TB - BC{{balance-checker}} - BS[blockscout] - GR[grafana] - LKI[loki] - end */} - - - \ No newline at end of file diff --git a/src/content/docs/en/technology/overview/scroll-upgrades/feynman-upgrade.mdx b/src/content/docs/en/technology/overview/scroll-upgrades/feynman-upgrade.mdx new file mode 100644 index 000000000..190c4f71b --- /dev/null +++ b/src/content/docs/en/technology/overview/scroll-upgrades/feynman-upgrade.mdx @@ -0,0 +1,75 @@ +--- +section: technology +date: Last Modified +title: "Feynman Upgrade" +lang: "en" +permalink: "technology/overview/scroll-upgrades/feynman-upgrade" +whatsnext: { "Euclid Upgrade": "/en/technology/overview/scroll-upgrades/euclid-upgrade" } +--- + +### Overview +This upgrade contains changes such as: +- Improve compatibility with EVM: + - opcode `blockhash` + - pre-compiles `ecPairing` +- Implemented: + - [EIP-2935](https://eips.ethereum.org/EIPS/eip-2935): Serve historical block hashes from state + - [EIP-7623](https://eips.ethereum.org/EIPS/eip-7623): Increase calldata cost +- Gas fee parameter redesign +- Post Euclid clean-ups + +### Timeline + +- **Scroll Sepolia** : Aug 19th, 2025 +- **Scroll Mainnet** : Jul 22nd, 2025 + +### Compatibility + +This release updates the embedded hard fork block timestamp for Scroll mainnet. +**Nodes that are not upgraded will be unable to follow the network after the hard fork block.** + +To follow the Feynman upgrade, simply run your node with the `--scroll` flag for mainnet (and `--scroll-sepolia` for testnet). + +If you do not use the `--scroll` flag, then you must update and reimport `genesis.json`. + +Genesis.json difference : +```json +{ + "config": { + "chainId": 534352, +... + "euclidTime": 1744815600, + "euclidV2Time": 1745305200, + "feynmanTime": 1755576000, +... +"scroll": { +... + "genesisStateRoot": "0x08d535cc60f40af5dd3b31e0998d7567c2d568b224bed2ba26070aeb078d1339", + "missingHeaderFieldsSHA256": "0xfa2746026ec9590e37e495cb20046e20a38fd0e7099abd2012640dddf6c88b25" +... +``` + +#### Node Operators + +**Mandatory changes:** +- `--gpo.congestionthreshold` is deprecated and should be removed. + +**Recommended changes:** + +- Enable the direct-to-sequencer endpoint using `--gossip.sequencerhttp `. This reduces latency for transaction submission. + + - Scroll mainnet: `--gossip.sequencerhttp https://mainnet-sequencer-proxy.scroll.io` + - Scroll Sepolia: `--gossip.sequencerhttp https://sepolia-sequencer-proxy.scroll.io` + +For nodes running with `--rollup.verify` or `--da.sync`: + +- Enable the AWS S3 blob data source using `--da.blob.awss3 `. +This can be used alongside other blob data sources (`da.blob.beaconnode`, `da.blob.blobscan`, `da.blob.blocknative`). + + - Scroll mainnet: `--da.blob.awss3 https://scroll-mainnet-blob-data.s3.us-west-2.amazonaws.com` + - Scroll Sepolia: `--da.blob.awss3 https://scroll-sepolia-blob-data.s3.us-west-2.amazonaws.com` + + +See more details in the [testnet release notes](https://github.com/scroll-tech/go-ethereum/releases/tag/scroll-v5.8.72). + +Projects requiring additional guidance should open a [ticket on Discord](https://discord.com/channels/853955156100907018/1280768286124146732). diff --git a/src/content/docs/en/user-guide/_images/bridge1.png b/src/content/docs/en/user-guide/_images/bridge1.png deleted file mode 100644 index dd552310e..000000000 Binary files a/src/content/docs/en/user-guide/_images/bridge1.png and /dev/null differ diff --git a/src/content/docs/en/user-guide/_images/bridge2.png b/src/content/docs/en/user-guide/_images/bridge2.png deleted file mode 100644 index e3fe4701f..000000000 Binary files a/src/content/docs/en/user-guide/_images/bridge2.png and /dev/null differ diff --git a/src/content/docs/en/user-guide/_images/bridge3.png b/src/content/docs/en/user-guide/_images/bridge3.png deleted file mode 100644 index 03772fee9..000000000 Binary files a/src/content/docs/en/user-guide/_images/bridge3.png and /dev/null differ diff --git a/src/content/docs/en/user-guide/_images/bridge4.png b/src/content/docs/en/user-guide/_images/bridge4.png deleted file mode 100644 index a060b2ce3..000000000 Binary files a/src/content/docs/en/user-guide/_images/bridge4.png and /dev/null differ diff --git a/src/content/docs/en/user-guide/_images/bridge5.png b/src/content/docs/en/user-guide/_images/bridge5.png deleted file mode 100644 index 7e75aeb4d..000000000 Binary files a/src/content/docs/en/user-guide/_images/bridge5.png and /dev/null differ diff --git a/src/content/docs/en/user-guide/_images/bridge6.png b/src/content/docs/en/user-guide/_images/bridge6.png deleted file mode 100644 index 80066a330..000000000 Binary files a/src/content/docs/en/user-guide/_images/bridge6.png and /dev/null differ diff --git a/src/content/docs/en/user-guide/_images/bridge7.png b/src/content/docs/en/user-guide/_images/bridge7.png deleted file mode 100644 index 66ee3ff94..000000000 Binary files a/src/content/docs/en/user-guide/_images/bridge7.png and /dev/null differ diff --git a/src/content/docs/en/user-guide/_images/bridge8.png b/src/content/docs/en/user-guide/_images/bridge8.png deleted file mode 100644 index 4b78a8b9e..000000000 Binary files a/src/content/docs/en/user-guide/_images/bridge8.png and /dev/null differ diff --git a/src/content/docs/en/user-guide/bridge.mdx b/src/content/docs/en/user-guide/bridge.mdx deleted file mode 100644 index c0748859a..000000000 --- a/src/content/docs/en/user-guide/bridge.mdx +++ /dev/null @@ -1,118 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Bridge" -lang: "en" -permalink: "user-guide/bridge/" -excerpt: "To start bridging assets from Sepolia, navigate to the portal bridge app." ---- - -{/* // import ClickToZoom from "../../../../components/ClickToZoom.astro" */} -{/* // import bridge1 from "./\_images/bridge1.png" */} -{/* // import bridge2 from "./\_images/bridge2.png" */} -{/* // import bridge3 from "./\_images/bridge3.png" */} -{/* // import bridge4 from "./\_images/bridge4.png" */} -{/* // import bridge5 from "./\_images/bridge5.png" */} -{/* // import bridge6 from "./\_images/bridge6.png" */} -{/* // import bridge7 from "./\_images/bridge7.png" */} -{/* // import bridge8 from "./\_images/bridge8.png" */} - -{/* TODO: Update all instructions after being able to walk through the whole flow. */} - - -Visit our bridge app on [Sepolia testnet](https://sepolia.scroll.io/bridge) or [Mainnet](https://scroll.io/bridge) to get started! The Bridge supports both **Deposit** and **Withdraw** operations, allowing users to trustlessly move assets from L1 to L2. - -## Deposit from Ethereum to Scroll - -### Instructions - -1. After navigating to the bridge app, press the "Connect Wallet" button. You might need to switch your wallet to the right network. -1. In the app, select the **Deposit to Scroll** tab. -1. Select the token you want to transfer from the L1 network. If it's your first time bridging, try "ETH." -1. If this is your first time transferring a specific ERC20 token, you must **Approve** the Sepolia or Ethereum Bridge contract to access your ERC20 token. -1. Select your deposit mode. The Fast option initiates a bridge transfer immediately, while the Economy option groups multiple requests together and initiates a single bridge transfer for the batch, sharing the cost among all included requests. -1. Next, slide the **Deposit funds** button to make the deposit. Your wallet will ask to confirm the transfer transaction. -1. Once the transfer transaction is sent and confirmed, the token will be deducted from your wallet. -1. You can always check the status of a transaction by pressing the "Transaction History" icon next to your wallet address in the top-right corner. - -{/* ### When will the token arrive in your Scroll Sepolia wallet? - -It could take between **8 to 14 minutes** (awaiting block to become [_Safe_](https://www.alchemy.com/overviews/ethereum-commitment-levels#what-are-ethereum-commitment-levels) on Sepolia) before the token shows up in your Scroll Sepolia wallet. */} - -{/* You can check the progress of deposit transactions as follows: */} - -{/* ##### 1. Click the "History" icon next to your wallet address in the top-right corner. */} - -{/* */} - -{/* The pop-up panel lists the most recent transactions made in the Bridge app. There are two statuses: Sepolia status and Scroll Sepolia status. For deposit transactions (L1 -> L2), once your transaction becomes _Safe_ on Sepolia (**8 to 14 minutes**), you will see the **`success`** status shown. Your funds will be relayed to Scoll Sepolia after this. */} - -{/* The Recent Bridge Transactions window should give you an estimate of the time expected before your transaction is _Safe_ on Sepolia. */} - -{/* ##### 2. Click on the most recent transaction’s Sepolia transaction hash. */} - -{/* */} - -{/* It will open the Transaction Details page in a new tab. You can see this transaction is confirmed on Sepolia. To check the Block's confirmation status, click the Block number and read the "Status" field. */} - -{/* */} - -{/* ##### 3. Return to the Bridge app and wait! */} - -{/* Once your transaction status shows **`success`** on Scroll Sepolia, you should see the funds in your Scroll L2 wallet and a transaction hash: */} - -{/* */} - -## Withdraw from Scroll to Ethereum - -### Instructions - -#### Submitting your Initial Withdrawal Transaction - -1. First, select the **Withdraw to Ethereum** tab in the app. You might need to switch your wallet to the right network. -1. Select the token you want to transfer, If it's you're first time bridging, try "ETH." -1. If this is your first time transferring a specific ERC20 token, you must **Approve** the Scroll Bridge contract to access your ERC20 token. -1. Next, slide the **Withdraw funds** button to make the withdrawal. Your wallet will ask to confirm the transfer transaction. -1. Once the transfer transaction is sent and confirmed, the token will be deducted from your wallet. - -#### Submitting an Execute Withdrawal Transaction - -{/* TODO: finish the additional instructions, better estimate "wait time" */} - -_The remaining steps happen on Scroll, but you first must wait for your transaction to be fully proven ("finalized") on the L1 side. This process can take up to four hours._ - -1. When your withdrawal transaction is completed finalizing on Sepolia or Ethereum, you will see the "Claim" button in the Recent Transactions area become solid. -1. Click the "Claim" button to submit the Execute Withdrawal transaction. -1. Once submitted, your withdrawn funds should appear immediately in your wallet. - -### When will the token arrive in your wallet? - -The transferred token will arrive in your wallet immediately after the block containing your Execute Withdrawal transaction is confirmed. - -{/* TODO: check architecture link is live */} - -:::tip[Rollup Status] -The rollup status `Finalized` indicates that the correct execution of transactions in this block has been proven by verifying a validity proof on-chain on the L1 chain. For more information about rollup status, see [Scroll's Architecture Overview](/technology). -::: - -{/* You can check the progress of withdrawal transactions as follows: */} - -{/* 1. Click your wallet address at the top-right corner of the Bridge web app. */} - -{/* */} - -{/* The pop-up panel lists the most recent transactions you made in the Bridge app (see the image below). There are two statuses: L1 status and L2 status. In this case, because we are bridging from L2 -> L1, we will quickly get a **`success`** status after submitting the transaction to the L2 Bridge. L1, on the other hand, takes **10 minutes to a few hours** to reach **`success`**. */} - -{/* 1. Click on the most recent transaction’s L2 transaction hash: */} - -{/* */} - -{/* It will open the _Transaction Details_ page in a new tab. You can see this transaction is confirmed on L2. */} - -{/* */} - -{/* The transaction is confirmed on L2, but still needs to be finalized on Goerli. */} - -{/* 1. Go back to the [Bridge](https://scroll.io/bridge) app. It takes about 10 minutes before the token shows up in your Goerli wallet. Once your transaction status shows success on L2, you should see the funds in your Goerli wallet and a transaction hash: */} - -{/* */} diff --git a/src/content/docs/en/user-guide/common-errors.mdx b/src/content/docs/en/user-guide/common-errors.mdx deleted file mode 100644 index 39f6b65bd..000000000 --- a/src/content/docs/en/user-guide/common-errors.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Common Errors" -lang: "en" -permalink: "user-guide/common-errors/" -excerpt: "Seeing an error when trying to interact with Scroll Sepolia Testnet? Here are some common configuration errors and how to quickly fix them." ---- - -## Incorrect nonce error when sending a transaction in MetaMask - -You will encounter this error when the local nonce stored in your MetaMask wallet is different from the nonce in the Scroll testnet node. It could be because there is a recent pending transaction. - -To fix this issue, you need to reset your account in MetaMask for the Scroll Sepolia Testnet. The steps to reset the account are: - -1. Open the **MetaMask** extension in the browser -2. Select **Scroll Sepolia Testnet** in the top area -3. Click the round **account icon** in the top-right corner -4. Select **Settings** -5. Go to **Advanced** -6. Click **Reset account** - -You will not lose any assets during the MetaMask account reset. - -:::caution[Caution] -Removing and re-adding a network is NOT enough to fix this - you must reset your account. -::: - -## Nothing happens when confirming a bridging/swapping transaction - -If no error or console logs appear, this is likely due to a nonce issue, please reset your MetaMask account as outlined above at [#incorrect-nonce-error-when-sending-a-transaction-in-metamask](#incorrect-nonce-error-when-sending-a-transaction-in-metamask). - -## Block Explorer shows "Internal server error" - -Use an incognito window, or open your browser developer console and remove the `_explorer_key` cookie (or all cookies). [See this guide for how to remove cookies](https://www.contentstack.com/docs/developers/how-to-guides/clear-caches-and-cookies-in-different-browsers/). - -## Sending max amount of Ether in MetaMask results in a "Failed" error - -When sending Ether using MetaMask, if you try sending the "Max" amount, it's going to result in a "Failed" error. This is because MetaMask doesn't account for the additional "L1 Fee" that rollups have on top of regular gas fees and falls short for a small amount needed to pay for the gas of the transaction. - -To solve this, manually lower the amount of ether to be a little smaller than suggested and the transaction will go through. diff --git a/src/content/docs/en/user-guide/faucet.mdx b/src/content/docs/en/user-guide/faucet.mdx deleted file mode 100644 index 75697072c..000000000 --- a/src/content/docs/en/user-guide/faucet.mdx +++ /dev/null @@ -1,45 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Faucet" -lang: "en" -permalink: "user-guide/faucet/" -whatsnext: { "Bridge your ETH to Scroll Sepolia": "/en/user-guide/bridge" } -excerpt: "To interact with our testnet, you first need to acquire Sepolia ETH. There are a few Sepolia faucet apps to get you started." ---- - -To interact with our testnet, you first need to receive testnet ETH on _Sepolia Testnet_. Then you may bridge from _Sepolia Testnet_ to _Scroll Sepolia Testnet_. - -## Sepolia Faucets - -Each faucet has its own rules and requirements, so you may need to try a few before you find one that works for you. - -Here are a few Sepolia faucet apps: - -- [https://sepoliafaucet.com](https://sepoliafaucet.com/) -- [https://sepolia-faucet.pk910.de](https://sepolia-faucet.pk910.de) -- [https://faucet.quicknode.com/drip](https://faucet.quicknode.com/drip) -- [https://faucet.chainstack.com](https://faucet.chainstack.com) -- [https://infura.io/faucet/sepolia](https://infura.io/faucet/sepolia) -- [https://www.sepoliafaucet.io/](https://www.sepoliafaucet.io/) -- [https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) - -Once you receive ETH on Sepolia, you should see it in your wallet on the _Sepolia Network_. It may take a few seconds for them to appear, but you can check the status by looking for a transaction to your address on a [Sepolia Block Explorer](https://sepolia.etherscan.io/). - -:::note[Pace Yourself!] -Most faucets only allow requests for test tokens once every 24 hours. -::: - -## Scroll Sepolia Faucets - -If you don't want to interact with the bridge, some faucets directly distribute Scroll Sepolia ETH. - -- [https://thirdweb.com/scroll-sepolia-testnet](https://thirdweb.com/scroll-sepolia-testnet) -- [https://www.hackquest.io/en/faucets/534351](https://www.hackquest.io/en/faucets/534351) -- [https://scroll.l2scan.co/faucet](https://scroll.l2scan.co/faucet) -- [https://www.covalenthq.com/faucet/](https://www.covalenthq.com/faucet) -- [https://faucet.quicknode.com/scroll/sepolia](https://faucet.quicknode.com/scroll/sepolia) -- [https://faucet.chainstack.com/scroll-sepolia-testnet-faucet](https://faucet.chainstack.com/scroll-sepolia-testnet-faucet) -- [https://bwarelabs.com/faucets/scroll-testnet](https://bwarelabs.com/faucets/scroll-testnet) -- [https://scroll.faucetme.pro](https://scroll.faucetme.pro) -- [https://www.l2faucet.com/scroll](https://www.l2faucet.com/scroll) diff --git a/src/content/docs/en/user-guide/index.mdx b/src/content/docs/en/user-guide/index.mdx deleted file mode 100644 index 53f71b09a..000000000 --- a/src/content/docs/en/user-guide/index.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Scroll Sepolia User Guide" -lang: "en" -permalink: "user-guide/" -excerpt: "Thank you for testing out our Sepolia Testnet. The Sepolia Testnet consists of Ethereum's Sepolia Testnet and the Scroll Sepolia test network." -whatsnext: { "Set Up Your Wallet": "/en/user-guide/setup" } ---- - -import Aside from "../../../../components/Aside.astro" - - - -Thank you for testing the Scroll Sepolia Testnet. If you have questions or want to give feedback, join our [Discord](https://discord.gg/scroll)! - -The Sepolia Testnet consists of _Ethereum's Sepolia Testnet_ and the _Scroll Sepolia_ test network. Sepolia is an Ethereum test network, while Scroll Sepolia is a zero knowledge rollup testnet deployed on top of the former. There are some pre-deployed demo applications: a [bridge](https://sepolia.scroll.io/bridge) between _Sepolia_ and _Scroll Sepolia_,[^1] a [block explorer](https://sepolia.scrollscan.com) for _Scroll Sepolia_, and a [rollup explorer](https://sepolia.scroll.io/rollupscan). - -To view L1 transactions, check out Etherscan's [Sepolia explorer](https://sepolia.etherscan.io/). -To view L2 transactions, you can use [Scrollscan](https://sepolia.scrollscan.com), or you may also want to try out the additional functionality provided by [Dora](https://www.ondora.xyz/network/scroll-sepolia/interactions) or [L2Scan](https://scroll-sepolia.l2scan.co/). - -Here is the suggested workflow to explore the Testnet: - -1. Add the [Sepolia Testnet](https://sepolia.scroll.io/portal) configurations to your wallet. -2. Request test tokens in the _Sepolia_ network from any Ethereum Faucet app. (see [Faucet](/user-guide/faucet) article) -3. Transfer test tokens from _Sepolia_ to _Scroll Sepolia_ through the [Bridge](https://sepolia.scroll.io/bridge) app. -4. Transfer tokens to other wallets on _Scroll Sepolia_ using your wallet. -5. Explore our ecosystem, interacting with contracts like [Uniswap](https://uniswap-showcase.sepolia.scroll.xyz/) or [Aave](https://app.aave.com). -6. Withdraw tokens from _Scroll Sepolia_ to _Sepolia_ through the [Bridge](https://sepolia.scroll.io/bridge) app. - -You can find the instructions for each app in the rest of this user guide. - -## Questions & Feedback - -If you encounter any issues, join our [Discord](https://discord.gg/scroll) and talk to us in the `#general-support` channel. We would love to hear your thoughts or feedback on how we can improve your experience, too. - -[^1]: Forked from the [Hop Exchange](https://hop.exchange/) UI 🐇🙌 \ No newline at end of file diff --git a/src/content/docs/en/user-guide/setup.mdx b/src/content/docs/en/user-guide/setup.mdx deleted file mode 100644 index 8bb00b4dd..000000000 --- a/src/content/docs/en/user-guide/setup.mdx +++ /dev/null @@ -1,76 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Setup" -lang: "en" -permalink: "user-guide/setup/" -whatsnext: { "Grab Sepolia ETH from a Faucet": "/en/user-guide/faucet" } -excerpt: "You need to have a wallet to interact with the Scroll network. You can find some example wallets and configuration tips here." ---- - -import Aside from "../../../../components/Aside.astro" -import ToggleElement from "../../../../components/ToggleElement.astro" - -## Wallet - -You need to have a wallet to interact with dApps on Scroll. You can find some example wallets and configuration tips below. Our Bridge app supports MetaMask, Coinbase Wallet, or any wallet with WalletConnect support. - -### MetaMask - -You can install MetaMask from their [official website](https://metamask.io/download/). - -You can import the Scroll mainnet and Scroll Sepolia testnet configurations to your MetaMask wallet by following the steps below. - -To do this, visit the [Scroll Sepolia portal](https://sepolia.scroll.io/portal), then click the "Connect Wallet" button and select MetaMask. Next, click the "Add to MetaMask" buttons for Sepolia Testnet and Scroll Sepolia Testnet. This will import the chain ID and RPC URLs for the Scroll Sepolia Testnet. The Sepolia Testnet is also configured on MetaMask by default. To show it, click "Show/hide test networks" in the MetaMask network selection dropdown menu. - -## Network Configuration - -### Scroll Mainnet - -Visit the [Scroll portal](https://scroll.io/portal), then click the "Connect Wallet" button and select MetaMask. Next, click the "Add to MetaMask" button in "Layer2: Scroll" to directly import the network configurations. Finally, click "Approve" to add the network to your MetaMask wallet. - -Alternatively, you can use the table below to manually configure Scroll mainnet in other wallets. - -| Network Name | Scroll | Ethereum Mainnet | -| ------------------ | -------------------------------------------------- | ---------------------------------------------------- | -| RPC URL | [https://rpc.scroll.io/](https://rpc.scroll.io/) | [https://eth.llamarpc.com](https://eth.llamarpc.com) | -| Chain ID | 534352 | 1 | -| Currency Symbol | ETH | ETH | -| Block Explorer URL | [https://scrollscan.com/](https://scrollscan.com/) | [https://etherscan.io](https://etherscan.io) | - - -
Additional Scroll Mainnet RPCs and Infra
- - [Scroll Native Bridge](https://scroll.io/bridge) - - [Scroll RPC Providers on ChainList.org](https://chainlist.org/chain/534352) - - [Ethereum RPC Providers on ChainList.org](https://chainlist.org/chain/1) - - - -### Scroll Sepolia Testnet - -Visit the [Scroll Sepolia portal](https://sepolia.scroll.io/portal), then click the "Connect Wallet" button and select MetaMask. Next, click the "Add to MetaMask" buttons for Scroll Sepolia Testnet. This will import the chain ID and RPC URLs for the Scroll Sepolia Testnet. The Ethereum Sepolia Testnet is also configured on MetaMask by default. To show it, click "Show/hide test networks" in the MetaMask network selection dropdown menu. - -Alternatively, you can use the table below to manually configure Scroll Sepolia testnet in other wallets. - -| Network Name | Scroll Sepolia | Ethereum Sepolia | -| ------------------ | ----------------------------------------------------------------- | ------------------------------------------------------------ | -| RPC URL | [https://sepolia-rpc.scroll.io/](https://sepolia-rpc.scroll.io/) | [https://rpc2.sepolia.org](https://rpc2.sepolia.org) | -| Chain ID | 534351 | 11155111 | -| Currency Symbol | ETH | ETH | -| Block Explorer URL | [https://sepolia.scrollscan.com](https://sepolia.scrollscan.com/) | [https://sepolia.etherscan.io](https://sepolia.etherscan.io) | - - -
Additional Scroll Sepolia RPCs and Infra
- - [Scroll Sepolia Native Bridge](https://sepolia.scroll.io/bridge) - - [Scroll Sepolia RPC Providers on ChainList.org](https://chainlist.org/chain/534351) - - [Ethereum Sepolia RPC Providers on ChainList.org](https://chainlist.org/chain/11155111) - - - - diff --git a/src/content/docs/en/user-guide/transfer-tokens.md b/src/content/docs/en/user-guide/transfer-tokens.md deleted file mode 100644 index ae62be9f4..000000000 --- a/src/content/docs/en/user-guide/transfer-tokens.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Transfer Tokens" -lang: "en" -permalink: "user-guide/transfer-tokens/" -excerpt: "You can use your wallet as usual to transfer tokens within the Scroll Sepolia Testnet." ---- - -You can use your wallet's normal function for transferring tokens within the Scroll Sepolia Testnet -- no additional configurations are needed. - -## Sending a token in MetaMask - -1. Open your wallet and switch to **Scroll Sepolia Testnet**. -2. Click the **Send** button in the middle and type the address you want to transfer to in the text box. -3. Select the token in the **Asset** box and type the amount of token that you want to transfer. -4. Click the **Next** button and then click the **Confirm** button to send out the transaction. -5. After sending, you can find the transaction in the **Activity** tab in your wallet. diff --git a/src/content/docs/es/getting-started/overview.md b/src/content/docs/es/getting-started/overview.md deleted file mode 100644 index 640fa0994..000000000 --- a/src/content/docs/es/getting-started/overview.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Vista General de Scroll" -lang: "es" -permalink: "docs/conceptual-overview/" -excerpt: "ZK Rollups and Scroll" -whatsnext: { "Guía de Usuario": "/es/user-guide/", "Construyendo en Scroll": "/es/developers/" } ---- - -#### ¡Bienvenido a la documentación de Scroll! - -Scroll es una solución de escalabilidad centrada en la seguridad de Ethereum, que utiliza innovaciones en el diseño de escalado y pruebas de “zero-knowledge” para construir una nueva capa en Ethereum. La red de Scroll es más accesible, más receptiva y puede soportar a más usuarios a la vez que Ethereum por sí solo, y si alguna vez has utilizado o desarrollado una aplicación en Ethereum, te sentirás como en casa. - -¿Quieres probar la Scroll Sepolia Testnet con monedas y activos grátis? Echa un vistazo a nuestra. [Guía de Usuario](/es/user-guide/). - -## ¿Qué está construyendo Scroll? - -Scroll está construyendo la tecnología para escalar Ethereum. - -Aunque Ethereum es la principal red de blockchain para alimentar aplicaciones descentralizadas, su popularidad también conlleva costos más altos, lo que crea una barrera para la adopción de la próxima ola de usuarios y desarrolladores. - -Aprovechando investigaciones punteras en pruebas de “zero-knowledge” ("zk"), Scroll está construyendo una red de segunda capa (Layer 2 rollup) en Ethereum. El equipo, en colaboración de código abierto con otros en la comunidad de Ethereum, ha creado un "zkEVM" que permite que toda la actividad en la red, que se comporta de manera similar a Ethereum, esté asegurada por smart contracts en Ethereum. La red publica todas las transacciones en Ethereum, y el zkEVM crea y publica "pruebas" criptográficas de que la red de Scroll sigue las reglas de Ethereum. - -En última instancia, los smart contracts de Ethereum verifican que cada transacción en Scroll sea válida para estas pruebas, brindando a la red una increíble seguridad, descentralización y resistencia a la censura. Este nivel de seguridad y escalabilidad para Ethereum solo es posible gracias a avances recientes en criptografía de “zero-knowledge”, diseño de protocolos blockchain y aceleración de hardware. - - - -Para obtener más información sobre nuestra arquitectura, consulta. [Arquitectura de Scroll](/es/technology/). - -## ¿Puedo usar Scroll hoy? - -Scroll mainnet ya lanzó! También tenemos la Scroll Sepolia testnet, una testnet corriendo encima de Ethereum Sepolia. Aunque tenemos una [guía completa](/es/user-guide/), si estás familiarizado/a con el uso de Ethereum, puedes comenzar en minutos: - -- Visita nuestro [Bridge](https://scroll.io/bridge) o nuestro [Bridge de Scroll Sepolia](https://sepolia.scroll.io/bridge) y conecta tu wallet -- Envía tokens de Ethereum a Scroll (o usa un [faucet](/es/user-guide/faucet)) -- Prueba una aplicación descentralizada (dapp) con nuestra [Uniswap Showcase](http://uniswap-showcase.sepolia.scroll.xyz/) o [Aave](https://app.aave.com/) -- ¡solo asegúrate de seleccionar la red Scroll Sepolia! - -## ¿Hacia dónde se dirige Scroll? - -Hemos lanzado nuestra mainnet en Ethereum, pero todavía hay bastante trabajo por hacer. A continuación, descentralizaremos cada componente de la infraestructura. Para mantenerte actualizado, echa un vistazo a [nuestro blog](https://scroll.io/blog), síguenos en [nuestro Discord](https://discord.gg/scroll) o en [Twitter](https://twitter.com/scroll_zkp) para estar al tanto. diff --git a/src/content/docs/es/learn/index.mdx b/src/content/docs/es/learn/index.mdx deleted file mode 100644 index a0dcf77ed..000000000 --- a/src/content/docs/es/learn/index.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -section: learn -title: "Aprende" -lang: "es" -permalink: "learn/" -excerpt: "Learn more about Ethereum scalability and zero knowledge cryptography." ---- - -import NavCard from "../../../../components/NavCard.astro" -import TechnologySvg from "../../../../assets/svgs/home/home-technology.svg?raw" -import LearnSvg from "../../../../assets/svgs/home/home-learn.svg?raw" - -Scroll reúne la investigación y la ingeniería de protocolos blockchain y criptografía zero knowledge. Si quieres profundizar más, sigue leyendo y consulta los recursos adicionales. - -¿Desea que se trate un tema específico? Crea [un issue](https://github.com/scroll-tech/scroll-documentation/issues/new?assignees=&labels=new+content%2Ctriage&projects=&template=new_content.yml&title=%5BNew+Content%5D%3A+%3Cyour-title-here%3E) en nuestro repositorio de Github. - -
- - -
diff --git a/src/content/docs/es/learn/intro-to-rollups.md b/src/content/docs/es/learn/intro-to-rollups.md deleted file mode 100644 index 6b8ac34bb..000000000 --- a/src/content/docs/es/learn/intro-to-rollups.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Intro a los Rollups" -lang: "es" -permalink: "learn/intro-to-rollups" -excerpt: "Los rollups son la solución de escalado de capa 2 más predominante en el ecosistema Ethereum." -whatsnext: { "Proceso del Rollup": "/es/technology/chain/rollup" } ---- - -## ¿Qué es un rollup? - -Los rollups son la solución de escalado de capa 2 más predominante en el ecosistema Ethereum, y se consideran una [parte central](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) de la hoja de ruta de Ethereum. - -Un rollup procesa lotes de transacciones fuera de la cadena (es decir, no en la capa 1), y luego publica los datos resultantes en la cadena (es decir, en la capa 1). - -La ejecución de cada transacción se realiza fuera de la cadena, y no es necesario que los nodos de la capa 1 vuelvan a ejecutarla. Esto permite un alto rendimiento de las transacciones, sin afectar a la descentralización de la capa 1. - -Para que un rollup sea seguro, debe demostrar que su cálculo fuera de la cadena (el procesamiento de las transacciones) se ha realizado correctamente. Existen principalmente dos mecanismos para demostrar la validez del cálculo fuera de la cadena: las pruebas de validez y las pruebas de fraude. - -## ¿Qué es un optimistic rollup? - -Un optimistic rollup es un rollup que utiliza pruebas de fraude para afirmar la validez de sus cálculos. - -Las pruebas de fraude son un mecanismo que permite a los usuarios cuestionar y demostrar la invalidez de cualquier cálculo realizado en el L2. Si una prueba de fraude se presenta con éxito, la L2 puede volver a un estado anterior y el cálculo no válido puede ser corregido. Las pruebas de fraude dependen de que al menos una parte honesta compruebe que las transacciones de la L2 se han ejecutado correctamente. - -## ¿Qué es un ZK rollup? - -Un ZK rollup es un rollup que utiliza pruebas de validez para afirmar la legitimidad de sus cálculos. - -Cuando un ZK rollup ejecuta un lote de transacciones y publica el estado resultante en L1, también publica una prueba de validez. Esta prueba matemática demuestra que el estado resultante es efectivamente el estado resultante de ejecutar correctamente el lote de transacciones. - -En la actualidad, existen múltiples tipos de ZK rollups, definidos en términos generales como zkVMs (zk Virtual Machines) o zkEVMs (zk Ethereum Virtual Machines). - -Los zkVMs están diseñados desde cero para trabajar bien con circuitos ZK y requieren diferentes flujos de trabajo de desarrollo en comparación con un zkEVM. Algunos ejemplos son Starkware y Aztec. - -Los zkEVMs están diseñados para emular la EVM. Existen dos tipos principales de zkEVMs: compatibles con bytecode y compatibles con lenguaje. Las zkEVM compatibles con bytecode emulan la EVM a un nivel muy bajo, permitiendo un desarrollo y una experiencia de usuario casi idénticos en comparación con Ethereum Layer 1. Los zkEVMs compatibles con lenguajes compilan Solidity y otros lenguajes de alto nivel en diferentes bytecodes, lo que puede resultar en cambios en el flujo de trabajo. zkSync es el zkEVM compatible con lenguajes más popular. - -Scroll es compatible con bytecode. Se eligió este enfoque porque aporta ciertas ventajas: - -- Solidity, Vyper y Huff funcionan desde el primer momento. -- No es necesario volver a auditar -- Se hereda la mayoría de las herramientas existentes -- UX y DevX casi idénticos a los de Ethereum. - -Encontrará más información sobre el enfoque de Scroll en la sección Tecnología. - -## Lecturas adicionales - -- [An Incomplete Guide to Rollups](https://vitalik.ca/general/2021/01/05/rollup.html) - Vitalik Buterin -- [Scaling](https://ethereum.org/en/developers/docs/scaling/) - Ethereum Docs diff --git a/src/content/docs/es/learn/the-scalability-problem.md b/src/content/docs/es/learn/the-scalability-problem.md deleted file mode 100644 index d26781c5f..000000000 --- a/src/content/docs/es/learn/the-scalability-problem.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -section: learn -date: Last Modified -title: "El Problema de la Escalabilidad" -lang: "es" -permalink: "learn/intro-to-rollups" -excerpt: "La fuerte descentralización y seguridad de Ethereum se consigue a costa de sacrificar la escalabilidad: para garantizar que todos los nodos participantes puedan seguir el ritmo de la red, el rendimiento de ésta es limitado. Este límite se traduce en costos y latencias más elevados para los usuarios." -whatsnext: { "Intro a los Rollups": "/es/learn/intro-to-rollups" } ---- - -## El problema de escalabilidad de Ethereum - -[Ethereum](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-is-ethereum) es una blockchain de propósito general que soporta el despliegue y ejecución de [smart contracts](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-are-smart-contracts). - -Una de las características que definen a Ethereum es su compromiso inquebrantable con la seguridad y la descentralización. Ethereum está diseñado para que ordenadores de todo el mundo (incluso los más baratos, como una [Raspberry Pi](https://ethereum-on-arm-documentation.readthedocs.io/)) puedan participar en la red, ejecutar copias locales de la blockchain y procesar nuevas transacciones. - -Sin embargo, la fuerte descentralización y seguridad de Ethereum se consigue a costa de sacrificar la escalabilidad: para garantizar que todos los nodos participantes puedan seguir el ritmo de la red, el rendimiento de ésta es limitado. En última instancia, este límite se traduce en mayores costos y latencias para los usuarios. - -## Soluciones de Escalabilidad - -Las soluciones de escalabilidad de Ethereum tienen como objetivo aumentar el rendimiento de la red sin sacrificar la descentralización o la seguridad. - -Existen principalmente dos tipos de soluciones de escalado: soluciones de escabilidad de capa 1 y soluciones de escabilidad de capa 2. - -**La Capa 1** (o **L1**) intenta escalar la red modificando directamente la blockchain de Ethereum. El término "capa 1" se refiere aquí a la cadena de bloques principal de Ethereum. En general, es muy difícil diseñar soluciones de escalado de capa 1 que aumenten el rendimiento y, al mismo tiempo, preserven altos niveles de seguridad y descentralización. Por ello, los recientes esfuerzos de escalado se han alejado de las soluciones de capa 1 y se han orientado hacia soluciones de capa 2. - -**La Capa 2** (o **L2**) de soluciones de escalado son redes que viven **en la parte superior** de la capa 1 de Ethereum - son esencialmente blockchains separadas que están "ancladas" a la blockchain subyacente de Ethereum de alguna manera. Estas redes de capa 2 generalmente pueden procesar transacciones a un ritmo mayor que la red de capa 1 subyacente, ya que no están sujetas a las mismas limitaciones. El mecanismo de "anclaje", cuyos detalles varían según la capa 2, permite a la red de capa 2 heredar las sólidas propiedades de seguridad y descentralización de la capa 1 de Ethereum. diff --git a/src/content/docs/es/learn/zero-knowledge/additional-zk-learning-resources.md b/src/content/docs/es/learn/zero-knowledge/additional-zk-learning-resources.md deleted file mode 100644 index 415705887..000000000 --- a/src/content/docs/es/learn/zero-knowledge/additional-zk-learning-resources.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Recursos de Aprendizaje ZK Adicionales" -lang: "es" -permalink: "learn/zero-knowledge/additional-zk-learning-resources" -excerpt: "¿Quieres profundizar en ZK? Éstos son algunos de nuestros recursos favoritos." ---- - -¿Quieres profundizar en el ZK? Aquí tienes algunos de nuestros recursos favoritos. - -## Vídeo - -- [ZK Whiteboard Sessions](https://youtube.com/playlist?list=PLj80z0cJm8QErn3akRcqvxUsyXWC81OGq) - - Estas sesiones de whiteboard son una forma fantástica de aprender sobre ZK. Las tres primeras conferencias de Dan Boneh proporcionan una gran base sobre la que se construyen las siguientes, en las que se analizan los desarrollos más recientes. -- [Zero Knowledge Proofs MOOC](https://youtube.com/playlist?list=PLS01nW3Rtgor_yJmQsGBZAg5XM4TSGpPs) - - Un MOOC que cubre las pruebas zero knowledge desde los primeros principios, hasta los temas modernos de la industria. -- [The 9th BIU Winter School on Cryptography - Zero Knowledge](https://youtube.com/playlist?list=PL8Vt-7cSFnw29cLUVqAIuMlg1QJ-szV0K) - - Estas conferencias sientan las bases teóricas zero knowledge - están dirigidas a académicos y público con madurez matemática. -- [ZK Symposium](https://www.youtube.com/playlist?list=PLrzRr7okCcmbAlgYpuFjzUJv8tAyowDQY) - - Una mezcla de presentaciones teóricas y aplicadas de algunos de los mejores investigadores y creadores de productos en el ámbito zero-knowledge. - -## Texto - -- [Proofs, Arguments, and Zero-Knowledge](https://people.cs.georgetown.edu/jthaler/ProofsArgsAndZK.html) - Justin Thaler - - Un libro de texto completo sobre la teoría zero-knowledge. diff --git a/src/content/docs/es/learn/zero-knowledge/introduction-to-zero-knowledge.mdx b/src/content/docs/es/learn/zero-knowledge/introduction-to-zero-knowledge.mdx deleted file mode 100644 index 66614320a..000000000 --- a/src/content/docs/es/learn/zero-knowledge/introduction-to-zero-knowledge.mdx +++ /dev/null @@ -1,75 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Introducción a Zero Knowledge" -lang: "es" -permalink: "learn/zero-knowledge/introduction-to-zero-knowledge" -whatsnext: { "Polynomial Commitment Schemes": "/es/learn/zero-knowledge/polynomial-commitment-schemes" } -excerpt: 'En la última década, un campo de la criptografía llamado "zero-knowledge" ha avanzado rápidamente. Promete nuevas formas de crear aplicaciones y permite que los protocolos aumenten la eficacia, la seguridad y la privacidad.' ---- - -import Aside from "../../../../../components/Aside.astro" - -En la última década, un campo de la criptografía llamado "zero-knowledge" ha avanzado rápidamente. Promete nuevas formas de crear aplicaciones y permite que los protocolos aumenten la eficacia, la seguridad y la privacidad. - -Examinemos qué hace que el campo de las pruebas "zero-knowledge" sea tan interesantes y qué problemas ayuda a resolver a los ingenieros. - -## Blockchains Trustless y Verificabilidad - -Las blockchains suelen funcionar procesando transacciones enviadas por los usuarios. Estas transacciones suelen desencadenar algún tipo de cálculo que la blockchain debe realizar. - -Para que la blockchain sea "trustless" (es decir, no dependa de la confianza en una parte concreta), los participantes en la red deben verificar que las transacciones son válidas y que los cálculos resultantes se han realizado correctamente. - -Comprobar que la transacción es válida suele requerir la verificación de la firma digital, que comprueba que el remitente de la transacción es realmente el autor de la misma. La verificación de que el cálculo de una transacción se ha realizado correctamente suele requerir la reejecución local de la transacción. - -## Limitaciones de la Verificabilidad - -Esta metodología de verificación de cada transacción se rompe en situaciones en las que un participante no puede volver a ejecutar el cálculo. Un participante puede no ser capaz de volver a ejecutar el cálculo por un par de razones: (1) podría ser que ciertos datos no estén disponibles (por razones de privacidad), o (2) puede ser demasiado caro para un ordenador participante volver a ejecutar todas las transacciones - esta segunda razón es especialmente relevante cuando se consideran blockchains de alto rendimiento con un gran número de transacciones por segundo. - -## El Poder de las Zero-Knowledge Proofs - -Las Zero-knowledge proofs (ZKP) permiten superar estas limitaciones. - -Las ZKP permiten a los participantes verificar los resultados de un cálculo (1) preservando la privacidad de cualquier dato sensible utilizado en el cálculo, y (2) haciendo que la verificación sea significativamente más barata que volver a ejecutar el cálculo. Estas dos propiedades de las ZKP se denominan **zero-knowledge** y **succinctness**, respectivamente. - -Estas propiedades de las ZKP son extremadamente útiles en el contexto de la verificabilidad de las blockchains "trustless". Sin ZKP, los participantes tienen que volver a ejecutar el cálculo resultante de cada transacción. Esto requiere que todos los participantes vean todos los datos (potencialmente sensibles) utilizados en cada cálculo, y también limita el rendimiento de todo el sistema. Con las ZKP, una parte puede realizar el cálculo y, a continuación, generar una prueba de que el cálculo se ha realizado correctamente. Otros participantes pueden verificar que el cálculo se ha realizado correctamente _verificando que la prueba es válida_, en lugar de volver a ejecutar el cálculo ellos mismos. Verificar la prueba (1) no filtra información sobre datos sensibles utilizados en el cálculo original, y (2) es significativamente más barato computacionalmente que volver a ejecutar el cálculo original. Estas dos propiedades tienen el potencial de permitir la privacidad y la escalabilidad de las blockchains trustless. - -## Circuitos, Pruebas y Verificadores - -En la práctica, las ZKP pueden ser bastante complejas de implementar en un sistema, pero a un alto nivel, te gustaría entender que las pruebas de zero-knowledge tienen unos pocos componentes: un circuito, una prueba y un verificador. - -El circuito es un programa que recibe datos de entrada y afirma que los datos de entrada son válidos de acuerdo con algunas "restricciones" que los datos de entrada deben satisfacer. Los datos de entrada pueden ser públicos (conocidos por todos), privados (conocidos sólo por el verificador) o mixtos (algunos datos de entrada son públicos y otros privados). - -Se puede generar una prueba, afirmando que una entrada satisface el circuito. La prueba no revela información sobre las entradas privadas y es bastante pequeña. - -El verificador puede comprobar (1) que la prueba es válida, (2) que la prueba coincide con las restricciones establecidas por el circuito (y no es sólo una prueba falsa), y (3) que las entradas públicas utilizadas para generar la prueba coinciden con las utilizadas por el verificador. Ten en cuenta que esta comprobación realizada por el verificador suele ser un cómputo barato. - - - -### Circuitos, Pruebas y Verificadores — un ejemplo - -Tomemos el Sudoku como ejemplo. Supongamos que hay un rompecabezas Sudoku, y Alice quiere demostrar a Bob que conoce una solución al rompecabezas, pero no quiere revelar cuál es la solución. - -En este caso, el rompecabezas en particular será una entrada pública (tanto Alice como Bob lo saben), y la solución es una entrada privada (Alice lo sabe, pero lo mantendrá en privado de Bob). El **circuito** tomaría ambas entradas y afirmaría que la solución es correcta comprobándola de la forma estándar, fila a fila, columna a columna, etc. De este modo, el circuito "restringe" que la solución de la entrada privada sea realmente una solución válida para el puzzle de la entrada pública, y sólo se "satisface" cuando se supera la comprobación de la solución. - -Entonces se puede generar una **prueba** que establezca que Alice conoce una entrada que satisface el circuito para el puzzle en particular (la entrada pública). - -La prueba, junto con el puzzle, podría pasarse a Bob, que podría utilizar un **verificador** correspondiente al circuito de comprobación del Sudoku para evaluar si la prueba es válida y, por tanto, si Alice conoce la solución del puzzle. Bob no obtiene ningún conocimiento de la solución de Alice, pero puede verificar que ella conoce una solución válida. - -## Zero-Knowledge Proofs y Blockchains - -Una de las principales motivaciones de los recientes avances en las ZKP es su aplicación a las cadenas de bloques. Dos de los principales retos a los que se enfrentan las blockchains descentralizadas son la privacidad y la escalabilidad: todos los datos son públicos y cada nodo de la red tiene que volver a ejecutar cada cálculo en la red. Las ZKP pueden ayudar a resolver ambos problemas. - -Aunque hay varios proyectos que utilizan la característica de zero-knowledge de las ZKP para crear aplicaciones que preserven la privacidad, en Scroll sólo utilizamos la característica de concisión de las ZKP para escalar Ethereum. - -## Scroll y Zero Knowledge Proofs - -La idea que impulsa Scroll es bastante simple. ¿Qué pasaría si pudiéramos utilizar un Smart Contract de Ethereum para verificar todos los cálculos de otra versión de Ethereum? Podríamos ejecutar otra red que proporcionara un acceso más rápido y barato a una máquina virtual de Ethereum ("EVM"), y Ethereum proporcionaría la seguridad necesaria para validar todos los cálculos y asegurarse de que esta otra red no infringe las reglas de la EVM. - -El resto de las secciones de Aprende y Tecnología explican cómo funciona esto con más detalle, pero a un nivel sencillo, recuerda que las zero-knowledge se basan en tener un circuito, una prueba y un verificador. - -En nuestra construcción, el circuito (en realidad un conjunto de circuitos) codifica las reglas de la EVM para "restringir" el comportamiento aceptable para procesar las transacciones de entrada relativas al estado de la cadena. Utilizando esta "zkEVM", una red de GPUs toma las transacciones de un conjunto de bloques y genera una prueba. Y de vuelta a Ethereum, un smart contract verifica que, para un conjunto de transacciones, esta prueba coincide con el circuito consagrado en el smart contract. Si es así, esas transacciones pueden considerarse "finalizadas", la red avanza y hemos creado un espacio de bloques rápido, seguro y asequible para el crecimiento de Ethereum. diff --git a/src/content/docs/es/learn/zero-knowledge/kzg-commitment-scheme.md b/src/content/docs/es/learn/zero-knowledge/kzg-commitment-scheme.md deleted file mode 100644 index 067992dd0..000000000 --- a/src/content/docs/es/learn/zero-knowledge/kzg-commitment-scheme.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Esquema de Compromiso KZG" -lang: "es" -permalink: "learn/zero-knowledge/kzg-commitment-scheme" -excerpt: "KZG se utiliza Proto-Danksharding de Ethereum, y también se utiliza en el sistema de pruebas de Scroll. Este artículo dará una visión general del esquema de compromiso KZG." -whatsnext: { "Recursos Adicionales": "/es/learn/zero-knowledge/additional-zk-learning-resources" } ---- - -Uno de los esquemas de compromiso polinómico más utilizados es el esquema de compromiso KZG. El esquema fue originalmente [publicado](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf) en 2010 por Kate, Zaverucha y Goldberg. - -KZG se utiliza en [Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) de Ethereum, y también se utiliza en el sistema de pruebas de Scroll. - -Este artículo dará una visión general del esquema de compromiso KZG.ç - -## Preliminares y notaciones - -Recordemos la premisa de los esquemas de compromiso polinómico. Tenemos algún polinomio $P(x)$ que nos gustaría comprometer. Asumiremos que el polinomio tiene un grado menor que $l$. - -KZG compromisos se basan en una [curva elíptica de pares](https://vitalik.ca/general/2017/01/14/exploring_ecp.html). Sean $\mathbb{G}_1$ y $\mathbb{G}_2$ dos grupos de curvas elípticas de orden $p$, con un no trivial [mapeo bilineal](https://en.wikipedia.org/wiki/Bilinear_map) $e: \mathbb{G}_1 \times \mathbb{G}_2 \rightarrow \mathbb{G}_T$. Sea $g$ un generador de $\mathbb{G}_1$, y $h$ un generador de $\mathbb{G}_2$. Utilizaremos la notación $[x]_1 := x \cdot g$ y $[x]_2 := x \cdot h$, donde $x \in \mathbb{F}_p$. - -## 1. Ceremonia o Trusted Setup - -Antes de calcular cualquier compromiso KZG, se debe realizar una única trusted setup. Una vez completada, puede reutilizarse para comprometer y revelar tantos polinomios diferentes como se desee. La trusted setup funciona de la siguiente manera: - -- Elija algún elemento de campo aleatorio $\tau \in \mathbb{F}_p$ -- Sea $l \in \mathbb{Z}$ el grado máximo de los polinomios que queremos comprometer a - - La trusted setup sólo permitirá compromisos con polinomios de grado $\leq l$ -- Se calcula $([\tau^0]_1,[\tau^1]_1,[\tau^{2}]_1\ldots,[\tau^{l}]_1)$ y $([\tau]_2)$, y se dan a conocer estos valores públicamente. - -Ten en cuenta que $\tau$ no debe ser revelado - es un parámetro secreto de la configuración, y debe ser desechado después de la ceremonia haya sido completada para que nadie pueda averiguar su valor. - -Existen métodos establecidos para llevar a cabo trusted setups con suposiciones de confianza débiles (suposición de confianza 1-de-N) utilizando [multi-party computation](https://en.wikipedia.org/wiki/Secure_multi-party_computation) (MPC). Para más información sobre cómo funcionan las trusted setups, véase este [post](https://vitalik.ca/general/2022/03/14/trustedsetup.html) de Vitalik. - -## 2. Compromiso con un polinomio - -- Dado un polinomio $P(x) = \sum_{i=0}^{l} p_i x^i$ -- Se computa y emite el compromiso $c = [P(\tau)]_1$. -- Aunque el committer no puede computar $P(\tau)$ directamente (ya que no conoce $\tau$), puede computarlo utilizando la salida de la trusted setup: - - $[P(\tau)]_1 = [\sum_{i=0}^{l} p_i \tau^i]_1 = \sum_{i=0}^{l} p_i [\tau^i]_1$. - -## 3. Probar una evaluación - -- Dada una evaluación $P(a) = b$ -- Se computa y emite la prueba $\pi = [Q(\tau)]_1$ - - Donde $Q(x) := \frac{P(x)-b}{x-a}$ - - Obsérvese que tal $Q(x)$ existe si y sólo si $P(a) = b$. Por tanto, la existencia de este polinomio cociente sirve como prueba de la evaluación. - -## 4. Verificación de una prueba de evaluación - -- Dado un compromiso $c = [P(\tau)]_1$, una evaluación $P(a) = b$, y una prueba $\pi = [Q(\tau)]_1$ -- Se Verifica que $e(\pi, [\tau - a]_2) = e(c - [b]_1, h)$ - - Algo de álgebra muestra que esto es equivalente a comprobar que el polinomio cociente está correctamente formado en $\tau$: $Q(\tau) = \frac{P(\tau) -b}{\tau-a}$ - $$ - \begin{align*} - & e(\pi, [\tau - a]_2) = e(c - [b]_1, h) \\ \iff - & e([Q(\tau)]_1, [\tau -a]_2) = e([P(\tau)]_1 - [b]_1, h) \\ \iff - & Q(\tau) \cdot (\tau - a) \cdot e(g, h) = (P(\tau)-b) \cdot e(g,h) \\ \iff - & Q(\tau) \cdot (\tau -a) = P(\tau) - b - \end{align*} - $$ - - El mapeo bilineal $e$ nos permite comprobar esta propiedad sin conocer el parámetro secreto de configuración $\tau$ -- Una vez realizada esta comprobación, podemos concluir que (con una probabilidad abrumadoramente alta) el polinomio cociente está correctamente formado, y por tanto que la evaluación es correcta. - -## Aprende Más - -- [https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html) -- [https://alinush.github.io/2020/05/06/kzg-polynomial-commitments.html](https://alinush.github.io/2020/05/06/kzg-polynomial-commitments.html) -- [https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf) diff --git a/src/content/docs/es/learn/zero-knowledge/polynomial-commitment-schemes.md b/src/content/docs/es/learn/zero-knowledge/polynomial-commitment-schemes.md deleted file mode 100644 index 333e883d2..000000000 --- a/src/content/docs/es/learn/zero-knowledge/polynomial-commitment-schemes.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Esquemas de Compromiso Polinómicos" -lang: "es" -permalink: "learn/zero-knowledge/polynomial-commitment-schemes" -excerpt: "Los Polynomial commitment schemea son un componente básico de los sistemas de pruebas de zero-knowledge." -whatsnext: { "Esquema de Compromiso KZG": "/es/learn/zero-knowledge/kzg-commitment-scheme" } ---- - -Los Esquemas de Compromiso Polinómicos son un componente básico de los sistemas de pruebas de zero-knowledge (así como de otros protocolos criptográficos). - -Como su nombre indica, los esquemas de compromiso polinómicos son esquemas de compromiso en los que el objeto a comprometer es un polinomio. Estos esquemas también tienen una propiedad especial por la que una evaluación del polinomio puede verificarse con acceso únicamente al compromiso del polinomio. - -## Esquemas de Compromiso - -Un **[esquema de compromiso](https://en.wikipedia.org/wiki/Commitment_scheme)** es una primitiva criptográfica que implica a dos partes: un _committer_ y un _verifier_. El committer se compromete con un valor $v$ computando un compromiso $c$ y revelándolo al verifier. En un momento posterior, el committer puede revelar el valor original, y el verifier puede verificar que el compromiso corresponde a este valor revelado. - -Los esquemas de compromiso seguros tienen dos características: - -1. **Binding**: una vez publicado el compromiso $c$, el committer no debe ser capaz de encontrar algún otro valor $v'$ distinto de $v$ que también corresponda a $c$. Es decir, el compromiso $c$ vincula al committer al valor original $v$. -2. **Hiding**: el verifier no debe poder obtener ninguna información sobre el valor original $v$ a partir del compromiso $c$. Es decir, el compromiso $c$ oculta toda la información sobre el valor original $v$. - -## Esquemas de Compromiso Polinómicos - -Un **esquema de compromiso polinómicos** es un esquema de compromiso en el que el committer se compromete con un polinomio $P(x)$ calculando un compromiso $c$. Como en los esquemas de compromiso normales, el committer puede revelar más tarde el polinomio original, y el verifier puede comprobar que el compromiso corresponde al polinomio revelado. Sin embargo, los esquemas de compromiso polinómico tienen una propiedad adicional: el committer puede probar evaluaciones particulares del polinomio comprometido sin revelar el propio polinomio. Por ejemplo, el committer puede probar que $P(a) = b$, y el verifier puede verificar dicha prueba utilizando sólo el compromiso $c$. - -Los esquemas de compromiso polinómicos son extremadamente útiles para aplicaciones que usan zero-knowledge. Un prover puede utilizar un esquema de este tipo para demostrar que conoce un polinomio que satisface ciertas propiedades (por ejemplo, que pasa por un cierto punto $(a,b)$), sin revelar el polinomio subyacente. - -Otra razón por la que los esquemas polinómicos son útiles es que el compromiso $c$ es generalmente mucho más pequeño que el polinomio que representa, y por lo tanto se puede considerar como una **compresión** del polinomio $P(x)$. La magnitud de la compresión depende del esquema concreto. Por ejemplo, en el esquema de compromiso polinómico KZG, un polinomio de grado arbitrariamente grande puede comprimirse hasta un compromiso consistente en un único elemento de grupo. - -## Aprende Más - -- [https://en.wikipedia.org/wiki/Commitment_scheme](https://en.wikipedia.org/wiki/Commitment_scheme) -- [https://learn.0xparc.org/materials/halo2/miscellaneous/polynomial-commitment](https://learn.0xparc.org/materials/halo2/miscellaneous/polynomial-commitment) diff --git a/src/content/docs/es/user-guide/_images/bridge1.png b/src/content/docs/es/user-guide/_images/bridge1.png deleted file mode 100644 index dd552310e..000000000 Binary files a/src/content/docs/es/user-guide/_images/bridge1.png and /dev/null differ diff --git a/src/content/docs/es/user-guide/_images/bridge2.png b/src/content/docs/es/user-guide/_images/bridge2.png deleted file mode 100644 index e3fe4701f..000000000 Binary files a/src/content/docs/es/user-guide/_images/bridge2.png and /dev/null differ diff --git a/src/content/docs/es/user-guide/_images/bridge3.png b/src/content/docs/es/user-guide/_images/bridge3.png deleted file mode 100644 index 03772fee9..000000000 Binary files a/src/content/docs/es/user-guide/_images/bridge3.png and /dev/null differ diff --git a/src/content/docs/es/user-guide/_images/bridge4.png b/src/content/docs/es/user-guide/_images/bridge4.png deleted file mode 100644 index a060b2ce3..000000000 Binary files a/src/content/docs/es/user-guide/_images/bridge4.png and /dev/null differ diff --git a/src/content/docs/es/user-guide/_images/bridge5.png b/src/content/docs/es/user-guide/_images/bridge5.png deleted file mode 100644 index 7e75aeb4d..000000000 Binary files a/src/content/docs/es/user-guide/_images/bridge5.png and /dev/null differ diff --git a/src/content/docs/es/user-guide/_images/bridge6.png b/src/content/docs/es/user-guide/_images/bridge6.png deleted file mode 100644 index 80066a330..000000000 Binary files a/src/content/docs/es/user-guide/_images/bridge6.png and /dev/null differ diff --git a/src/content/docs/es/user-guide/_images/bridge7.png b/src/content/docs/es/user-guide/_images/bridge7.png deleted file mode 100644 index 66ee3ff94..000000000 Binary files a/src/content/docs/es/user-guide/_images/bridge7.png and /dev/null differ diff --git a/src/content/docs/es/user-guide/_images/bridge8.png b/src/content/docs/es/user-guide/_images/bridge8.png deleted file mode 100644 index 4b78a8b9e..000000000 Binary files a/src/content/docs/es/user-guide/_images/bridge8.png and /dev/null differ diff --git a/src/content/docs/es/user-guide/bridge.mdx b/src/content/docs/es/user-guide/bridge.mdx deleted file mode 100644 index 1ce5e6b5b..000000000 --- a/src/content/docs/es/user-guide/bridge.mdx +++ /dev/null @@ -1,126 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Bridge" -lang: "es" -permalink: "user-guide/bridge/" -excerpt: "Para empezar a transferir activos desde Sepolia, navegue hasta el portal del bridge." ---- - -{/* // import ClickToZoom from "../../../../components/ClickToZoom.astro" */} -{/* // import bridge1 from "./\_images/bridge1.png" */} -{/* // import bridge2 from "./\_images/bridge2.png" */} -{/* // import bridge3 from "./\_images/bridge3.png" */} -{/* // import bridge4 from "./\_images/bridge4.png" */} -{/* // import bridge5 from "./\_images/bridge5.png" */} -{/* // import bridge6 from "./\_images/bridge6.png" */} -{/* // import bridge7 from "./\_images/bridge7.png" */} -{/* // import bridge8 from "./\_images/bridge8.png" */} - -{/* TODO: Update all instructions after being able to walk through the whole flow. */} - -Visita nuestro [Bridge](https://sepolia.scroll.io/bridge) para empezar. [^thanks-hop] El Bridge admite operaciones de **depósito** y **retirada**, lo que permite a los usuarios mover activos de Sepolia Testnet a Scroll Sepolia Testnet con total confianza. -[^thanks-hop]: Un fork de la IU de [Hop Exchange]('https://hop.exchange/') 🙌. - -Los depósitos pueden tardar hasta 15 minutos en estar disponibles en Scroll. - -Los retiros, que requieren una segunda interacción en Sepolia una vez finalizada la retirada, pueden tardar mucho más. - -:::caution[¿Esperando mucho tiempo para una transacción del bridge?] -Las estimaciones de tiempo anteriores son típicas para el comportamiento normal de la red y los niveles de actividad. Dado que sólo procesamos un número determinado de transacciones de L1 en cola por bloque L2, los mensajes en el bridge pueden tardar más en incluirse en Scroll en momentos de uso excesivo de la red. -::: - -## Depósito de Sepolia a Scroll Sepolia - -### Instrucciones - -1. En primer lugar, navegue hasta el [Scroll Bridge](https://sepolia.scroll.io/bridge) y pulse el botón "Connect Wallet". -1. En la app, asegúrate de que **Ethereum Sepolia** está arriba y **Scroll Sepolia** abajo. Puedes pulsar el botón "**↓**" para cambiar sus posiciones. -1. Selecciona el token que quieres transferir de Sepolia a Scroll Sepolia. Si es la primera vez que usas el bridge, prueba con "ETH". -1. Si es la primera vez que transfieres un token ERC20 específico, debes **Aprobar** el contrato Sepolia Bridge para acceder a tu token ERC20. -1. A continuación, haz clic en el botón **Enviar a Scroll Sepolia** para realizar el ingreso. Tu billetera te pedirá que confirmes la transacción de transferencia. -1. Una vez enviada y confirmada la operación de transferencia, el token se deducirá de tu billetera de Sepolia. -1. Siempre puedes comprobar el estado de una transacción pulsando el icono "Historial" situado junto a la dirección de tu billetera en la esquina superior derecha. - -### ¿Cuándo llegarán los tokens a tu billetera de Scroll Sepolia? - -Puede tardar entre **8 y 14 minutos** (esperando a que el bloque se vuelva [_Seguro_](https://www.alchemy.com/overviews/ethereum-commitment-levels#what-are-ethereum-commitment-levels) en Sepolia) antes de que el token aparezca en tu billetera de Scroll Sepolia. - -{/* You can check the progress of deposit transactions as follows: */} - -{/* ##### 1. Click the "History" icon next to your billetera address in the top-right corner. */} - -{/* */} - -{/* The pop-up panel lists the most recent transactions made in the Bridge app. There are two statuses: Sepolia status and Scroll Sepolia status. For deposit transactions (L1 -> L2), once your transaction becomes _Safe_ on Sepolia (**8 to 14 minutes**), you will see the **`success`** status shown. Your funds will be relayed to Scoll Sepolia after this. */} - -{/* The Recent Bridge Transactions window should give you an estimate of the time expected before your transaction is _Safe_ on Sepolia. */} - -{/* ##### 2. Click on the most recent transaction’s Sepolia transaction hash. */} - -{/* */} - -{/* It will open the Transaction Details page in a new tab. You can see this transaction is confirmed on Sepolia. To check the Block's confirmation status, click the Block number and read the "Status" field. */} - -{/* */} - -{/* ##### 3. Return to the Bridge app and wait! */} - -{/* Once your transaction status shows **`success`** on Scroll Sepolia, you should see the funds in your Scroll L2 wallet and a transaction hash: */} - -{/* */} - -## Retiro de Scroll Sepolia a Sepolia - -### Instrucciones - -#### Envío de la primera transacción de retiro de fondos - -1. Primero, cambia a la red **Scroll Sepolia** en tu billetera. -1. En la app, asegúrate de que **Scroll Sepolia** está arriba y **Ethereum Sepolia** abajo. Puedes pulsar el botón "**↓**" para cambiar las posiciones. -1. Selecciona el token que quieres transferir de **Scroll Sepolia** a **Sepolia**. Si es la primera vez que usas el bridge, prueba con "ETH". -1. Si es la primera vez que transfieres un token ERC20 específico, debes **Aprobar** el contrato Scroll Sepolia Bridge para acceder a tus tokens ERC20. -1. A continuación, haz clic en el botón **Enviar a Ethereum Sepolia** para realizar la retirada. Tu billetera te pedirá que confirmes la transacción de transferencia. -1. Una vez enviada y confirmada la operación de transferencia, el token se deducirá de tu billetera de Scroll Sepolia. - -#### Envío de una transacción de retiro de fondos - -{/* TODO: finish the additional instructions, better estimate "wait time" */} - -_Los pasos restantes tienen lugar en Scroll Sepolia, pero primero debes esperar a que tu transacción esté completamente probada ("finalizada") en Ethereum Sepolia. Este proceso puede durar hasta cuatro horas._ - -1. Cuando tu transacción de retirada haya finalizado en Ethereum Sepolia, verá que el botón "Claim" en el área de Transacciones Recientes se vuelve sólido. -1. Haz clic en el botón "Claim" para enviar la ejecución de la transacción de retiro de fondos. -1. Una vez enviado, los fondos retirados deberían aparecer inmediatamente en tu billetera de Sepolia. - -### ¿Cuándo llegará el token a tu billetera Sepolia? - -El token transferido llegará a tu billetera de Sepolia inmediatamente después de que el bloque que contiene la ejecución de la transacción de retirada se confirme en Sepolia. - -{/* TODO: check architecture link is live */} - -:::tip[Estatus del Rollup] -El estado de rollup `Finalizado` indica que se ha comprobado la correcta ejecución de las transacciones de este bloque mediante la verificación de una prueba de validez on-chain en Sepolia. Para más información sobre el estado de rollup, véase [Visión general de la arquitectura de Scroll](/es/technology). -::: - -{/* You can check the progress of withdrawal transactions as follows: */} - -{/* 1. Click your wallet address at the top-right corner of the Bridge web app. */} - -{/* */} - -{/* The pop-up panel lists the most recent transactions you made in the Bridge app (see the image below). There are two statuses: L1 status and L2 status. In this case, because we are bridging from L2 -> L1, we will quickly get a **`success`** status after submitting the transaction to the L2 Bridge. L1, on the other hand, takes **10 minutes to a few hours** to reach **`success`**. */} - -{/* 1. Click on the most recent transaction’s L2 transaction hash: */} - -{/* */} - -{/* It will open the _Transaction Details_ page in a new tab. You can see this transaction is confirmed on L2. */} - -{/* */} - -{/* The transaction is confirmed on L2, but still needs to be finalized on Goerli. */} - -{/* 1. Go back to the [Bridge](https://scroll.io/bridge) app. It takes about 10 minutes before the token shows up in your Goerli wallet. Once your transaction status shows success on L2, you should see the funds in your Goerli wallet and a transaction hash: */} - -{/* */} diff --git a/src/content/docs/es/user-guide/common-errors.mdx b/src/content/docs/es/user-guide/common-errors.mdx deleted file mode 100644 index d27a04ca1..000000000 --- a/src/content/docs/es/user-guide/common-errors.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Errores Comunes" -lang: "es" -permalink: "user-guide/common-errors/" -excerpt: "¿Ve un error cuando intenta interactuar con Scroll Sepolia Testnet? Aquí hay algunos errores comunes de configuración y cómo solucionarlos rápidamente." ---- - -## Error de nonce incorrecto al enviar una transacción en MetaMask - -Encontrarás este error cuando el nonce local almacenado en tu wallet MetaMask sea diferente del nonce en el nodo Scroll testnet. Podría deberse a que hay una transacción pendiente reciente. - -Para solucionar este problema, es necesario restablecer su cuenta en MetaMask para el Scroll Sepolia Testnet. Los pasos para restablecer la cuenta son: - -1. Abre la extensión **MetaMask** en el navegador -2. Selecciona **Scroll Sepolia Testnet** en el área superior -3. Haz clic en el **icono de la cuenta** redondo en la esquina superior derecha -4. Selecciona **Configuración** -5. Vé a **Avanzado**. -6. Haz clic en **Borrar datos de la pestaña de actividad**. - -No perderás ningún activo durante el reinicio de la cuenta MetaMask. - -:::caution[Precaución] -Eliminar y volver a añadir una red NO es suficiente para solucionarlo, debes restablecer tu cuenta. -::: - -## No ocurre nada al confirmar una transacción bridging/swapping - -Si no aparece ningún error o registro de consola, es probable que se deba a un problema de nonce, por favor, reinicie su cuenta MetaMask como se indica más [arriba](/es/user-guide/common-errors#error-de-nonce-incorrecto-al-enviar-una-transacción-en-metamask). - -## Block Explorer muestra "Internal server error". - -Utiliza una ventana de incógnito o abre la "Developer Console" de tu navegador y elimina la cookie `_explorer_key` (o todas las cookies). [Consulta esta guía para saber cómo eliminar las cookies](https://www.contentstack.com/docs/developers/how-to-guides/clear-caches-and-cookies-in-different-browsers/). - -## Al enviar la cantidad máxima de ETH en MetaMask se produce un error "Failed". - -Cuando envías ETH usando MetaMask, si intentas enviar la cantidad "Max", y resulta en un error "Failed". Esto se debe a que MetaMask no tiene en cuenta la "Comisión L1" adicional que tienen los rollups además de la comisión normal por el gas, por ello, se queda corto en una pequeña cantidad necesaria para pagar el gas de la transacción. - -Para solucionar esto, baje manualmente la cantidad de ETH para que sea un poco menor que la sugerida y la transacción se realizará. diff --git a/src/content/docs/es/user-guide/faucet.mdx b/src/content/docs/es/user-guide/faucet.mdx deleted file mode 100644 index 9ce37945a..000000000 --- a/src/content/docs/es/user-guide/faucet.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Faucet" -lang: "es" -permalink: "user-guide/faucet/" -whatsnext: { "Pasa tu ETH a Scroll Sepolia": "/es/user-guide/bridge" } -excerpt: "Para interactuar con nuestra testnet, primero necesitas adquirir Sepolia ETH. Hay algunas aplicaciones de faucets de Sepolia para empezar." ---- - -Para interactuar con nuestra testnet, primero necesitas recibir ETH de la _Sepolia Testnet_. Luego puedes usar un bridge de _Sepolia Testnet_ a _Scroll Sepolia Testnet_. - -## Faucets de Sepolia - -Cada faucet tiene sus propias reglas y requisitos, por lo que es posible que tengas que probar unos cuantos antes de encontrar uno que funcione para ti. - -Aquí tienes algunos faucets de Sepolia: - -- [https://sepoliafaucet.com](https://sepoliafaucet.com//) -- [https://sepolia-faucet.pk910.de](https://sepolia-faucet.pk910.de/) -- [https://faucet.quicknode.com/drip](https://faucet.quicknode.com/drip) -- [https://faucet.chainstack.com](https://faucet.chainstack.com) -- [https://infura.io/faucet/sepolia](https://infura.io/faucet/sepolia) - -Una vez que recibas ETH en Sepolia, deberías verlos en tu wallet en la _Red Sepolia_. Pueden tardar unos segundos en aparecer, pero puedes comprobar el estado buscando una transacción a tu dirección en un [Explorador de bloques de Sepolia](https://sepolia.etherscan.io/). - -:::note[¡No te apresures!] -La mayoría de los faucets sólo permiten solicitar tokens de prueba una vez cada 24 horas. -::: - -## Faucets de Scroll Sepolia - -Si no quieres interactuar con el bridge, algunos faucets distribuyen ETH directamente a Scroll Sepolia . --> - -- [https://thirdweb.com/scroll-sepolia-testnet](https://thirdweb.com/scroll-sepolia-testnet) -- [https://www.hackquest.io/en/faucets/534351](https://www.hackquest.io/en/faucets/534351) -- [https://scroll.l2scan.co/faucet](https://scroll.l2scan.co/faucet) -- [https://www.covalenthq.com/faucet/](https://www.covalenthq.com/faucet/) -- [https://faucet.quicknode.com/scroll/sepolia](https://faucet.quicknode.com/scroll/sepolia) - {/* - [https://bwarelabs.com/faucets/scroll-testnet](https://bwarelabs.com/faucets/scroll-testnet) */} diff --git a/src/content/docs/es/user-guide/index.mdx b/src/content/docs/es/user-guide/index.mdx deleted file mode 100644 index 58f8df277..000000000 --- a/src/content/docs/es/user-guide/index.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Guía de Usuario de Scroll Sepolia" -lang: "es" -permalink: "user-guide/" -excerpt: "Gracias por probar nuestra Scroll Sepolia Testnet. La Sepolia Testnet está formada por la Sepolia Testnet de Ethereum y la red de pruebas Scroll Sepolia." -whatsnext: { "Configuración de Wallet": "/es/user-guide/setup" } ---- - -import Aside from "../../../../components/Aside.astro" - - - -Gracias por probar la Scroll Sepolia Testnet. Si tienes preguntas o quieres darnos tu opinión, ¡únete a nuestro [Discord](https://discord.gg/scroll)! - -Sepolia Testnet está formada por _Ethereum's Sepolia Testnet_ y la red de pruebas _Scroll Sepolia_. Sepolia es una red de pruebas de Ethereum, mientras que Scroll Sepolia es una zero-knowledge rollup testnet desplegada sobre la primera. Existen algunas aplicaciones demo predesplegadas: un [bridge](https://sepolia.scroll.io/bridge) entre _Sepolia_ y _Scroll Sepolia_,[^1] un [block explorer](https://sepolia-blockscout.scroll.io/) para _Scroll Sepolia_,[^2] y un [rollup explorer](https://sepolia.scroll.io/rollupscan). - -Para ver las transacciones en L1, echa un vistazo al [Sepolia explorer](https://sepolia.etherscan.io/) de Etherscan. -Para ver las transacciones en L2, puedes usar [Scrollscan](https://sepolia.scrollscan.com) or el [Blockscout](https://sepolia-blockscout.scroll.io/) de Scroll, pero también puedes probar la funcionalidad adicional proporcionada por [Dora](https://www.ondora.xyz/network/scroll-sepolia/interactions) o [L2Scan](https://scroll-sepolia.l2scan.co/). - -Este es el flujo de trabajo sugerido para explorar la Testnet: - -1. Añade las configuraciones de [Sepolia Testnet](https://sepolia.scroll.io/portal) a tu wallet. -2. Solicita tokens de prueba en la red _Sepolia_ desde cualquier aplicación de Ethereum Faucet. (véase el artículo [Faucet](/es/user-guide/faucet)). -3. Transfiere tokens de prueba de _Sepolia_ a _Scroll Sepolia_ a través del [Bridge](https://sepolia.scroll.io/bridge). -4. Transfiere tokens a otras wallets en _Scroll Sepolia_ utilizando tu wallet. -5. Explora nuestro ecosistema, interactuando con contratos como [Uniswap](https://uniswap-showcase.sepolia.scroll.xyz/) o [Aave](https://app.aave.com). -6. Retira tokens de _Scroll Sepolia_ a _Sepolia_ a través del [Bridge](https://sepolia.scroll.io/bridge). - -Encontrarás las instrucciones de cada aplicación en el resto de esta guía del usuario. - -## Preguntas y Feedback - -Si tienes algún problema, únete a nuestro [Discord](https://discord.gg/scroll) y habla con nosotros en el canal `#general-support`. También nos encantaría conocer tus opiniones o comentarios sobre cómo podemos mejorar tu experiencia. - -[^1]: Un fork de la IU de [Hop Exchange](https://hop.exchange/) 🐇🙌. -[^2]: Usando el gran explorador de bloques de código abierto de [Blockscout](https://blockscout.com/) diff --git a/src/content/docs/es/user-guide/setup.mdx b/src/content/docs/es/user-guide/setup.mdx deleted file mode 100644 index 3dce074b3..000000000 --- a/src/content/docs/es/user-guide/setup.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Configuración" -lang: "es" -permalink: "user-guide/setup/" -whatsnext: { "Obten ETH de Sepolia ETH desde un Faucet": "/es/user-guide/faucet" } -excerpt: "Necesitas tener un wallet para interactuar con la Scroll Testnet. Puedes encontrar algunas wallets de ejemplo y consejos de configuración aquí." ---- - -import Aside from "../../../../components/Aside.astro" - -## Wallet - -Necesitas tener una wallet para interactuar con las dApps en la Scroll Sepolia testnet. Puedes encontrar algunos ejemplos de wallets y consejos de configuración más abajo. Nuestra aplicación Bridge es compatible con MetaMask, Coinbase Wallet o cualquier otra wallet compatible con WalletConnect. - -### MetaMask - -Puedes instalar MetaMask desde su [sitio web oficial](https://metamask.io/download/). - -Puedes importar las configuraciones de la Scroll Sepolia testnet a tu wallet de MetaMask. Para ello, visita el [portal de Scroll Sepolia](https://sepolia.scroll.io/portal), luego haz clic en el botón "Connect Wallet" y selecciona MetaMask. A continuación, haz clic en los botones "Add to MetaMask" para Sepolia Testnet y Scroll Sepolia Testnet. Esto importará el identificador de cadena y las URL RPC para el Scroll Sepolia Testnet. La Sepolia Testnet también está configurada por defecto en MetaMask. Para mostrarla, haz clic en "Mostrar/ocultar redes de prueba" en el menú desplegable de selección de redes de MetaMask. - -### Configuración manual de la red (para otras wallets) - -Los links **Add to wallet** pueden no ser compatibles con todos las wallets. Si tiene problemas para utilizarlos, puede que necesite añadir manualmente la red _Sepolia Testnet_ y _Scroll Sepolia_ introduciendo los detalles de configuración de la tabla siguiente: - -| Nombre de la Red | Scroll Sepolia Testnet | Sepolia Testnet | -| ------------------ | ---------------------------------------------------------------- | ---------------------------------------------------------------------------- | -| RPC URL | [https://sepolia-rpc.scroll.io/](https://sepolia-rpc.scroll.io/) | [https://eth-sepolia-public.unifra.io](https://eth-sepolia-public.unifra.io) | -| Chain ID | 534351 | 11155111 | -| Currency Symbol | ETH | ETH | -| Block Explorer URL | [https://sepolia.scrollscan.com](https://sepolia.scrollscan.com) | [https://sepolia.etherscan.io](https://sepolia.etherscan.io) | - - diff --git a/src/content/docs/es/user-guide/transfer-tokens.md b/src/content/docs/es/user-guide/transfer-tokens.md deleted file mode 100644 index 0b1c76361..000000000 --- a/src/content/docs/es/user-guide/transfer-tokens.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Transferencia de Tokens" -lang: "es" -permalink: "user-guide/transfer-tokens/" -excerpt: "Puede utilizar su wallet como de costumbre para transferir tokens dentro de la Scroll Sepolia Testnet." ---- - -Puedes utilizar la funcionalidad normal de tu wallet para transferir tokens dentro de la Testnet de Scroll Sepolia -- no es necesaria ninguna configuración adicional. - -## Envío de un token en MetaMask - -1. Abre tu wallet y cambia a **Scroll Sepolia Testnet**. -2. Haz clic en el botón **Enviar** del centro y escribe la dirección a la que deseas transferir en el cuadro de texto. -3. Selecciona el token en la casilla **Activo** y escribe la cantidad de tokens que quieres transferir. -4. Pulsa el botón **Siguiente** y después pulsa el botón **Confirmar** para enviar la transacción. -5. Después del envío, puedes encontrar la transacción en la pestaña **Actividad** de tu wallet. diff --git a/src/content/docs/tr/getting-started/overview.md b/src/content/docs/tr/getting-started/overview.md deleted file mode 100644 index 644d0a643..000000000 --- a/src/content/docs/tr/getting-started/overview.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Scroll'a Genel Bakış" -lang: "tr" -permalink: "docs/conceptual-overview/" -excerpt: "ZK Rollups and Scroll" -whatsnext: { "Kullanıcı kılavuzu": "/tr/user-guide/", "Scroll üzerinde geliştirmek": "/tr/developers/" } ---- - -#### Scroll Dokümantasyonu'na hoş geldiniz! - -Scroll, Ethereum için güvenlik odaklı bir ölçeklenebilirlik çözümüdür; ölçekleme tasarımındaki ve zero knowledge kanıtlarındaki yenilikleri kullanarak Ethereum üzerinde yeni bir katman oluşturmayı hedeflemektedir. Scroll ağı, Ethereum'un tek başına olduğundan daha erişilebilirdir, daha duyarlıdır ve aynı anda daha fazla kullanıcıyı destekleyebilir. Eğer daha önce Ethereum üzerinde bir uygulama kullandıysanız veya geliştirdiyseniz, Scroll'da kendinizi evinizde hissedeceksiniz. - -Scroll'u kullanmadan önce Scroll Sepolia test ağını ücretsiz varlıklarla denemek ister misiniz? [Kullanıcı kılavuzumuza](/tr/user-guide/) göz atın. - -## Scroll ne inşa ediyor? - -Scroll, Ethereum'u ölçeklendirmek için teknoloji geliştiriyor. - -Ethereum, merkeziyetsiz uygulamaları desteklemek konusunda önde gelen blokzinciri ağı olmasına rağmen, popülerliği daha yüksek maliyetleri de beraberinde getiriyor ve bu durum gelecek kullanıcılar ve geliştiriciler için bir engel oluşturuyor. - -Zero knowledge kanıtları alanındaki öncü araştırmalardan yararlanarak, Scroll, Ethereum üzerinde bir Katman 2 rollup ağı inşa ediyor. Ethereum topluluğundaki diğer kişilerle açık kaynaklı işbirliği içinde olan ekip, tıpkı Ethereum gibi davranan ağdaki tüm faaliyetlerin Ethereum üzerindeki akıllı sözleşmelerle güvence altına alınmasına olanak tanıyan bir "zkEVM" oluşturdu. Ağ, tüm işlemleri Ethereum'da yayınlar ve zkEVM, Scroll ağının Ethereum kurallarına uyduğuna dair kriptografik "kanıtlar" oluşturur ve yayınlar. - -Sonuç olarak, Ethereum'daki akıllı sözleşmeler Scroll'daki her işlemin bu kanıtlar için geçerli olduğunu doğrular ve ağı inanılmaz bir güvenliğe, merkeziyetsizliğe ve sansür direncine kavuşturur. Ethereum için bu düzeyde güvenlik ve ölçeklenebilirlik yalnızca zero knowledge kriptografisi, blokzincir protokol tasarımı ve donanım hızlandırmadaki son gelişmelerle mümkün olabilir. - -Daha fazla bilgi için mimarimiz hakkında bilgi almak için [Scroll Mimarisi](/tr/technology/) sayfasına bakın. - -## Scroll'u şu anda kullanabilir miyim? - -Scroll ana ağı Ethereum üzerinde aktif! Ayrıca, Ethereum Sepolia üzerinde çalışan Scroll Sepolia test ağımız da bulunuyor. [Kapsamlı bir kılavuzumuz](/tr/user-guide/) olsa da, Ethereum'u kullanmaya aşina iseniz, birkaç dakika içinde başlayabilirsiniz: - -- [Köprü](https://scroll.io/bridge) sayfamızı veya [Scroll Sepolia Köprüsü](https://sepolia.scroll.io/bridge) sayfamızı ziyaret edin ve cüzdanınızı bağlayın. -- Ethereum ana ağından Scroll'a token gönderin. (veya bir Scroll Sepolia [musluğu](/tr/user-guide/faucet) kullanın) -- Scroll Sepolia test ağı dApp'lerini deneyin, örneğin [Uniswap Vitrini](http://uniswap-showcase.sepolia.scroll.xyz/) veya [Aave](https://app.aave.com/) -- Scroll Sepolia Ağı'nı seçtiğinizden emin olun! - -## Scroll ne yönde ilerliyor? - -Scroll ana ağımızı Ethereum üzerinde yayınladık, ancak hala daha yapılacak çok iş buluyor. Sırada yığının her bileşenini merkeziyetsizleştirmek var. Güncel kalmak için [bloğumuza](https://scroll.io/blog) göz atın, [Discord](https://discord.gg/scroll) veya [Twitter](https://twitter.com/scroll_zkp) hesaplarımızı takip edin. diff --git a/src/content/docs/tr/learn/index.mdx b/src/content/docs/tr/learn/index.mdx deleted file mode 100644 index e1adb6972..000000000 --- a/src/content/docs/tr/learn/index.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -section: learn -title: "Öğren" -lang: "tr" -permalink: "learn/" -excerpt: "Ethereum ölçeklenebilirliği ve zero knowledge kanıtları hakkında daha fazlasını öğrenin." ---- - -import NavCard from "../../../../components/NavCard.astro" -import TechnologySvg from "../../../../assets/svgs/home/home-technology.svg?raw" -import LearnSvg from "../../../../assets/svgs/home/home-learn.svg?raw" - -Scroll, blokzincir protokolleri ve zero knowledge kriptografisinden araştırma ve mühendislik çalışmalarını bir araya getiriyor. Daha derinlemesine bilgi için okumaya devam edin ve ek kaynaklara göz atın. - -Belirli bir konunun da ele alınmasını mı istiyorsunuz? Github repo'muzda bir [issue](https://github.com/scroll-tech/scroll-documentation/issues/new?assignees=&labels=new+content%2Ctriage&projects=&template=new_content.yml&title=%5BNew+Content%5D%3A+%3Cyour-title-here%3E) oluşturun. - -
- - -
diff --git a/src/content/docs/tr/learn/intro-to-rollups.md b/src/content/docs/tr/learn/intro-to-rollups.md deleted file mode 100644 index 91e13c157..000000000 --- a/src/content/docs/tr/learn/intro-to-rollups.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Rollup'lara Giriş" -lang: "tr" -permalink: "learn/intro-to-rollups" -excerpt: "Rolluplar, Ethereum ekosistemindeki en yaygın ikinci katman ölçekleme çözümüdür." -whatsnext: { "Scroll Rollup Süreci": "/tr/technology/chain/rollup" } ---- - -## Rollup nedir? - -Rolluplar, Ethereum ekosistemindeki en yaygın katman 2 ölçeklenme çözümüdür ve Ethereum yol haritasının [merkezi bir parçası](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) olarak görülmektedir. - -Bir rollup, işlem gruplarını zincir dışında işler (yani katman 1'de değil) ve ardından ortaya çıkan verileri zincir üstünde yayınlar (yani katman 1'de). - -Her işlemin yürütülmesi zincir-dışı olarak gerçekleştirilir ve bu işlemlerin katman 1 düğümleri tarafından yeniden yürütülmesi gerekmez. Bu da, katman 1'in merkeziyetsizini etkilemeden yüksek işlem hızına olanak tanır. - -Bir rollup'un güvenli olması için, zincir-dışı hesaplamanın (işlemlerin işlenmesi) doğru bir şekilde gerçekleştirildiğini kanıtlaması gerekir. Zincir dışı hesaplamanın geçerliliğini kanıtlamanın iki temel mekanizması vardır: geçerlilik kanıtları(validity proofs) ve dolandırıcılık kanıtları(fraud proofs). - -## Optimistic rollup nedir? - -Bir optimistic rollup, yaptığı hesaplamaların geçerliliğini savunmak için dolandırıcılık kanıtlarını kullanan bir rollup'tır. - -Dolandırıcılık kanıtları, kullanıcıların L2'de gerçekleştirilen herhangi bir hesaplamanın geçersizliğini sorgulamasına ve kanıtlamasına olanak tanıyan bir mekanizmadır. Bir dolandırıcılık kanıtı başarıyla gönderildiğinde, L2 bir önceki bir duruma geri döndürülebilir ve geçersiz hesaplama düzeltilebilir. Dolandırıcılık kanıtları, en az bir dürüst tarafın L2 işlemlerinin doğru bir şekilde yürütüldüğünü kontrol etmesine dayanır. - -## ZK rollup nedir? - -Bir ZK rollup, yaptığı hesaplamaların geçerliliğini savunmak için geçerlilik kanıtlarını kullanan bir rollup'tır. - -Bir ZK rollup, bir işlem grubunu yürüttüğünde ve sonucu L1'e gönderdiğinde, aynı zamanda bir geçerlilik kanıtı da gönderir. Bu matematiksel kanıt, sonuç ile işlem grubunun doğru bir şekilde yürütülmesiyle ortaya çıkan durumun, aynı olduğunu kanıtlar. - -Bugünlerde birden çok türde ZK rollup bulunuyor, bunlar genel olarak zkVM'ler (zk Sanal Makineler) veya zkEVM'ler (zk Ethereum Sanal Makineleri) olarak tanımlanıyor. - -zkVM'ler, ZK devreleriyle iyi çalışacak şekilde temelden tasarlanmıştır ve bir zkEVM'e kıyasla farklı geliştirme iş akışları gerektirir. Bunlara örnek olarak Starkware ve Aztec verilebilir. - -zkEVM'ler, EVM'i taklit etmek üzere tasarlanmıştır. İki ana türü vardır: bytecode uyumlu ve dil uyumlu. Bytecode uyumlu zkEVM'ler, EVM'i çok düşük seviyede taklit eder ve Ethereum Katman 1'e kıyasla neredeyse aynı geliştirme ve kullanıcı deneyimi sağlar. Dil uyumlu zkEVM'ler, Solidity ve diğer yüksek seviye dilleri farklı bytecode'lara derler; bu da iş akışında değişikliklere neden olabilir. zkSync, en popüler dil uyumlu zkEVM'dir. - -Scroll, bytecode uyumlu bir yapıya sahiptir. Bu yaklaşımın seçilmesinin bazı faydaları vardır: - -- Solidity, Vyper ve Huff doğrudan kullanıma hazır. -- Yeniden kod denetimine gerek yok -- Varolan geliştirme araçlarının çoğu devralınır -- Ethereum ile neredeyse aynı kullanıcı deneyimi ve geliştirici deneyimi sağlar - -Scroll'un yaklaşımına ilişkin daha fazla ayrıntı Teknoloji bölümünde bulunabilir. - -## Daha fazla okumak için - -- [Rollup'lar Hakkında Eksik Bir Kılavuz](https://vitalik.ca/general/2021/01/05/rollup.html) - Vitalik Buterin -- [Ölçeklenme](https://ethereum.org/en/developers/docs/scaling/) - Ethereum Dokümanları diff --git a/src/content/docs/tr/learn/the-scalability-problem.md b/src/content/docs/tr/learn/the-scalability-problem.md deleted file mode 100644 index 2ad2bb976..000000000 --- a/src/content/docs/tr/learn/the-scalability-problem.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Ölçeklenebilirlik Sorunu" -lang: "tr" -permalink: "learn/intro-to-rollups" -excerpt: "Ethereum'ın güçlü merkeziyetsizliği ve güvenliği, ölçeklenebilirliğini feda etmesiyle sağlanır: Katılan tüm düğümlerin ağa ayak uydurabilmesini sağlamak için ağın işlem kapasitesi sınırlıdır. Bu sınır sonuçta kullanıcılar için daha yüksek maliyetlere ve gecikmelere neden olur." -whatsnext: { "Rollup'lara Giriş": "/tr/learn/intro-to-rollups" } ---- - -## Ethereum’un ölçeklenme sorunu - -[Ethereum](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-is-ethereum) genel amaçlı bir blokzincirdir ve [akıllı kontratların](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-are-smart-contracts) dağıtımını ve yürütülmesini destekler. - -Ethereum'un tanımlayıcı özelliklerinden biri, güvenliğe ve merkeziyetsizliğe olan sarsılmaz bağlılığıdır. Ethereum, dünyanın her yerindeki bilgisayarların ([Raspberry Pi](https://ethereum-on-arm-documentation.readthedocs.io/) gibi ucuz bilgisayarların bile) ağa katılarak, blokzincirin yerel kopyalarını çalıştırabilecek ve yeni işlemleri işleyebilecek şekilde tasarlanmıştır. - -Ancak Ethereum'un güçlü merkeziyetsizliği ve güvenliği, ölçeklenebilirlikten ödün verme pahasına gelir: katılan tüm düğümlerin ağa ayak uydurabilmesini sağlamak için ağın verimi sınırlıdır. Bu durum, kullanıcılar için daha yüksek maliyetler ve gecikmeler anlamına gelir. - -## Ölçeklenme çözümleri - -Ethereum'un ölçeklenme çözümleri, merkeziyetsizlikten veya güvenlikten ödün vermeden ağın verimini artırmayı amaçlıyor. - -Ana olarak iki tür ölçeklenme çözümü vardır: katman 1 ölçeklenme çözümleri ve katman 2 ölçeklenme çözümleri. - -**Katman 1** (veya **L1**) ölçeklenme çözümleri, doğrudan Ethereum blokzincirinde değişiklikler yaparak ağı ölçeklendirmeye çalışır. Buradaki “katman 1” terimi ana Ethereum blokzincirini ifade etmektedir. Genel olarak, verimi artıran ve aynı zamanda yüksek düzeyde güvenlik ve merkeziyetsizliği koruyan katman 1 ölçeklenme çözümlerini tasarlamak çok zordur. Bu nedenle son zamanlardaki ölçeklenme çabaları 1. katman çözümlerinden 2. katman çözümlerine doğru kaymıştır. - -**Katman 2** (veya **L2**) ölçeklenme çözümleri, Ethereum katman 1'in **üstünde** yaşayan ağlardır; bunlar esasen, temeldeki Ethereum blokzincirine bir şekilde "sabitlenmiş" ayrı blokzincirlerdir. Bu katman 2 ağları, aynı sınırlamalara tabi olmadıkları için genellikle işlemleri temel katman 1 ağından daha yüksek bir hızda işleyebilir. "Sabitleme" mekanizmasının özellikleri çeşitli katman 2'ler arasında farklılık gösterebilir. Bu mekanizma, katman 2 ağının, Ethereum katman 1'in güçlü güvenlik ve merkeziyetsiz özelliklerini miras almasını sağlar. diff --git a/src/content/docs/tr/learn/zero-knowledge/additional-zk-learning-resources.md b/src/content/docs/tr/learn/zero-knowledge/additional-zk-learning-resources.md deleted file mode 100644 index 2c8022e1a..000000000 --- a/src/content/docs/tr/learn/zero-knowledge/additional-zk-learning-resources.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Ek ZK Öğrenme Kaynakları" -lang: "tr" -permalink: "learn/zero-knowledge/additional-zk-learning-resources" -excerpt: "ZK'nin derinliklerine dalmak mı istiyorsunuz? İşte favori kaynaklarımızdan bazıları." ---- - -ZK'nin derinliklerine dalmak mı istiyorsunuz? İşte favori kaynaklarımızdan bazıları. - -## Video - -- [ZK Beyaz Tahta Oturumları](https://youtube.com/playlist?list=PLj80z0cJm8QErn3akRcqvxUsyXWC81OGq) - - Bu beyaz tahta oturumları ZK hakkında bilgi edinmek için harika bir yoldur. Dan Boneh'in ilk üç dersi, sonraki derslerin üzerine inşa edildiği, daha yeni gelişmeleri tartışan harika bir temel anlayış sağlıyor. -- [Zero Knowledge Kanıtı MOOC](https://youtube.com/playlist?list=PLS01nW3Rtgor_yJmQsGBZAg5XM4TSGpPs) - - İlk prensiplerden modern endüstri konularına kadar zero knowledge kanıtlarını kapsayan bir MOOC(Massive Open Online Courses). -- [9. BIU Kriptografi Kış Okulu - Zero Knowledge](https://youtube.com/playlist?list=PL8Vt-7cSFnw29cLUVqAIuMlg1QJ-szV0K) - - Bu dersler zero knowledge'ın teorik temellerini oluşturur; akademisyenleri ve matematiksel olgunluğa sahip izleyicileri hedefler. -- [ZK Sempozyumu](https://www.youtube.com/playlist?list=PLrzRr7okCcmbAlgYpuFjzUJv8tAyowDQY) - - Zero knowledge alanındaki en iyi araştırmacıların ve ürün geliştiricilerin bazılarının uygulamalı ve teorik sunumlarının bir karışımı. - -## Yazı - -- [Kanıtlar, Argümanlar ve Zero Knowledge](https://people.cs.georgetown.edu/jthaler/ProofsArgsAndZK.html) - Justin Thaler - - Zero knowledge teorisi üzerine kapsamlı bir ders kitabı. diff --git a/src/content/docs/tr/learn/zero-knowledge/introduction-to-zero-knowledge.mdx b/src/content/docs/tr/learn/zero-knowledge/introduction-to-zero-knowledge.mdx deleted file mode 100644 index 2404d5d48..000000000 --- a/src/content/docs/tr/learn/zero-knowledge/introduction-to-zero-knowledge.mdx +++ /dev/null @@ -1,73 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Zero Knowledge'a Giriş" -lang: "en" -permalink: "learn/zero-knowledge/introduction-to-zero-knowledge" -whatsnext: { "Polynomial Commitment Schemes": "/learn/zero-knowledge/polynomial-commitment-schemes" } -excerpt: 'Over the past decade, a field of cryptography called "zero knowledge" has been rapidly advancing. It promises new ways to build applications and enables protocols to increase efficiency, security, and privacy.' ---- - -import Aside from "../../../../../components/Aside.astro" - -Son on yılda, "zero knowledge" olarak adlandırılan kriptografi alanı hızla ilerlemektedir. Zero knowledge, uygulama oluşturmanın yeni yollarını vaat ediyor ve protokollerin verimliliği, güvenliği ve gizliliği artırmasını sağlıyor. - -Zero knowledge kanıtları alanını bu kadar heyecan verici kılan şeyin ne olduğuna ve mühendislerin hangi sorunları çözmesine yardımcı olduğuna bakalım. - -## Güven Gerektirmeyen Blokzincirler ve Doğrulanabilirlik - -Blokzincirler genellikle kullanıcılar tarafından gönderilen işlemleri işleyerek çalışır. Bu işlemler genellikle blokzincirin gerçekleştirmesi için bazı hesaplamaları tetikler. - -Blokzincirin güven gerektirmemesi (yani bireysel bir tarafa güvenmeye bağlı olmaması) için ağdaki katılımcıların işlemlerin geçerli olduğunu ve sonuçta ortaya çıkan hesaplamaların doğru şekilde yapıldığını doğrulaması gerekir. - -İşlemin geçerli olduğunu doğrulamak için genellikle dijital imza doğrulaması gerekir; bu, işlemin bildirilen göndericisinin gerçekten işlemin yazarı olduğunu doğrular. Bir işlemin hesaplamasının doğru bir şekilde gerçekleştirildiğinin doğrulanması genellikle işlemin yerel olarak yeniden yürütülmesini gerektirir. - -## Doğrulanabilirliğe İlişkin Sınırlamalar - -Her bir işlemi doğrulamaya yönelik bu metodoloji, bir katılımcının hesaplamayı yeniden çalıştıramadığı durumlarda bozulur. Bir katılımcı birkaç nedenden dolayı hesaplamayı yeniden gerçekleştiremeyebilir: (1) belirli verilerin kullanıma sunulmaması gerekebilir (gizlilik nedenleriyle) veya (2) belirli bir veri için çok pahalı olabilir. Katılımcı bilgisayarın tüm işlemleri yeniden yürütmesi - bu ikinci neden, özellikle saniyede çok sayıda işlem gerçekleştiren yüksek verimli blokzincirler söz konusu olduğunda geçerlidir. - -## Zero Knowledge Kanıtlarının Gücü - -Zero knowledge kanıtları (ZKP'ler) bu sınırlamaların üstesinden gelme gücüne sahiptir. - -ZKP'ler, (1) hesaplamada kullanılan hassas verilerin gizliliğini korurken ve (2) doğrulamanın, hesaplamanın yeniden yürütülmesinden önemli ölçüde daha ucuz olmasını sağlayarak katılımcıların bir hesaplamanın sonuçlarını doğrulamasına olanak tanır. ZKP'lerin bu iki özelliğine sırasıyla **zero knowledge** ve **özlülük** denir. - -ZKP'lerin yukarıdaki özellikleri, güven gerektirmeyen blokzincirlerin doğrulanabilirliği bağlamında son derece faydalıdır. ZKP'ler olmadan katılımcıların her işlemin sonuç hesaplamasını yeniden yürütmesi gerekir. Bu, tüm katılımcıların her hesaplamada kullanılan tüm (potansiyel olarak hassas) verileri görmesini gerektirir ve aynı zamanda tüm sistemin verimini de sınırlar. ZKP'lerle bir taraf hesaplamayı gerçekleştirebilir ve ardından hesaplamanın doğru yapıldığına dair bir kanıt oluşturabilir. Diğer katılımcılar, hesaplamayı kendileri yeniden yürütmek yerine, _kanıtın geçerli olduğunu doğrulayarak_ hesaplamanın doğru şekilde yapıldığını doğrulayabilirler. Kanıtın doğrulanması (1) orijinal hesaplamada kullanılan hassas veriler hakkında bilgi sızdırmaz ve (2) hesaplama açısından orijinal hesaplamanın tekrar gerçekleştirilmesinden büyük oranda daha ucuzdur. Bu iki özellik, güven gerektirmeyen blokzincirler için gizlilik ve ölçeklenebilirlik sağlama potansiyeline sahiptir. - -## Devreler, Kanıtlar ve Doğrulayıcılar - -Pratikte ZKP'lerin bir sisteme uygulanması oldukça karmaşık olabilir, ancak yüksek düzeyde zero knowledge kanıtlarının birkaç bileşene sahip olduğunu anlamak isteyeceksiniz: bir devre, bir kanıt ve bir doğrulayıcı. - -Devre, giriş verilerini alan ve giriş verilerinin karşılaması gereken bazı "kısıtlamalara" göre giriş verilerinin geçerli olduğunu ileri süren bir programdır. Giriş verileri genel (herkes tarafından bilinir), özel (yalnızca kanıtlayan tarafından bilinir) veya karışık (bazı girişler genel, bazıları özel) olabilir. - -Bir girişin devreyi karşıladığını iddia eden bir kanıt üretilebilir. Kanıt, özel girdiler hakkında hiçbir bilgi ortaya çıkarmaz ve boyutu oldukça küçüktür. - -Doğrulayıcı, (1) kanıtın geçerli olup olmadığını, (2) kanıtın devre tarafından ortaya konan kısıtlamalarla eşleştiğini (ve sadece sahte bir kanıt olmadığını) ve (3) kanıtı oluşturmak için kullanılan genel girdilerin denetleyici tarafından kullanılanlarla eşleştiğini kontrol edebilir. Kanıt, doğrulayıcı tarafından kullanılanlarla eşleşir. Doğrulayıcı tarafından gerçekleştirilen bu kontrolün genellikle ucuz bir hesaplama olduğunu unutmayın. - - - -### Devreler, Kanıt ve Doğrulayıcılar — bir örnek - -Örnek olarak Sudoku'yu ele alalım. Diyelim ki bir Sudoku bulmacası var ve Alice Bob'a bulmacanın çözümünü bildiğini kanıtlamak istiyor ancak çözümün ne olduğunu açıklamak istemiyor. - -Bu durumda, söz konusu bulmaca genel bir girdi olacaktır (hem Alice hem de Bob bunu biliyor) ve çözüm de özel bir girdi olacaktır (Alice bunu biliyor ancak bunu Bob'tan gizli tutacak). **Devre** bu girdilerin her ikisini de alır ve çözümü standart yöntemle, satır satır, sütun sütun vb. kontrol ederek çözümün doğru olduğunu iddia eder. Bu devre, özel girdi çözümünün gerçekten genel girdi bulmacası için geçerli bir çözüm olduğunu "kısıtlar" ve yalnızca çözüm kontrolü geçtiğinde yalnızca "doğrulanır". - -Daha sonra Alice'in belirli bir bulmaca için devreyi karşılayan bir girdiyi (genel girdi) bildiğini belirten bir **kanıt** oluşturulabilir. - -Kanıt, bulmacayla birlikte Bob'a iletilebilir; o da daha sonra kanıtın geçerli olup olmadığını değerlendirmek için Sudoku kontrol devresine karşılık gelen bir **doğrulayıcı** kullanabilir ve böylece Alice gerçekten bulmacanın çözümünü bilir. . İşin kritik tarafı Bob, Alice'in çözümü hakkında herhangi bir bilgi sahibi değil ama yine de Alice'in geçerli bir çözüm bildiğini doğrulayabiliyor! - -## Zero Knowledge Kanıtları ve Blokzincirler - -ZKP'lerdeki son gelişmelerin temel motivasyonlarından biri, bunun blokzincirlere uygulanmasıdır. Merkezi olmayan blokzincirlerin karşılaştığı en önemli zorluklardan ikisi gizlilik ve ölçeklenebilirliktir; tüm veriler halka açıktır ve ağdaki her düğüm, ağdaki her hesaplamayı yeniden çalıştırmak zorundadır. ZKP'ler bu iki zorluğun da çözülmesine yardımcı olabilir. - -Gizliliği koruyan uygulamalar oluşturmak için ZKP'lerin zero knowledge özelliğini kullanan çeşitli projeler olsa da, biz Scroll olarak Ethereum'u ölçeklendirmek için ZKP'lerin yalnızca kısa ve öz özelliğini kullanıyoruz. - -## Scroll ve Zero Knowledge Kanıtları - -Scroll'a güç veren fikir oldukça basit. Peki ya Ethereum'un başka bir versiyonunun tüm hesaplamalarını doğrulamak için bir Ethereum akıllı sözleşmesi kullanabilseydik? Ethereum Sanal Makinesine ("EVM") daha hızlı ve daha ucuz erişim sağlayan başka bir ağ çalıştırabiliriz ve Ethereum'un kendisi de tüm hesaplamaların doğrulanması ve bu diğer ağın EVM kurallarını ihlal etmediğinden emin olmak için gereken güvenliği sağlayacaktır. - -Öğrenme ve Teknoloji bölümlerinin geri kalanı bunun nasıl çalıştığını daha ayrıntılı olarak ele alıyor ancak basit bir düzeyde, zero knowledge'ın bir devre, kanıt ve doğrulayıcıya sahip olmaya bağlı olduğunu unutmayın. - -Bizim yapımızda, devre (aslında bir devreler kümesi), zincir durumuna göre girdi işlemlerinin işlenmesi için kabul edilebilir davranışı "kısıtlamak" amacıyla EVM kurallarını kodlar. Bu "zkEVM"yi kullanan bir GPU ağı, işlemleri bir dizi blok için alır ve bir kanıt oluşturur. Ethereum'a dönersek, akıllı bir sözleşme, bir dizi işlem için bu kanıtın akıllı sözleşmede yer alan devreyle eşleştiğini doğrular. Eğer öyleyse, bu işlemler "kesinleşmiş" olarak değerlendirilebilir, ağ ileriye doğru hareket eder ve biz de Ethereum'u büyütmek için hızlı, güvenli ve uygun fiyatlı blok alanı yaratmış oluruz. \ No newline at end of file diff --git a/src/content/docs/tr/learn/zero-knowledge/kzg-commitment-scheme.md b/src/content/docs/tr/learn/zero-knowledge/kzg-commitment-scheme.md deleted file mode 100644 index 4ecd927ce..000000000 --- a/src/content/docs/tr/learn/zero-knowledge/kzg-commitment-scheme.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -section: learn -date: Last Modified -title: "KZG Taahhüt Şeması" -lang: "tr" -permalink: "learn/zero-knowledge/kzg-commitment-scheme" -excerpt: "KZG, Ethereum'un Proto-Danksharding'inde kullanılır ve ayrıca Scroll'un kanıt sisteminde de kullanılır. Bu makale KZG taahhüt planına genel bir bakış sunacaktır." -whatsnext: { "Ek Kaynaklar": "/tr/learn/zero-knowledge/additional-zk-learning-resources" } ---- - -En yaygın kullanılan polinom taahhüt planlarından biri KZG taahhüt şemasıdır. Plan ilk olarak 2010 yılında Kate, Zaverucha ve Goldberg tarafından [yayınlanmıştır](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf). - -KZG, Ethereum'un [Proto-Danksharding'inde](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) ve ayrıca Scroll'un kanıt sisteminde kullanılır. - -Bu makale KZG taahhüt planına genel bir bakış sunacaktır. - -## Ön bilgiler ve notasyon - -Polinom taahhüt şemalarının önermesini hatırlayın. Taahhüt etmek istediğimiz bazı $P(x)$ polinomumuz var. Polinomun derecesinin $l$'dan küçük olduğunu varsayacağız. - -KZG taahhütleri [eliptik eğri eşleştirmelerine](https://vitalik.ca/general/2017/01/14/exploring_ecp.html) dayanmaktadır. $\mathbb{G}_1$ ve $\mathbb{G}_2$ $p$ düzeyinde iki eliptik eğri grubu olsun ve önemsiz olmayan bir [çift doğrusal eşleme](https://en.wikipedia.org/wiki/Bilinear_map) olsun. $e: \mathbb{G}_1 \times \mathbb{G}_2 \rightarrow \mathbb{G}_T$. $g$, $\mathbb{G}_1$ oluşturucusu olsun ve $h$, $\mathbb{G}_2$ oluşturucusu olsun. $[x]_1 := x \cdot g$ ve $[x]_2 := x \cdot h$ gösterimini kullanacağız, burada $x \in \mathbb{F}_p$. - -## 1. Güvenilir kurulum - -Herhangi bir KZG taahhüdünü hesaplamadan önce tek seferlik güvenilir kurulum gerçekleştirilmelidir. Güvenilir kurulum tamamlandıktan sonra, istenildiği kadar farklı polinomun kaydedilmesi ve ortaya çıkarılması için yeniden kullanılabilir. Güvenilir kurulum şu şekilde çalışır: - -- Rastgele bir alan öğesi seçin $\tau \in \mathbb{F}_p$ -- $l \in \mathbb{Z}$ taahhüt etmek istediğimiz polinomların maksimum derecesi olsun - - Güvenilir kurulum yalnızca $\leq l$ derecesindeki polinomlara yönelik taahhütleri etkinleştirir -- $([\tau^0]_1,[\tau^1]_1,[\tau^{2}]_1\ldots,[\tau^{l}]_1)$ ve $([\tau]_2)$ hesaplayın ve bu değerleri herkese açık olarak yayınlayın. - -$\tau$'ın açıklanmaması gerektiğini unutmayın; bu, kurulumun gizli bir parametresidir ve güvenilir kurulum töreni tamamlandıktan sonra kimsenin değerini anlayamaması için atılmalıdır. - -[Çok taraflı hesaplamayı](https://en.wikipedia.org/wiki/Secure_multi-party_computation) (MPC) kullanarak, zayıf güven varsayımlarıyla (N'den 1'i güven varsayımı) güvenilir kurulum törenleri yürütmenin yerleşik yöntemleri vardır. Güvenilir kurulumların nasıl çalıştığı hakkında daha fazla bilgi için Vitalik'in bu [yazısına](https://vitalik.ca/general/2022/03/14/trustedsetup.html) bakın. - -## 2. Bir polinoma bağlı kalmak - -- Bir $P(x) = \sum_{i=0}^{l} p_i x^i$ polinomu verildiğinde -- Taahhüdü hesaplayın ve çıktısını alın $c = [P(\tau)]_1$ - - Her ne kadar taahhüt eden $P(\tau)$'ı doğrudan hesaplayamasa da ($\tau$'ı bilmediğinden), güvenilir kurulumun çıktısını kullanarak bunu hesaplayabilir: - - $[P(\tau)]_1 = [\sum_{i=0}^{l} p*i \tau^i]\_1 = \sum*{i=0}^{l} p_i [\tau^i]\_1$ - -## 3. Bir değerlendirmeyi kanıtlayın - -- Bir değerlendirme verildiğinde $P(a) = b$ -- $\pi = [Q(\tau)]_1$ kanıtını hesaplayın ve çıktısını alın - - Burada $Q(x) := \frac{P(x)-b}{x-a}$ - - Buna “bölüm polinomu” denir. Böyle bir $Q(x)$'ın ancak ve ancak $P(a) = b$ olması durumunda var olduğuna dikkat edin. Dolayısıyla bu bölüm polinomunun varlığı değerlendirmenin bir kanıtıdır. - -## 4. Değerlendirme kanıtını doğrulayın - -- $c = [P(\tau)]_1$ taahhüdü, $P(a) = b$ değerlendirmesi ve $\pi = [Q(\tau)]_1$ kanıtı verildiğinde -- $e(\pi, [\tau - a]_2) = e(c - [b]_1, h)$ olduğunu doğrulayın - - Bazı cebir çalışmaları bunun, bölüm polinomunun $\tau$'da doğru şekilde oluşturulduğunu kontrol etmeye eşdeğer olduğunu gösterir: $Q(\tau) = \frac{P(\tau) -b}{\tau-a}$ - $$ - \begin{align*} - & e(\pi, [\tau - a]_2) = e(c - [b]_1, h) \\ \iff - & e([Q(\tau)]_1, [\tau -a]_2) = e([P(\tau)]_1 - [b]_1, h) \\ \iff - & Q(\tau) \cdot (\tau - a) \cdot e(g, h) = (P(\tau)-b) \cdot e(g,h) \\ \iff - & Q(\tau) \cdot (\tau -a) = P(\tau) - b - \end{align*} - $$ - - Çift doğrusal eşleme $e$, gizli kurulum parametresi $\tau$'ı bilmeden bu özelliği kontrol etmemizi sağlar. -- Bu doğrulama tamamlandıktan sonra, bölüm polinomunun doğru şekilde oluşturulduğu ve dolayısıyla değerlendirmenin (çok yüksek olasılıkla) doğru olduğu sonucuna varabiliriz. - -## Daha fazla bilgi edin - -- [https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html) -- [https://alinush.github.io/2020/05/06/kzg-polynomial-commitments.html](https://alinush.github.io/2020/05/06/kzg-polynomial-commitments.html) -- [https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf) diff --git a/src/content/docs/tr/learn/zero-knowledge/polynomial-commitment-schemes.md b/src/content/docs/tr/learn/zero-knowledge/polynomial-commitment-schemes.md deleted file mode 100644 index 54523a174..000000000 --- a/src/content/docs/tr/learn/zero-knowledge/polynomial-commitment-schemes.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Polinom Taahhüt Şemaları" -lang: "tr" -permalink: "learn/zero-knowledge/polynomial-commitment-schemes" -excerpt: "Polinom taahhüt şemaları zero knowledge kanıt sisteminin temel yapı taşıdır" -whatsnext: { "KZG Taahhüt Şeması": "/tr/learn/zero-knowledge/kzg-commitment-scheme" } ---- - -Polinom taahhüt şemaları, zero knowledge kanıtlama sistemlerinin (ve diğer şifreleme protokollerinin) temel yapı taşıdır. - -Adından da anlaşılacağı gibi polinom taahhüt şemaları, taahhüt edilecek nesnenin bir polinom olduğu taahhüt şemalarıdır. Bu şemaların ayrıca polinomun değerlendirmesinin yalnızca polinomun taahhüdüne erişimle doğrulanabileceği özel bir özelliği vardır. - -## Taahhüt planları - -**[Taahhüt şeması](https://en.wikipedia.org/wiki/Commitment_scheme)** iki tarafı içeren bir kriptografik ilkeldir: _committer_ ve _verifier_. Taahhüt eden kişi, $c$ taahhüdünü hesaplayıp bunu doğrulayıcıya açıklayarak $v$ değerini taahhüt eder. Daha sonraki bir zamanda taahhüt eden kişi orijinal değeri ortaya çıkarabilir ve doğrulayıcı da taahhüdün bu açıklanan değere karşılık geldiğini doğrulayabilir. - -Güvenli taahhüt planlarının iki özelliği vardır: - -1. **Bağlayıcı olma**: $c$ taahhüdünü yayınladıktan sonra, taahhüt eden kişi $v$'den farklı olan ve aynı zamanda $c$'ye karşılık gelen başka bir $v'$ değeri bulamamalıdır. Yani, $c$ taahhüdü, taahhüt edeni orijinal $v$ değerine bağlar. -2. **Gizleme**: Doğrulayıcı, $c$ taahhüdünden orijinal $v$ değeri hakkında herhangi bir bilgi öğrenememelidir. Yani, $c$ taahhüdü, orijinal $v$ değeri hakkındaki tüm bilgileri gizler. - -## Polinom taahhüt şemaları - -**Polinom taahhüt şeması**, taahhüt eden kişinin $c$ taahhüdünü hesaplayarak $P(x)$ polinomunu taahhüt ettiği bir taahhüt şemasıdır. Normal taahhüt planlarında olduğu gibi, taahhüt eden kişi daha sonra orijinal polinomu ortaya çıkarabilir ve doğrulayıcı, taahhüdün ortaya çıkan polinoma karşılık gelip gelmediğini kontrol edebilir. Bununla birlikte, polinom taahhüt şemalarının ek bir özelliği vardır: taahhüt eden, polinomun kendisini açıklamadan taahhüt edilen polinomun belirli değerlendirmelerini kanıtlayabilir. Örneğin, taahhüt eden $P(a) = b$ olduğunu kanıtlayabilir ve doğrulayıcı böyle bir kanıtı yalnızca $c$ taahhüdünü kullanarak doğrulayabilir. - -Polinom taahhüt şemaları zero knowledge uygulamaları için son derece faydalıdır. Bir kanıtlayıcı, temeldeki polinomu açıklamadan, belirli özellikleri (örneğin, belirli bir $(a,b)$ noktasından geçtiğini) karşılayan bazı polinomları bildiğini kanıtlamak için böyle bir şema kullanabilir. - -Polinom şemalarının faydalı olmasının bir başka nedeni de, $c$ taahhüdünün genellikle temsil ettiği polinomdan çok daha küçük olmasıdır ve dolayısıyla $P(x)$ polinomunun **sıkıştırılması** olarak düşünülebilir. Sıkıştırmanın büyüklüğü özel şemaya bağlıdır. Örneğin, KZG polinom taahhüt şemasında, keyfi derecede büyük dereceli bir polinom, tek bir grup elemanından oluşan bir taahhüt halinde sıkıştırılabilir. - -## Daha fazla bilgi edin - -- [https://en.wikipedia.org/wiki/Commitment_scheme](https://en.wikipedia.org/wiki/Commitment_scheme) -- [https://learn.0xparc.org/materials/halo2/miscellaneous/polynomial-commitment](https://learn.0xparc.org/materials/halo2/miscellaneous/polynomial-commitment) diff --git a/src/content/docs/tr/user-guide/_images/bridge1.png b/src/content/docs/tr/user-guide/_images/bridge1.png deleted file mode 100644 index dd552310e..000000000 Binary files a/src/content/docs/tr/user-guide/_images/bridge1.png and /dev/null differ diff --git a/src/content/docs/tr/user-guide/_images/bridge2.png b/src/content/docs/tr/user-guide/_images/bridge2.png deleted file mode 100644 index e3fe4701f..000000000 Binary files a/src/content/docs/tr/user-guide/_images/bridge2.png and /dev/null differ diff --git a/src/content/docs/tr/user-guide/_images/bridge3.png b/src/content/docs/tr/user-guide/_images/bridge3.png deleted file mode 100644 index 03772fee9..000000000 Binary files a/src/content/docs/tr/user-guide/_images/bridge3.png and /dev/null differ diff --git a/src/content/docs/tr/user-guide/_images/bridge4.png b/src/content/docs/tr/user-guide/_images/bridge4.png deleted file mode 100644 index a060b2ce3..000000000 Binary files a/src/content/docs/tr/user-guide/_images/bridge4.png and /dev/null differ diff --git a/src/content/docs/tr/user-guide/_images/bridge5.png b/src/content/docs/tr/user-guide/_images/bridge5.png deleted file mode 100644 index 7e75aeb4d..000000000 Binary files a/src/content/docs/tr/user-guide/_images/bridge5.png and /dev/null differ diff --git a/src/content/docs/tr/user-guide/_images/bridge6.png b/src/content/docs/tr/user-guide/_images/bridge6.png deleted file mode 100644 index 80066a330..000000000 Binary files a/src/content/docs/tr/user-guide/_images/bridge6.png and /dev/null differ diff --git a/src/content/docs/tr/user-guide/_images/bridge7.png b/src/content/docs/tr/user-guide/_images/bridge7.png deleted file mode 100644 index 66ee3ff94..000000000 Binary files a/src/content/docs/tr/user-guide/_images/bridge7.png and /dev/null differ diff --git a/src/content/docs/tr/user-guide/_images/bridge8.png b/src/content/docs/tr/user-guide/_images/bridge8.png deleted file mode 100644 index 4b78a8b9e..000000000 Binary files a/src/content/docs/tr/user-guide/_images/bridge8.png and /dev/null differ diff --git a/src/content/docs/tr/user-guide/bridge.mdx b/src/content/docs/tr/user-guide/bridge.mdx deleted file mode 100644 index dafaeef7c..000000000 --- a/src/content/docs/tr/user-guide/bridge.mdx +++ /dev/null @@ -1,124 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Köprü" -lang: "tr" -permalink: "user-guide/bridge/" -excerpt: "Sepolia'dan varlıkları köprülemeye başlamak için Portal Bridge uygulamasına gidin." ---- - -{/* // import ClickToZoom from "../../../../components/ClickToZoom.astro" */} -{/* // import bridge1 from "./\_images/bridge1.png" */} -{/* // import bridge2 from "./\_images/bridge2.png" */} -{/* // import bridge3 from "./\_images/bridge3.png" */} -{/* // import bridge4 from "./\_images/bridge4.png" */} -{/* // import bridge5 from "./\_images/bridge5.png" */} -{/* // import bridge6 from "./\_images/bridge6.png" */} -{/* // import bridge7 from "./\_images/bridge7.png" */} -{/* // import bridge8 from "./\_images/bridge8.png" */} - -{/* TODO: Update all instructions after being able to walk through the whole flow. */} - -Başlamak için [Köprü](https://sepolia.scroll.io/bridge) uygulamamızı ziyaret edin![^thanks-hop] Köprü, varlık **Yatırma** ve **Çekme** işlemlerini destekler ve kullanıcılara Sepolia Test Ağı'ndan Scroll Sepolia Test Ağı'na varlıkları güvenle taşıma imkanı sunar. -[^thanks-hop]: [Hop Exchange](https://hop.exchange/)’in kullanıcı arayüzünden forklanmıştır 🙌 - -Yatırılan varlıkların Scroll üzerinde kullanılabilir hale gelmesi 15 dakikaya kadar sürebilir. - -Varlık çekme işlemleri, çekim işlemi tamamlandıktan sonra Sepolia'da ikinci bir ek etkileşim gerektirmesinden dolayı çok daha uzun sürebilir. - -:::caution[Köprü işlemi için uzun süredir bekliyor musunuz?] -Yukarıdaki zaman tahminleri, normal ağ davranışı ve etkinlik seviyeleri içindir. Bir L2 bloğunda, yalnızca belirli sayıda sıralanmış L1 işlemini işlediğimizden, köprülenmiş mesajların Scroll’a dahil edilmesi, istisnai ağ kullanım durumlarında daha uzun sürebilir. -::: - -## Sepolia'dan Scroll Sepolia'ya Yatırma - -### Talimatlar - -1. İlk olarak, [Scroll Köprüsü'ne](https://sepolia.scroll.io/bridge) gidin ve "Cüzdanı Bağla" düğmesine basın. -1. Uygulamada, **Ethereum Sepolia**'nın en üstte ve **Scroll Sepolia**'nın en altta olduğundan emin olun. Pozisyonlarını değiştirmek için "**↓**" düğmesine tıklayabilirsiniz. -1. Sepolia'dan Scroll Sepolia'ya transfer etmek istediğiniz tokenı seçin. İlk kez köprü kullanıyorsanız, "ETH"yi deneyin. -1. Eğer belirli bir ERC20 tokenını ilk kez transfer ediyorsanız, Sepolia Köprü sözleşmesine ERC20 tokenınıza erişim izni vermek için **Onayla**'yı seçmelisiniz. -1. Ardından, yatırma işlemi yapmak için **Scroll Sepolia'ya Gönder** düğmesine tıklayın. Cüzdanınız transfer işlemini onaylamanızı isteyecektir. -1. Transfer işlemi gönderildikten ve onaylandıktan sonra, token Sepolia cüzdanınızdan düşecektir. -1. Bir işlemin durumunu her zaman sağ üst köşede cüzdan adresinizin yanındaki "Geçmiş" simgesine basarak kontrol edebilirsiniz. - -### Tokenlarınız Scroll Sepolia cüzdanınıza ne zaman ulaşır? - -Tokenlarınızın Scroll Sepolia cüzdanınıza gelmesi **8 ile 14 dakika** arasında sürebilir. (Sepolia'da [_Güvenli_](https://www.alchemy.com/overviews/ethereum-commitment-levels#what-are-ethereum-commitment-levels) duruma gelmesi bekleniyor). - -{/* You can check the progress of deposit transactions as follows: */} - -{/* ##### 1. Click the "History" icon next to your wallet address in the top-right corner. */} - -{/* */} - -{/* The pop-up panel lists the most recent transactions made in the Bridge app. There are two statuses: Sepolia status and Scroll Sepolia status. For deposit transactions (L1 -> L2), once your transaction becomes _Safe_ on Sepolia (**8 to 14 minutes**), you will see the **`success`** status shown. Your funds will be relayed to Scoll Sepolia after this. */} - -{/* The Recent Bridge Transactions window should give you an estimate of the time expected before your transaction is _Safe_ on Sepolia. */} - -{/* ##### 2. Click on the most recent transaction’s Sepolia transaction hash. */} - -{/* */} - -{/* It will open the Transaction Details page in a new tab. You can see this transaction is confirmed on Sepolia. To check the Block's confirmation status, click the Block number and read the "Status" field. */} - -{/* */} - -{/* ##### 3. Return to the Bridge app and wait! */} - -{/* Once your transaction status shows **`success`** on Scroll Sepolia, you should see the funds in your Scroll L2 wallet and a transaction hash: */} - -{/* */} - -## Scroll Sepolia'dan Sepolia'ya Varlık Çekme - -### Talimatlar - -#### İlk Çekim İşleminizi Gönderme - -1. İlk olarak, cüzdanınızda **Scroll Sepolia** Ağı'na geçin. -1. Uygulamada, **Scroll Sepolia**'nın en üstte ve **Ethereum Sepolia**'nın en altta olduğundan emin olun. Pozisyonlarını değiştirmek için "**↓**" butonuna tıklayabilirsiniz. -1. **Scroll Sepolia**'dan **Sepolia**'ya aktarmak istediğiniz tokenı seçin. İlk kez köprü kullanıyorsanız, "ETH"yi deneyin. -1. Eğer belirli bir ERC20 tokenını ilk kez transfer ediyorsanız, Scroll Sepolia Köprü sözleşmesine ERC20 tokenınıza erişim izni vermek için **Onayla**'yı seçmelisiniz. -1. Ardından, varlık çekme işlemi yapmak için **Ethereum Sepolia'ya Gönder** düğmesine tıklayın. Cüzdanınız transfer işlemini onaylamanızı isteyecektir. -1. Transfer işlemi gönderildikten ve onaylandıktan sonra, token Scroll Sepolia cüzdanınızdan düşecektir. - -#### Çekim Gerçekleştirme İşlemi Göndermek - -_Kalan adımlar Scroll Sepolia'da gerçekleşiyor, ama işleminizin Ethereum Sepolia'da tamamen kanıtlanması ("kesinleşmesi") beklenmelidir. Bu süreç en fazla dört saat sürebilir._ - -1. Varlık çekme işleminiz Ethereum Sepolia'da tamamlandığında, Son İşlemler alanındaki "Talep Et" butonunun sabit hale geldiğini göreceksiniz. -1. "Talep Et" düğmesine tıklayarak Çekim Gerçekleştirme işlemini gönderin. -1. Gönderildikten sonra, çekilen fonlarınız Sepolia cüzdanınızda hemen görünmelidir. - -### Tokenlarınız ne zaman Sepolia cüzdanınıza ulaşır? - -Transfer edilen token, Çekim Gerçekleştirme işlemi Sepolia'da onaylandıktan hemen sonra Sepolia cüzdanınıza ulaşacaktır. - -{/* TODO: check architecture link is live */} - -:::tip[Rollup Durumu] -Rollup durumu `Kesinleştirildi`, bu bloktaki işlemlerin doğru bir şekilde yürütülmesinin Sepolia üzerinde bir geçerlilik kanıtının doğrulanmasıyla kanıtlandığını belirtir. Rollup durumu hakkında daha fazla bilgi için [Scroll Mimarisine Genel Bakış](/tr/technology)'a bakın. -::: - -{/* You can check the progress of withdrawal transactions as follows: */} - -{/* 1. Click your wallet address at the top-right corner of the Bridge web app. */} - -{/* */} - -{/* The pop-up panel lists the most recent transactions you made in the Bridge app (see the image below). There are two statuses: L1 status and L2 status. In this case, because we are bridging from L2 -> L1, we will quickly get a **`success`** status after submitting the transaction to the L2 Bridge. L1, on the other hand, takes **10 minutes to a few hours** to reach **`success`**. */} - -{/* 1. Click on the most recent transaction’s L2 transaction hash: */} - -{/* */} - -{/* It will open the _Transaction Details_ page in a new tab. You can see this transaction is confirmed on L2. */} - -{/* */} - -{/* The transaction is confirmed on L2, but still needs to be finalized on Goerli. */} - -{/* 1. Go back to the [Bridge](https://scroll.io/bridge) app. It takes about 10 minutes before the token shows up in your Goerli wallet. Once your transaction status shows success on L2, you should see the funds in your Goerli wallet and a transaction hash: */} - -{/* */} diff --git a/src/content/docs/tr/user-guide/common-errors.mdx b/src/content/docs/tr/user-guide/common-errors.mdx deleted file mode 100644 index 42285c7f5..000000000 --- a/src/content/docs/tr/user-guide/common-errors.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Yaygın Hatalar" -lang: "tr" -permalink: "user-guide/common-errors/" -excerpt: "Scroll Sepolia Test Ağı ile etkileşim kurmaya çalışırken bir hata mı görüyorsunuz? İşte bazı yaygın yapılandırma hataları ve bunları hızlıca nasıl düzeltebileceğiniz hakkında bilgiler." ---- - -## MetaMask'te işlem gönderirken yanlış nonce hatası - -MetaMask cüzdanınızda depolanan yerel nonce, Scroll Test Ağı düğümündeki nonce'tan farklı olduğunda bu hatayla karşılaşırsınız. Bunun nedeni yakın zamanda bekleyen bir işleminiz olması olabilir. - -Bu sorunu düzeltmek için MetaMask hesabınızı Scroll Sepolia Test Ağı için sıfırlamanız gerekir. Hesabı sıfırlamak için izlenmesi gereken adımlar şunlardır: - -1. Tarayıcıda **MetaMask** uzantısını açın -2. Üst bölgede **Scroll Sepolia Test Ağı'nı** seçin -3. Sağ üst köşedeki yuvarlak **hesap simgesine** tıklayın -4. **Ayarlar**'ı seçin -5. **Gelişmiş** bölümüne gidin -6. **Hesabı sıfırla**'ya tıklayın - -MetaMask hesabınızı sıfırlarken hiçbir varlık kaybolmaz. - -:::caution[Caution] -Bir ağı kaldırmak ve yeniden eklemek bu sorunu düzeltmek için YETERLİ DEĞİLDİR - hesabınızı sıfırlamanız gerekir. -::: - -## Köprüleme/değiştirme işlemi onaylandığında hiçbir şey olmuyor ise - -Eğer hata veya konsol kayıtları görünmüyorsa, büyük olasılıkla bir nonce sorunu vardır. Lütfen MetaMask hesabınızı yukarıda belirtilen şekilde [sıfırlayın](/tr/user-guide/common-errors). - -## Blok Gezgini "Dahili sunucu hatası" gösteriyor - -Bir gizli pencere kullanın veya tarayıcıdan geliştirici konsolunu açıp `_explorer_key` çerezini (veya tüm çerezleri) kaldırın. [Çerezlerin nasıl kaldırılacağı hakkında bu kılavuzu inceleyin.](https://www.contentstack.com/docs/developers/how-to-guides/clear-caches-and-cookies-in-different-browsers/). - -## MetaMask'te maksimum Ether gönderme "Başarısız" hatası veriyor - -MetaMask kullanarak Ether gönderirken, "Maksimum" miktarı göndermeyi denerseniz, "Başarısız" hatasıyla sonuçlanacaktır. Bunun nedeni, MetaMask'ın, rollup'ların normal gaz ücretlerinin yanı sıra ek "L1 Ücreti"ni hesaba katmaması ve işlemin gazını ödemek için gereken küçük bir miktarın yetersiz kalmasıdır. - -Bunu çözmek için, ether miktarını önerilenden biraz daha az olacak şekilde manuel olarak azaltın; işlem gerçekleşecektir. diff --git a/src/content/docs/tr/user-guide/faucet.mdx b/src/content/docs/tr/user-guide/faucet.mdx deleted file mode 100644 index dab58c598..000000000 --- a/src/content/docs/tr/user-guide/faucet.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Musluk" -lang: "tr" -permalink: "user-guide/faucet/" -whatsnext: { "ETH'nizi Scroll Sepolia'ya köprüleyin": "/tr/user-guide/bridge" } -excerpt: "Test ağımızla etkileşimde bulunmak için öncelikle Sepolia ETH elde etmeniz gerekiyor. Başlamak için birkaç Sepolia musluk uygulaması bulunmaktadır." ---- - -Test ağımız ile etkileşimde bulunmak için öncelikle _Sepolia Test Ağı'nda_ test ağı ETH'i almanız gerekmektedir. Daha sonra _Sepolia Test Ağı_ üzerinden _Scroll Sepolia Test Ağı'na_ köprüleme yapabilirsiniz. - -## Sepolia Muslukları - -Her musluk kendi kurallarına ve şartlarına sahiptir, bu nedenle işinize yarayacak bir musluk bulana kadar birkaç tanesini denemeniz gerekebilir. - -İşte birkaç Sepolia musluk uygulaması: - -- [https://sepoliafaucet.com](https://sepoliafaucet.com/) -- [https://sepolia-faucet.pk910.de](https://sepolia-faucet.pk910.de) -- [https://faucet.quicknode.com/drip](https://faucet.quicknode.com/drip) -- [https://faucet.chainstack.com](https://faucet.chainstack.com) -- [https://infura.io/faucet/sepolia](https://infura.io/faucet/sepolia) - -Sepolia'da ETH aldıktan sonra, bunları cüzdanınızda _Sepolia Ağı_ üzerinde görmelisiniz. Görünmeleri birkaç saniye sürebilir, ancak [Sepolia Blok Gezgini](https://sepolia.etherscan.io/) üzerinde adresinize yapılan bir işlemi kontrol ederek durumu kontrol edebilirsiniz. - -:::note[Yavaşlayın!] -Çoğu musluk, test tokenları için yalnızca 24 saatte bir talep oluşturmanıza izin verir. -::: - -## Scroll Sepolia Muslukları - -Köprü ile etkileşime geçmek istemiyorsanız, bazı musluklar doğrudan Scroll Sepolia ETH dağıtır. - -- [https://thirdweb.com/scroll-sepolia-testnet](https://thirdweb.com/scroll-sepolia-testnet) -- [https://www.hackquest.io/en/faucets/534351](https://www.hackquest.io/en/faucets/534351) -- [https://scroll.l2scan.co/faucet](https://scroll.l2scan.co/faucet) -- [https://www.covalenthq.com/faucet/](https://www.covalenthq.com/faucet) -- [https://faucet.quicknode.com/scroll/sepolia](https://faucet.quicknode.com/scroll/sepolia) -- [https://bwarelabs.com/faucets/scroll-testnet](https://bwarelabs.com/faucets/scroll-testnet) -- [https://scroll.faucetme.pro](https://scroll.faucetme.pro) diff --git a/src/content/docs/tr/user-guide/index.mdx b/src/content/docs/tr/user-guide/index.mdx deleted file mode 100644 index 5abdb281a..000000000 --- a/src/content/docs/tr/user-guide/index.mdx +++ /dev/null @@ -1,44 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Scroll Sepolia Kullanıcı Kılavuzu" -lang: "tr" -permalink: "user-guide/" -excerpt: "Sepolia Test Ağı'mızı denediğiniz için teşekkür ederiz. Sepolia Ağı, Ethereum Sepolia Test Ağı'nı ve Scroll Sepolia Test Ağı'nı içerir." -whatsnext: { "Cüzdanınızı Kurun": "/tr/user-guide/setup" } ---- - -import Aside from "../../../../components/Aside.astro" - - - -Scroll Sepolia Test Ağı'nı denediğiniz için teşekkür ederiz. Sorularınız varsa veya geri bildirimde bulunmak istiyorsanız, [Discord](https://discord.gg/scroll)'umuza katılın! - -Sepolia Test Ağı, _Ethereum Sepolia Test Ağı_ ve _Scroll Sepolia Test Ağı'ndan_ oluşur. Sepolia, bir Ethereum test ağıdır; Scroll Sepolia ise, bu test ağının üstüne kurulmuş bir zero knowledge rollup(zk rollup) test ağıdır. Önceden dağıtılmış bazı demo uygulamalar bulunmaktadır: _Sepolia_ ile _Scroll Sepolia_ arasında bir [köprü](https://sepolia.scroll.io/bridge),[^1] _Scroll Sepolia_ için bir [blok gezgini](https://sepolia-blockscout.scroll.io/),[^2] ve bir [rollup gezgini](https://sepolia.scroll.io/rollupscan). - -L1 işlemlerini görüntülemek için Etherscan'in [Sepolia gezgini](https://sepolia.etherscan.io/). -L2 işlemlerini görüntülemek için [Scrollscan](https://sepolia.scrollscan.com) veya Scroll'un [Blockscout](https://sepolia-blockscout.scroll.io/)'unu kullanabilirsiniz, ancak ayrıca [Dora](https://www.ondora.xyz/network/scroll-sepolia/interactions) veya [L2Scan](https://scroll-sepolia.l2scan.co/)'in sağladığı ek işlevleri de denemek isteyebilirsiniz. - -Test ağını keşfetmek için önerilen iş akışı aşağıdaki gibidir: - -1. Cüzdanınıza [Sepolia Test Ağı](https://sepolia.scroll.io/portal) yapılandırmalarını ekleyin -2. Herhangi bir Ethereum Musluğu uygulamasından _Sepolia_ ağında test tokenları isteyin. (bkz. [Musluk](/tr/user-guide/faucet) makalesi) -3. _Sepolia_ ile _Scroll Sepolia_ arasında [Köprü](https://sepolia.scroll.io/bridge) uygulaması aracılığıyla test tokenlarını aktarın. -4. Cüzdanınızı kullanarak _Scroll Sepolia_'daki diğer cüzdanlara token aktarın. -5. [Uniswap](https://uniswap-showcase.sepolia.scroll.xyz/) veya [Aave](https://app.aave.com) gibi akıllı sözleşmelerle etkileşimde bulunarak ekosistemimizi keşfedin. -6. _Scroll Sepolia_'dan _Sepolia_'ya tokenları [Köprü](https://sepolia.scroll.io/bridge) uygulaması aracılığıyla çekin. - -Her uygulama için talimatları bu kullanıcı kılavuzunun geri kalanında bulabilirsiniz. - -## Sorular ve Geri Bildirim - -Herhangi bir sorunla karşılaşırsanız, [Discord](https://discord.gg/scroll)'a katılın ve `#general-support` kanalında bizimle konuşun. Ayrıca deneyiminizi nasıl iyileştirebileceğimiz hakkındaki düşüncelerinizi veya geri bildirimlerinizi de duymaktan mutluluk duyarız. - -[^1]: [Hop Exchange](https://hop.exchange/) arayüzünden forklanmıştır 🐇🙌 -[^2]: [Blockscout](https://blockscout.com/)'un harika açık kaynaklı blok gezgini \ No newline at end of file diff --git a/src/content/docs/tr/user-guide/setup.mdx b/src/content/docs/tr/user-guide/setup.mdx deleted file mode 100644 index 2dda51c18..000000000 --- a/src/content/docs/tr/user-guide/setup.mdx +++ /dev/null @@ -1,40 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Kurulum" -lang: "tr" -permalink: "user-guide/setup/" -whatsnext: { "Sepolia ETH'sini bir musluktan alabilirsiniz": "/tr/user-guide/faucet" } -excerpt: "Scroll Test Ağı ile etkileşimde bulunmak için bir cüzdana ihtiyacınız var. Bazı örnek cüzdanlara ve yapılandırma ipuçlarına işte buradan ulaşabilirsiniz." ---- - -import Aside from "../../../../components/Aside.astro" - -## Cüzdan - -Scroll Sepolia Test Ağı'ndaki dApp'lerle etkileşimde bulunmak için bir cüzdana ihtiyacınız olacak. Aşağıda bazı örnek cüzdanları ve yapılandırma ipuçlarını bulabilirsiniz. Köprü uygulamamız MetaMask, Coinbase Wallet veya WalletConnect desteği olan herhangi bir cüzdanı destekler. - -### MetaMask - -MetaMask'i [resmi web sitelerinden](https://metamask.io/download/) indirebilirsiniz. - -Scroll Sepolia Test Ağı yapılandırmalarını MetaMask cüzdanınıza içe aktarabilirsiniz. Bunun için, [Scroll Sepolia portalına](https://sepolia.scroll.io/portal) gidin, ardından "Cüzdanı Bağla" düğmesine tıklayın ve MetaMask'i seçin. Sonraki adımda, Sepolia Test Ağı ve Scroll Sepolia Test Ağı için "MetaMask'e Ekle" düğmelerine tıklayın. Bu işlem, Scroll Sepolia Test Ağı için zincir kimliği ve RPC URL'lerini içe aktaracaktır. Sepolia Test Ağı ayrıca MetaMask'te varsayılan olarak yapılandırılmıştır. Onu göstermek için, MetaMask ağ seçim açılır menüsünde "Test ağlarını göster/gizle" yi tıklayın. - -### Manuel ağ yapılandırması (diğer cüzdanlar için) - -**Cüzdan Ekle** bağlantıları her cüzdanla uyumlu olmayabilir. Bunları kullanırken sorun yaşıyorsanız, _Sepolia Test Ağı_ ve _Scroll Sepolia Ağı'nı_ tablodaki yapılandırma detaylarını manuel olarak eklemeniz gerekebilir: - -| Ağ Adı | Scroll Sepolia Test Ağı | Sepolia Test Ağı | -| ------------------ | ---------------------------------------------------------------- | ---------------------------------------------------------------------------- | -| RPC URL | [https://sepolia-rpc.scroll.io/](https://sepolia-rpc.scroll.io/) | [https://eth-sepolia-public.unifra.io](https://eth-sepolia-public.unifra.io) | -| Zincir Kimliği | 534351 | 11155111 | -| Para Birimi Sembolü| ETH | ETH | -| Blok Gezgini URL'si| [https://sepolia.scrollscan.com](https://sepolia.scrollscan.com) | [https://sepolia.etherscan.io](https://sepolia.etherscan.io) | - - diff --git a/src/content/docs/tr/user-guide/transfer-tokens.md b/src/content/docs/tr/user-guide/transfer-tokens.md deleted file mode 100644 index 854a2cb5b..000000000 --- a/src/content/docs/tr/user-guide/transfer-tokens.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Tokenları Aktar" -lang: "tr" -permalink: "user-guide/transfer-tokens/" -excerpt: "Scroll Sepolia Test Ağı'nda tokenları aktarmak için cüzdanınızı her zamanki gibi kullanabilirsiniz." ---- - -Scroll Sepolia Test Ağı'nda token aktarmak için cüzdanınızın normal işlevini kullanabilirsiniz -- hiçbir ek yapılandırmaya gerek yoktur. - -## MetaMask'te bir token gönderme - -1. Cüzdanınızı açın ve **Scroll Sepolia Test Ağı**'na geçin. -2. Ortadaki **Gönder** düğmesine tıklayın ve metin kutusuna transfer yapmak istediğiniz adresi yazın. -3. **Varlık** kutusunda tokenı seçin ve aktarmak istediğiniz token miktarını yazın. -4. İşlemi göndermek için **İleri** düğmesine ve ardından **Onayla** düğmesine tıklayın. -5. Gönderdikten sonra işlemi cüzdanınızın **Aktivite** sekmesinde bulabilirsiniz. diff --git a/src/content/docs/zh/getting-started/overview.md b/src/content/docs/zh/getting-started/overview.md deleted file mode 100644 index a404cbd45..000000000 --- a/src/content/docs/zh/getting-started/overview.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Scroll概览" -lang: "zh" -permalink: "docs/conceptual-overview/" -excerpt: "ZK Rollups and Scroll" -whatsnext: { "用户指南": "/zh/user-guide/", "在Scroll上开发": "/zh/developers/" } ---- - -#### 欢迎来到 Scroll 的文档 - -Scroll 是以安全为中心的以太坊扩容解决方案，通过设计上的创新和零知识证明在以太坊上构建 Layer2。与以太坊相比，Scroll 网络更易于访问，响应更快，并且可以同时支持更多用户，如果您曾经在以太坊上使用或开发过应用程序，那么您在 Scroll 上开发会和到家了一样感到熟悉和亲切。 - -想试用 Scroll 的 Sepolia 测试网吗？请查看我们的 [用户指南](/zh/user-guide/)。 - -## Scroll 在构建什么? - -Scroll 正在构建扩容以太坊的技术。 - -虽然以太坊是用于为去中心化应用程序提供动力的领先区块链网络，但它的普及也带来了更高的成本，为下一波用户和开发人员的采用创造了障碍。 - -利用零知识证明（zero knowledge proofs,“zk”）的前沿研究，Scroll 正在以太坊上构建二层 Rollup 网络。Scroll 团队通过开源合作的方式，与以太坊社区中的其他人共同创建了“zkEVM”，允许网络上的所有交易活动（就像以太坊一样）通过以太坊上的智能合约进行安全保证。Scroll 网络会将所有交易发布到以太坊，zkEVM 创建并发布加密“证明”，证明 Scroll 网络遵循了以太坊的规则。 - -最终，以太坊智能合约将通过每笔证明验证 Scroll 上的每笔交易都是有效的，为网络提供了难以置信的安全性，去中心化和抗审查性。继承以太坊的这种安全性和可扩展性只有在零知识证明密码学、区块链协议设计和硬件加速方面的最新突破下，才可能实现。 - - - -关于我们架构的详细信息，请参阅[Scroll 架构](/zh/technology/). - -## 现在可以使用 Scroll 吗？ - -Scroll 在以太坊上的主网已经上线！我们还在以太坊 Sepolia 上运行了一个测试网，即 Scroll Sepolia 测试网。 虽然我们有一个 [完整指南](zh//user-guide/), 但如果您熟悉以太坊，您可以在几分钟内就开始使用： - -- 访问我们的 [跨链桥](https://scroll.io/bridge) 或 [Scroll Sepolia 跨链桥](https://sepolia.scroll.io/bridge) 并连接您的钱包。 -- 从以太坊主网发送代币到 Scroll（或使用 Scroll Sepolia 的 [水龙头](/user-guide/faucet)）。 -- 尝试使用 Scroll Sepolia 测试网的 dApp，比如我们的 [Uniswap 展示](http://uniswap-showcase.sepolia.scroll.xyz/) 或者 [Aave](https://app.aave.com/)，只需确保选择了 Scroll Sepolia 网络！ - -## Scroll 的未来方向? - -我们已经在以太坊上发布了我们的主网，但还有更多工作要做，接下来将去中心化堆栈的每个组件。查看 [我们的路线图](https://scroll.io) 或者关注 [我们的 Discord](https://discord.gg/scroll) 或者 [Twitter](https://twitter.com/scroll_zkp)。 diff --git a/src/content/docs/zh/learn/index.mdx b/src/content/docs/zh/learn/index.mdx deleted file mode 100644 index f670971d2..000000000 --- a/src/content/docs/zh/learn/index.mdx +++ /dev/null @@ -1,30 +0,0 @@ ---- -section: learn -title: "学习" -lang: "zh" -permalink: "learn/" -excerpt: "Learn more about Ethereum scalability and zero knowledge cryptography." ---- - -import NavCard from "../../../../components/NavCard.astro" -import TechnologySvg from "../../../../assets/svgs/home/home-technology.svg?raw" -import LearnSvg from "../../../../assets/svgs/home/home-learn.svg?raw" - -Scroll 汇集了区块链协议和零知识证明密码学的研究和工程资料。如果您想更深入地了解，请继续阅读并查看补充资料。 - -想要看到我们覆盖特定的话题吗？快来我们的 Github 仓库中创建 [issue](https://github.com/scroll-tech/scroll-documentation/issues/new?assignees=&labels=new+content%2Ctriage&projects=&template=new_content.yml&title=%5BNew+Content%5D%3A+%3Cyour-title-here%3E)。 - -
- - -
diff --git a/src/content/docs/zh/learn/intro-to-rollups.md b/src/content/docs/zh/learn/intro-to-rollups.md deleted file mode 100644 index 3178e2f01..000000000 --- a/src/content/docs/zh/learn/intro-to-rollups.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -section: learn -date: Last Modified -title: "Rollups 介绍" -lang: "zh" -permalink: "learn/intro-to-rollups" -excerpt: "Rollups are the most predominant layer 2 scaling solution in the Ethereum ecosystem." -whatsnext: { "Scroll Rollup Process": "/zh/technology/chain/rollup" } ---- - -## 什么是 rollup? - -Rollups 是以太坊生态系统中最主要的 L2 扩容解决方案，被视为以太坊路线图的 [核心部分](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698)。 - -Rollup 在链下（即不在 L1 ）处理交易的批次，然后将结果数据发布到链上（即在 L1）。 - -每笔交易的执行都是在链下执行的，不需要在 L1 节点上重新执行。这可以大幅提高交易的吞吐量，而不会影响 L1 的去中心化。 - -为了确保 rollup 的安全，它必须证明其链下计算（交易处理）已经正确执行。证明链下计算有效性的机制主要有两种：有效性证明和欺诈证明。 - -## 什么是 optimistic rollup? - -Optimistic rollup 是使用欺诈证明来确保其计算有效性的 rollup。 - -欺诈证明机制下，允许用户挑战和证明在 L2 上执行的任何计算是无效的。如果成功提交欺诈证明，则可以将 L2 回滚到之前的状态，从而更正无效的计算。欺诈证明基于至少有一个诚实的一方在检查 L2 交易是否正确执行。 - -## 什么是 ZK rollup? - -ZK rollup 是使用有效性证明来确保其计算有效性的 rollup。 - -当 ZK rollup 执行交易的批次并将结果状态发布到 L1 时，它还会发布有效性证明。这个数学证明，可以证明结果状态确实是正确执行一批交易后所生成的状态。 - -如今，有多种类型的 ZK rollup，广义上定义为 zkVM（零知识虚拟机）或 zkEVM（零知识以太坊虚拟机）。 - -zkVM 从头开始设计，可与 ZK 电路很好地配合使用，并且与 zkEVM 相比，需要完全不同的开发工作流程。其中的例子包括 Starkware 和 Aztec。 - -zkEVM 旨在模拟 EVM。zkEVM 主要有两种类型：字节码层面兼容和语言层面兼容。字节码兼容的 zkEVM 在非常低的水平上模拟 EVM，与以太坊 L1 相比，可实现几乎相同的开发和用户体验。语言层面兼容的 zkEVM 将 Solidity 和其他高级语言编译为不同的字节码，这可能会导致工作流程发生变化。zkSync 是最流行的语言层面兼容的 zkEVM。 - -Scroll 是字节码兼容的。之所以选择这种方案，是因为它带来了如下好处： - -- Solidity, Vyper 和 Huff 开箱即用 -- 无需重新进行合约审计 -- 继承大多数现有工具 -- 与以太坊几乎相同的用户体验和开发者体验 - -有关 Scroll 方案的更多详细信息，请参阅“技术”部分。 - -## 延伸阅读 - -- [Rollups 的不完全指南](https://vitalik.ca/general/2021/01/05/rollup.html) - Vitalik Buterin -- [扩容](https://ethereum.org/en/developers/docs/scaling/) - 以太坊文档 diff --git a/src/content/docs/zh/learn/the-scalability-problem.md b/src/content/docs/zh/learn/the-scalability-problem.md deleted file mode 100644 index 263b41473..000000000 --- a/src/content/docs/zh/learn/the-scalability-problem.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -section: learn -date: Last Modified -title: "扩容问题" -lang: "zh" -permalink: "learn/intro-to-rollups" -excerpt: "以太坊强大的去中心化和安全性是以牺牲可扩展性为代价的：为了确保所有参与节点都能跟上网络的进度，网络的吞吐量是有限的。这样的限制最终会导致用户端的成本和延迟增加。" -whatsnext: { "Rollups 介绍": "/zh/learn/intro-to-rollups" } ---- - -## 以太坊的扩容问题 - -[以太坊](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-is-ethereum) 是一个通用的区块链平台，支持 [智能合约](https://ethereum.org/en/developers/docs/intro-to-ethereum/#what-are-smart-contracts) 的部署和执行。 - -以太坊的核心价值是它坚持于安全和去中心化。以太坊的设计使得世界各地的计算机（甚至是便宜的计算机，如 [树莓派](https://ethereum-on-arm-documentation.readthedocs.io/)）都可以参与网络，运行区块链的本地节点并处理新交易。 - -然而，以太坊强大的去中心化和安全性是以牺牲可扩展性为代价的：为了确保所有参与节点都能跟上网络的进度，网络的吞吐量是有限的。这样的限制最终会导致用户端的成本和延迟增加。 - -## 扩容解决方案 - -以太坊的扩容解决方案旨在在不牺牲去中心化或安全性的情况下提高网络的吞吐量。 - -扩容解决方案主要有两种类型：一层（Layer 1）扩容解决方案和二层（Layer 2）扩容解决方案。 - -**Layer 1** (后文简称 **L1**) 扩容解决方案尝试通过直接修改以太坊区块链来扩展网络。这里的术语“Layer 1”是指核心的以太坊区块链。通常，很难设计出能够提高吞吐量并同时保持高级别安全性和去中心化的一层扩展解决方案。因此，最近的扩容工作已从一层解决方案转向二层解决方案。 - -**Layer 2** (后文简称 **L2**) 扩容解决方案是位于以太坊一层之上的网络 - 它们本质上是独立的区块链，以某种方式“锚定”到底层以太坊区块链。这些二层网络通常可以比底层网络以更高的速率处理交易，因为它们不受相同的限制。“锚定”机制的细节在各个二层中有所不同，使二层网络能够继承以太坊一层网络的强大安全性和去中心化性。 diff --git a/src/content/docs/zh/learn/zero-knowledge/additional-zk-learning-resources.md b/src/content/docs/zh/learn/zero-knowledge/additional-zk-learning-resources.md deleted file mode 100644 index c750f9810..000000000 --- a/src/content/docs/zh/learn/zero-knowledge/additional-zk-learning-resources.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -section: learn -date: Last Modified -title: "其他 ZK 学习资源" -lang: "zh" -permalink: "learn/zero-knowledge/additional-zk-learning-resources" -excerpt: "想要更深入学习 ZK？以下是我们最收藏的一些资源。" ---- - -想要更深入学习 ZK？以下是我们最收藏的一些资源。 - -## 视频 - -- [ZK Whiteboard Sessions](https://youtube.com/playlist?list=PLj80z0cJm8QErn3akRcqvxUsyXWC81OGq) - - ZK Whiteboard Sessions 系列是了解 ZK 的绝佳方式。Dan Boneh 的前三场演讲提供了一个很好的基础况下，以下讲座在此基础上讨论了最近的发展。 -- [Zero Knowledge Proofs MOOC](https://youtube.com/playlist?list=PLS01nW3Rtgor_yJmQsGBZAg5XM4TSGpPs) - - 涵盖了零知识证明的第一性原理到行业前沿话题的慕课 -- [The 9th BIU Winter School on Cryptography - Zero Knowledge](https://youtube.com/playlist?list=PL8Vt-7cSFnw29cLUVqAIuMlg1QJ-szV0K) - - 这些讲座需要一定的零知识理论基础 —— 它们所针对的是具有数学背景的学者和听众。 -- [ZK Symposium](https://www.youtube.com/playlist?list=PLrzRr7okCcmbAlgYpuFjzUJv8tAyowDQY) - - 来自零知识证明领域一些顶级研究员和产品开发者的应用和理论演讲的合集。 - -## 文档 - -- [Proofs, Arguments, and Zero Knowledge](https://people.cs.georgetown.edu/jthaler/ProofsArgsAndZK.html) - Justin Thaler - - 一本关于零知识理论的综合教科书。 diff --git a/src/content/docs/zh/learn/zero-knowledge/introduction-to-zero-knowledge.mdx b/src/content/docs/zh/learn/zero-knowledge/introduction-to-zero-knowledge.mdx deleted file mode 100644 index b6523eecb..000000000 --- a/src/content/docs/zh/learn/zero-knowledge/introduction-to-zero-knowledge.mdx +++ /dev/null @@ -1,85 +0,0 @@ ---- -section: learn -date: Last Modified -title: "零知识证明介绍" -lang: "zh" -permalink: "learn/zero-knowledge/introduction-to-zero-knowledge" -whatsnext: { "多项式承诺方案": "/zh/learn/zero-knowledge/polynomial-commitment-schemes" } -excerpt: '在过去的十年中，称为“零知识证明”的密码学领域一直在迅速发展。它提供了构建应用程序的新范式，并使协议能够提高效率、安全性和隐私性。' ---- - -import Aside from "../../../../../components/Aside.astro" - -在过去的十年中，称为“零知识证明”的密码学领域一直在迅速发展。它提供了构建应用程序的新范式，并使协议能够提高效率、安全性和隐私性。 - -让我们看看是什么让零知识证明领域如此令人兴奋，以及它帮助工程师解决了哪些问题。 - -## 无需信任的区块链和可验证性 - -区块链通常用于处理用户提交的交易。这些交易通常会触发区块链所需执行的一些计算。 - -为了使区块链是无需信任的（即不依赖于信任单独的一方），网络中的参与者必须可以验证交易是否有效，以及它们所含的计算是否正确执行。 - -验证交易是否有效通常需要数字签名验证 - 这需要验证交易的发送方确实是交易的发起人。验证交易的计算是否正确执行通常需要在本地重新执行交易。 - -## 可验证性的局限性 - -这种验证每个交易的方法在验证者无法重新运行计算的情况下会面临崩溃。 -参与者出于某些原因可能无法重新执行计算，例如： -（1）（出于隐私原因）某些数据可能不应当公开，或者（2）对于参与验证的计算机来说，重新执行所有交易可能太昂贵了 - 在考虑每秒有大量交易的高吞吐量区块链时，第二个原因尤其重要。 - -## 零知识证明的力量 - -零知识证明 （以下简称 ZKP） 有克服这些限制的神奇魔力。 - -ZKP 允许验证者验证计算结果，同时 （1） 保护计算中所使用的任何敏感数据的隐私，以及 （2） 验证比重新执行计算便宜得多。ZKP 的这两个性质分别称为 **零知识** 和 **简洁性** 。 - -ZKP 的上述特性在无需信任的区块链的可验证性方面非常有用。 -如果没有 ZKP，验证者需要重新执行每笔交易的计算结果。这要求所有验证者都能看到每次计算中使用的所有（潜在敏感）数据，这也限制了整个系统的吞吐量。 -使用 ZKP，一方可以执行计算，然后生成计算正确执行的证明。其他参与方可以通过验证证明是否有效来验证计算是否正确执行，而无需自己重新执行计算。 -验证证明 （1） 不会泄露有关原始计算中使用的敏感数据的信息，并且 （2） 在计算上比重新执行原始计算便宜得多。这两个属性将为无需信任的区块链实现隐私和可扩展性。 - -## 电路、证明和验证器 - -在实践中，ZKP 在系统中的实现可能非常复杂，但在概览的层面，您需要了解零知识证明有几个组件：电路、证明和验证器。 - -电路是一个程序，它接收输入数据，并根据输入数据必须满足的一些“约束”来确保输入数据是有效的。输入数据可以是公开的（每个人都知道）、隐私的（只有证明者知道）或混合的（有些输入是公开的，有些是隐私的）。 - -证明生成可以用来确保满足电路。证明不会泄漏有关隐私输入的信息，并且非常之小。 - -验证器可以验真 （1） 证明是否有效，（2） 证明是否符合电路规定的约束（而不仅仅是虚假证明），以及 （3） 用于生成证明的公开输入是否与验证器使用的输入像匹配。请注意，验证器执行的此类检查通常是一种开销较低的计算 - - - -### 电路、证明和验证器 — 一个例子 - -让我们以数独为例。假设有一个数独题，爱丽丝想向鲍勃证明她知道谜题的答案，但不想透露答案是什么。 - -在这种情况下，特定的谜题将是一个公开输入（Alice 和 Bob 都知道它），而解决方案是一个隐私输入（Alice 知道它，但会对 Bob 保密）。**电路** 将接受这两个输入，并通过以标准方法、逐行逐列地检查答案来断言答案是正确的。 -电路在这个例子中，约束了隐私输入的答案确实是公开输入的谜题的解，并且电路只有在答案检查通过时才“满足”。 - -然后即可以生成一个 **证明** ，说明爱丽丝知道满足特定谜题电路（公开输入）的隐私输入。 - -证明可以和谜题一起传递给鲍勃，然后鲍勃可以使用与数独检查电路相对应的 **验证器** 来判断证明是否有效，从而证明爱丽丝确实知道谜题的解。最重要的是，鲍勃没有获得任何关于爱丽丝所知道的解的信息，但他仍然可以验证她是否知道有效的解！ - -## 零知识证明和区块链 - -ZKPs 最近取得进展的主要原因是它在区块链中的应用。 -去中心化区块链面临的两个关键挑战是隐私和可扩展性 —— 所有数据都是公开的，网络中的每个节点都必须在网络上重新执行每个计算。 -ZKP 可以帮助解决这两个挑战。 - -虽然有一些项目利用 ZKP 的零知识特性来构建隐私保护的应用程序，但我们 Scroll 仅使用了 ZKP 的简洁性来扩容以太坊。 - -## Scroll 和零知识证明 - -驱动 Scroll 的想法非常简单。如果我们可以使用以太坊智能合约来验证另一个版本的以太坊的所有计算呢？我们可以运行另一个网络，提供对以太坊虚拟机（“EVM”）的更快、更便宜的访问，而以太坊本身将提供验证所有计算所需的安全性，并确保另一个网络不会违反 EVM 规范。 - -“学习”和“技术”部分的其余部分更详细地讲解了其工作原理， -但简单理解，只需记住，零知识依赖于电路、证明和验证器。 - -在我们的架构中，电路（实际上是一组电路）对 EVM 的规则进行了编码，来“约束”对链状态更改的输入交易的可接受行为。 -使用这个“zkEVM”，GPU 网络获取一组区块的交易并生成证明。 -然后回到以太坊，智能合约将验证该批次交易的证明，证明需要与智能合约中所规定的电路相匹配。 -如果确实满足，这些交易可以被认为是“最终确认的”，网络将向前推进，而我们已经为以太坊的发展创造了快速、安全和可负担得起的区块空间。 \ No newline at end of file diff --git a/src/content/docs/zh/learn/zero-knowledge/kzg-commitment-scheme.md b/src/content/docs/zh/learn/zero-knowledge/kzg-commitment-scheme.md deleted file mode 100644 index 914c59fa0..000000000 --- a/src/content/docs/zh/learn/zero-knowledge/kzg-commitment-scheme.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -section: learn -date: Last Modified -title: "KZG 承诺方案" -lang: "zh" -permalink: "learn/zero-knowledge/kzg-commitment-scheme" -excerpt: "KZG 用于以太坊的 Proto-Danksharding，也用于 Scroll 的证明系统。本节将概述 KZG 承诺方案。" -whatsnext: { "其他资源": "/zh/learn/zero-knowledge/additional-zk-learning-resources" } ---- - -使用最广泛的多项式承诺方案之一是 KZG 承诺方案。该方案最早由 Kate、Zaverucha 和 Goldberg 于 2010 年[发布](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf)。 - -KZG 用于以太坊的 [Proto-Danksharding](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq), 也用于 Scroll 的证明系统。 - -本节将概述 KZG 承诺方案。 - -## 初步工作和符号表示 - -回顾一下多项式承诺方案的假设，我们需要对一些多项式 $P(x)$ 进行承诺。我们假设多项式的阶数小于 $l$. - -KZG 承诺依赖于 [椭圆曲线配对](https://vitalik.ca/general/2017/01/14/exploring_ecp.html)。假设 $\mathbb{G}_1$ 和 $\mathbb{G}_2$ 是两个阶为 $p$ 的椭圆曲线群，满足 non-trivial [双线性配对](https://en.wikipedia.org/wiki/Bilinear_map) $e: \mathbb{G}_1 \times \mathbb{G}_2 \rightarrow \mathbb{G}_T$。假设 $g$ 是群 $\mathbb{G}_1$ 的生成元，$h$ 是群 $\mathbb{G}_2$ 的生成元。我们使用符号表示为 $[x]_1 := x \cdot g$ 和 $[x]_2 := x \cdot h$，其中 $x \in \mathbb{F}_p$. - -## 1. 可信设置 - -在计算任何 KZG 承诺之前，必须执行一次性的可信设置。一旦可信设置完成，就可以重复使用它来承诺和揭示所需的任意数量的不同多项式。可信设置的工作流程如下： - -- 选择随机的域元素 $\tau \in \mathbb{F}_p$ -- 假设 $l \in \mathbb{Z}$ 是我们想要承诺的多项式的最大次数 - - 可信设置只能阶数 $\leq l$ 的多项式有效 -- 计算 $([\tau^0]_1,[\tau^1]_1,[\tau^{2}]_1\ldots,[\tau^{l}]_1)$ 和 $([\tau]_2)$，并公开发布这些值。 - -请注意，$\tau$ 不应该被揭示 - 它是可信设置的秘密参数，应在可信设置仪式完成后丢弃，以便没有人知道它的值。 - -使用[多方计算](https://en.wikipedia.org/wiki/Secure_multi-party_computation) （MPC） 在弱信任假设（N 个信任假设中为 1 个）的情况下，有一些已有的方法来执行可信设置仪式。有关可信设置如何工作的更多信息，请参阅 Vitalik 的这篇[文章](https://vitalik.ca/general/2022/03/14/trustedsetup.html)。 - -## 2. 承诺多项式 - -- 给定 $P(x) = \sum_{i=0}^{l} p_i x^i$ -- 计算并输出承诺 $c = [P(\tau)]_1$ - - 虽然承诺者不能直接计算 $P(\tau)$ (因为他不知道 $\tau$)，但他可以使用可信设置的输出来计算它： - - $[P(\tau)]_1 = [\sum_{i=0}^{l} p_i \tau^i]_1 = \sum_{i=0}^{l} p_i [\tau^i]_1$ - -## 3. 证明求值 - -- 给定多项式的点求值 $P(a) = b$ -- 计算并输出证明 $\pi = [Q(\tau)]_1$ - - 其中 $Q(x) := \frac{P(x)-b}{x-a}$ - - 这称为“商多项式”。请注意，当且仅当 $P(a) = b$ 时，存在 $Q(x)$。因此，这个商多项式的存在可以作为求值的证明。 - -## 4. 验证求值证明 - -- 给定承诺 $c = [P(\tau)]_1$， 求值 $P(a) = b$ 和证明 $\pi = [Q(\tau)]_1$ -- 验证 $e(\pi, [\tau - a]_2) = e(c - [b]_1, h)$ - - 根据代数推导，这等价于检查商多项式是否正确构造 $\tau$: $Q(\tau) = \frac{P(\tau) -b}{\tau-a}$ - $$ - \begin{align*} - & e(\pi, [\tau - a]_2) = e(c - [b]_1, h) \\ \iff - & e([Q(\tau)]_1, [\tau -a]_2) = e([P(\tau)]_1 - [b]_1, h) \\ \iff - & Q(\tau) \cdot (\tau - a) \cdot e(g, h) = (P(\tau)-b) \cdot e(g,h) \\ \iff - & Q(\tau) \cdot (\tau -a) = P(\tau) - b - \end{align*} - $$ - - 双线性映射 $e$ 使我们能够在不知道秘密设置参数 $\tau$ 的情况下检验该属性。 -- 一旦验证完成，我们可以（以极高的概率）得出结论：商多项式是正确构造的，因此计算是正确的。 - -## 了解更多 - -- [https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html) -- [https://alinush.github.io/2020/05/06/kzg-polynomial-commitments.html](https://alinush.github.io/2020/05/06/kzg-polynomial-commitments.html) -- [https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf](https://www.iacr.org/archive/asiacrypt2010/6477178/6477178.pdf) diff --git a/src/content/docs/zh/learn/zero-knowledge/polynomial-commitment-schemes.md b/src/content/docs/zh/learn/zero-knowledge/polynomial-commitment-schemes.md deleted file mode 100644 index a2739f1f0..000000000 --- a/src/content/docs/zh/learn/zero-knowledge/polynomial-commitment-schemes.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -section: learn -date: Last Modified -title: "多项式承诺方案" -lang: "zh" -permalink: "learn/zero-knowledge/polynomial-commitment-schemes" -excerpt: "多项式承诺方案是零知识证明系统（以及其他加密协议）的核心组成部分" -whatsnext: { "KZG 承诺方案": "/zh/learn/zero-knowledge/kzg-commitment-scheme" } ---- - -多项式承诺方案是零知识证明系统（以及其他加密协议）的核心组成部分。 - -顾名思义，多项式承诺方案是承诺方案，其中要承诺的对象是多项式。这类方案的一个特殊属性是，多项式的计算可以通过仅访问多项式的承诺来验证。 - -## 承诺方案 - -A **[承诺方案](https://en.wikipedia.org/wiki/Commitment_scheme)** 是一种加密原语，涉及两方：_承诺者_ 和 _验证者_。承诺者对值 $v$ 进行计算承诺 $c$，并将其揭示给验证者。随后，承诺者可以揭示原始值，验证者可以验证承诺是否与所揭示的原始值相对应。 - -安全的承诺方案有两个属性： - -1. **绑定**: 一旦发布承诺 $c$，承诺者就无法找到与 $v$ 不同的值 $v’$ 与承诺 $c$ 相对应。也就是说，承诺 $c$ 将承诺者与他的原始价值 $v$ 绑定。 -2. **隐藏**: 验证者无法从承诺 $c$ 中获知有关原始值 $v$ 的任何信息。也就是说，承诺 $c$ 隐藏了有关原始值 $v$ 的所有信息。 - -## 多项式承诺方案 - -**多项式承诺方案** 中，承诺者通过计算承诺 $c$，对多项式 $P(x)$ 进行承诺。与常规的承诺方案一样，承诺者稍后可以揭示原始多项式，验证者可以检查承诺是否与所揭示的多项式相对应。然而，多项式承诺方案还有一个额外的属性：承诺者可以在不透露多项式本身的情况下证明对所承诺多项式的特定计算。例如，承诺者可以证明多项式上的一点 $P(a) = b$， 而验证者可以仅使用承诺 $c$ 来验证这样的证明。 - -多项式承诺方案在零知识应用中非常有用。证明者可以使用这样的方案来证明他知道一些满足某些性质的多项式（例如，它通过某个特定的点 $(a,b)$），而无需揭示潜在的多项式。 - -多项式方案有用的另一个原因是，承诺  $c$  通常比它所表示的多项式小得多，因此可以认为是多项式 $P(x)$ 的**压缩**。压缩的程度取决于特定的方案。例如，在 KZG 多项式承诺方案中，任意大小次数的多项式可以压缩为由单个群元素组成的承诺。 - -## 了解更多 - -- [https://en.wikipedia.org/wiki/Commitment_scheme](https://en.wikipedia.org/wiki/Commitment_scheme) -- [https://learn.0xparc.org/materials/halo2/miscellaneous/polynomial-commitment](https://learn.0xparc.org/materials/halo2/miscellaneous/polynomial-commitment) diff --git a/src/content/docs/zh/user-guide/_images/bridge1.png b/src/content/docs/zh/user-guide/_images/bridge1.png deleted file mode 100644 index dd552310e..000000000 Binary files a/src/content/docs/zh/user-guide/_images/bridge1.png and /dev/null differ diff --git a/src/content/docs/zh/user-guide/_images/bridge2.png b/src/content/docs/zh/user-guide/_images/bridge2.png deleted file mode 100644 index e3fe4701f..000000000 Binary files a/src/content/docs/zh/user-guide/_images/bridge2.png and /dev/null differ diff --git a/src/content/docs/zh/user-guide/_images/bridge3.png b/src/content/docs/zh/user-guide/_images/bridge3.png deleted file mode 100644 index 03772fee9..000000000 Binary files a/src/content/docs/zh/user-guide/_images/bridge3.png and /dev/null differ diff --git a/src/content/docs/zh/user-guide/_images/bridge4.png b/src/content/docs/zh/user-guide/_images/bridge4.png deleted file mode 100644 index a060b2ce3..000000000 Binary files a/src/content/docs/zh/user-guide/_images/bridge4.png and /dev/null differ diff --git a/src/content/docs/zh/user-guide/_images/bridge5.png b/src/content/docs/zh/user-guide/_images/bridge5.png deleted file mode 100644 index 7e75aeb4d..000000000 Binary files a/src/content/docs/zh/user-guide/_images/bridge5.png and /dev/null differ diff --git a/src/content/docs/zh/user-guide/_images/bridge6.png b/src/content/docs/zh/user-guide/_images/bridge6.png deleted file mode 100644 index 80066a330..000000000 Binary files a/src/content/docs/zh/user-guide/_images/bridge6.png and /dev/null differ diff --git a/src/content/docs/zh/user-guide/_images/bridge7.png b/src/content/docs/zh/user-guide/_images/bridge7.png deleted file mode 100644 index 66ee3ff94..000000000 Binary files a/src/content/docs/zh/user-guide/_images/bridge7.png and /dev/null differ diff --git a/src/content/docs/zh/user-guide/_images/bridge8.png b/src/content/docs/zh/user-guide/_images/bridge8.png deleted file mode 100644 index 4b78a8b9e..000000000 Binary files a/src/content/docs/zh/user-guide/_images/bridge8.png and /dev/null differ diff --git a/src/content/docs/zh/user-guide/bridge.mdx b/src/content/docs/zh/user-guide/bridge.mdx deleted file mode 100644 index b53f10cc8..000000000 --- a/src/content/docs/zh/user-guide/bridge.mdx +++ /dev/null @@ -1,126 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "跨链桥" -lang: "zh" -permalink: "user-guide/bridge/" -excerpt: "To start bridging assets from Sepolia, navigate to the portal bridge app." ---- - -{/* // import ClickToZoom from "../../../../components/ClickToZoom.astro" */} -{/* // import bridge1 from "./\_images/bridge1.png" */} -{/* // import bridge2 from "./\_images/bridge2.png" */} -{/* // import bridge3 from "./\_images/bridge3.png" */} -{/* // import bridge4 from "./\_images/bridge4.png" */} -{/* // import bridge5 from "./\_images/bridge5.png" */} -{/* // import bridge6 from "./\_images/bridge6.png" */} -{/* // import bridge7 from "./\_images/bridge7.png" */} -{/* // import bridge8 from "./\_images/bridge8.png" */} - -{/* TODO: Update all instructions after being able to walk through the whole flow. */} - -从访问我们的[跨链桥](https://scroll.io/bridge) 应用开始![^thanks-hop] 跨链桥同时支持 **存款** and **提款** 操作, 允许用户无需信任地将资产从Sepolia测试网转移到Scroll Sepolia测试网。 -[^thanks-hop]: 从[Hop Exchange]('https://hop.exchange/')的 UI 分叉而来 🙌 - -存款最多可能需要 15 分钟才能在 Scroll 上可用。 - -提款需要在提款完成后在 Sepolia 上进行第二次互动，可能需要更长的时间。 - -:::caution[跨链交易需要等待很长时间?] -上述时间预估是正常网络行为和活动时的值。由于我们每个 L2 区块仅处理队列中一定的 L1 交易，因此在网络异常拥堵时，跨链桥消息可能需要更长的时间才能包含在 Scroll 中 -::: - -## 从 Sepolia 存款到 Scroll Sepolia - -### 操作 - -1. 首先，导航到[Scroll 跨链桥](https://scroll.io/bridge)，然后按“连接钱包”。 -1. 在应用程序中，确保以太坊 **Sepolia** 位于顶部，**Scroll Sepolia** 位于底部。您可以单击“↓”按钮切换其位置。 -1. 选择要从 **Sepolia** 转移到 **Scroll Sepolia** 的代币。如果您是第一次桥接，请尝试“ETH”。 -1. 如果这是您第一次转移特定的ERC20代币，您必须批准Sepolia 跨链桥合约才能访问您的ERC20代币 -1. 接下来，点击 **发送到Scroll Sepolia** 按钮进行存款。您的钱包将要求确认转账交易。 -1. 一旦发送并确认转账交易后，代币将从您的Sepolia钱包中扣除。 -1. 您可以随时通过按右上角钱包地址旁边的“历史记录”图标来检查交易状态。 - -### 代币何时到达您的 Scroll Sepolia 钱包？ - -可能需要 8 到 14 分钟（等待区块在 Sepolia 上变得[_安全_](https://www.alchemy.com/overviews/ethereum-commitment-levels#what-are-ethereum-commitment-levels)），代币才会显示在您的 Scroll Sepolia 钱包中。 - -{/* You can check the progress of deposit transactions as follows: */} - -{/* ##### 1. Click the "History" icon next to your wallet address in the top-right corner. */} - -{/* */} - -{/* The pop-up panel lists the most recent transactions made in the Bridge app. There are two statuses: Sepolia status and Scroll Sepolia status. For deposit transactions (L1 -> L2), once your transaction becomes _Safe_ on Sepolia (**8 to 14 minutes**), you will see the **`success`** status shown. Your funds will be relayed to Scoll Sepolia after this. */} - -{/* The Recent Bridge Transactions window should give you an estimate of the time expected before your transaction is _Safe_ on Sepolia. */} - -{/* ##### 2. Click on the most recent transaction’s Sepolia transaction hash. */} - -{/* */} - -{/* It will open the Transaction Details page in a new tab. You can see this transaction is confirmed on Sepolia. To check the Block's confirmation status, click the Block number and read the "Status" field. */} - -{/* */} - -{/* ##### 3. Return to the Bridge app and wait! */} - -{/* Once your transaction status shows **`success`** on Scroll Sepolia, you should see the funds in your Scroll L2 wallet and a transaction hash: */} - -{/* */} - -## 从 Scroll Sepolia 往 Sepolia 提款 - -### 操作 - -#### 提交您的提款交易 - -1. 首先，切换到钱包中的**Scroll Sepolia**网络。 -1. 在应用程序中，确保 **Scroll Sepolia** 位于顶部，以太坊 **Sepolia** 位于底部。您可以单击“↓”按钮切换位置。 -1. 选择要从 **Scroll Sepolia** 转移到 **Sepolia** 的代币。如果您是第一次桥接，请尝试“ETH”。 -1. 如果这是您第一次转移特定的ERC20代币，您必须**批准**Scroll Sepolia 跨链桥合约才能访问您的ERC20代币。 -1. 接下来，点击 **发送到以太坊 Sepolia** 按钮进行提款。您的钱包将要求确认转账交易。 -1. 一旦转账交易被发送并确认，代币将从您的Scroll Sepolia钱包中扣除。 - -#### 提交执行提款交易 - -{/* TODO: finish the additional instructions, better estimate "wait time" */} - -_其余步骤发生在Scroll Sepolia上，但您首先必须等待您的交易在以太坊Sepolia上得到完全证明（“最终确认”）。此过程最多可能需要四个小时。._ - -1. 当您的提款交易在以太坊Sepolia上完成时，您将看到“最近交易”区域中的“认领”按钮。 -1. 点击“认领”按钮提交执行提款交易。 -1. 一旦提交后，您提取的资金应立即出现在您的Sepolia钱包中。 - -### 代币什么时候会到达您的Sepolia钱包？ - -转移的代币将在包含您的执行提款交易的区块在Sepolia上确认后，立即到达您的Sepolia钱包。 - -{/* TODO: check architecture link is live */} - -:::tip[Rollup 状态] -Rollup 状态 `最终确认` 表明，通过在Sepolia上验证链上的有效性证明，已经证明了该区块中交易的正确执行。有关Rollup状态的详细信息，请参阅 [Scroll 的架构概览](/technology)。 -::: - -{/* You can check the progress of withdrawal transactions as follows: */} - -{/* 1. Click your wallet address at the top-right corner of the Bridge web app. */} - -{/* */} - -{/* The pop-up panel lists the most recent transactions you made in the Bridge app (see the image below). There are two statuses: L1 status and L2 status. In this case, because we are bridging from L2 -> L1, we will quickly get a **`success`** status after submitting the transaction to the L2 Bridge. L1, on the other hand, takes **10 minutes to a few hours** to reach **`success`**. */} - -{/* 1. Click on the most recent transaction’s L2 transaction hash: */} - -{/* */} - -{/* It will open the _Transaction Details_ page in a new tab. You can see this transaction is confirmed on L2. */} - -{/* */} - -{/* The transaction is confirmed on L2, but still needs to be finalized on Goerli. */} - -{/* 1. Go back to the [Bridge](https://scroll.io/bridge) app. It takes about 10 minutes before the token shows up in your Goerli wallet. Once your transaction status shows success on L2, you should see the funds in your Goerli wallet and a transaction hash: */} - -{/* */} diff --git a/src/content/docs/zh/user-guide/common-errors.mdx b/src/content/docs/zh/user-guide/common-errors.mdx deleted file mode 100644 index d06ebb107..000000000 --- a/src/content/docs/zh/user-guide/common-errors.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "常见错误" -lang: "zh" -permalink: "user-guide/common-errors/" -excerpt: "Seeing an error when trying to interact with Scroll Sepolia Testnet? Here are some common configuration errors and how to quickly fix them." ---- - -## 在小狐狸钱包中发送交易时使用不正确的nonce - -当存储在小狐狸钱包中的本地nonce与Scroll 测试网节点中的nonce不同时，您会遇到此错误。这可能是因为最近有一个待处理的交易。 - -要解决此问题，您需要在小狐狸钱包中重置您的帐户以使用Scroll Sepolia 测试网。重置帐户的步骤如下 - -1. 在浏览器中打开**小狐狸钱包**扩展插件 -2. 选择顶部区域中的**Scroll Sepolia测试网** -3. 点击右上角的**账户图标** -4. 选择 **设置** -5. 前往 **高级** -6. 点击 **重置账户** - -在小狐狸钱包账户重置期间，您不会丢失任何资产。 - -:::caution[提醒] -删除和重新添加网络不足以解决此问题 - 您必须重置您的帐户。 -::: - -## 确认跨链桥/Swap交易时没有任何反应 - -如果没有出现错误或控制台日志，这可能是由于nonce问题，请按照上述[#在小狐狸钱包中发送交易时使用不正确的nonce](#incorrect-nonce-error-when-sending-a-transaction-in-metamask)中所述，重置您的小狐狸钱包帐户。 - -## 区块链浏览器显示 "内部服务器错误" - -使用隐身窗口，或打开浏览器开发者控制台并移除 Cookie（或所有 `_explorer_key` Cookie）。[请参阅本指南](https://www.contentstack.com/docs/developers/how-to-guides/clear-caches-and-cookies-in-different-browsers/)，了解如何删除 Cookie。 - -## 在小狐狸钱包中发送最大数量的ETH导致“失败”错误 - -使用小狐狸钱包发送ETH时，如果您尝试发送“最大”金额，将导致“失败”错误。这是因为小狐狸钱包没有考虑Rollup在常规Gas费外的额外“L1 费用”，并且不足以支付交易Gas所需的费用。 - -要解决此问题，请手动将ETH的数量降低到比建议的要小一点，交易就可以完成。 diff --git a/src/content/docs/zh/user-guide/faucet.mdx b/src/content/docs/zh/user-guide/faucet.mdx deleted file mode 100644 index a71cd7574..000000000 --- a/src/content/docs/zh/user-guide/faucet.mdx +++ /dev/null @@ -1,39 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "水龙头" -lang: "zh" -permalink: "user-guide/faucet/" -whatsnext: { "将 ETH 桥接至 Scroll Sepolia": "/zh/user-guide/bridge" } -excerpt: "To interact with our testnet, you first need to acquire Sepolia ETH. There are a few Sepolia faucet apps to get you started." ---- - -要与我们的测试网互动，您首先需要在*Sepolia测试网*上接收测试网ETH。然后，您可以从*Sepolia测试网*桥接到*Scroll Sepolia测试网*。 - -## Sepolia 水龙头 - -每个水龙头都有自己的规则和要求，因此您可能需要尝试一些水龙头，然后才能找到适合您的水龙头。 - -以下是一些Sepolia水龙头应用程序： - -- [https://sepoliafaucet.com](https://sepoliafaucet.com/) -- [https://sepolia-faucet.pk910.de](https://sepolia-faucet.pk910.de) -- [https://faucet.quicknode.com/drip](https://faucet.quicknode.com/drip) -- [https://faucet.chainstack.com](https://faucet.chainstack.com) - -一旦您在Sepolia上收到ETH，您应该会在Sepolia网络上的钱包中看到它。它们可能需要几秒钟才能出现，但您可以通过在 [Sepolia 区块浏览器](https://sepolia.etherscan.io/) 上查找您的地址交易来检查状态。 - -:::note[适度使用!] -大多数水龙头只允许每 24 小时请求一次测试代币。 -::: - -## Scroll Sepolia 水龙头 - -如果您不想与跨链桥互动，一些水龙头可以直接发送 Scroll Sepolia ETH。 - -- [https://thirdweb.com/scroll-sepolia-testnet](https://thirdweb.com/scroll-sepolia-testnet) -- [https://www.hackquest.io/en/faucets/534351](https://www.hackquest.io/en/faucets/534351) -- [https://scroll.l2scan.co/faucet](https://scroll.l2scan.co/faucet) -- [https://www.covalenthq.com/faucet/](https://www.covalenthq.com/faucet) -- [https://faucet.quicknode.com/scroll/sepolia](https://faucet.quicknode.com/scroll/sepolia) -- [https://bwarelabs.com/faucets/scroll-testnet](https://bwarelabs.com/faucets/scroll-testnet) diff --git a/src/content/docs/zh/user-guide/index.mdx b/src/content/docs/zh/user-guide/index.mdx deleted file mode 100644 index fceffe67a..000000000 --- a/src/content/docs/zh/user-guide/index.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "Scroll Sepolia 测试网用户指南" -lang: "zh" -permalink: "user-guide/" -excerpt: "Thank you for testing out our Sepolia Testnet. The Sepolia Testnet consists of Ethereum's Sepolia Testnet and the Scroll Sepolia test network." -whatsnext: { "设置你的钱包": "/zh/user-guide/setup" } ---- - -import Aside from "../../../../components/Aside.astro" - - - -感谢您测试 Scroll Sepolia 测试网。如果您有任何疑问或想提供反馈，请加入我们的 [Discord](https://discord.gg/scroll)！ - -Sepolia 测试网由 _以太坊的 Sepolia 测试网_ 和 _Scroll Sepolia 测试网络_ 组成。Sepolia 是以太坊的一个测试网络，而 Scroll Sepolia 是一个部署在前者之上的 zkRollup 测试网。有一些预先部署的演示程序: 一个 Sepolia 和 Scroll Sepolia 之间的[跨链桥](https://scroll.io/bridge),[^1] 一个 Scroll Sepolia 的[区块链浏览器](https://sepolia-blockscout.scroll.io/) ,[^2]和一个[rollup 浏览器](https://scroll.io/rollupscan). - -要查看 L1 的交易，请查看 Etherscan 的[Sepolia 浏览器](https://sepolia.etherscan.io/)。要查看 L2 的交易，您可以使用 Scroll 的区块浏览器，但您可能也会想尝试[Dora](https://www.ondora.xyz/network/scroll-sepolia/interactions)或[L2Scan](https://scroll.l2scan.co/)提供的附加功能。 - -以下是体验测试网的参考流程： - -1. 将[Sepolia 测试网](https://scroll.io/portal)配置添加到您的钱包中。 -2. 从任何以太坊水龙头应用程序请求*Sepolia 网络*中的测试代币（请参阅 [水龙头](/zh/user-guide/faucet) 文章）。 -3. 通过 [跨链桥](https://scroll.io/bridge) 应用程序将测试代币从*Sepolia 网络*转移到*Scroll Sepolia*。 -4. 使用您的钱包将代币转移到*Scroll Sepolia*上的其他钱包。 -5. 探索我们的生态系统，与 [Uniswap](http://uniswap-showcase.sepolia.scroll.xyz/) 等合约互动。 -6. 通过 [跨链桥](https://scroll.io/bridge) 应用程序将测试代币从*Scroll Sepolia*提取到*Sepolia 网络*。 - -您可以在本用户指南的其余部分找到每个应用的说明。 - -## 问题与反馈 - -如果您遇到任何问题，请加入我们的 [Discord](https://discord.gg/scroll) 并在频道 #general-support 中与我们交流。我们也很乐意听到您对如何改善您的体验的想法或反馈。 - -[^1]: 从 [Hop Exchange](https://hop.exchange/) UI 分叉而来 🐇🙌 -[^2]: 使用 [Blockscout](https://blockscout.com/) 出色的开源区块链浏览器 diff --git a/src/content/docs/zh/user-guide/setup.mdx b/src/content/docs/zh/user-guide/setup.mdx deleted file mode 100644 index 8bfecc78b..000000000 --- a/src/content/docs/zh/user-guide/setup.mdx +++ /dev/null @@ -1,41 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "设置" -lang: "zh" -permalink: "user-guide/setup/" -whatsnext: { "从水龙头中获取Sepolia ETH": "/zh/user-guide/faucet" } -excerpt: "You need to have a wallet to interact with the Scroll Testnet. You can find some example wallets and configuration tips here." ---- - -import Aside from "../../../../components/Aside.astro" - -## 钱包 - -您需要有一个钱包才能与Scroll Sepolia测试网上的dApp进行交互。您可以在下面找到一些示例钱包和配置提示。我们的跨链桥应用程序支持小狐狸钱包(MetaMask)，Coinbase钱包或任何支持WalletConnect的钱包。 - -### 小狐狸钱包(MetaMask) - -您可以从他们的[官方网站](https://metamask.io/download/)安装小狐狸钱包。 - -您可以将 Scroll Sepolia 测试网配置导入您的小狐狸钱包。为此，请访问 [Scroll Sepolia 门户网站](https://scroll.io/portal)，然后单击“连接钱包”按钮并选择小狐狸钱包。接下来，单击Sepolia测试网和Scroll Sepolia测试网的“添加到小狐狸钱包”按钮。这将导入 Scroll Sepolia 测试网的链 ID 和 RPC URL。默认情况下，Sepolia 测试网也在小狐狸钱包配置中。要显示它，请单击小狐狸钱包网络选择下拉菜单中的“显示/隐藏测试网络”。 - - -### 手动网络配置（适用于其他钱包） - -**添加到钱包**链接可能不是和每个钱包都兼容。如果您在使用它们时遇到问题，您可能需要通过插入下表中的详细配置信息来手动添加 Sepolia 测试网和Scroll Sepolia 网络： - -| 网络名称 | Scroll Sepolia 测试网 | Sepolia Testnet | -| ------------------ | ----------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | -| RPC URL | [https://sepolia-rpc.scroll.io/](https://sepolia-rpc.scroll.io/) | [https://eth-sepolia-public.unifra.io](https://eth-sepolia-public.unifra.io) | -| 链 ID | 534351 | 11155111 | -| 代币符号 | ETH | ETH | -| 区块链浏览器链接 | [https://sepolia-blockscout.scroll.io](https://sepolia-blockscout.scroll.io/) | [https://sepolia.etherscan.io](https://sepolia.etherscan.io) | - - diff --git a/src/content/docs/zh/user-guide/transfer-tokens.md b/src/content/docs/zh/user-guide/transfer-tokens.md deleted file mode 100644 index 31910a235..000000000 --- a/src/content/docs/zh/user-guide/transfer-tokens.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -section: gettingStarted -date: Last Modified -title: "转移代币" -lang: "zh" -permalink: "user-guide/transfer-tokens/" -excerpt: "You can use your wallet as usual to transfer tokens within the Scroll Sepolia Testnet." ---- - -您可以使用钱包的正常功能在 Scroll Sepolia 测试网中转移代币 - 无需其他配置。 - -## 在小狐狸钱包中发送代币 - -1. 打开你的钱包，切换到 **Scroll Sepolia 测试网**. -2. 单击中间的**发送**按钮，然后在文本框中键入要转移到的地址。 -3. 在“资产”框中选择代币，然后键入要转移的代币数量。 -4. 单击**下一步**按钮，然后单击**确认**按钮以发送交易。 -5. 发送后，您可以在钱包的**活动**选项卡中找到交易。 diff --git a/src/features/landing/sections/NewUserCTA.astro b/src/features/landing/sections/NewUserCTA.astro index 764d36514..ac5667881 100644 --- a/src/features/landing/sections/NewUserCTA.astro +++ b/src/features/landing/sections/NewUserCTA.astro @@ -13,7 +13,7 @@ import i18next, { t } from "i18next"
- Get Started + Get Started
diff --git a/src/features/redirects/redirects.json b/src/features/redirects/redirects.json index 3697167d6..2fb227517 100644 --- a/src/features/redirects/redirects.json +++ b/src/features/redirects/redirects.json @@ -1,9 +1,204 @@ { "redirects": [ + { + "source": "developers/faq", + "destination": "developers", + "statusCode": 301 + }, + { + "source": "community/faq", + "destination": "community", + "statusCode": 301 + }, + { "source": "docs/any-api/api-reference", "destination": "any-api/api-reference", "statusCode": 301 + }, + + { + "source": "developers/developer-quickstart", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "developers/verifying-smart-contracts", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "developers/tooling-deployed-on-scroll", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "developers/guides/contract-deployment-tutorial", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "developers/guides/canvas-badge-integration", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "getting-started/overview", + "destination": "/developers", + "statusCode": 301 + }, + + { + "source": "sdk", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/sdk-faq", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/technical-stack", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/technical-stack/configuration", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/technical-stack/services", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/technical-stack/contracts", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/technical-stack/proof-generation", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/guides/devnet-deployment", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/guides/digital-ocean-alt-gas-token", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/guides/aws-deployment", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/guides/customizing-sdk-components", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/operation/contracts-verification", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/operation/gas-and-fees", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/operation/monitoring", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/operation/upgrades", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/operation/troubleshooting", + "destination": "/developers", + "statusCode": 301 + }, + { + "source": "sdk/operation/security-and-recovery", + "destination": "/developers", + "statusCode": 301 + }, + + { + "source": "learn", + "destination": "/technology", + "statusCode": 301 + }, + { + "source": "learn/the-scalability-problem", + "destination": "/technology", + "statusCode": 301 + }, + { + "source": "learn/intro-to-rollups", + "destination": "/technology", + "statusCode": 301 + }, + { + "source": "learn/zero-knowledge/introduction-to-zero-knowledge", + "destination": "/technology", + "statusCode": 301 + }, + { + "source": "learn/zero-knowledge/polynomial-commitment-schemes", + "destination": "/technology", + "statusCode": 301 + }, + { + "source": "learn/zero-knowledge/kzg-commitment-scheme", + "destination": "/technology", + "statusCode": 301 + }, + { + "source": "learn/zero-knowledge/additional-zk-learning-resources", + "destination": "/technology", + "statusCode": 301 + }, + + { + "source": "user-guide", + "destination": "/community", + "statusCode": 301 + }, + { + "source": "user-guide/setup", + "destination": "/community", + "statusCode": 301 + }, + { + "source": "user-guide/faucet", + "destination": "/community", + "statusCode": 301 + }, + { + "source": "user-guide/bridge", + "destination": "/community", + "statusCode": 301 + }, + { + "source": "user-guide/transfer-tokens", + "destination": "/community", + "statusCode": 301 + }, + { + "source": "user-guide/common-errors", + "destination": "/community", + "statusCode": 301 } ] } diff --git a/src/middleware.ts b/src/middleware.ts new file mode 100644 index 000000000..a4a761822 --- /dev/null +++ b/src/middleware.ts @@ -0,0 +1,38 @@ +import type { MiddlewareHandler } from "astro" + +export const onRequest: MiddlewareHandler = (context, next) => { + const url = new URL(context.request.url) + const pathname = url.pathname + + if ( + pathname.startsWith("/sdk") || + pathname.startsWith("/en/sdk") || + pathname.startsWith("/es/sdk") || + pathname.startsWith("/tr/sdk") || + pathname.startsWith("/zh/sdk") + ) { + return context.redirect("/developers", 301) + } + + if ( + pathname.startsWith("/learn") || + pathname.startsWith("/en/learn") || + pathname.startsWith("/es/learn") || + pathname.startsWith("/tr/learn") || + pathname.startsWith("/zh/learn") + ) { + return context.redirect("/technology", 301) + } + + if ( + pathname.startsWith("/user-guide") || + pathname.startsWith("/en/user-guide") || + pathname.startsWith("/es/user-guide") || + pathname.startsWith("/tr/user-guide") || + pathname.startsWith("/zh/user-guide") + ) { + return context.redirect("/community", 301) + } + + return next() +} diff --git a/src/pages/en/home/Navigate.astro b/src/pages/en/home/Navigate.astro index 97f783106..187178588 100644 --- a/src/pages/en/home/Navigate.astro +++ b/src/pages/en/home/Navigate.astro @@ -1,19 +1,10 @@ --- import NavCard from "~/components/NavCard.astro" -import StartSvg from "~/assets/svgs/home/home-start.svg?raw" import DevelopSvg from "~/assets/svgs/home/home-develop.svg?raw" import TechnologySvg from "~/assets/svgs/home/home-technology.svg?raw" -import LearnSvg from "~/assets/svgs/home/home-learn.svg?raw" -import SdkSvg from "~/assets/svgs/home/home-sdk.svg?raw" import SectionHeader from "~/components/SectionHeader/index.astro" const navList = [ - { - icon: StartSvg, - name: "Getting started", - content: "Bridge into Scroll and explore our dApp Ecosystem.", - link: "/en/getting-started/overview", - }, { icon: DevelopSvg, name: "Developers", @@ -26,18 +17,6 @@ const navList = [ content: "An overview of Scroll’s zkEVM Architecture.", link: "/en/technology", }, - { - icon: LearnSvg, - name: "Learn", - content: "An introduction to the world of ZK and Scalability.", - link: "/en/learn", - }, - { - icon: SdkSvg, - name: "SDK", - content: "Deploy a chain and own your blockspace.", - link: "/en/sdk", - }, ] --- diff --git a/src/pages/es/home/Navigate.astro b/src/pages/es/home/Navigate.astro index 07a37eec9..9977badd0 100644 --- a/src/pages/es/home/Navigate.astro +++ b/src/pages/es/home/Navigate.astro @@ -1,19 +1,10 @@ --- import NavCard from "~/components/NavCard.astro" -import StartSvg from "~/assets/svgs/home/home-start.svg?raw" import DevelopSvg from "~/assets/svgs/home/home-develop.svg?raw" import TechnologySvg from "~/assets/svgs/home/home-technology.svg?raw" -import LearnSvg from "~/assets/svgs/home/home-learn.svg?raw" -import SdkSvg from "~/assets/svgs/home/home-sdk.svg?raw" import SectionHeader from "~/components/SectionHeader/index.astro" const navList = [ - { - icon: StartSvg, - name: "¿Cómo empezar?", - content: "Migra hacia Scroll usando el Bridge y explora el Ecosistema de dApps.", - link: "/es/getting-started/overview", - }, { icon: DevelopSvg, name: "Desarrolladores", @@ -26,18 +17,6 @@ const navList = [ content: "Un vistazo general a la arquitectura de la zkEVM de Scroll.", link: "/es/technology", }, - { - icon: LearnSvg, - name: "Aprende", - content: "Una introducción al mundo de ZK y de la escalabilidad.", - link: "/es/learn", - }, - { - icon: SdkSvg, - name: "SDK", - content: "Lanza una cadena y administra tu propio espacio de bloques.", - link: "/es/sdk", - }, ] --- diff --git a/src/pages/tr/home/Navigate.astro b/src/pages/tr/home/Navigate.astro index 003c259ff..1ee3fcdf1 100644 --- a/src/pages/tr/home/Navigate.astro +++ b/src/pages/tr/home/Navigate.astro @@ -1,19 +1,10 @@ --- import NavCard from "~/components/NavCard.astro" -import StartSvg from "~/assets/svgs/home/home-start.svg?raw" import DevelopSvg from "~/assets/svgs/home/home-develop.svg?raw" import TechnologySvg from "~/assets/svgs/home/home-technology.svg?raw" -import LearnSvg from "~/assets/svgs/home/home-learn.svg?raw" -import SdkSvg from "~/assets/svgs/home/home-sdk.svg?raw" import SectionHeader from "~/components/SectionHeader/index.astro" const navList = [ - { - icon: StartSvg, - name: "Başla", - content: "Scroll'a geçiş yapın ve dApp ekosistemimizi keşfedin.", - link: "/tr/getting-started/overview", - }, { icon: DevelopSvg, name: "Geliştiriciler", @@ -26,18 +17,6 @@ const navList = [ content: "Scroll'un zkEVM mimarisine genel bakış.", link: "/tr/technology", }, - { - icon: LearnSvg, - name: "Öğren", - content: "ZK ve ölçeklenebilirliğin dünyasına giriş.", - link: "/tr/learn", - }, - { - icon: SdkSvg, - name: "SDK", - content: "Bir zincir ayağa kaldırın ve kendi ekosisteminize sahip olun.", - link: "/tr/sdk", - }, ] --- diff --git a/src/pages/zh/home/Navigate.astro b/src/pages/zh/home/Navigate.astro index ef658295d..05797f165 100644 --- a/src/pages/zh/home/Navigate.astro +++ b/src/pages/zh/home/Navigate.astro @@ -1,19 +1,10 @@ --- import NavCard from "~/components/NavCard.astro" -import StartSvg from "~/assets/svgs/home/home-start.svg?raw" import DevelopSvg from "~/assets/svgs/home/home-develop.svg?raw" import TechnologySvg from "~/assets/svgs/home/home-technology.svg?raw" -import LearnSvg from "~/assets/svgs/home/home-learn.svg?raw" -import SdkSvg from "~/assets/svgs/home/home-sdk.svg?raw" import SectionHeader from "~/components/SectionHeader/index.astro" const navList = [ - { - icon: StartSvg, - name: "入门", - content: "通过跨链桥进入 Scroll 并探索我们的 dApp 生态系统", - link: "/zh/getting-started/overview", - }, { icon: DevelopSvg, name: "开发者", @@ -26,18 +17,6 @@ const navList = [ content: "Scroll 的 zkEVM 架构概述", link: "/zh/technology", }, - { - icon: LearnSvg, - name: "学习", - content: "介绍 ZK 和扩容的世界", - link: "/zh/learn", - }, - { - icon: SdkSvg, - name: "SDK", - content: "部署链并拥有您的区块空间。", - link: "/zh/sdk", - }, ] --- diff --git a/vercel.json b/vercel.json index fa7039763..9eec4d9b9 100644 --- a/vercel.json +++ b/vercel.json @@ -5,12 +5,5 @@ "headers": [{ "key": "Access-Control-Allow-Origin", "value": "*" }] } ], - "cleanUrls": true, - "redirects": [ - { - "source": "docs/any-api/api-reference", - "destination": "any-api/api-reference", - "statusCode": 301 - } - ] + "cleanUrls": true }