-
{t("rightSidebar.feedback")}
+
{t("rightSidebar.feedback")}
@@ -37,7 +37,7 @@ const { content, githubEditUrl, headings, clientSideToc } = Astro.props
@apply !mb-6;
}
.sidebar-nav-inner {
- padding: 16px 20px 70px 4px;
+ padding: 24px 20px 24px 4px;
overflow: auto;
background: #fff8f3;
border-radius: 1em;
@@ -45,16 +45,12 @@ const { content, githubEditUrl, headings, clientSideToc } = Astro.props
width: 280px;
/* width: 250px; */
max-height: 100%;
- /* @apply pt-doc; */
+ @apply bg-white dark:bg-dark-normal;
}
.sidebar-nav-inner > * {
- margin-top: 1rem;
+ margin-top: 32px;
}
.sidebar-nav-inner > *:first-child {
margin-top: 0;
}
-
- .sidebar-nav-inner h2 {
- @apply m-0 mt-4;
- }
diff --git a/src/components/ToggleElement.astro b/src/components/ToggleElement.astro
index 4e6c61234..e2a53d2b5 100644
--- a/src/components/ToggleElement.astro
+++ b/src/components/ToggleElement.astro
@@ -7,7 +7,9 @@ const anchorHash = anchor.replace(/\s+/g, "-")
---
-
+
@@ -46,9 +48,9 @@ const anchorHash = anchor.replace(/\s+/g, "-")
border-radius: 27px;
border: 1px solid #dadada;
overflow: hidden;
- color: var(--color-text-primary);
font-weight: 600;
padding-left: 0.3rem;
+ @apply text-black dark:text-white border-primary dark:border-dark-primary;
}
details:hover {
@@ -89,7 +91,6 @@ const anchorHash = anchor.replace(/\s+/g, "-")
}
summary::before {
- content: "";
display: inline-block;
font-size: 0.75em;
transform: rotate(-90deg);
@@ -97,8 +98,9 @@ const anchorHash = anchor.replace(/\s+/g, "-")
margin-right: 1rem;
height: 10px;
width: 10px;
- background: url(data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMTAiIGhlaWdodD0iNiIgdmlld0JveD0iMCAwIDEwIDYiIGZpbGw9Im5vbmUiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+CjxwYXRoIGlkPSJWZWN0b3IiIGZpbGwtcnVsZT0iZXZlbm9kZCIgY2xpcC1ydWxlPSJldmVub2RkIiBkPSJNNC45OTk3NiA2QzQuNzY4MSA2IDQuNTUwMjkgNS45MDc3NCA0LjM4NjQ0IDUuNzQwMTlMMC4yNTM0NTEgMS41MTM4N0MtMC4wODQ0ODM2IDEuMTY4MDIgLTAuMDg0NDgzNiAwLjYwNTY2IDAuMjUzNDUxIDAuMjU5ODExQzAuNDE3Mjk4IDAuMDkyMjY0MiAwLjYzNTExNSAwIDAuODY2NzcgMEMxLjA5ODQzIDAgMS4zMTYyNCAwLjA5MjI2NDIgMS40ODAwOSAwLjI1OTgxMUw1LjAwMDAzIDMuODU5MjVMOC41MTk3IDAuMjU5ODExQzguNjgzNTUgMC4wOTIyNjQyIDguOTAxMzcgMCA5LjEzMzAyIDBDOS4zNjQ2OCAwIDkuNTgyNDkgMC4wOTIyNjQyIDkuNzQ2MzQgMC4yNTk4MTFDMTAuMDg0NiAwLjYwNTY2IDEwLjA4NDYgMS4xNjgzIDkuNzQ2MzQgMS41MTM4N0w1LjYxMzM1IDUuNzQwMTlDNS40NDk1MSA1LjkwNzc0IDUuMjMxNjkgNiA1LjAwMDAzIDZINC45OTk3NloiIGZpbGw9ImJsYWNrIi8+Cjwvc3ZnPgo=)
- center / contain no-repeat;
+ background-position: center;
+ background-size: contain;
+ background-repeat: no-repeat;
}
details[open] summary::before {
transform: rotate(0deg);
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 4328eb611..5d73ae02b 100644
--- a/src/content/docs/en/developers/ethereum-and-scroll-differences.mdx
+++ b/src/content/docs/en/developers/ethereum-and-scroll-differences.mdx
@@ -63,7 +63,7 @@ type StateAccount struct {
Related to this, we maintain two types of codehash for each contract bytecode: Keccak hash and Poseidon hash.
-`KeccakCodeHash` is kept to maintain compatibility for `EXTCODEHASH`. `PoseidonCodeHash` is used for verifying correctness of bytecodes loaded in the zkEVM, where Poseidon hashing is far more efficient.
+`KeccakCodeHash` is kept to maintain compatibility for `EXTCODEHASH`. `PoseidonCodeHash` is used for verifying the correctness of bytecodes loaded in the zkEVM, where Poseidon hashing is far more efficient.
### CodeSize
@@ -82,12 +82,6 @@ This was chosen for two reasons:
We keep a close eye on all emerging EIPs adopted by Ethereum and adopt them when suitable. If you’re interested in more specifics, reach out in [our community forum](https://community.scroll.io) or on the [Scroll Discord](https://discord.gg/scroll).
-## EVM Target version
-
-To ensure no unexpected behavior happens in your contracts, we recommend using `london` as the target version when compiling your smart contracts.
-
-You can read in more detail on Shanghai hard fork differences from London on the [Ethereum Execution spec](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md) and how the new `PUSH0` instruction [impacts the Solidity compiler](https://blog.soliditylang.org/2023/05/10/solidity-0.8.20-release-announcement/).
-
## Transaction Fees
The fee charged to Scroll transactions contains two parts:
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 15d26035e..8ba6476b8 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
@@ -79,13 +79,13 @@ contract GreeterOperator {
We pass the message by executing `executeFunctionCrosschain` and passing the following parameters:
- `scrollMessengerAddress`: This will depend on where you deployed the `GreeterOperator` contract.
- - If you deployed it on Sepolia use `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`. If you deployed on Scroll use `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`.
+ - If you deployed it on Sepolia use `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`. If you deployed on Scroll Sepolia use `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`.
- `targetAddress`: The address of the `Greeter` contract on the opposite chain.
- `value`: In this case, it is `0` because the `setGreeting`is not payable.
-- `greeting`: This is the parameter that will be sent through the message. Try passing `“This message was crosschain!”`
+- `greeting`: This is the parameter that will be sent through the message. Try passing `“This message was cross-chain!”`
- `gasLimit`:
- - If you are sending the message from L1 to L2, around `5000` gas limit should be more than enough.
- - If you are sending the message from L2 to L1, pass `0`, as the transaction be completed by executing an additional transaction on L1.
+ - If you are sending the message from L1 to L2, around `1000000` gas limit should be more than enough. That said, if you set this too high, and `msg.value` doesn't cover `gasLimit` * `baseFee`, the transaction will revert. If `msg.value` is greater than the gas fee, the unused portion will be refunded.
+ - If you are sending the message from L2 to L1, pass `0`, as the transaction will be completed by executing an additional transaction on L1.
### Relay the Message when sending from L2 to L1
@@ -117,6 +117,6 @@ in the [Scroll Messenger](/developers/l1-and-l2-bridging/the-scroll-messenger) a
applications and users.
-After executing and confirming the transaction on both L1 and L2, the new state of `greeting` on the `Greeter` contract should be `“This message was crosschain!”`. Sending a message from one chain to the other should take around 20 minutes after the transactions are confirmed on the origin chain.
+After executing and confirming the transaction on both L1 and L2, the new state of `greeting` on the `Greeter` contract should be `“This message was cross-chain!”`. Sending a message from one chain to the other should take around 20 minutes after the transactions are confirmed on the origin chain.
Congratulations, you now executed a transaction from one chain to the other using our native bridge!
diff --git a/src/content/docs/en/developers/l1-and-l2-bridging/enforced-transactions.mdx b/src/content/docs/en/developers/l1-and-l2-bridging/enforced-transactions.mdx
index 21e2bc15e..80ca6f427 100644
--- a/src/content/docs/en/developers/l1-and-l2-bridging/enforced-transactions.mdx
+++ b/src/content/docs/en/developers/l1-and-l2-bridging/enforced-transactions.mdx
@@ -9,7 +9,7 @@ excerpt: "The Enforced Transaction contract enables sending transactions between
import Aside from "../../../../../components/Aside.astro"
-The Enforced Transaction contract enables sending transactions between L1 and L2 the **`sendTransaction`** function. This contract shares similarities with the Scroll Messenger contract as it allows sending arbitrary data from one layer to the other. However, it distinguishes itself by enabling the relaying of signed transactions and the ability to set the sender (CALLER or msg.sender) on the receiving transaction on Scroll.
+In future upgrades to Scroll, the Enforced Transaction contract will enable sending transactions between L1 and L2 with the **`sendTransaction`** function. This contract shares similarities with the Scroll Messenger contract as it allows sending arbitrary data from one layer to the other. However, it distinguishes itself by enabling the relaying of signed transactions and the ability to set the sender (CALLER or msg.sender) on the receiving transaction on Scroll.
## Enforced Transactions API
@@ -25,10 +25,10 @@ Add an enforced transaction to L2 from an EOA account sender.
| Parameter | Description |
| ---------- | ---------------------------------------------------------- |
-| \_target | The address of target contract to call in L2. |
+| \_target | The address of the target contract to call in L2. |
| \_value | The value passed. |
| \_gasLimit | The maximum gas should be used for this transaction in L2. |
-| \_data | The calldata passed to target contract. |
+| \_data | The calldata passed to the target contract. |
### sendTransaction
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 3a83794d7..082ab18fd 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
@@ -16,7 +16,7 @@ ERC1155 bridging from L1 to L2 is done via the L1ERC1155Gateway. Similarly to ER
@@ -115,7 +115,7 @@ Deposit an ERC1155 token from L1 to a recipient's account on L2.
| to | The address of recipient's account on L2. |
| tokenId | The NFT id to deposit. |
| amount | The amount of tokens to deposit. |
-| gasLimit | Gas limit required to complete the deposit on L2. |
+| gasLimit | Gas limit required to complete the deposit on L2. Unused portion of fee will be refunded.|
### updateTokenMapping
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 a92bca857..c14966466 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
@@ -86,7 +86,7 @@ Deposit an ERC721 NFT from L1 to a recipient's account on L2.
| token | The address of ERC721 NFT contract on L1. |
| to | The address of recipient's account on L2. |
| tokenId | The NFT id to deposit. |
-| gasLimit | Gas limit required to complete the deposit on L2. |
+| gasLimit | Gas limit required to complete the deposit on L2. Unused portion of fee will be refunded. |
### updateTokenMapping
@@ -106,7 +106,7 @@ Update the mapping that connects an NFT contract from L1 to L2.
### withdrawERC721
```solidity
-function depositERC721(address _token, address _to, uint256 _tokenId, uint256 _gasLimit) external payable;
+function withdrawERC721(address _token, address _to, uint256 _tokenId, uint256 _gasLimit) external payable;
```
Send an ERC721 NFT from L2 to a recipient's account on L1.
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 62c2be537..b46d30062 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
@@ -28,10 +28,9 @@ When bridging ERC20 tokens, you don’t have to worry about selecting the right
All Gateway contracts will form the message and send it to the `L1ScrollMessenger` which can send arbitrary messages to L2. The `L1ScrollMessenger` passes the message to the `L1MessageQueue`. Any user can send messages directly to the Messenger to execute arbitrary data on L2. This means they can execute any function on L2 from a transaction made on L1 via the bridge. Although an application could directly pass messages to existing token contracts, the Gateway abstracts the specifics and simplifies making transfers and calls.
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.
@@ -54,7 +53,7 @@ The L2 Gateway is very similar to the L1 Gateway. We can withdraw ETH and ERC20
## Creating an ERC20 token with custom logic on L2
-If a token needs custom logic on L2, it will need to be bridged through a `L1CustomERC20Gateway` and `L2CustomERC20Gateway` respectively. The custom token on L2 will need to give permission to the Gateway to mint new tokens when a deposit occurs and to burn when tokens are withdrawn
+If a token needs custom logic on L2, it will need to be bridged through an `L1CustomERC20Gateway` and `L2CustomERC20Gateway` respectively. The custom token on L2 will need to give permission to the Gateway to mint new tokens when a deposit occurs and to burn when tokens are withdrawn
The following interface is the `IScrollStandardERC20` needed for deploying tokens compatible with the `L2CustomERC20Gateway` on L2.
@@ -105,7 +104,7 @@ Sends ETH from L1 to L2.
| --------- | --------------------------------------------------------------------------------------------------------------------------- |
| to | The address of recipient's account on L2. |
| amount | The amount of token to transfer, in wei. |
-| gasLimit | Gas limit required to complete the deposit on L2. From 4000 to 10000 gas limit should be enough to process the transaction. |
+| gasLimit | Gas limit required to complete the deposit on L2. 170000 should be enough to process the transaction, but unused funds are refunded. |
### depositERC20
@@ -120,7 +119,7 @@ Sends ERC20 tokens from L1 to L2.
| token | The token address on L1. |
| to | The address of recipient's account on L2. |
| amount | The amount of token to transfer, in wei. |
-| gasLimit | Gas limit required to complete the deposit on L2. From 4000 to 10000 gas limit should be enough to process the transaction. |
+| gasLimit | Gas limit required to complete the deposit on L2. 20000 should be enough to process the transaction, depending on the Gateway, but unused funds are refunded. |
### getL2ERC20Address
diff --git a/src/content/docs/en/developers/scroll-contracts.mdx b/src/content/docs/en/developers/scroll-contracts.mdx
index 39b70bc8b..332f379d7 100644
--- a/src/content/docs/en/developers/scroll-contracts.mdx
+++ b/src/content/docs/en/developers/scroll-contracts.mdx
@@ -98,6 +98,13 @@ 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)
+#### Ethereum Attestation Service (EAS)
+
+- EAS: [`0xC47300428b6AD2c7D03BB76D05A176058b47E6B0`](https://scrollscan.com/address/0xC47300428b6AD2c7D03BB76D05A176058b47E6B0)
+- SchemaRegistry: [`0xD2CDF46556543316e7D34e8eDc4624e2bB95e3B6`](https://scrollscan.com/address/0xD2CDF46556543316e7D34e8eDc4624e2bB95e3B6)
+- EIP712Proxy: [`0x77b7DA1c40762Cd8AFfE2069b575328EfD4D9801`](https://scrollscan.com/address/0x77b7DA1c40762Cd8AFfE2069b575328EfD4D9801)
+- Indexer: `Not deployed yet`
+
## Additional Useful Contracts
- Multicall3: [`0xcA11bde05977b3631167028862bE2a173976CA11`](https://scrollscan.com/address/0xcA11bde05977b3631167028862bE2a173976CA11)
diff --git a/src/content/docs/en/getting-started/overview.md b/src/content/docs/en/getting-started/overview.md
index 9a854f2e8..acddb22f3 100644
--- a/src/content/docs/en/getting-started/overview.md
+++ b/src/content/docs/en/getting-started/overview.md
@@ -10,7 +10,7 @@ whatsnext: { "User Guide": "/user-guide/", "Building on Scroll": "/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 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, and 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/).
diff --git a/src/content/docs/en/learn/index.mdx b/src/content/docs/en/learn/index.mdx
index 55b8184ed..ade566b4d 100644
--- a/src/content/docs/en/learn/index.mdx
+++ b/src/content/docs/en/learn/index.mdx
@@ -7,6 +7,8 @@ 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.
@@ -14,13 +16,13 @@ Want to see a specific topic covered? Create [an issue](https://github.com/scrol
-Both functions require users to provide a gas limit for the corresponding `L1MessageTx` transaction on L2 and prepay the [message relay fee](#message-relay-fee) on L1, which is calculated based on the gas limit amount. The fee is collected to a `feeVault` contract on L1. In case the transaction fails on L2 because the user did not set the correct gas limit for their message on L1, the user can replay the same message with a higher gas limit. You can find more details in the [Retrying failed messages](#retrying-failed-messages) section.
+Both functions require users to provide a gas limit for the corresponding `L1MessageTx` transaction on L2 and prepay the [message relay fee](#message-relay-fee) on L1, which is calculated based on the gas limit amount. The fee is collected to a `feeVault` contract on L1. In case the transaction fails on L2 because the user did not set the correct gas limit for their message on L1, the user can replay the same message with a higher gas limit. You can find more details in the [Retrying failed messages](#retrying-failed-messages) section, but since any unused portion of these fees is refunded to the user, there is no penalty for overestimating the gas limit.
The `sendMessage` functions encode the arguments into a cross-domain message (see the code snippet below), where the message nonce is the next queue index of the L1 message queue. The encoded data is then used as calldata in the `L1MessageTx` transaction executed on L2. Note that such cross-domain messages always call the `relayMessage` function of the `L2ScrollMessenger` contract on L2.
diff --git a/src/content/docs/en/technology/chain/accounts.mdx b/src/content/docs/en/technology/chain/accounts.mdx
index fb1d2e85c..a478e5766 100644
--- a/src/content/docs/en/technology/chain/accounts.mdx
+++ b/src/content/docs/en/technology/chain/accounts.mdx
@@ -16,14 +16,14 @@ Scroll stores additional information of the contract bytecode in the account to
The account in Scroll contains the following fields:
- `nonce`: A counter that indicates the number of transactions sent by the sender.
-- `balance`: The balance of `ETH` token in the account balance (unit in wei).
+- `balance`: The balance of `ETH` token in the account (unit in wei).
- `storageRoot`: The root hash of the storage trie. Since Scroll uses the [zkTrie](/technology/sequencer/zktrie) for the storage trie, the `storageRoot` stores the Poseidon hash digest in a 256-bit integer.
- `codeHash`: The Keccak hash digest of the contract bytecode.
- `PoseidonCodeHash` (**new field**): The Poseidon hash digest of the contract bytecode in a 256-bit integer.
-- `CodeSize` (**new field**): The number of bytes in the contract bytecode.
+- `CodeSize` (**new field**): The size of the contract bytecode in bytes.
## State
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. In the 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 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.
diff --git a/src/content/docs/en/technology/security/audits-and-bug-bounty.mdx b/src/content/docs/en/technology/security/audits-and-bug-bounty.mdx
index 8e51ffe2f..b5dc337da 100644
--- a/src/content/docs/en/technology/security/audits-and-bug-bounty.mdx
+++ b/src/content/docs/en/technology/security/audits-and-bug-bounty.mdx
@@ -32,8 +32,8 @@ Scroll has worked with several industry-leading security audit firms to review o
- [Wave 2](https://github.com/trailofbits/publications/blob/master/reviews/2023-08-scroll-zkEVM-wave2-securityreview.pdf)
- [Wave 3](https://github.com/trailofbits/publications/blob/master/reviews/2023-09-scroll-zkEVM-wave3-securityreview.pdf)
- Zellic and Kalos
- - [Wave 1](https://github.com/Zellic/publications/blob/master/Scroll%20zkEVM%20-%20Part%201%20Audit%20Report.pdf)
- - [Wave 2](https://github.com/Zellic/publications/blob/master/Scroll%20zkEVM%20-%20Part%202%20Audit%20Report.pdf)
+ - [Wave 1](https://github.com/Zellic/publications/blob/master/Scroll%20zkEVM%20-%20Part%201%20-%20Audit%20Report.pdf)
+ - [Wave 2](https://github.com/Zellic/publications/blob/master/Scroll%20zkEVM%20-%20Part%202%20-%20Audit%20Report.pdf)
### Node implementation
diff --git a/src/content/docs/en/technology/sequencer/zktrie.mdx b/src/content/docs/en/technology/sequencer/zktrie.mdx
index 9c85e1aa7..0975ff424 100644
--- a/src/content/docs/en/technology/sequencer/zktrie.mdx
+++ b/src/content/docs/en/technology/sequencer/zktrie.mdx
@@ -61,9 +61,9 @@ When we insert a new leaf node to a zkTrie, there are two cases illustrated in t
The deletion of a leaf node is similar to the insertion. There are two cases illustrated in the Figure 3.
-1. The sibling node of to-be-deleted leaf node is a
+1. The sibling node of the to-be-deleted leaf node is a
branch node (Figure 3a). In this case, we can simply replace the node `a` by an empty node and update the node hash of its ancestors till the root node.
-2. The node of to-be-deleted leaf node is a leaf node (Figure 3b). Similarly to case 1, we first replace the leaf node by an empty node and start to contract its sibling node upwards until its sibling node is not an empty node. For example, in Figure 3b, we replace the leaf node `b` by an empty node. Because the sibling of node `c` now becomes an empty node, we need to move node `c` one level upward and replace its parent. The new sibling of node `c`, node `e`, is still an empty node. So again we move node `c` upward. Now that the sibling of node `c` is node `a`, a leaf node, the deletion process is finished.
+2. The sibling node of the to-be-deleted leaf node is a leaf node (Figure 3b). Similarly to case 1, we first replace the leaf node by an empty node and start to contract its sibling node upwards until its sibling node is not an empty node. For example, in Figure 3b, we replace the leaf node `b` by an empty node. Because the sibling of node `c` now becomes an empty node, we need to move node `c` one level upward and replace its parent. The new sibling of node `c`, node `e`, is still an empty node. So again we move node `c` upward. Now that the sibling of node `c` is node `a`, a leaf node, the deletion process is finished.
Note that the sibling of a leaf node in a valid zkTrie cannot be an empty node. Otherwise, we should always prune the subtree and move the leaf node upwards.
diff --git a/src/content/docs/en/technology/zkevm/intro-to-zkevm.md b/src/content/docs/en/technology/zkevm/intro-to-zkevm.md
index 1c4bc4772..f2751c980 100644
--- a/src/content/docs/en/technology/zkevm/intro-to-zkevm.md
+++ b/src/content/docs/en/technology/zkevm/intro-to-zkevm.md
@@ -12,7 +12,7 @@ whatsnext: { "zkEVM Overview": "/technology/zkevm/zkevm-overview" }
ZK rollups are widely recognized as the ideal scaling solution for Ethereum. They inherit the strong security of Ethereum Layer 1 and offer the fastest transaction finality compared to other Layer 2 solutions.
-The basic idea of a ZK rollup is to execute transactions off-chain and to generate succinct proofs of the execution’s validity. These succinct proof can then be posted and verified on Ethereum Layer 1. ZK rollups improve scalability since verifying the proof for a batch of transactions is much cheaper than re-executing the batch of transactions.
+The basic idea of a ZK rollup is to execute transactions off-chain and to generate succinct proofs of the execution’s validity. These succinct proofs can then be posted and verified on Ethereum Layer 1. ZK rollups improve scalability since verifying the proof for a batch of transactions is much cheaper than re-executing the batch of transactions.
ZK rollups can be categorized into application-specific and general-purpose rollups, based on the types of transactions they support. Application-specific ZK rollups are designed for particular transaction sets, such as payments and swaps, or a player’s action set for an on-chain game. In these cases, rollups only need to generate proofs attesting to the correctness of the supported primitives, such as valid state transitions for game players.
diff --git a/src/content/docs/en/user-guide/faucet.mdx b/src/content/docs/en/user-guide/faucet.mdx
index ea7dd1272..c889c7581 100644
--- a/src/content/docs/en/user-guide/faucet.mdx
+++ b/src/content/docs/en/user-guide/faucet.mdx
@@ -36,3 +36,4 @@ If you don't want to interact with the bridge, some faucets directly distribute
- [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/es/developers/ethereum-and-scroll-differences.mdx b/src/content/docs/es/developers/ethereum-and-scroll-differences.mdx
index 0335f0fbb..afb918330 100644
--- a/src/content/docs/es/developers/ethereum-and-scroll-differences.mdx
+++ b/src/content/docs/es/developers/ethereum-and-scroll-differences.mdx
@@ -82,12 +82,6 @@ Esto se eligió por dos razones:
Seguimos de cerca todas las EIP emergentes adoptadas por Ethereum y las adoptamos cuando es conveniente. Si estás interesado en más detalles, ponte en contacto con nosotros en [nuestro foro de la comunidad](https://community.scroll.io) o en [Scroll Discord](https://discord.gg/scroll).
-## Versión del compilador de la EVM
-
-Para garantizar que no se produzca ningún comportamiento inesperado en sus contratos, recomendamos utilizar `london` como versión de referencia al compilar sus smart contracts.
-
-Puedes leer con más detalle las diferencias entre el hard fork de Shanghai y London en la [Ethereum Execution spec](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md) y cómo la nueva instrucción `PUSH0` [afecta al compilador de Solidity](https://blog.soliditylang.org/2023/05/10/solidity-0.8.20-release-announcement/).
-
## Comisiones de Transacciones
La comisión aplicada a las transacciones de Scroll consta de dos partes:
diff --git a/src/content/docs/es/developers/guides/scroll-messenger-cross-chain-interaction.mdx b/src/content/docs/es/developers/guides/scroll-messenger-cross-chain-interaction.mdx
index fa0c65f71..72e067c9a 100644
--- a/src/content/docs/es/developers/guides/scroll-messenger-cross-chain-interaction.mdx
+++ b/src/content/docs/es/developers/guides/scroll-messenger-cross-chain-interaction.mdx
@@ -78,12 +78,12 @@ contract GreeterOperator {
Pasamos el mensaje ejecutando `executeFunctionCrosschain` y pasando los siguientes parámetros:
- `scrollMessengerAddress`: Esto dependerá de dónde hayas desplegado el contrato `GreeterOperator`.
- - Si lo desplegaste en Sepolia utiliza `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`. Si lo has desplegado en Scroll utiliza `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`.
+ - Si lo desplegaste en Sepolia utiliza `0x50c7d3e7f7c656493D1D76aaa1a836CedfCBB16A`. Si lo has desplegado en Scroll Sepolia utiliza `0xBa50f5340FB9F3Bd074bD638c9BE13eCB36E603d`.
- `targetAddress`: La dirección del contrato `Greeter` en la cadena opuesta.
- `value`: En este caso es `0` porque el `setGreeting` no es de tipo `payable`.
- `greeting`: Es el parámetro que se enviará a través del mensaje. Prueba pasar `"¡Este mensaje fue ejecutado de manera crosschain!"`.
- `gasLimit`:
- - Si estás enviando el mensaje de L1 a L2, alrededor de un límite de gas de `5000` debería ser más que suficiente.
+ - Si estás enviando el mensaje de L1 a L2, alrededor de un límite de gas de `1000000` debería ser más que suficiente. Habiendo dicho esto, si estableces un valor muy alto, y tu `msg.value` no cubre `gasLimit` * `baseFee`, la transacción revertirá. Si `msg.value` es mayor a la comisión de gas, la porción que no se usó se te devolverá.
- Si estás enviando el mensaje de L2 a L1, pasa `0`, ya que la transacción se completará ejecutando una transacción adicional en L1.
### Retransmisión del mensaje al enviar de L2 a L1
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx b/src/content/docs/es/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx
index b217c16c9..039ab6d62 100644
--- a/src/content/docs/es/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx
+++ b/src/content/docs/es/developers/l1-and-l2-bridging/erc1155-token-bridge.mdx
@@ -114,7 +114,7 @@ Deposita tokens ERC1155 desde L1 en la cuenta de un destinatario en L2.
| to | Dirección de la cuenta del destinatario en L2. |
| tokenId | Id del NFT a depositar. |
| amount | Cantidad de tokens a depositar. |
-| gasLimit | Límite de gas necesario para completar el depósito en L2. |
+| gasLimit | Límite de gas necesario para completar el depósito en L2. La porción de gas que no fué utilizado será automáticamente enviada de vuelta. |
### updateTokenMapping
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx b/src/content/docs/es/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx
index 2a3ed76c5..19f842247 100644
--- a/src/content/docs/es/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx
+++ b/src/content/docs/es/developers/l1-and-l2-bridging/erc721-nft-bridge.mdx
@@ -85,7 +85,7 @@ Depósito de un NFT ERC721 desde L1 a la cuenta de un destinatario en L2.
| token | Dirección del contrato ERC721 NFT en L1. |
| to | Dirección de la cuenta del destinatario en L2. |
| tokenId | Id del NFT a depositar. |
-| gasLimit | Límite de gas necesario para completar el depósito en L2. |
+| gasLimit | Límite de gas necesario para completar el depósito en L2. La porción de gas que no fué utilizado será automáticamente enviada de vuelta. |
### updateTokenMapping
@@ -105,7 +105,7 @@ Actualización del mapping que conecta un contrato NFT de L1 a L2.
### withdrawERC721
```solidity
-function depositERC721(address _token, address _to, uint256 _tokenId, uint256 _gasLimit) external payable;
+function withdrawERC721(address _token, address _to, uint256 _tokenId, uint256 _gasLimit) external payable;
```
Envío de un ERC721 NFT desde L2 a la cuenta de un destinatario en L1.
diff --git a/src/content/docs/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx b/src/content/docs/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx
index 5a5a3113c..3adeaf9ae 100644
--- a/src/content/docs/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx
+++ b/src/content/docs/es/developers/l1-and-l2-bridging/eth-and-erc20-token-bridge.mdx
@@ -30,10 +30,9 @@ Al enviar tokens ERC20, no tienes que preocuparte de seleccionar la Gateway corr
Todos los contratos Gateway formarán el mensaje y lo enviarán al `L1ScrollMessenger` que puede enviar mensajes arbitrarios a L2. El `L1ScrollMessenger` pasa el mensaje a la `L1MessageQueue`. Cualquier usuario puede enviar mensajes directamente al Messenger para ejecutar datos arbitrarios en L2. Esto significa que pueden ejecutar cualquier función en L2 desde una transacción realizada en L1 a través del bridge. Aunque una aplicación podría pasar directamente mensajes a los contratos de tokens existentes, el Gateway abstrae los detalles y simplifica las transferencias y llamadas.
Cuando se crea un nuevo bloque en L1, el Watcher detectará el mensaje en la `L1MessageQueue` y lo pasará al servicio Relayer, que enviará la transacción a L2 a través del nodo l2geth. Finalmente, el nodo l2geth pasará la transacción al contrato `L2ScrollMessagner` para su ejecución en L2.
@@ -107,7 +106,7 @@ Envía ETH desde L1 a L2.
| --------- | --------------------------------------------------------------------------------------------------------------------------- |
| to | Dirección de la cuenta del destinatario en L2. |
| amount | Cantidad de token a transferir, en wei. |
-| gasLimit | Límite de gas necesario para completar el depósito en la L2. De 4000 a 10000 de gas debería ser suficiente para procesar la transacción. |
+| gasLimit | Límite de gas necesario para completar el depósito en la L2. De 170000 de gas debería ser suficiente para procesar la transacción. Recuerda que todo el excedente gas que no fue utilizado será automáticamente devuelto. |
### depositERC20
@@ -122,7 +121,7 @@ Envía ERC20 tokens desde L1 a L2.
| token | Dirección del token en L1. |
| to | Dirección de la cuenta del destinatario en L2. |
| amount | Cantidad de token a transferir, en wei. |
-| gasLimit | Límite de gas necesario para completar el depósito en la L2. De 4000 a 10000 de gas debería ser suficiente para procesar la transacción. |
+| gasLimit | Límite de gas necesario para completar el depósito en la L2. 20000 de gas debería ser suficiente para procesar la transacción, dependiendo del Gateway, los fondos que no fueron usados serán devueltos. |
### getL2ERC20Address
diff --git a/src/content/docs/es/learn/index.mdx b/src/content/docs/es/learn/index.mdx
index d68f94ac8..a0dcf77ed 100644
--- a/src/content/docs/es/learn/index.mdx
+++ b/src/content/docs/es/learn/index.mdx
@@ -7,6 +7,8 @@ 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.
@@ -14,13 +16,13 @@ Scroll reúne la investigación y la ingeniería de protocolos blockchain y crip
-Ambas funciones requieren que los usuarios proporcionen un límite de gas para la transacción `L1MessageTx` correspondiente en L2 y paguen por adelantado el [Message Relay Fee](#message-relay-fee) en L1, que se calcula en función del importe del límite de gas. La comisión se recoge en un contrato `feeVault` en L1. En caso de que la transacción falle en L2 porque el usuario no ha establecido el límite de gas correcto para su mensaje en L1, el usuario puede repetir el mismo mensaje con un límite de gas más alto. Puedes encontrar más detalles en la sección [Reintento de Mensajes Fallidos](#reintentar-mensajes-fallidos).
+Ambas funciones requieren que los usuarios proporcionen un límite de gas para la transacción `L1MessageTx` correspondiente en L2 y paguen por adelantado el [Message Relay Fee](#message-relay-fee) en L1, que se calcula en función del importe del límite de gas. La comisión se recoge en un contrato `feeVault` en L1. En caso de que la transacción falle en L2 porque el usuario no ha establecido el límite de gas correcto para su mensaje en L1, el usuario puede repetir el mismo mensaje con un límite de gas más alto. Puedes encontrar más detalles en la sección [Reintento de Mensajes Fallidos](#reintentar-mensajes-fallidos), pero dado que la porción de gas de comisiones que no fue usada es devuelta al usuaior, hoy hay penalidad por sobrestimar el límite de gas.
Las funciones `sendMessage` codifican los argumentos en un mensaje entre dominios (véase el fragmento de código siguiente), donde el nonce del mensaje es el siguiente índice de la cola de mensajes en L1. Los datos codificados se utilizan como calldata en la transacción `L1MessageTx` ejecutada en L2. Ten en cuenta que estos mensajes entre dominios siempre llaman a la función `relayMessage` del contrato `L2ScrollMessenger` en L2.
diff --git a/src/content/docs/es/technology/chain/accounts.mdx b/src/content/docs/es/technology/chain/accounts.mdx
index def6b59b0..db25cca2e 100644
--- a/src/content/docs/es/technology/chain/accounts.mdx
+++ b/src/content/docs/es/technology/chain/accounts.mdx
@@ -20,7 +20,7 @@ La cuenta en Scroll contiene los siguientes campos:
- `storageRoot`: El hash raíz del trie de almacenamiento. Dado que Scroll utiliza [zkTrie](/es/technology/sequencer/zktrie) para el trie de almacenamiento, `storageRoot` almacena el hash digest de Poseidon en un entero de 256 bits.
- `codeHash`: El hash digest Keccak del bytecode del contrato.
- `PoseidonCodeHash` (**nuevo campo**): El hash digest Poseidon del bytecode del contrato en un entero de 256 bits.
-- `CodeSize` (**nuevo campo**): El número de bytes en el bytecode del contrato.
+- `CodeSize` (**nuevo campo**): El tamaño del bytecode del contrato en bytes.
## Estado
diff --git a/src/content/docs/es/technology/security/audits-and-bug-bounty.mdx b/src/content/docs/es/technology/security/audits-and-bug-bounty.mdx
index f0ad9b4d9..0df780940 100644
--- a/src/content/docs/es/technology/security/audits-and-bug-bounty.mdx
+++ b/src/content/docs/es/technology/security/audits-and-bug-bounty.mdx
@@ -37,8 +37,8 @@ Scroll ha trabajado con varias firmas líderes en auditoría de seguridad de la
- Wave 2
- Wave 3
- Zellic y Kalos
- - [Wave 1](https://github.com/Zellic/publications/blob/master/Scroll%20zkEVM%20-%20Part%201%20Audit%20Report.pdf)
- - [Wave 2](https://github.com/Zellic/publications/blob/master/Scroll%20zkEVM%20-%20Part%202%20Audit%20Report.pdf)
+ - [Wave 1](https://github.com/Zellic/publications/blob/master/Scroll%20zkEVM%20-%20Part%201%20-%20Audit%20Report.pdf)
+ - [Wave 2](https://github.com/Zellic/publications/blob/master/Scroll%20zkEVM%20-%20Part%202%20-%20Audit%20Report.pdf)
### Implementación del Nodo
diff --git a/src/content/docs/es/technology/sequencer/zktrie.mdx b/src/content/docs/es/technology/sequencer/zktrie.mdx
index b4ff90cee..2e82fb45b 100644
--- a/src/content/docs/es/technology/sequencer/zktrie.mdx
+++ b/src/content/docs/es/technology/sequencer/zktrie.mdx
@@ -63,7 +63,7 @@ La eliminación de un nodo hoja es similar a la inserción. En la Figura 3 se il
1. El nodo hermano del nodo hoja que se va a eliminar es un nodo rama (Figura 3a).
En este caso, podemos simplemente reemplazar el nodo `a` por un nodo vacío y actualizar el hash de sus ancestros hasta el nodo raíz.
-2. El nodo hoja a eliminar es un nodo hoja (Figura 3b). De forma similar al caso 1, primero sustituimos el nodo hoja por un nodo vacío y empezamos a contraer su nodo hermano hacia arriba hasta que su nodo hermano no sea un nodo vacío. Por ejemplo, en la figura 3b, sustituimos el nodo hoja `b` por un nodo vacío. Como el hermano del nodo `c` se convierte ahora en un nodo vacío, tenemos que mover el nodo `c` un nivel hacia arriba y reemplazar a su padre. El nuevo hermano del nodo `c`, el nodo `e`, sigue siendo un nodo vacío. Así que de nuevo movemos el nodo `c` hacia arriba. Ahora que el hermano del nodo `c` es el nodo `a`, un nodo hoja, el proceso de borrado ha terminado.
+2. El nodo hermano del nodo a hoja a eliminar (Figura 3b). De forma similar al caso 1, primero sustituimos el nodo hoja por un nodo vacío y empezamos a contraer su nodo hermano hacia arriba hasta que su nodo hermano no sea un nodo vacío. Por ejemplo, en la figura 3b, sustituimos el nodo hoja `b` por un nodo vacío. Como el hermano del nodo `c` se convierte ahora en un nodo vacío, tenemos que mover el nodo `c` un nivel hacia arriba y reemplazar a su padre. El nuevo hermano del nodo `c`, el nodo `e`, sigue siendo un nodo vacío. Así que de nuevo movemos el nodo `c` hacia arriba. Ahora que el hermano del nodo `c` es el nodo `a`, un nodo hoja, el proceso de borrado ha terminado.
Ten en cuenta que el hermano de un nodo hoja en una zkTrie válida no puede ser un nodo vacío. De lo contrario, siempre debemos purgar el subárbol y mover el nodo hoja hacia arriba.
diff --git a/src/env.d.ts b/src/env.d.ts
index 22be14928..3c51dddce 100644
--- a/src/env.d.ts
+++ b/src/env.d.ts
@@ -1,2 +1,6 @@
///
///
+
+interface Window {
+ dataLayer: Array
+}
diff --git a/src/features/landing/components/SectionHeader.tsx b/src/features/landing/components/SectionHeader.tsx
index 0bb31c078..5bb6e8a03 100644
--- a/src/features/landing/components/SectionHeader.tsx
+++ b/src/features/landing/components/SectionHeader.tsx
@@ -1,9 +1,7 @@
-import React, { useState, useCallback } from "react"
-import styles from "./SectionHeader.module.css"
-
+import styles from "./SectionHeader.module.css"
const SectionHeader = (props) => {
- const { dark, title, description, ...rest } = props
+ const { title, description } = props
return (
{title}
diff --git a/src/layouts/HomeLayout.astro b/src/layouts/HomeLayout.astro
index f8fd54a44..8f5c51e4e 100644
--- a/src/layouts/HomeLayout.astro
+++ b/src/layouts/HomeLayout.astro
@@ -3,10 +3,10 @@ import HeadCommon from "../components/HeadCommon.astro"
import HeadSEO from "../components/HeadSEO.astro"
import Header from "../components/Header/Header.astro"
import * as CONFIG from "../config"
-import Footer from "~/components/Footer/Footer"
+import Footer from "~/components/Footer/Footer.astro"
import LeftSidebar from "../components/LeftSidebar/LeftSidebar.astro"
-const { content = {}, dark } = Astro.props
+const { content = {} } = Astro.props
const currentPage = new URL(Astro.request.url).pathname
const formattedContentTitle = content.title
? `${content.title} | ${CONFIG.SITE.title}`
@@ -23,15 +23,16 @@ const canonicalURL = new URL(Astro.url.pathname, Astro.site)
body {
--doc-padding: 65px;
}
+
.home-layout {
margin-bottom: 0;
}
#grid-left {
position: fixed;
- background-color: var(--theme-bg);
z-index: 10;
display: none;
+ @apply bg-pure-white dark:bg-black;
}
@media (min-width: 50em) {
@@ -59,16 +60,24 @@ const canonicalURL = new URL(Astro.url.pathname, Astro.site)
height: calc(100vh - 20px);
}
+
+
+
+
+
+
+
+
+