diff --git a/.nvmrc b/.nvmrc index 7fd023741..13480246a 100644 --- a/.nvmrc +++ b/.nvmrc @@ -1 +1 @@ -v16.15.0 +v18.14.1 \ No newline at end of file diff --git a/.tool-versions b/.tool-versions index eedff58c8..ac4d6020f 100644 --- a/.tool-versions +++ b/.tool-versions @@ -1 +1 @@ -nodejs 16.16.0 +nodejs 18.14.1 diff --git a/astro.config.ts b/astro.config.ts index 00e9a466b..dea16d477 100644 --- a/astro.config.ts +++ b/astro.config.ts @@ -5,7 +5,6 @@ import svgr from "vite-plugin-svgr" import astroI18next from "astro-i18next" import { astroCallouts, asideAutoImport } from "./integrations/astro-callouts" import { solidityRemixCode, codeSampleAutoImport } from "./integrations/solidity-remix" -import { youtubeEmbed } from "./integrations/youtube-embed" import mdx from "@astrojs/mdx" import rehypeSlug from "rehype-slug" import rehypeAutolinkHeadings from "rehype-autolink-headings" @@ -13,7 +12,6 @@ import rehypeKatex from "rehype-katex" import rehypeMermaid from "rehype-mermaidjs" import remarkGfm from "remark-gfm" import remarkMath from "remark-math" -import image from "@astrojs/image" import AutoImport from "astro-auto-import" import sitemap from "@astrojs/sitemap" @@ -23,6 +21,7 @@ import tailwind from "@astrojs/tailwind" // https://astro.build/config export default defineConfig({ site: "https://docs.scroll.io", + scopedStyleStrategy: "where", legacy: { astroFlavoredMarkdown: true, }, @@ -39,14 +38,12 @@ export default defineConfig({ }), astroCallouts(), solidityRemixCode(), - youtubeEmbed(), mdx(), - image(), tailwind({ - // Example: Disable injecting a basic `base.css` import on every page. - // Useful if you need to define and/or import your own custom `base.css`. - config: { applyBaseStyles: false }, + applyBaseStyles: false, + nesting: true, }), + astroI18next(), ], vite: { @@ -61,7 +58,14 @@ export default defineConfig({ [ rehypeAutolinkHeadings, { - behavior: "append", + behavior: "wrap", + properties: {}, + content: { + type: "element", + tagName: "span", + properties: { className: ["icon", "icon-link"] }, + children: [], + }, }, ], [ diff --git a/integrations/youtube-embed.ts b/integrations/youtube-embed.ts deleted file mode 100644 index 85b3f191a..000000000 --- a/integrations/youtube-embed.ts +++ /dev/null @@ -1,25 +0,0 @@ -/** - * Add Youtube import to MD pages. - * Remove when astro supports 3rd party integration officially. - */ - -import type { AstroIntegration } from "astro" - -const CodeSampleTagName = "YouTube" -/** - * Astro integration that sets up the remark plugin and auto-imports the ` + + ### Hardhat Modify your Hardhat config file `hardhat.config.ts` to point at the Scroll Sepolia Testnet public RPC. diff --git a/src/content/docs/en/developers/ethereum-and-scroll-differences.mdx b/src/content/docs/en/developers/ethereum-and-scroll-differences.mdx index 5d73ae02b..cf728988e 100644 --- a/src/content/docs/en/developers/ethereum-and-scroll-differences.mdx +++ b/src/content/docs/en/developers/ethereum-and-scroll-differences.mdx @@ -4,7 +4,7 @@ date: Last Modified title: "Ethereum & Scroll Differences" lang: "en" permalink: "developers/ethereum-and-scroll-differences" -whatsnext: { "L1 & L2 Bridging": "/developers/l1-and-l2-bridging/" } +whatsnext: { "L1 & L2 Bridging": "/en/developers/l1-and-l2-bridging/" } excerpt: "There are a number of technical details that differ between Ethereum mainnet's EVM and Scroll's modified design for a zkEVM. Below you can see those differences as they exist now." --- @@ -20,6 +20,7 @@ For open-source contributors and infrastructure builders, please contact our tea ## EVM Opcodes + | Opcode | Solidity equivalent | Scroll Behavior | | --------------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------- | | `BLOCKHASH` | `block.blockhash` | Returns `keccak(chain_id \|\| block_number)` for the last 256 blocks. | @@ -28,12 +29,16 @@ For open-source contributors and infrastructure builders, please contact our tea | `BASEFEE` | `block.basefee` | Disabled.[^eip1559] If the opcode is encountered, the transaction will be reverted. | | `SELFDESTRUCT` | `selfdestruct` | Disabled. If the opcode is encountered, the transaction will be reverted.[^willadpot] | + + [^eip1559]: We have currently disabled EIP-1559 on Scroll. [^willadpot]: Will change to adopt Ethereum’s solution in the future. ## EVM Precompiles -The `SHA2-256` (address `0x2`), `RIPEMD-160` (address `0x3`), and `blake2f` (address `0x9`) precompiles are currently not supported. Calls to these precompiled contracts will revert. We plan to enable these three precompiles in a future hard fork. +The `RIPEMD-160` (address `0x3`) `blake2f` (address `0x9`), and `point evaluation` (address `0x0a`) precompiles are currently not supported. Calls to unsupported precompiled contracts will revert. We plan to enable these precompiles in future hard forks. The `modexp` precompile is supported but only supports inputs of size less than or equal to 32 bytes (i.e. `u256`). @@ -41,6 +46,21 @@ The `ecPairing` precompile is supported, but the number of points(sets, pairs) i The other EVM precompiles are all supported: `ecRecover`, `identity`, `ecAdd`, `ecMul`. +### Precompile Limits + +Because of a bounded size of the zkEVM circuits, there is an upper limit on the number of calls that can be made for some precompiles. These transactions will not revert, but simply be skipped by the sequencer if they cannot fit into the space of the circuit. Read more about the [Circuit Capacity Checker](/en/technology/sequencer/execution-node#circuit-capacity-checker). + +| Precompile / Opcode | Limit | +| ------------------- | ----- | +| `keccak256` | 3157 | +| `ecRecover` | 119 | +| `modexp` | 23 | +| `ecAdd` | 50 | +| `ecMul` | 50 | +| `ecPairing` | 2 | +{/* TODO: Add SHA256 after upgrade */} + + ## State Account ### **Additional Fields** diff --git a/src/content/docs/en/developers/guides/contract-deployment-tutorial.mdx b/src/content/docs/en/developers/guides/contract-deployment-tutorial.mdx index 60c126a9c..1f293a3fe 100644 --- a/src/content/docs/en/developers/guides/contract-deployment-tutorial.mdx +++ b/src/content/docs/en/developers/guides/contract-deployment-tutorial.mdx @@ -5,7 +5,7 @@ title: "Contract Deployment Tutorial" lang: "en" permalink: "developers/guides/contract-deployment-tutorial" excerpt: "The Scroll Sepolia Testnet allows the community to deploy smart contracts on Scroll. In this tutorial, we will teach you how to deploy a contract on Scroll Sepolia." -whatsnext: { "Scroll Messenger Cross-chain Interaction": "/developers/guides/scroll-messenger-cross-chain-interaction/" } +whatsnext: { "Scroll Messenger Cross-chain Interaction": "/en/developers/guides/scroll-messenger-cross-chain-interaction/" } --- import Aside from "../../../../../components/Aside.astro" diff --git a/src/content/docs/en/developers/guides/running-a-scroll-node.mdx b/src/content/docs/en/developers/guides/running-a-scroll-node.mdx index 58d2493ae..8f16b722c 100644 --- a/src/content/docs/en/developers/guides/running-a-scroll-node.mdx +++ b/src/content/docs/en/developers/guides/running-a-scroll-node.mdx @@ -4,21 +4,21 @@ date: Last Modified title: "Running a Scroll L2geth Node" lang: "en" permalink: "developers/guides/running-a-scroll-node" -excerpt: "This guide contains instructions on how to to run your own node on the Scroll network." +excerpt: "This guide contains instructions on how to run your own node on the Scroll network." --- import Aside from "../../../../../components/Aside.astro" import ToggleElement from "../../../../../components/ToggleElement.astro" -For most developers, using [our official RPC endpoint](../developer-quickstart#network-configuration) or one offered by other RPC providers in the ecosystem is the easiest way to get started on Scroll. For those looking to maintain their own node, this guide provides instructions on how to run a "follower node" that participates in the public mempool of transactions, but does not participate in consensus or block building. Scroll nodes are a fork of geth, using the clique protocol for consensus, which we call l2geth. +For most developers, using [our official RPC endpoint](/en/developers/developer-quickstart#network-configuration) or one offered by other RPC providers in the ecosystem is the easiest way to get started on Scroll. For those looking to maintain their own node, this guide provides instructions on how to run a "follower node" that participates in the public mempool of transactions, but does not participate in consensus or block building. Scroll nodes are a fork of geth, using the clique protocol for consensus, which we call l2geth. ## Prerequisites ### Finding the latest version -We recommend using the latest release at https://github.com/scroll-tech/go-ethereum/releases. For Scroll Mainnet, the required version is `scroll-v5.0.0` or higher. If you'd like to keep up with new node releases, go to https://github.com/scroll-tech/go-ethereum, click on **Watch**, **Custom**, and make sure that **Releases** is selected. +We recommend using the latest release at https://github.com/scroll-tech/go-ethereum/releases. The required version for Scroll Mainnet is `scroll-v5.3.0` or higher, and for Scroll Sepolia it is `scroll-v5.2.0` or higher. If you'd like to keep up with new node releases, go to https://github.com/scroll-tech/go-ethereum, click on **Watch**, **Custom**, and make sure that **Releases** is selected. -For the remainder of this guide, `VERSION` will denote the version tag. For example, `scroll-v5.1.10`. +For the remainder of this guide, `VERSION` will denote the version tag. For example, `scroll-v5.3.0`. ### Hardware Requirements @@ -288,6 +288,7 @@ enode://dd1ac5433c5c2b04ca3166f4cb726f8ff6d2da83dbc16d9b68b1ea83b7079b371eb16ef4 "londonBlock": 0, "archimedesBlock": 0, "shanghaiBlock": 0, + "bernoulliBlock": 3747132, "clique": { "period": 3, "epoch": 30000 diff --git a/src/content/docs/en/developers/guides/scroll-messenger-cross-chain-interaction.mdx b/src/content/docs/en/developers/guides/scroll-messenger-cross-chain-interaction.mdx index 8ba6476b8..9bb1c7f6f 100644 --- a/src/content/docs/en/developers/guides/scroll-messenger-cross-chain-interaction.mdx +++ b/src/content/docs/en/developers/guides/scroll-messenger-cross-chain-interaction.mdx @@ -4,7 +4,7 @@ date: Last Modified title: "Scroll Messenger Cross-chain Interaction" lang: "en" permalink: "developers/guides/scroll-messenger-cross-chain-interaction" -whatsnext: { "Bridge ERC20 through the Custom Gateway": "/developers/guides/bridge-erc20-through-the-custom-gateway" } +whatsnext: { "Bridge ERC20 through the Custom Gateway": "/en/developers/guides/bridge-erc20-through-the-custom-gateway" } excerpt: "In this example, we will launch a dummy smart contract on either Sepolia or Scroll Sepolia testnet and interact with it from the opposite chain." --- diff --git a/src/content/docs/en/developers/index.mdx b/src/content/docs/en/developers/index.mdx index d46fc8d4a..8a1135227 100644 --- a/src/content/docs/en/developers/index.mdx +++ b/src/content/docs/en/developers/index.mdx @@ -5,7 +5,7 @@ title: "Building on Scroll" lang: "en" permalink: "developers/" excerpt: "Building on Scroll feels just like Ethereum, and you can bring your favorite tooling and contracts with you." -whatsnext: { "Developer Quickstart": "/developers/developer-quickstart" } +whatsnext: { "Developer Quickstart": "/en/developers/developer-quickstart" } --- import Aside from "../../../../components/Aside.astro" @@ -80,7 +80,7 @@ ensuring that all code executed on the Scroll Layer 2 behaves just as if it were

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 that can provide real-world feedback. + testnet or mainnet, we’re excited to connect builders with users who can provide real-world feedback.

diff --git a/src/content/docs/en/developers/l1-and-l2-bridging.mdx b/src/content/docs/en/developers/l1-and-l2-bridging.mdx index b30000ef4..abf53308f 100644 --- a/src/content/docs/en/developers/l1-and-l2-bridging.mdx +++ b/src/content/docs/en/developers/l1-and-l2-bridging.mdx @@ -4,7 +4,7 @@ date: Last Modified title: "L1 and L2 Bridging" lang: "en" permalink: "developers/l1-and-l2-bridging" -whatsnext: { "ETH & ERC20 Token Bridge": "/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge/" } +whatsnext: { "ETH & ERC20 Token Bridge": "/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge/" } excerpt: "An overview of Scroll's Bridging architecture" --- @@ -26,12 +26,12 @@ In addition to token transfers, the Scroll Messenger contract enables cross-chai -There are many entry points from the user to the Scroll bridge. This will depend on what you want to do and how you want to do it. If you want to send ETH or ERC20 tokens, you should use the `GatewayRouter` . If you want to send NFTs, you should use the `L1ERC721Gateway` or `L1ERC1155Gateway`. If you want to send arbitrary data, you should use the `L1ScrollMessenger`. All Gateway transfers use the Scroll Messenger to send assets cross-chain, whose job is to append the transactions to the Message Queue for L2 inclusion. +There are many entry points from the user to the Scroll bridge. This will depend on what you want to do and how you want to do it. If you want to send ETH or ERC20 tokens, you should use the `GatewayRouter`. If you want to send NFTs, you should use the `L1ERC721Gateway` or `L1ERC1155Gateway`. If you want to send arbitrary data, you should use the `L1ScrollMessenger`. All Gateway transfers use the Scroll Messenger to send assets cross-chain, whose job is to append the transactions to the Message Queue for L2 inclusion. ## L2 Gateway architecture -Regarding possible permissionlessly callable entry points, the L2 Gateway Architecture is very similar to L1. The difference is that when sending a message from L2, calling the `appendMessage` function will store the message in an append-only binary merkle tree (aka withdraw tree) in the `L2MessageQueue`. When a new message is sent to the `L2MessageQueue`, the relayer will detect it and store it in the database. When the block is finalized, it will generate a proof of the new merkle path and pass it to the L1geth node to execute on `L1ScrollMessenger` . All finalized withdraw roots will be stored in the rollup contract so we can verify the proof against them. In the next Scroll versions, the Relayer won't be needed since all users will be able to finalize the transaction on L1. +Regarding possible permissionlessly callable entry points, the L2 Gateway Architecture is very similar to L1. The difference is that when sending a message from L2, calling the `appendMessage` function will store the message in an append-only binary merkle tree (aka withdraw tree) in the `L2MessageQueue`. When a new message is sent to the `L2MessageQueue`, the relayer will detect it and store it in the database. When the block is finalized, it will generate a proof of the new merkle path and pass it to the L1geth node to execute on `L1ScrollMessenger`. All finalized withdraw roots will be stored in the rollup contract so we can verify the proof against them. In the next Scroll versions, the Relayer won't be needed since all users will be able to finalize the transaction on L1. -In the upcoming sections, we will explore the technical aspects of the bridge, including the smart contract API required to utilize its capabilities. Detailed guides with code examples are provided in the Developer Guides section to assist developers and users in understanding and implementing these functionalities. \ No newline at end of file +In the upcoming sections, we will explore the technical aspects of the bridge, including the smart contract API required to utilize its capabilities. Detailed guides with code examples are provided in the Developer Guides section to assist developers and users in understanding and implementing these functionalities. diff --git a/src/content/docs/en/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx b/src/content/docs/en/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx index 082ab18fd..e766893e4 100644 --- a/src/content/docs/en/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx +++ b/src/content/docs/en/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx @@ -4,7 +4,7 @@ date: Last Modified title: "ERC1155 Token Bridge" lang: "en" permalink: "developers/l1-and-l2-bridging/erc1155-token-bridge" -whatsnext: { "The Scroll Messenger": "/developers/l1-and-l2-bridging/the-scroll-messenger/" } +whatsnext: { "The Scroll Messenger": "/en/developers/l1-and-l2-bridging/the-scroll-messenger/" } excerpt: "ERC1155 bridging from L1 to L2 is done via the L1ERC1155Gateway." --- @@ -52,7 +52,7 @@ interface IScrollERC1155 { /// @notice Batch mint some token to recipient's account. /// @dev Gateway Utilities, only gateway contract can call /// @param _to The address of recipient. - /// @param _tokenIds The token id to mint. + /// @param _tokenIds The list of token ids to mint. /// @param _amounts The list of corresponding amount of token to mint. /// @param _data The data passed to recipient function batchMint( @@ -158,5 +158,5 @@ Update the mapping that connects an ERC1155 token contract from L2 to L1. | Parameter | Description | | --------- | ------------------------------------------------- | -| \_l1Token | The address of th ERC1155 token in L1. | +| \_l1Token | The address of the ERC1155 token in L1. | | \_l2Token | The address of corresponding ERC1155 token in L2. | diff --git a/src/content/docs/en/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx b/src/content/docs/en/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx index c14966466..60828c338 100644 --- a/src/content/docs/en/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx +++ b/src/content/docs/en/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx @@ -5,7 +5,7 @@ title: "ERC721 NFT Bridge" lang: "en" permalink: "developers/l1-and-l2-bridging/erc721-nft-bridge" excerpt: "NFT bridging from L1 to L2 is done via the L1ERC721Gateway contract instead of using a router." -whatsnext: { "ERC1155 Token Bridge": "/developers/l1-and-l2-bridging/erc1155-token-bridge/" } +whatsnext: { "ERC1155 Token Bridge": "/en/developers/l1-and-l2-bridging/erc1155-token-bridge/" } --- import Aside from "../../../../../components/Aside.astro" diff --git a/src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx b/src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx index b46d30062..8999637f8 100644 --- a/src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx +++ b/src/content/docs/en/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx @@ -4,7 +4,7 @@ date: Last Modified title: "ETH and ERC20 Token Bridge" lang: "en" permalink: "developers/l1-and-l2-bridging/eth-and-erc20-token-bridge" -whatsnext: { "ERC721 NFT Bridge": "/developers/l1-and-l2-bridging/erc721-nft-bridge/" } +whatsnext: { "ERC721 NFT Bridge": "/en/developers/l1-and-l2-bridging/erc721-nft-bridge/" } excerpt: "The Gateway Router allows ETH and ERC20 token bridging from L1 to L2 using the depositETH and depositERC20 functions respectively." --- @@ -33,7 +33,7 @@ All Gateway contracts will form the message and send it to the `L1ScrollMessenge address of the `L1ScrollMessenger`. -When a new block gets created on L1, the Watcher will detect the message on the `L1MessageQueue` and will pass it to the Relayer service, which will submit the transaction to the L2 via the l2geth node. Finally, the l2geth node will pass the transaction to the `L2ScrollMessagner` contract for execution on L2. +When a new block gets created on L1, the Watcher will detect the message on the `L1MessageQueue` and will pass it to the Relayer service, which will submit the transaction to the L2 via the l2geth node. Finally, the l2geth node will pass the transaction to the `L2ScrollMessenger` contract for execution on L2. ## Withdraw ETH and ERC20 tokens from L2 @@ -76,7 +76,7 @@ interface IScrollStandardERC20 { /// @param _amount The amount of token to mint. function mint(address _to, uint256 _amount) external; - /// @notice Mint some token from account. + /// @notice Burn some token from account. /// @dev Gateway Utilities, only gateway contract can call /// @param _from The address of account to burn token. /// @param _amount The amount of token to mint. diff --git a/src/content/docs/en/developers/l1-and-l2-bridging/the-scroll-messenger.mdx b/src/content/docs/en/developers/l1-and-l2-bridging/the-scroll-messenger.mdx index 284210f2e..d18efb807 100644 --- a/src/content/docs/en/developers/l1-and-l2-bridging/the-scroll-messenger.mdx +++ b/src/content/docs/en/developers/l1-and-l2-bridging/the-scroll-messenger.mdx @@ -4,7 +4,7 @@ date: Last Modified title: "The Scroll Messenger" lang: "en" permalink: "developers/l1-and-l2-bridging/the-scroll-messenger" -whatsnext: { "Transaction Fees on Scroll": "/developers/transaction-fees-on-scroll/" } +whatsnext: { "Transaction Fees on Scroll": "/en/developers/transaction-fees-on-scroll/" } excerpt: "The Scroll Messenger documentation for arbitrary message passing between L1 and L2." --- diff --git a/src/content/docs/en/developers/scroll-contracts.mdx b/src/content/docs/en/developers/scroll-contracts.mdx index f1b251997..6d30f8f72 100644 --- a/src/content/docs/en/developers/scroll-contracts.mdx +++ b/src/content/docs/en/developers/scroll-contracts.mdx @@ -4,7 +4,7 @@ date: Last Modified title: "Scroll Contracts" lang: "en" permalink: "developers/scroll-contracts" -whatsnext: { "Ethereum & Scroll Differences": "/developers/ethereum-and-scroll-differences" } +whatsnext: { "Ethereum & Scroll Differences": "/en/developers/ethereum-and-scroll-differences" } excerpt: "The network info and contract addresses you need to start with Scroll Sepolia Testnet." --- @@ -100,6 +100,21 @@ Use the table below to configure your Ethereum tools to the Scroll mainnet. - v3StakerAddress: [`0xFdFbE973c9ecB036Ecfb7af697FcACe789D3f928`](https://scrollscan.com/address/0xFdFbE973c9ecB036Ecfb7af697FcACe789D3f928) - quoterV2Address: [`0x2566e082Cb1656d22BCbe5644F5b997D194b5299`](https://scrollscan.com/address/0x2566e082Cb1656d22BCbe5644F5b997D194b5299) +### Safe + +You can access Safe on Scroll [here](https://safe.scroll.xyz/), and the transaction service API is at https://transaction.safe.scroll.xyz. + +- CompatibilityFallbackHandler: [`0xf48f2B2d2a534e402487b3ee7C18c33Aec0Fe5e4`](https://scrollscan.com/address/0xf48f2B2d2a534e402487b3ee7C18c33Aec0Fe5e4) +- CreateCall: [`0x7cbB62EaA69F79e6873cD1ecB2392971036cFAa4`](https://scrollscan.com/address/0x7cbB62EaA69F79e6873cD1ecB2392971036cFAa4) +- DefaultCallbackHandler: [`0x1AC114C2099aFAf5261731655Dc6c306bFcd4Dbd`](https://scrollscan.com/address/0x1AC114C2099aFAf5261731655Dc6c306bFcd4Dbd) +- GnosisSafe: [`0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552`](https://scrollscan.com/address/0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552) +- GnosisSafeL2: [`0x3E5c63644E683549055b9Be8653de26E0B4CD36E`](https://scrollscan.com/address/0x3E5c63644E683549055b9Be8653de26E0B4CD36E) +- GnosisSafeProxyFactory: [`0xa6B71E26C5e0845f74c812102Ca7114b6a896AB2`](https://scrollscan.com/address/0xa6B71E26C5e0845f74c812102Ca7114b6a896AB2) +- MultiSend: [`0xA238CBeb142c10Ef7Ad8442C6D1f9E89e07e7761`](https://scrollscan.com/address/0xA238CBeb142c10Ef7Ad8442C6D1f9E89e07e7761) +- MultiSendCallOnly: [`0x40A2aCCbd92BCA938b02010E17A5b8929b49130D`](https://scrollscan.com/address/0x40A2aCCbd92BCA938b02010E17A5b8929b49130D) +- SignMessageLib: [`0xA65387F16B013cf2Af4605Ad8aA5ec25a2cbA3a2`](https://scrollscan.com/address/0xA65387F16B013cf2Af4605Ad8aA5ec25a2cbA3a2) +- SimulateTxAccessor: [`0x59AD6735bCd8152B84860Cb256dD9e96b85F69Da`](https://scrollscan.com/address/0x59AD6735bCd8152B84860Cb256dD9e96b85F69Da) + #### Ethereum Attestation Service (EAS) - EAS: [`0xC47300428b6AD2c7D03BB76D05A176058b47E6B0`](https://scrollscan.com/address/0xC47300428b6AD2c7D03BB76D05A176058b47E6B0) @@ -224,6 +239,21 @@ See this [Github gist](https://gist.github.com/dghelm/7fe68f0a524f30846e1142721c - EIP712Proxy: [`0xB3574f76b1720E61FdA98702c7016674CD6Eaa7b`](https://sepolia.scrollscan.com/address/0xB3574f76b1720E61FdA98702c7016674CD6Eaa7b) - Indexer: [`0x7C2cb1eDC328491da52de2a0afc44D3B0Ae7ee17`](https://sepolia.scrollscan.com/address/0x7C2cb1eDC328491da52de2a0afc44D3B0Ae7ee17) +### Safe + +You can access Safe on Scroll [here](https://safe.scroll.xyz/), and the transaction service API is at https://transaction-sepolia.safe.scroll.xyz. + +- CompatibilityFallbackHandler: [`0xf48f2B2d2a534e402487b3ee7C18c33Aec0Fe5e4`](https://sepolia.scrollscan.com/address/0xf48f2B2d2a534e402487b3ee7C18c33Aec0Fe5e4) +- CreateCall: [`0x7cbB62EaA69F79e6873cD1ecB2392971036cFAa4`](https://sepolia.scrollscan.com/address/0x7cbB62EaA69F79e6873cD1ecB2392971036cFAa4) +- DefaultCallbackHandler: [`0x1AC114C2099aFAf5261731655Dc6c306bFcd4Dbd`](https://sepolia.scrollscan.com/address/0x1AC114C2099aFAf5261731655Dc6c306bFcd4Dbd) +- GnosisSafe: [`0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552`](https://sepolia.scrollscan.com/address/0xd9Db270c1B5E3Bd161E8c8503c55cEABeE709552) +- GnosisSafeL2: [`0x3E5c63644E683549055b9Be8653de26E0B4CD36E`](https://sepolia.scrollscan.com/address/0x3E5c63644E683549055b9Be8653de26E0B4CD36E) +- GnosisSafeProxyFactory: [`0xa6B71E26C5e0845f74c812102Ca7114b6a896AB2`](https://sepolia.scrollscan.com/address/0xa6B71E26C5e0845f74c812102Ca7114b6a896AB2) +- MultiSend: [`0xA238CBeb142c10Ef7Ad8442C6D1f9E89e07e7761`](https://sepolia.scrollscan.com/address/0xA238CBeb142c10Ef7Ad8442C6D1f9E89e07e7761) +- MultiSendCallOnly: [`0x40A2aCCbd92BCA938b02010E17A5b8929b49130D`](https://sepolia.scrollscan.com/address/0x40A2aCCbd92BCA938b02010E17A5b8929b49130D) +- SignMessageLib: [`0xA65387F16B013cf2Af4605Ad8aA5ec25a2cbA3a2`](https://sepolia.scrollscan.com/address/0xA65387F16B013cf2Af4605Ad8aA5ec25a2cbA3a2) +- SimulateTxAccessor: [`0x59AD6735bCd8152B84860Cb256dD9e96b85F69Da`](https://sepolia.scrollscan.com/address/0x59AD6735bCd8152B84860Cb256dD9e96b85F69Da) + ### Additional Useful Contracts - Multicall3: [`0xcA11bde05977b3631167028862bE2a173976CA11`](https://sepolia.scrollscan.com/address/0xcA11bde05977b3631167028862bE2a173976CA11) diff --git a/src/content/docs/en/developers/transaction-fees-on-scroll.mdx b/src/content/docs/en/developers/transaction-fees-on-scroll.mdx index 75cc1d056..31785a135 100644 --- a/src/content/docs/en/developers/transaction-fees-on-scroll.mdx +++ b/src/content/docs/en/developers/transaction-fees-on-scroll.mdx @@ -4,7 +4,7 @@ date: Last Modified title: "Transaction Fees on Scroll" lang: "en" permalink: "developers/transaction-fees-on-scroll" -whatsnext: { "Contract Deployment Tutorial": "/developers/guides/contract-deployment-tutorial/" } +whatsnext: { "Contract Deployment Tutorial": "/en/developers/guides/contract-deployment-tutorial/" } excerpt: "Understand how L1 and L2 transaction fees work on Scroll " --- @@ -178,7 +178,7 @@ On Sepolia, an upgraded `L1MessageQueueWithGasPriceOracle` should be used, deplo If your system supports off-chain mechanisms, you can also call `eth_estimateGas` and `eth_gasPrice` on any Scroll RPC node to get an estimate of the gas required for a given transaction. diff --git a/src/content/docs/en/getting-started/overview.md b/src/content/docs/en/getting-started/overview.md index acddb22f3..53866abbe 100644 --- a/src/content/docs/en/getting-started/overview.md +++ b/src/content/docs/en/getting-started/overview.md @@ -5,12 +5,12 @@ title: "Scroll Overview" lang: "en" permalink: "docs/conceptual-overview/" excerpt: "ZK Rollups and Scroll" -whatsnext: { "User Guide": "/user-guide/", "Building on Scroll": "/developers/" } +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, and if you've ever used or developed an application on Ethereum, you'll be right at home on Scroll. +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/). @@ -20,7 +20,7 @@ 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 proofs (”zk”), 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. +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. diff --git a/src/content/docs/en/learn/intro-to-rollups.md b/src/content/docs/en/learn/intro-to-rollups.md index 68e9b4c19..990445c84 100644 --- a/src/content/docs/en/learn/intro-to-rollups.md +++ b/src/content/docs/en/learn/intro-to-rollups.md @@ -5,12 +5,12 @@ 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": "/technology/chain/rollup" } +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. +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). @@ -22,13 +22,13 @@ In order for a rollup to be secure, it must prove that its off-chain computation An optimistic rollup is a rollup that uses fraud proofs to assert the validity of its computation. -Fraud proofs are a mechanism that allow 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. +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 which results from correctly executing the batch of transactions. +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). diff --git a/src/content/docs/en/learn/the-scalability-problem.md b/src/content/docs/en/learn/the-scalability-problem.md index 984d28c29..c5055fd6c 100644 --- a/src/content/docs/en/learn/the-scalability-problem.md +++ b/src/content/docs/en/learn/the-scalability-problem.md @@ -5,7 +5,7 @@ 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": "/learn/intro-to-rollups" } +whatsnext: { "Intro to Rollups": "/en/learn/intro-to-rollups" } --- ## Ethereum’s scaling problem @@ -24,4 +24,4 @@ There are primarily two types of scaling solutions: layer 1 scaling solutions an **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 which 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. +**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 index 4dd9e9679..01ae590ba 100644 --- 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 @@ -16,7 +16,7 @@ Looking to dive deeper into ZK? Here are some of our favorite resources. - [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 towards academics and audiences with mathematical maturity. + - 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. 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 index 1de1bf7d0..77c6817bf 100644 --- 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 @@ -4,7 +4,7 @@ date: Last Modified title: "Introduction to Zero Knowledge" lang: "en" permalink: "learn/zero-knowledge/introduction-to-zero-knowledge" -whatsnext: { "Polynomial Commitment Schemes": "/learn/zero-knowledge/polynomial-commitment-schemes" } +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.' --- @@ -38,9 +38,9 @@ The above properties of ZKPs are extremely useful in the context of verifiabilit 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 (know to only the prover), or mixed (some inputs are public and some are private). +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. +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. @@ -62,7 +62,7 @@ The proof, along with the puzzle, could be passed to Bob, who could then use a * ## 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 these challenges. +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. 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 index 1ff01ca4b..6d25e00b7 100644 --- a/src/content/docs/en/learn/zero-knowledge/kzg-commitment-scheme.md +++ b/src/content/docs/en/learn/zero-knowledge/kzg-commitment-scheme.md @@ -5,7 +5,7 @@ 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": "/learn/zero-knowledge/additional-zk-learning-resources" } +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. @@ -51,7 +51,7 @@ There are established methods of conducting trusted setup ceremonies with weak t - 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 that the quotient polynomial is correctly formed at $\tau$: $Q(\tau) = \frac{P(\tau) -b}{\tau-a}$ + - 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 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 index 299976d0a..535c19104 100644 --- a/src/content/docs/en/learn/zero-knowledge/polynomial-commitment-schemes.md +++ b/src/content/docs/en/learn/zero-knowledge/polynomial-commitment-schemes.md @@ -5,7 +5,7 @@ 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": "/learn/zero-knowledge/kzg-commitment-scheme" } +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). diff --git a/src/content/docs/en/technology/bridge/cross-domain-messaging.mdx b/src/content/docs/en/technology/bridge/cross-domain-messaging.mdx index fa1bb858f..359484f8a 100644 --- a/src/content/docs/en/technology/bridge/cross-domain-messaging.mdx +++ b/src/content/docs/en/technology/bridge/cross-domain-messaging.mdx @@ -4,7 +4,7 @@ date: Last Modified title: "Cross-Domain Messaging" lang: "en" permalink: "technology/bridge/cross-domain-messaging" -whatsnext: { "Deposit Gateways": "/technology/bridge/deposit-gateways/" } +whatsnext: { "Deposit Gateways": "/en/technology/bridge/deposit-gateways/" } --- import ClickToZoom from "../../../../../components/ClickToZoom.astro" @@ -60,7 +60,7 @@ Both functions construct an L1-initiated transaction with a new transaction type - `appendCrossDomainMessage` can be only called by `L1ScrollMessenger` and it uses the [aliased address](#address-alias) of `msg.sender`, which will be the address of `L1ScrollMessenger`, as the transaction sender. - `appendEnforcedTransaction` can be only called by `EnforcedTxGateway` and it uses `sender` from the function parameter as the transaction sender. This allows users to enforce a withdrawal or transfer of ETH from their L2 accounts directly through the L1 bridge. -After the transaction is successfully executed on L1, the watcher in the Scroll sequencer that monitors the `L1MessageQueue` contract collects the new `QueueTransaction` events from L1 blocks. The sequencer then constructs a new `L1MessageTx` transaction per event and appends them to its local L1 transaction queue. When constructing a new L2 block, the sequencer includes the transactions from both its L1 transaction queue and its L2 mempool. Note that the L1 message transactions must be included sequentially based on the L1 message queue order in the `L1MessageQueue` contract. `L1MessageTx` transactions always come first in the L2 blocks followed by L2 transactions. Currently, we limit the number of `L1MessageTx` transactions in a L2 block to `NumL1MessagesPerBlock` (currently set to 10). +After the transaction is successfully executed on L1, the watcher in the Scroll sequencer that monitors the `L1MessageQueue` contract collects the new `QueueTransaction` events from L1 blocks. The sequencer then constructs a new `L1MessageTx` transaction per event and appends them to its local L1 transaction queue. When constructing a new L2 block, the sequencer includes the transactions from both its L1 transaction queue and its L2 mempool. Note that the L1 message transactions must be included sequentially based on the L1 message queue order in the `L1MessageQueue` contract. `L1MessageTx` transactions always come first in the L2 blocks followed by L2 transactions. Currently, we limit the number of `L1MessageTx` transactions in an L2 block to `NumL1MessagesPerBlock` (currently set to 10). Next, we will expand more on the specific process of sending arbitrary messages via `L1ScrollMessenger` and sending enforced transactions via `EnforcedTxGateway`. @@ -162,7 +162,7 @@ Similar to arbitrary message relaying, `sendTransaction` deducts the message rel ### Retrying Failed Messages -If a `L1MessageTx` transaction fails on L2 due to insufficient gas, users can replay the message with a higher gas limit. `L1ScrollMessenger` provides the method `replayMessage` that allows users to send the same information as the previous failed message with a higher gas limit. This message will become a new `L1MessageTx` transaction on L2. Note that we won't refund the gas fee for the previous failed transaction as it is already processed on L2. +If an `L1MessageTx` transaction fails on L2 due to insufficient gas, users can replay the message with a higher gas limit. `L1ScrollMessenger` provides the method `replayMessage` that allows users to send the same information as the previous failed message with a higher gas limit. This message will become a new `L1MessageTx` transaction on L2. Note that we won't refund the gas fee for the previous failed transaction as it is already processed on L2.
replayMessage function signature
diff --git a/src/content/docs/en/technology/bridge/deposit-gateways.mdx b/src/content/docs/en/technology/bridge/deposit-gateways.mdx index bbb4636b2..72adf4c3f 100644 --- a/src/content/docs/en/technology/bridge/deposit-gateways.mdx +++ b/src/content/docs/en/technology/bridge/deposit-gateways.mdx @@ -4,7 +4,7 @@ date: Last Modified title: "Deposit Gateways" lang: "en" permalink: "technology/bridge/deposit-gateways" -whatsnext: { "Withdraw Gateways": "/technology/bridge/withdraw-gateways/" } +whatsnext: { "Withdraw Gateways": "/en/technology/bridge/withdraw-gateways/" } --- import ClickToZoom from "../../../../../components/ClickToZoom.astro" @@ -80,7 +80,7 @@ The deposit of ERC20 tokens works as follows. ) public payable; ``` -2. Based on the mapping from ERC20 tokens to gateway, the `L1GatewayRouter` calls to the corresponding gateway: `L1StandardERC20Gateway`, `L1CustomERC20Gateway`, or `L1WETHGateway`. The remaining of steps will be described separately. +2. Based on the mapping from ERC20 tokens to gateway, the `L1GatewayRouter` calls to the corresponding gateway: `L1StandardERC20Gateway`, `L1CustomERC20Gateway`, or `L1WETHGateway`. The remaining steps will be described separately. ### Standard ERC20 Tokens @@ -96,10 +96,10 @@ Standard ERC20 tokens are tokens that do not require any custom logic. For such ### Custom ERC20 Tokens -In comparison to standard ERC20 tokens, the L2 contract of custom ERC20 tokens are deployed by the token owner. The remaining steps for custom ERC20 token deposit are: +In comparison to standard ERC20 tokens, the L2 contract of custom ERC20 tokens is deployed by the token owner. The remaining steps for custom ERC20 token deposit are: 3. The `L1CustomERC20Gateway` contract locks the ERC20 tokens on L1 by transferring them from the sender to itself. -4. `L1CustomERC20Gateway` requires a L2 ERC20 token address present in the `tokenMapping`. It retrieves the corresponding ERC20 token address, encodes the token deposit message, and forwards it to `L1ScrollMessenger`. +4. `L1CustomERC20Gateway` requires an L2 ERC20 token address present in the `tokenMapping`. It retrieves the corresponding ERC20 token address, encodes the token deposit message, and forwards it to `L1ScrollMessenger`. 5. The corresponding L2 transaction calls the `L2ScrollMessenger.relayMessage` function to finalize the deposit on L2. In the case of custom ERC20 token deposits, the transaction calls `L2CustomERC20Gateway.finalizeDepositERC20`. 6. `L2CustomERC20Gateway` calls the mint function on the corresponding L2 ERC20 token contract. It is required that the L2 ERC20 token contract grants mint permissions to the `L2CustomERC20Gateway` contract. 7. If the user calls `depositERC20AndCall` on L1, the `L2CustomERC20Gateway` will call the target L2 contract with additional data. diff --git a/src/content/docs/en/technology/bridge/withdraw-gateways.mdx b/src/content/docs/en/technology/bridge/withdraw-gateways.mdx index 5b0053981..bef07b452 100644 --- a/src/content/docs/en/technology/bridge/withdraw-gateways.mdx +++ b/src/content/docs/en/technology/bridge/withdraw-gateways.mdx @@ -4,7 +4,7 @@ date: Last Modified title: "Withdraw Gateways" lang: "en" permalink: "technology/bridge/withdraw-gateways" -whatsnext: { "Sequencer": "/technology/sequencer/execution-node/" } +whatsnext: { "Sequencer": "/en/technology/sequencer/execution-node/" } --- import ClickToZoom from "../../../../../components/ClickToZoom.astro" @@ -27,7 +27,7 @@ This document describes how users and developers can utilize gateways to withdra -The figure depicts the withdrawal workflow from L2 to L1. Users call the gateways to initialize the token withdrawal. The withdrawal is encoded into a message sent to the `L2ScrollMessenger`, which is then appended to the `L2MessageQueue`. `L2MessageQueue` maintains a Withdraw Trie and updates the root every time a new message appended. The Withdraw Trie root is finalized on the L1 rollup contract along with the L2 state root. After the new Withdraw Trie root is finalized on the L1, users or third parties can then construct a valid Merkle Inclusion Proof to the Withdraw Trie root and send a _withdraw execution_ transaction to finalize the withdrawal on L1. You can find more details about the L2-to-L1 message relay workflow in the [Cross-Domain Messaging](/technology/bridge/cross-domain-messaging#sending-messages-from-l2-to-l1). +The figure depicts the withdrawal workflow from L2 to L1. Users call the gateways to initialize the token withdrawal. The withdrawal is encoded into a message sent to the `L2ScrollMessenger`, which is then appended to the `L2MessageQueue`. `L2MessageQueue` maintains a Withdraw Trie and updates the root every time a new message is appended. The Withdraw Trie root is finalized on the L1 rollup contract along with the L2 state root. After the new Withdraw Trie root is finalized on the L1, users or third parties can then construct a valid Merkle Inclusion Proof to the Withdraw Trie root and send a _withdraw execution_ transaction to finalize the withdrawal on L1. You can find more details about the L2-to-L1 message relay workflow in the [Cross-Domain Messaging](/technology/bridge/cross-domain-messaging#sending-messages-from-l2-to-l1). The subsequent sections describe the details of how different tokens are withdrawn. @@ -57,9 +57,9 @@ The withdrawal of ETH token works as follows. ## Withdrawing ERC20 Tokens -The withdraw of ERC20 tokens works as follows. +The withdrawal of ERC20 tokens works as follows. -1. To withdraw ERC20 tokens from L1 to L2, users can use `L2GatewayRouter.withdrawERC20` and `L2GatewayRouter.withdrawERC20AndCall` showed below. +1. To withdraw ERC20 tokens from L2 to L1, users can use `L2GatewayRouter.withdrawERC20` and `L2GatewayRouter.withdrawERC20AndCall` showed below. ```solidity function withdrawERC20(address _token, uint256 _amount, uint256 _gasLimit) external payable; @@ -75,15 +75,15 @@ The withdraw of ERC20 tokens works as follows. ) public payable; ``` -2. Based on the mapping from ERC20 tokens to gateway, the `L2GatewayRouter` calls to the corresponding gateway, `L2StandardERC20Gateway`, `L2CustomERC20Gateway`, or `L2WETHGateway`. The remaining of steps will be described separately. +2. Based on the mapping from ERC20 tokens to gateway, the `L2GatewayRouter` calls to the corresponding gateway, `L2StandardERC20Gateway`, `L2CustomERC20Gateway`, or `L2WETHGateway`. The remaining steps will be described separately. ### Standard and Custom ERC20 Tokens The withdrawal of standard and custom ERC20 tokens works in the same way as follows. 3. The `L2StandardERC20Gateway` or `L2CustomERC20Gateway` contract burns the withdrawn ERC20 token, encodes the withdrawal into a message, and sends it to `L2ScrollMessenger`. -4. The L1 withdrawal execution transaction calls `L1ScrollMessenger.relayMessageWithProof` function to finalize the withdrawals on L1. In the case of standard or custome ERC20 token withdrawal, the transaction calls `finalizeWithdrawERC20` function on the `L1StandardERC20Gateway` or `L1CustomERC20Gateway` contract respectively. - - In the `L1StandardERC20Gateway` contract, if this is the first withdrawal transaction of a ERC20 token, `finalizeWithdrawERC20` function will update the mapping from L1 token address to its L2 token address in the `tokenMapping`. +4. The L1 withdrawal execution transaction calls `L1ScrollMessenger.relayMessageWithProof` function to finalize the withdrawals on L1. In the case of standard or custom ERC20 token withdrawal, the transaction calls `finalizeWithdrawERC20` function on the `L1StandardERC20Gateway` or `L1CustomERC20Gateway` contract respectively. + - In the `L1StandardERC20Gateway` contract, if this is the first withdrawal transaction of an ERC20 token, `finalizeWithdrawERC20` function will update the mapping from L1 token address to its L2 token address in the `tokenMapping`. 5. The L1 ERC20 token gateway releases the locked ERC20 tokens by transferring them from itself to the recipient address on L1. 6. If the user calls `withdrawERC20AndCall` on L2, the gateways will call the target L1 contract with additional data. diff --git a/src/content/docs/en/technology/chain/accounts.mdx b/src/content/docs/en/technology/chain/accounts.mdx index a478e5766..812ad8470 100644 --- a/src/content/docs/en/technology/chain/accounts.mdx +++ b/src/content/docs/en/technology/chain/accounts.mdx @@ -4,12 +4,12 @@ date: Last Modified title: "Accounts and State" lang: "en" permalink: "technology/chain/accounts-and-state" -whatsnext: { "Transactions": "/technology/chain/transactions/" } +whatsnext: { "Transactions": "/en/technology/chain/transactions/" } --- ## Accounts -Same as Ethereum, Scroll has two account types: Externally-owned account (EOA) and contract account that holds the smart contract and additional storages. +Same as Ethereum, Scroll has two account types: Externally-owned account (EOA) and contract account that holds the smart contract and additional storage. Scroll stores additional information of the contract bytecode in the account to facilitate the zkEVM circuit to prove the state transition more efficiently. @@ -26,4 +26,4 @@ The account in Scroll contains the following fields: The state of a blockchain is a collection of account data. The _state trie_ encodes account data and their corresponding addresses to a [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree) data structure. The root of tree, or the state of the blockchain, is a cryptographic digest of all the account data contained in the tree. -Ethereum uses a data structure called [Patricia Merkle Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) for both the state trie and the storage trie that stores the key-value entries stored in a smart contract. In Scroll, we replace the Patricia Merkle Trie by a more zk-friendly data structure, called zkTrie, for both state trie and storage trie. At a high level, the zkTrie data structure is a sparse binary Merkle tree with the [Poseidon hash](https://eprint.iacr.org/2019/458.pdf), a zk-friendly hash function. The [zkTrie](/technology/sequencer/zktrie) document describes more details about this data structure. +Ethereum uses a data structure called [Patricia Merkle Trie](https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) for both the state trie and the storage trie that stores the key-value entries stored in a smart contract. In Scroll, we replace the Patricia Merkle Trie with a more zk-friendly data structure, called zkTrie, for both state trie and storage trie. At a high level, the zkTrie data structure is a sparse binary Merkle tree with the [Poseidon hash](https://eprint.iacr.org/2019/458.pdf), a zk-friendly hash function. The [zkTrie](/technology/sequencer/zktrie) document describes more details about this data structure. diff --git a/src/content/docs/en/technology/chain/blocks.mdx b/src/content/docs/en/technology/chain/blocks.mdx index eb6f716d6..7cc6d491d 100644 --- a/src/content/docs/en/technology/chain/blocks.mdx +++ b/src/content/docs/en/technology/chain/blocks.mdx @@ -4,7 +4,7 @@ date: Last Modified title: "Blocks" lang: "en" permalink: "technology/chain/blocks" -whatsnext: { "Rollup Process": "/technology/chain/rollup/" } +whatsnext: { "Rollup Process": "/en/technology/chain/rollup/" } --- A block is a collection of transactions and links to the previous block it extends. @@ -27,7 +27,7 @@ The block header in Scroll mirrors the structure of Ethereum's. However, certain | `gasLimit` | The maximum gas allowed in the block. | | `gasUsed` | The gas used in the block. | | `timestamp` | The block time. | -| `extraData` | Signature by the block's signer, followd by arbitrary additional data. | +| `extraData` | Signature by the block's signer, followed by arbitrary additional data. | | `mixHash` | Always 0. | | `nonce` | Always 0. | | `baseFee` | Currently empty in Scroll because we haven't enabled the EIP-1559. | @@ -36,4 +36,4 @@ The block header in Scroll mirrors the structure of Ethereum's. However, certain Block time refers to the interval between two consecutive blocks. In Scroll, the block time is set at 3s. A reduced block time elevates the user experience and augments the Scroll chain's scalability. -The 3 second block time is maintained on a best effort basis, it is not guaranteed or enforced by the protocol. +The 3-second block time is maintained on a best-effort basis, it is not guaranteed or enforced by the protocol. diff --git a/src/content/docs/en/technology/chain/differences.mdx b/src/content/docs/en/technology/chain/differences.mdx index bbb6dac52..ad02ed0a8 100644 --- a/src/content/docs/en/technology/chain/differences.mdx +++ b/src/content/docs/en/technology/chain/differences.mdx @@ -4,9 +4,11 @@ date: Last Modified title: "EVM Differences from Ethereum" lang: "en" permalink: "technology/chain/differences" -whatsnext: { "Bridge": "/technology/bridge/cross-domain-messaging/" } +whatsnext: { "Bridge": "/en/technology/bridge/cross-domain-messaging/" } --- +import Aside from "../../../../../components/Aside.astro" + ## Opcodes | Opcode | Scroll Behavior | @@ -21,11 +23,11 @@ whatsnext: { "Bridge": "/technology/bridge/cross-domain-messaging/" } | Address | Name | Scroll behavior | | ------- | ------------ | ----------------------------------------------------------------------------------------------- | -| `0x02` | `SHA2-256` | Currently not supported. | | `0x03` | `RIPEMD-160` | Currently not supported. | | `0x05` | `modexp` | Restrict the input values `B, E, M` to unsigned integers less than $2^{256}$. | | `0x08` | `ecPairing` | The inputs are still multiple of 6 32-byte values, but limit the number of tuples to at most 4. | | `0x09` | `blake2f` | Currently not supported. | +| `0x0a` | `point evaluation` | Currently not supported. | The remaining precompiled contracts have the same behavior as Ethereum. However, their maximum usage within a block is constrained by a limit tied to the zkEVM circuit capacity. @@ -44,3 +46,8 @@ EIPs imported from the Shanghai fork: - [EIP-3651](https://eips.ethereum.org/EIPS/eip-3651): Warm `COINBASE` - [EIP-3855](https://eips.ethereum.org/EIPS/eip-3855): `PUSH0` instruction - [EIP-3860](https://eips.ethereum.org/EIPS/eip-3860): Limit and meter initcode + + + diff --git a/src/content/docs/en/technology/chain/rollup.mdx b/src/content/docs/en/technology/chain/rollup.mdx index 0019f9204..1232dd60e 100644 --- a/src/content/docs/en/technology/chain/rollup.mdx +++ b/src/content/docs/en/technology/chain/rollup.mdx @@ -4,11 +4,13 @@ date: Last Modified title: "Rollup Process" lang: "en" permalink: "technology/chain/rollup" -whatsnext: { "EVM Differences from Ethereum": "/technology/chain/differences/" } +whatsnext: { "EVM Differences from Ethereum": "/en/technology/chain/differences/" } --- import ClickToZoom from "../../../../../components/ClickToZoom.astro" import RollupProcess from "../_images/rollup.png" +import NetworkTabs from "../../../../../components/Tabs/NetworkTabs.astro" +import { Tabs } from "../../../../../components/Tabs/Tabs.tsx" This document describes the rollup process in Scroll. @@ -24,8 +26,8 @@ The figure illustrates the rollup workflow. The L2 sequencer contains three modu The rollup node contains three modules: -- **Relayer** submits the commit transactions and finalize transactions to the rollup contract for data availability and finality. -- **Chunk Proposer** and **Batch Proposer** proposes new chunks and new batches following the constraints described in the [Transaction Batching](/technology/chain/transactions#transaction-batching). +- **Relayer** submits the commit transactions and finalizes transactions to the rollup contract for data availability and finality. +- **Chunk Proposer** and **Batch Proposer** propose new chunks and new batches following the constraints described in the [Transaction Batching](/technology/chain/transactions#transaction-batching). The rollup process can be broken down into three phases: transaction execution, batching and data commitment, and proof generation and finalization. @@ -51,7 +53,7 @@ The rollup process can be broken down into three phases: transaction execution, ## Commit Transaction -The Commit Transaction submits the block information and transaction data to L1 for data availability. The transaction includes the parent batch header, chunk data, and a bitmap of skipped L1 message. The parent batch header designates the previous batch that this batch links to. The parent batch must be committed before; otherwise the transaction will be reverted. See the `commitBatch` function signature below. +The Commit Transaction submits the block information and transaction data to L1 for data availability. The transaction includes the parent batch header, chunk data, and a bitmap of skipped L1 messages. The parent batch header designates the previous batch that this batch links to. The parent batch must be committed before; otherwise, the transaction will be reverted. See the `commitBatch` function signature below. ```solidity function commitBatch( @@ -68,7 +70,7 @@ After the `commitBatch` function verifies the parent batch is committed before, mapping(uint256 => bytes32) public committedBatches; ``` -The encoding of batch header and chunk data are described in the [Codec](#codec) section. Most fields in the batch header are straight-forward to derive from the chunk data. One important field to note is `dataHash` that will become part of the public input to verify the validity proof. Assuming that a batch contains `n` chunks, its `dataHash` is computed as follows +The encoding of batch header and chunk data are described in the [Codec](#codec) section. Most fields in the batch header are straightforward to derive from the chunk data. One important field to note is `dataHash` which will become part of the public input to verify the validity proof. Assuming that a batch contains `n` chunks, its `dataHash` is computed as follows ``` batch.dataHash := keccak(chunk[0].dataHash || ... || chunk[n-1].dataHash) @@ -84,7 +86,7 @@ chunk.dataHash := keccak(blockContext[0] || ... || blockContext[k-1] || , where `block.l1TxHashes` are the concatenated transaction hashes of the L1 transactions in this block and `block.l2TxHashes` are the concatenated transaction hashes of the L2 transactions in this block. Note that the transaction hashes of L1 transactions are not uploaded by the rollup node, but instead directly loaded from the `L1MessageQueue` contract given the index range of included L1 messages in this block. The L2 transaction hashes are calculated from the RLP-encoded bytes in the `l2Transactions` field in the [`Chunk`](#Chunk-Codec). -In addition, the `commitBatch` function contains a bitmap of skipped L1 messages. Unfortunately, this is due to the problem of proof overflow. If the L1 transaction corresponding to a L1 message exceeds the circuit capacity limit, we won't be able to generate a valid proof for this transaction and thus cannot finalize it on L1. Scroll is working actively to eliminate the proof overflow problem through upgrades to our proving system. +In addition, the `commitBatch` function contains a bitmap of skipped L1 messages. Unfortunately, this is due to the problem of proof overflow. If the L1 transaction corresponding to an L1 message exceeds the circuit capacity limit, we won't be able to generate a valid proof for this transaction and thus cannot finalize it on L1. Scroll is working actively to eliminate the proof overflow problem through upgrades to our proving system. ## Finalize Transaction @@ -119,37 +121,77 @@ At this stage, the state root of the latest finalized batch can be used trustles This section describes the codec of three data structures in the Rollup contract: `BatchHeader`, `Chunk`, and `BlockContext`. -### `BatchHeader` Codec - -| Field | Bytes | Type | Offset | Description | -| ------------------------ | ------- | ----------- | ------ | --------------------------------------------------------------- | -| `version` | 1 | `uint8` | 0 | The batch header version | -| `batchIndex` | 8 | `uint64` | 1 | The index of the batch | -| `l1MessagePopped` | 8 | `uint64` | 9 | The number of L1 messages poped in the batch | -| `totalL1MessagePopped` | 8 | `uint64` | 17 | The number of total L1 messages popped after the batch | -| `dataHash` | 32 | `bytes32` | 25 | The data hash of the batch | -| `parentBatchHash` | 32 | `bytes32` | 57 | The parent batch hash | -| `skippedL1MessageBitmap` | dynamic | `uint256[]` | 89 | A bitmap to indicate which L1 messages are skipped in the batch | - -### `Chunk` Codec - -| Field | Bytes | Type | Offset | Description | -| ---------------- | ------- | -------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | -| `numBlocks` | 1 | `uint8` | 0 | The number of blocks in the chunk | -| `block[0]` | 60 | `BlockContext` | 1 | The block information of the 1st block | -| ... | ... | ... | ... | ... | -| `block[i]` | 60 | `BlockContext` | `60*i+1` | The block information of `i+1`-th block | -| ... | ... | ... | ... | ... | -| `block[n-1]` | 60 | `BlockContext` | `60*n-59` | The block information of the last block | -| `l2Transactions` | dynamic | `bytes` | `60*n+1` | The concatenated RLP encoding of L2 transactions with signatures. The byte length (`uint32`) of RLP encoding is inserted before each transaction. | - -### `BlockContext` Codec - -| Field | Bytes | Type | Offset | Description | -| ----------------- | ----- | --------- | ------ | ----------------------------------------------------------------------------------- | -| `blockNumber` | 8 | `uint64` | 0 | The block number | -| `timestamp` | 8 | `uint64` | 8 | The block time | -| `baseFee` | 32 | `uint256` | 16 | The base fee of this block. Currently, it is always 0, because we disable EIP-1559. | -| `gasLimit` | 8 | `uint64` | 48 | The gas limit of this block | -| `numTransactions` | 2 | `uint16` | 56 | The number of transactions in this block, including both L1 & L2 txs | -| `numL1Messages` | 2 | `uint16` | 58 | The number of L1 messages in this block | +The latest update to the codec was introduced in the Bernoulli upgrade. + +### Bernoulli + + #### `BatchHeader` Codec + + | Field | Bytes | Type | Offset | Description | + | ------------------------ | ------- | ----------- | ------ | --------------------------------------------------------------- | + | `version` | 1 | `uint8` | 0 | The batch header version | + | `batchIndex` | 8 | `uint64` | 1 | The index of the batch | + | `l1MessagePopped` | 8 | `uint64` | 9 | The number of L1 messages popped in the batch | + | `totalL1MessagePopped` | 8 | `uint64` | 17 | The number of total L1 messages popped after the batch | + | `dataHash` | 32 | `bytes32` | 25 | The data hash of the batch | + | `blobVersionedHash` | 32 | `bytes32` | 57 | The versioned hash of the blob with this batch’s data | + | `parentBatchHash` | 32 | `bytes32` | 89 | The parent batch hash | + | `skippedL1MessageBitmap` | dynamic | `uint256[]` | 121 | A bitmap to indicate which L1 messages are skipped in the batch | + + #### `Chunk` Codec + + | Field | Bytes | Type | Offset | Description | + | ---------------- | ------- | -------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | + | `numBlocks` | 1 | `uint8` | 0 | The number of blocks in the chunk | + | `block[0]` | 60 | `BlockContext` | 1 | The block information of the 1st block | + | ... | ... | ... | ... | ... | + | `block[i]` | 60 | `BlockContext` | `60*i+1` | The block information of `i+1`-th block | + | ... | ... | ... | ... | ... | + | `block[n-1]` | 60 | `BlockContext` | `60*n-59` | The block information of the last block | + + #### `BlockContext` Codec + + | Field | Bytes | Type | Offset | Description | + | ----------------- | ----- | --------- | ------ | ----------------------------------------------------------------------------------- | + | `blockNumber` | 8 | `uint64` | 0 | The block number | + | `timestamp` | 8 | `uint64` | 8 | The block time | + | `baseFee` | 32 | `uint256` | 16 | The base fee of this block. Currently, it is always 0, because we disable EIP-1559. | + | `gasLimit` | 8 | `uint64` | 48 | The gas limit of this block | + | `numTransactions` | 2 | `uint16` | 56 | The number of transactions in this block, including both L1 & L2 txs | + | `numL1Messages` | 2 | `uint16` | 58 | The number of L1 messages in this block + +### Archimedes + #### `BatchHeader` Codec + + | Field | Bytes | Type | Offset | Description | + | ------------------------ | ------- | ----------- | ------ | --------------------------------------------------------------- | + | `version` | 1 | `uint8` | 0 | The batch header version | + | `batchIndex` | 8 | `uint64` | 1 | The index of the batch | + | `l1MessagePopped` | 8 | `uint64` | 9 | The number of L1 messages popped in the batch | + | `totalL1MessagePopped` | 8 | `uint64` | 17 | The number of total L1 messages popped after the batch | + | `dataHash` | 32 | `bytes32` | 25 | The data hash of the batch | + | `parentBatchHash` | 32 | `bytes32` | 57 | The parent batch hash | + | `skippedL1MessageBitmap` | dynamic | `uint256[]` | 89 | A bitmap to indicate which L1 messages are skipped in the batch | + + #### `Chunk` Codec + + | Field | Bytes | Type | Offset | Description | + | ---------------- | ------- | -------------- | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | + | `numBlocks` | 1 | `uint8` | 0 | The number of blocks in the chunk | + | `block[0]` | 60 | `BlockContext` | 1 | The block information of the 1st block | + | ... | ... | ... | ... | ... | + | `block[i]` | 60 | `BlockContext` | `60*i+1` | The block information of `i+1`-th block | + | ... | ... | ... | ... | ... | + | `block[n-1]` | 60 | `BlockContext` | `60*n-59` | The block information of the last block + | `l2Transactions` | dynamic | `bytes` | `60*n+1` | The concatenated RLP encoding of L2 transactions with signatures. The byte length (`uint32`) of RLP encoding is inserted before each transaction. | | + + #### `BlockContext` Codec + + | Field | Bytes | Type | Offset | Description | + | ----------------- | ----- | --------- | ------ | ----------------------------------------------------------------------------------- | + | `blockNumber` | 8 | `uint64` | 0 | The block number | + | `timestamp` | 8 | `uint64` | 8 | The block time | + | `baseFee` | 32 | `uint256` | 16 | The base fee of this block. Currently, it is always 0, because we disable EIP-1559. | + | `gasLimit` | 8 | `uint64` | 48 | The gas limit of this block | + | `numTransactions` | 2 | `uint16` | 56 | The number of transactions in this block, including both L1 & L2 txs | + | `numL1Messages` | 2 | `uint16` | 58 | The number of L1 messages in this block diff --git a/src/content/docs/en/technology/chain/transactions.mdx b/src/content/docs/en/technology/chain/transactions.mdx index d22a3402a..9fa5f17db 100644 --- a/src/content/docs/en/technology/chain/transactions.mdx +++ b/src/content/docs/en/technology/chain/transactions.mdx @@ -4,7 +4,7 @@ date: Last Modified title: "Transactions" lang: "en" permalink: "technology/chain/transactions" -whatsnext: { "Blocks": "/technology/chain/blocks/" } +whatsnext: { "Blocks": "/en/technology/chain/blocks/" } --- import ClickToZoom from "../../../../../components/ClickToZoom.astro" @@ -20,11 +20,11 @@ Currently, Scroll supports three types of transactions. - Legacy Transaction (refer to [EIP-155](https://eips.ethereum.org/EIPS/eip-155)) - `L1MessageTx` Typed Transaction (Type: `0x7E`): This is a new [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) transaction introduced in Scroll as described below. This transaction type is for transactions initiated on L1. -Note that [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) and [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) transaction type are not supported in Scroll currently. Scroll will bring back these two transaction types in the future. +Note that [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) and [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) transaction types are not supported in Scroll currently. Scroll will bring back these two transaction types in the future. ### L1 Message Transaction -We introduce a new type of transactions `L1MessageTx` for L1 initiated transactions. This type of transaction is initiated on the L1 bridge contract. Every time a new message is appended to the `L1MessageQueue` contract on L1, the L2 sequeuncer will create a corresponding `L1MessageTx` transaction to be included in the L2 blocks. Because the signature was already implicitly verified when users submitted the transaction on L1, `L1MessageTx` transactions don't have signature. +We introduce a new type of transaction `L1MessageTx` for L1-initiated transactions. This type of transaction is initiated on the L1 bridge contract. Every time a new message is appended to the `L1MessageQueue` contract on L1, the L2 sequencer will create a corresponding `L1MessageTx` transaction to be included in the L2 blocks. Because the signature was already implicitly verified when users submitted the transaction on L1, `L1MessageTx` transactions don't have signature. The `L1MessageTx` transaction type is `0x7E` and its payload is defined as follows. @@ -43,15 +43,15 @@ The RLP encoding of `L1MessageTx` transactions follows the [EIP-2718](https://ei Two noticeable behaviors of the `L1MessageTx` transactions: -- The `QueueIndex` in the transaction is the queue index in the L1 message queue, different from the `Nonce` of the `Sender` account. But the sender's `Nonce` will still increases by 1 after the transaction. +- The `QueueIndex` in the transaction is the queue index in the L1 message queue, different from the `Nonce` of the `Sender` account. But the sender's `Nonce` will still increase by 1 after the transaction. - This type of transactions doesn't pay [L2 fee](/developers/transaction-fees-on-scroll#l2-fee) or [L1 fee](/developers/transaction-fees-on-scroll#l1-fee). The L2 fee is already paid when users submit transactions on L1. The L1 Fee isn't charged because the data of `L1MessageTx` transactions is already available in the L1 bridge contract. ## Transaction Life Cycle The transaction life cycle in the Scroll contains the following three phases: -1. **Confirmed**: Users submits a transaction to either the L1 bridge contract or L2 sequencer. The transaction becomes `Confirmed` after it gets executed and included in a L2 block. -2. **Committed**: The transactions are included in a batch and a _commit transaction_ that contains the data of this batch is submitted to L1. After the commit transaction is finalized in the L1 blocks, the transactions in this batch becomes `Committed`. +1. **Confirmed**: Users submits a transaction to either the L1 bridge contract or L2 sequencer. The transaction becomes `Confirmed` after it gets executed and included in an L2 block. +2. **Committed**: The transactions are included in a batch and a _commit transaction_ that contains the data of this batch is submitted to L1. After the commit transaction is finalized in the L1 blocks, the transactions in this batch become `Committed`. 3. **Finalized**: The validity proof of this batch is generated and verified on the L1. After the _finalize transaction_ is finalized on L1, the status of the transaction is `Finalized` and becomes a canonical part of the Scroll L2 chain. ### Submit Transactions @@ -74,7 +74,7 @@ The rollup node collects new L2 blocks and packs them into chunks and batches (s ### Finalize Transactions -After the validity proof is generated, the rollup node sends a _Finalize Transaction_ including the validity proof and the new state root after this batch for onchain verification. Once the Finalize Transaction succeeds and confirmed in a L1 block, the status of the L2 transactions in this batch becomes `Finalized`. The new state root can be used by third parties trustlessly. +After the validity proof is generated, the rollup node sends a _Finalize Transaction_ including the validity proof and the new state root after this batch for onchain verification. Once the Finalize Transaction succeeds and is confirmed in an L1 block, the status of the L2 transactions in this batch becomes `Finalized`. The new state root can be used by third parties trustlessly. ## Transaction Batching diff --git a/src/content/docs/en/technology/index.mdx b/src/content/docs/en/technology/index.mdx index 927303aa8..3476b2ce3 100644 --- a/src/content/docs/en/technology/index.mdx +++ b/src/content/docs/en/technology/index.mdx @@ -5,7 +5,7 @@ title: "Scroll Architecture" lang: "en" permalink: "technology" whatsnext: - { "Scroll Chain": "/technology/chain/accounts", "Bridge": "/technology/bridge/cross-domain-messaging", "Sequencer": "/technology/sequencer/execution-node", "zkEVM": "/technology/zkevm/zkevm-overview" } + { "Scroll Chain": "/en/technology/chain/accounts", "Bridge": "/en/technology/bridge/cross-domain-messaging", "Sequencer": "/en/technology/sequencer/execution-node", "zkEVM": "/en/technology/zkevm/zkevm-overview" } --- import ClickToZoom from "../../../../components/ClickToZoom.astro" @@ -15,9 +15,9 @@ import Architecture from "./_images/arch.png" As illustrated in the figure above, Scroll chain consists of three layers: -- **Settlement Layer**: provides data availability and ordering for the canonical Scroll chain, verifies validity proofs, and allows users and dapps to send messages and assets between Ethereum and Scroll. We use Ethereum as the Settlement Layer and deploy the bridge and rollup contract onto the Ethereum. -- **Sequencing Layer**: contains a *Execution Node* that executes the transactions submitted to the Scroll sequencer and the transactions submitted to the L1 bridge contract and produces L2 blocks, and a *Rollup Node* that batches transactions, posts transaction data and block information to Ethereum for data availability, and submits validity proofs to Ethereum for finality. -- **Proving Layer**: consists of a pool of provers that are responsible for generating the zkEVM validity proofs that verify the correctness of L2 transactions, and a coordinator that dispatches the proving tasks to provers and relays the proofs to the Rollup Node to finalize on the Ethereum. +- **Settlement Layer**: provides data availability and ordering for the canonical Scroll chain, verifies validity proofs, and allows users and dapps to send messages and assets between Ethereum and Scroll. We use Ethereum as the Settlement Layer and deploy the bridge and rollup contract onto Ethereum. +- **Sequencing Layer**: contains an *Execution Node* that executes the transactions submitted to the Scroll sequencer and the transactions submitted to the L1 bridge contract and produces L2 blocks, and a *Rollup Node* that batches transactions, posts transaction data and block information to Ethereum for data availability, and submits validity proofs to Ethereum for finality. +- **Proving Layer**: consists of a pool of provers that are responsible for generating the zkEVM validity proofs that verify the correctness of L2 transactions, and a coordinator that dispatches the proving tasks to provers and relays the proofs to the Rollup Node to finalize on Ethereum. This section of the documentation provides comprehensive information on the Scroll protocol specification, bridging protocol, sequencer, and zkEVM circuit. diff --git a/src/content/docs/en/technology/overview/scroll-upgrades.mdx b/src/content/docs/en/technology/overview/scroll-upgrades.mdx index b8be2174d..87558da24 100644 --- a/src/content/docs/en/technology/overview/scroll-upgrades.mdx +++ b/src/content/docs/en/technology/overview/scroll-upgrades.mdx @@ -17,7 +17,65 @@ The following contracts are used to initiate upgrades and execute upgrades after | L2 Scroll Multisig | Scroll| [`0xEfc9D1096fb65c832207E5e7F13C2D1102244dbe`](https://scrollscan.com/address/0xEfc9D1096fb65c832207E5e7F13C2D1102244dbe)| | L2 Timelock | Scroll | [`0xf6069DB81239E5194bb53f83aF564d282357bc99`](https://scrollscan.com/address/0xf6069DB81239E5194bb53f83aF564d282357bc99)| -## February 2024 Bridge Upgrade +You can join our [Telegram channel for technical updates](https://t.me/scroll_tech_updates), which includes future upgrade announcements and on-chain operation events. + +## Bernoulli Upgrade + +### Overview + +This upgrade features a significant reduction in transaction costs by introducing support for EIP-4844 data blobs and supporting the SHA2-256 precompile. + +### Timeline + +- **Scroll Sepolia** + - Network Upgrade: April 15th, 2024 +- **Scroll Mainnet** + - Upgrade Initiation: April 15th, 2024 + - Timelock Completion & Upgrade: April 29th, 2024 + +### Technical Details + +#### Contract changes + +The contract changes for this upgrade are in [this PR](https://github.com/scroll-tech/scroll/pull/1179), along with the audit fixes [here](https://github.com/scroll-tech/scroll/pulls?q=is%3Apr+created%3A2024-04-10..2024-04-11+fix+in%3Atitle+label%3Abug). The main changes are as follows: + +- `ScrollChain` now accepts batches with either calldata or blob encoding in `commitBatch`. +- `ScrollChain` now supports finalizing blob-encoded batches through `finalizeBatchWithProof4844`. +- `MultipleVersionRollupVerifier` can now manage different on-chain verifiers for each batch encoding version. + +#### Node changes + +The new node version is `v5.3.0`. See [here](https://github.com/scroll-tech/go-ethereum/releases/tag/scroll-v5.3.0) for the release log. + +#### zkEVM circuit changes + +The new version of zkevm circuits is `v0.10.3`. See [here](https://github.com/scroll-tech/zkevm-circuits/releases/tag/v0.10.3) for the release log. + +#### Audits + +- [OpenZeppelin](https://blog.openzeppelin.com/scroll-eip-4844-support-audit) +- TrailofBits (will be posted soon) + +### Compatibility + +#### Sequencer and follower nodes (l2geth) + +This upgrade is a hard fork as it introduces the new blob data type and the SHA2-256 precompiled contract. Operators running an `l2geth` node are required to upgrade before the hard fork block. See the [node releases](https://github.com/scroll-tech/go-ethereum/releases) for more information. + +#### Indexers and Bridges + +This upgrade changes the format that Scroll uses to publish data to Ethereum. Projects that rely on this data should carefully review [the new data format](/en/technology/chain/rollup/#codec), and check whether their decoders need to be adjusted. A summary of the new format: + +- The format of [`BlockContext`](https://github.com/scroll-tech/scroll/blob/5362e28f744093495c1c09a6b68fc96a3264278b/common/types/encoding/codecv1/codecv1.go#L125) will not change. +- `Chunks` will [no longer include](https://github.com/scroll-tech/scroll/blob/5362e28f744093495c1c09a6b68fc96a3264278b/common/types/encoding/codecv1/codecv1.go#L162) the L2 transaction data. This will instead be [stored in a blob](https://github.com/scroll-tech/scroll/blob/5362e28f744093495c1c09a6b68fc96a3264278b/common/types/encoding/codecv1/codecv1.go#L284) attached to the `commitBatch` transaction. +- `BatchHeader` now contains one new field, [`BlobVersionedHash`](https://github.com/scroll-tech/scroll/blob/5362e28f744093495c1c09a6b68fc96a3264278b/common/types/encoding/codecv1/codecv1.go#L405). + +#### Provers + +This upgrade involves a breaking change in [zkevm-circuits](https://github.com/scroll-tech/zkevm-circuits). Operators running a prover node are required to upgrade. + + +## Bridge Upgrade ### Overview @@ -56,7 +114,7 @@ To reduce bridging costs, we implemented several gas optimizations on our bridge - In `ScrollChain`, change `messageQueue` and `verifier` to `immutable`. - In `L1ScrollMessenger`, change `counterpart`, `rollup`, and `messageQueue` to `immutable`. - In all token gateways, change `counterpart`, `router`, and `messenger` to `immutable`. -- Merge `L1MessageQueue` and `L2GasPriceOracle` into a single contract `L1MessageQueueWithGasPriceOracle` (deployed on the same address as the previous `L1MessageQueue`). In this contract we also change `messenger` and `scrollChain` to `immutable`, and simplify `calculateIntrinsicGasFee`. +- Merge `L1MessageQueue` and `L2GasPriceOracle` into a single contract `L1MessageQueueWithGasPriceOracle` (deployed on the same address as the previous `L1MessageQueue`). In this contract, we also change `messenger` and `scrollChain` to `immutable`, and simplify `calculateIntrinsicGasFee`. **Changes to L2 contracts:** diff --git a/src/content/docs/en/technology/sequencer/execution-node.mdx b/src/content/docs/en/technology/sequencer/execution-node.mdx index b51fd0476..b467cc440 100644 --- a/src/content/docs/en/technology/sequencer/execution-node.mdx +++ b/src/content/docs/en/technology/sequencer/execution-node.mdx @@ -4,12 +4,12 @@ date: Last Modified title: "Execution Node" lang: "en" permalink: "technology/sequencer/execution-node" -whatsnext: { "Rollup Node": "/technology/sequencer/rollup-node/" } +whatsnext: { "Rollup Node": "/en/technology/sequencer/rollup-node/" } --- import Aside from "../../../../../components/Aside.astro" -The execution node is one of the core components in the Scroll protocol: it is responsible for maintaining the L2 blockchain. The execution node also ensures that the user and developer experience on Scroll closely resemble those on Ethereum. It achieves this by maintaining EVM and RPC behaviour that is directly inherited from Ethereum, with very few modifications. +The execution node is one of the core components in the Scroll protocol: it is responsible for maintaining the L2 blockchain. The execution node also ensures that the user and developer experience on Scroll closely resembles that on Ethereum. It achieves this by maintaining EVM and RPC behavior that is directly inherited from Ethereum, with very few modifications. The primary functions of Scroll's execution node are: - Collect transactions from L2 and L1. @@ -24,7 +24,7 @@ The secondary functions of Scroll's execution node are: The execution node, being a fork of [go-ethereum](https://github.com/ethereum/go-ethereum), inherits most of its functionality from Ethereum. This includes transaction and block data structures, EVM execution, RPC and p2p protocols. As these were not reimplemented but were directly inherited from `go-ethereum`, we can have a very high certainty of Scroll's compatibility with Ethereum. -The following sections will introduce the main components of the execution node, the additional validation rules, and summary of modification details. +The following sections will introduce the main components of the execution node, the additional validation rules, and a summary of modification details. ## `l2geth` Components @@ -45,7 +45,7 @@ During block creation, if the next transaction would lead to proof overflow, the Skipping L2 transactions means simply discarding them. In this case, the user needs to submit another transaction with the same nonce that does not lead to proof overflow in order to proceed. -Skipping L1 messages is a more explicit process. Both the `ScrollChain` contract on L1 and the zkEVM verifies that each L1 transaction in `L1MessageQueue` was either included and executed, or skipped. While the batch encoding does not contain L1 transactions, it does include a *skip bitmap* that indicates to `ScrollChain` which L1 messages were skipped. If an L1 deposit message is skipped, the user can get their tokens refunded on L1. +Skipping L1 messages is a more explicit process. Both the `ScrollChain` contract on L1 and the zkEVM verify that each L1 transaction in `L1MessageQueue` was either included and executed, or skipped. While the batch encoding does not contain L1 transactions, it does include a *skip bitmap* that indicates to `ScrollChain` which L1 messages were skipped. If an L1 deposit message is skipped, the user can get their tokens refunded on L1.