From 8562ad1d451b42fa107c39c2a23d6281a2d78109 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Fri, 28 Jun 2024 15:45:56 +0300 Subject: [PATCH 1/6] fix actions.md --- notes/actions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/notes/actions.md b/notes/actions.md index f6de8274f..b30c595c7 100644 --- a/notes/actions.md +++ b/notes/actions.md @@ -16,4 +16,4 @@ Runs once per day. The `tutorials.yml` workflow runs several of the tutorials within these docs. Most tutorials take the form of JavaScript files that are imported within the content of the docs. -Same files can be executed individually to make sure that the tutorial actually works and isn't broken for one reason or another. +The same files can be executed individually to make sure that the tutorial actually works and isn't broken for one reason or another. From d7c576b2112f2f4538c8e94982f6293758e70bc1 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Fri, 28 Jun 2024 15:46:19 +0300 Subject: [PATCH 2/6] fix content-reuse.md --- notes/content-reuse.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/notes/content-reuse.md b/notes/content-reuse.md index 82b6cd9a4..d11dcbfd8 100644 --- a/notes/content-reuse.md +++ b/notes/content-reuse.md @@ -28,7 +28,7 @@ Text before Text after ``` -### How to Use a Multiple Reusable Content Components +### How to Use Multiple Reusable Content Components 1. You can create a `index.js` file in the `content` directories and export the components like this: From 1d8106f42f02dc47801eac948e573c6c93d26581 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Fri, 28 Jun 2024 15:47:48 +0300 Subject: [PATCH 3/6] fix standard-bridge.mdx --- pages/builders/app-developers/bridging/standard-bridge.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/builders/app-developers/bridging/standard-bridge.mdx b/pages/builders/app-developers/bridging/standard-bridge.mdx index ac2ee936f..9397ea11f 100644 --- a/pages/builders/app-developers/bridging/standard-bridge.mdx +++ b/pages/builders/app-developers/bridging/standard-bridge.mdx @@ -87,7 +87,7 @@ The process for bridging a native token involves a few steps. {

The Standard Bridge locks the transferred tokens

} When the user triggers the `bridgeERC20To` function while transferring a native token, the Standard Bridge will pull the `_amount` of `_localToken` tokens from the user's address and lock them inside of the bridge contract. - A record of all locked tokens are stored within a [`deposits` mapping](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L41-L42) that keeps track of the total number of tokens deposited for a given `_localToken` and `_remoteToken` pair. + A record of all locked tokens is stored within a [`deposits` mapping](https://github.com/ethereum-optimism/optimism/blob/2e647210882d961f04055e656590d90ad98c9934/packages/contracts-bedrock/src/universal/StandardBridge.sol#L41-L42) that keeps track of the total number of tokens deposited for a given `_localToken` and `_remoteToken` pair. Since a native token may have more than one bridged representation, the `deposits` token must keep track of the deposit pools for each `_localToken`/`_remoteToken` pair independently. From ca8d74e69f467966eced90a930e5abd153c549fc Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Fri, 28 Jun 2024 15:48:17 +0300 Subject: [PATCH 4/6] fix optimization.mdx --- pages/builders/app-developers/contracts/optimization.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/builders/app-developers/contracts/optimization.mdx b/pages/builders/app-developers/contracts/optimization.mdx index d19db4ea2..7d599718c 100644 --- a/pages/builders/app-developers/contracts/optimization.mdx +++ b/pages/builders/app-developers/contracts/optimization.mdx @@ -29,7 +29,7 @@ Gas optimization can reduce the amount of gas used by a contract and make your a OP Mainnet contracts can be gas optimized to reduce overall transaction costs, just like contracts on Ethereum. However, OP Mainnet transactions must also pay for another fee called the L1 Data Fee which accounts for the cost of publishing transaction data to Ethereum. -At the time this guide was written, this L1 Data Fee makes up the majority of the cost of most transactions on OP Mainnet. +At the time this guide was written, this L1 Data Fee made up the majority of the cost of most transactions on OP Mainnet. Because the L1 Data Fee tends to be larger than the execution gas fee, **OP Mainnet contracts can be further optimized by increasing the amount of storage/execution used in order to decrease the amount of user-provided data in each transaction.** This is the basic premise that makes OP Mainnet contract optimization slightly different than on Ethereum. From ace59c067a2d7956ed2a9310b9ce0480c3ffdd49 Mon Sep 17 00:00:00 2001 From: Elias Rad <146735585+nnsW3@users.noreply.github.com> Date: Fri, 28 Jun 2024 15:50:06 +0300 Subject: [PATCH 5/6] fix fp-changes.mdx --- pages/builders/notices/fp-changes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/builders/notices/fp-changes.mdx b/pages/builders/notices/fp-changes.mdx index 4f7a34d81..d92f15195 100644 --- a/pages/builders/notices/fp-changes.mdx +++ b/pages/builders/notices/fp-changes.mdx @@ -15,7 +15,7 @@ If you experience difficulty at any stage of this process, please reach out to [ **Important Notice for Bridges and Users** -**ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reproven after the upgrade is complete. +**ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reprovened after the upgrade is complete. * Reproving simply requires that you execute the [withdrawal proving flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow) again. * Withdrawals prior to the Fault Proofs upgrade must wait a 7-day challenge period before finalization. As a result, any withdrawal initiated less than 7 days before the upgrade cannot be finalized before the upgrade is executed. You may want to consider waiting until after the upgrade is complete to begin a withdrawal during this 7-day window. From 316770e14238d951c4086f2cdef1e7217d67b24f Mon Sep 17 00:00:00 2001 From: cpengilly <29023967+cpengilly@users.noreply.github.com> Date: Fri, 28 Jun 2024 10:10:44 -0700 Subject: [PATCH 6/6] Update fp-changes.mdx --- pages/builders/notices/fp-changes.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pages/builders/notices/fp-changes.mdx b/pages/builders/notices/fp-changes.mdx index d92f15195..4f7a34d81 100644 --- a/pages/builders/notices/fp-changes.mdx +++ b/pages/builders/notices/fp-changes.mdx @@ -15,7 +15,7 @@ If you experience difficulty at any stage of this process, please reach out to [ **Important Notice for Bridges and Users** -**ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reprovened after the upgrade is complete. +**ALL** withdrawals that are not finalized before the Fault Proofs upgrade executes will need to be reproven after the upgrade is complete. * Reproving simply requires that you execute the [withdrawal proving flow](https://docs.optimism.io/stack/protocol/rollup/withdrawal-flow) again. * Withdrawals prior to the Fault Proofs upgrade must wait a 7-day challenge period before finalization. As a result, any withdrawal initiated less than 7 days before the upgrade cannot be finalized before the upgrade is executed. You may want to consider waiting until after the upgrade is complete to begin a withdrawal during this 7-day window.