From 1bb0fcd551a9110caac7e8c4402004751c2a0ff9 Mon Sep 17 00:00:00 2001 From: soyboy Date: Fri, 14 Feb 2025 16:21:03 -0800 Subject: [PATCH 1/3] updating pectra notice page with challenger details --- pages/notices/pectra-changes.mdx | 46 +++++++++++++++++++------------- 1 file changed, 28 insertions(+), 18 deletions(-) diff --git a/pages/notices/pectra-changes.mdx b/pages/notices/pectra-changes.mdx index 226392e85..7873c815f 100644 --- a/pages/notices/pectra-changes.mdx +++ b/pages/notices/pectra-changes.mdx @@ -44,7 +44,6 @@ Pectra contains a variety of EIPs, some of which apply to the OP Stack; others d Node operators will need to upgrade to the respective releases before the activation dates.These following steps are necessary for every node operator: - ### Update to the latest release @@ -53,42 +52,51 @@ Node operators will need to upgrade to the respective releases before the activa * `op-node` at [`v1.11.0`](https://github.com/ethereum-optimism/optimism/releases/tag/op-node%2Fv1.11.0) * `op-geth` at [`v1.101500.0`](https://github.com/ethereum-optimism/op-geth/releases/tag/v1.101500.0) -* `op-batcher` at [`v1.11.1`](https://github.com/ethereum-optimism/optimism/releases/tag/op-batcher%2Fv1.11.1) * `op-reth` at [`v1.1.5`](https://github.com/paradigmxyz/reth/releases/tag/v1.1.5) also includes L1 Pectra support. ## For chain operators The following sections are how chain operators can prepare the first part of the OP Stack's Pectra L1 support. This ensures OP Stack chains do not break when the L1 Pectra upgrade activates. -Every chain operator will need to first follow the guidance outlined in the [Node Operator section](#update-to-the-latest-release) to update your nodes to the latest releases. +Every chain operator will need to: + + + + ### Update your node binaries + + Follow the guidance outlined in the [Node Operator section](#update-to-the-latest-release) to update your nodes to the latest releases. + + ### Update your batcher + + Then update your batcher to [`op-batcher/v1.11.1`](https://github.com/ethereum-optimism/optimism/releases/tag/op-batcher%2Fv1.11.1). + + + ## For fault proof enabled chains The following instructions assume your chain is on the latest contract release `op-contracts/v1.8.0` and have Holocene activated. - -The following steps are to update your absolute prestate on your chain. **This is absolutely necessary for chains running permissionless fault proofs.** For chains running the Fault Proof System with permissioned games you can skip this section because games will not be played out and the absolute prestate is not used. + +The following steps are to update your absolute prestate with new dispute game contracts. **This is absolutely necessary for chains running permissionless fault proofs.** For chains running the Fault Proof System with permissioned games you can skip this section because games will not be played out and the absolute prestate is not used. The Pectra upgrade changes the derivation rules, permissionless fault proof chains need to upgrade the `op-program` version used in the fault proof system to support these changes. The `op-program` version used is specified via the `faultGameAbsolutePrestate` setting, deployed as part of `FaultDisputeGame` and `PermissionedDisputeGame` contracts. - ### Make sure the Superchain Registry is up to date - The new `op-program` release will pull the configurations from the [superchain-registry](https://github.com/ethereum-optimism/superchain-registry). This is important because the op-challenger uses the `op-program` and it needs to be aware of your chain's configuration. If your chain that not in the superchain-registry, please [open a PR to add your chain to the superchain-registry](https://github.com/ethereum-optimism/superchain-registry/blob/main/docs/ops.md#adding-a-chain). + ### Update your `op-challenger` - ### Verify the new absolute prestate + Update your `op-challenger` binary to [`op-challenger/v1.3.1`](https://github.com/ethereum-optimism/optimism/releases/tag/op-challenger%2Fv1.3.1). - - The following is based on the [op-program/v1.5.0-rc.2](https://github.com/ethereum-optimism/optimism/tree/op-program/v1.5.0-rc.2) which will be included in the `op-challenger` release. - + ### Verify the new absolute prestate - You can use this new absolute prestate (`0x035ac388b5cb22acf52a2063cfde108d09b1888655d21f02f595f9c3ea6cbdcd`) for the following chains: + The absolute prestate is generated with the [op-program/v1.5.0-rc.2](https://github.com/ethereum-optimism/optimism/tree/op-program/v1.5.0-rc.2). You can use this new absolute prestate (`0x035ac388b5cb22acf52a2063cfde108d09b1888655d21f02f595f9c3ea6cbdcd`) for the following chains: * Sepolia: Base, OP, Metal, Mode, Zora, Ethernity, Unichain, Ink * Mainnet: Base, OP, Orderly, Lyra, Metal, Mode, Zora, Lisk, Ethernity, Binary, Ink, Unichain - You can verify this absolute prestate by running the following [command](https://github.com/ethereum-optimism/optimism/blob/3f18df1c8a502136bbe33f10ed1e29a26cd4678a/Makefile#L129-L131) in the root of the monorepo: + You can verify this absolute prestate by running the following [command](https://github.com/ethereum-optimism/optimism/blob/3f18df1c8a502136bbe33f10ed1e29a26cd4678a/Makefile#L129-L131) in the root of the monorepo on the `op-program/v1.5.0-rc.2` tag: ```shell make reproducible-prestate @@ -105,6 +113,12 @@ The Pectra upgrade changes the derivation rules, permissionless fault proof chai 0x0379d61de1833af6766f07b4ed931d85b3f6282508bbcbf9f4637398d97b61c1 ``` + ### Upload your new preimage file + + During the previous step, you also generated the preimage of the absolute prestate, which is basically the op-program serialized into a binary file. You'll find that new file at `optimism/op-program/bin/prestate.bin.gz`. Rename that file to have the absolute prestate hash as the filename so it looks like `0x035ac388b5cb22acf52a2063cfde108d09b1888655d21f02f595f9c3ea6cbdcd.bin.gz`. + + Upload that file to where you're storing your other absolute preimage files. This should be the location where you're pointing your `--cannon-prestates-url` at. The `op-challenger` will grab this file and use it when it needs to challenge games. + ### Deploy new dispute game contracts You will then take the absolute prestate and deploy new `FaultDisputeGame` and `PermissionedDisputeGame` contracts with that value. You can reuse the [Holocene script](https://github.com/ethereum-optimism/optimism/tree/op-contracts/v1.8.0-rc.4/packages/contracts-bedrock/scripts/upgrades/holocene) to deploy the new contracts. The only change you will need to make is to update the `absolutePrestate` value in your [deploy-config](https://github.com/ethereum-optimism/optimism/blob/2073f4059bd806af3e8b76b820aa3fa0b42016d0/packages/contracts-bedrock/scripts/upgrades/holocene/README.md?plain=1#L53-L54). Alternatively we will be releasing an `OPPrestateUpdater` that can be used to deploy the new contracts. @@ -113,13 +127,9 @@ The Pectra upgrade changes the derivation rules, permissionless fault proof chai You will then need to update the `DisputeGameFactory` to point to the new `FaultDisputeGame` and `PermissionedDisputeGame` contracts by calling `DisputeGameFactory.setImplementation`. You can utilize this [template](https://github.com/ethereum-optimism/superchain-ops/tree/main/tasks/sep/fp-recovery/005-set-game-implementation) to generate the transaction and validation script for this step. Before executing, you will need to update your op-challenger. - ### Update your op-challenger - - Update your `op-challenger` to the new release version that will be provided soon and configure it to use the new absolute prestate. - ### Execute the upgrade - Once your challenger is ready, you can execute the "Set Dispute Game Implementation" transaction. Please simulate and validate that the expected output prior to executing the transaction. + Once your `op-challenger` is ready with the new preimage, you can execute the "Set Dispute Game Implementation" transaction. Please simulate and validate that the expected output prior to executing the transaction. ## For OP Stack forks From 0373bead3334168f1bb56a8f232cc56ed04fc5a4 Mon Sep 17 00:00:00 2001 From: soyboy Date: Fri, 14 Feb 2025 16:21:12 -0800 Subject: [PATCH 2/3] fixing linter issues --- pages/stack/interop.mdx | 2 + pages/stack/interop/reorg.mdx | 105 +++++++++--------- .../interop/tutorials/message-passing.mdx | 99 +++++++++-------- words.txt | 1 + 4 files changed, 107 insertions(+), 100 deletions(-) diff --git a/pages/stack/interop.mdx b/pages/stack/interop.mdx index 1e131f94f..4b5c0abee 100644 --- a/pages/stack/interop.mdx +++ b/pages/stack/interop.mdx @@ -34,4 +34,6 @@ Documentation covering Cross Chain Message, Explainer, Message Passing, Op Super } /> } /> + + diff --git a/pages/stack/interop/reorg.mdx b/pages/stack/interop/reorg.mdx index 2472da76d..caff773f2 100644 --- a/pages/stack/interop/reorg.mdx +++ b/pages/stack/interop/reorg.mdx @@ -13,45 +13,43 @@ import { InteropCallout } from '@/components/WipCallout' # Interop reorg awareness -[A chain reorganization, or “reorg”,](https://www.alchemy.com/overviews/what-is-a-reorg#what-happens-to-reorgs-after-the-merge) happens when validators disagree on the most accurate version of the blockchain. -If not handled correctly, reorgs in a cross-chain context could result in a [double-spend problem](https://en.wikipedia.org/wiki/Double-spending). +[A chain reorganization, or "reorg",](https://www.alchemy.com/overviews/what-is-a-reorg#what-happens-to-reorgs-after-the-merge) happens when validators disagree on the most accurate version of the blockchain. +If not handled correctly, reorgs in a cross-chain context could result in a [double-spend problem](https://en.wikipedia.org/wiki/Double-spending). The most frequent solution to mitigate the double-spend problem is to wait for Ethereum finality; however, that solution results in high latency cross-chain communication and a poor user experience.
- -What is double-spending? - -```mermaid - -flowchart LR - subgraph init ["Initiating transaction (source chain)"] - burn(tokens burned) - burn-->send(send) - end - subgraph exec ["Executing transaction (destination chain)"] - send==initiating message==>receive(receive) - receive-->mint(tokens minted) - end -``` - -In a normal asset transfer tokens are burned on the source chain first, then a message is sent to the destination chain. -When that message is received, the tokens are minted on the destination chain, where the user can now use those tokens. - -```mermaid - -flowchart LR - subgraph init ["Not really the source chain"] - err((error)) - end - subgraph exec ["Executing transaction (destination chain)"] - err==initiating message==>receive(receive) - receive-->mint(tokens minted) - end -``` - -A double-spend problem occurs when the destination chain receives a valid initiating message, but due to issues on the source chain, such as a reorg, that initiating transaction is no longer valid. -When that happens, the tokens are still on the source chain, but they are also on the destination chain. - + What is double-spending? + + ```mermaid + + flowchart LR + subgraph init ["Initiating transaction (source chain)"] + burn(tokens burned) + burn-->send(send) + end + subgraph exec ["Executing transaction (destination chain)"] + send==initiating message==>receive(receive) + receive-->mint(tokens minted) + end + ``` + + In a normal asset transfer tokens are burned on the source chain first, then a message is sent to the destination chain. + When that message is received, the tokens are minted on the destination chain, where the user can now use those tokens. + + ```mermaid + + flowchart LR + subgraph init ["Not really the source chain"] + err((error)) + end + subgraph exec ["Executing transaction (destination chain)"] + err==initiating message==>receive(receive) + receive-->mint(tokens minted) + end + ``` + + A double-spend problem occurs when the destination chain receives a valid initiating message, but due to issues on the source chain, such as a reorg, that initiating transaction is no longer valid. + When that happens, the tokens are still on the source chain, but they are also on the destination chain.
Most solutions to mitigate the double-spend problem rely on [L1 finality](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). However, that solution results in high latency and poor user experience. @@ -81,13 +79,13 @@ graph LR class A101,A102,A103,B302,B303 unsafe ``` -In the diagram above, solid arrows are the derivation of a block from the previous block in the chain. +In the diagram above, solid arrows are the derivation of a block from the previous block in the chain. Dotted arrows go from the block with the initiating message (the source) to the block with the executing message (the destination). Blocks can either be finalized (grey), cross-safe (green), or unsafe (red). -Blockchain A has only written block A100 to the blockchain. +Blockchain A has only written block A100 to the blockchain. As a result, block A101 is unsafe, and so are all the blocks that depend on it, directly (A102 and B302) or indirectly (A103 and B303). -Blocks B302 and B303 may be *local-safe* (if they are written to L1), but they cannot be *cross-safe* because they depend on a block that isn't. -If all goes well, eventually A101 will be written to L1, turn safe, and then the blocks that depend on it can become safe as well. +Blocks B302 and B303 may be *local-safe* (if they are written to L1), but they cannot be *cross-safe* because they depend on a block that isn't. +If all goes well, eventually A101 will be written to L1, turn safe, and then the blocks that depend on it can become safe as well. The message between A101 and B302 can be an asset moving across the bridge. In that case, the initiating message (A101) burns `n` tokens on the source chain (A), and the executing message (B302) mints `n` tokens on the destination chain (B). @@ -104,11 +102,10 @@ So L1 reorgs are basically invisible to L2. Sequencers inform the rest of the Superchain about a new block in two ways: -- The gossip protocol, which is typically used as soon as the block is created. - The problem is that the gossip protocol does not create a commitment. -- Posting to L1, which typically happens a few minutes after the block is created. - The reason is cost, it is a lot cheaper if compression and L1 posting are done in large batches, rather than for each individual block. - +* The gossip protocol, which is typically used as soon as the block is created. + The problem is that the gossip protocol does not create a commitment. +* Posting to L1, which typically happens a few minutes after the block is created. + The reason is cost, it is a lot cheaper if compression and L1 posting are done in large batches, rather than for each individual block. Equivocation happens when a sequencer publishes a block using the gossip protocol that is different from the one that eventually gets written to L1. In this case, the block that is written to L1 (let's call it A'101) is the valid one, and that causes every dependent block to be recalculated. @@ -154,15 +151,13 @@ So the change from A101 to A'101 cannot invalidate any exi If a block is invalid, even if it is posted on L1, the canonical chain replaces it with a block that only includes the deposit transactions, those transactions posted to L1.
+ What makes a block invalid? -What makes a block invalid? - -There are several potential reasons: - -- The block posted to L1 includes incorrect information, for example because it relied on a node on a different blockchain for interop and that node reported incorrect information. -- The block was never posted. - After a timeout of twelve hours all the verifiers will assume that the block that should have been posted is a deposit-only block. + There are several potential reasons: + * The block posted to L1 includes incorrect information, for example because it relied on a node on a different blockchain for interop and that node reported incorrect information. + * The block was never posted. + After a timeout of twelve hours all the verifiers will assume that the block that should have been posted is a deposit-only block.
This is functionally equivalent to equivocation, and dealt with the same way, so it can change unsafe blocks but only those blocks. @@ -177,6 +172,6 @@ At worst, some unsafe blocks need to be recalculated (if one fork is chosen over ## Next steps -- Build a [revolutionary app](/app-developers/get-started) that uses multiple blockchains within the Superchain. -- Deploy a [SuperchainERC20](./tutorials/deploy-superchain-erc20) to the Superchain. -- View more [interop tutorials](./tutorials). \ No newline at end of file +* Build a [revolutionary app](/app-developers/get-started) that uses multiple blockchains within the Superchain. +* Deploy a [SuperchainERC20](./tutorials/deploy-superchain-erc20) to the Superchain. +* View more [interop tutorials](./tutorials). diff --git a/pages/stack/interop/tutorials/message-passing.mdx b/pages/stack/interop/tutorials/message-passing.mdx index a124b43c3..1007024ba 100644 --- a/pages/stack/interop/tutorials/message-passing.mdx +++ b/pages/stack/interop/tutorials/message-passing.mdx @@ -93,10 +93,9 @@ For development purposes, we'll first use autorelay mode to handle message execu ### Setting up test networks - - + If you attempt to run these steps with the [devnet](../tools/devnet), you *must* Send the executing message yourself, as explained [here](#implement-manual-message-relaying). - + 1. In the directory where Supersim is installed, start it with autorelay. @@ -107,7 +106,7 @@ For development purposes, we'll first use autorelay mode to handle message execu Supersim creates three `anvil` blockchains: | Role | ChainID | RPC URL | - | -------- | ------: | --------------------------------------------- | + | -------- | ------: | ---------------------------------------------- | | L1 | 900 | [http://127.0.0.1:8545](http://127.0.0.1:8545) | | OPChainA | 901 | [http://127.0.0.1:9545](http://127.0.0.1:9545) | | OPChainB | 902 | [http://127.0.0.1:9546](http://127.0.0.1:9546) | @@ -143,11 +142,12 @@ For development purposes, we'll first use autorelay mode to handle message execu cd onchain-code forge init ``` + 2. In `src/Greeter.sol` put this file. This is a variation on [Hardhat's Greeter contract](https://github.com/matter-labs/hardhat-zksync/blob/main/examples/upgradable-example/contracts/Greeter.sol). - ```solidity file=/public/tutorials/Greeter.sol#L1-L20 hash=b3c5550bcc2cc4272125388ef23a67e7 - ``` + ```solidity file=/public/tutorials/Greeter.sol#L1-L20 hash=b3c5550bcc2cc4272125388ef23a67e7 + ``` 3. Deploy the `Greeter` contract to Chain B and store the resulting contract address in the `GREETER_B_ADDR` environment variable. @@ -446,8 +446,8 @@ In production we will not have this, we need to create our own executing message 2. Create or replace `src/app.mts` with this code. - ```typescript file=/public/tutorials/app.mts#L1-L51 hash=8f6f776884b8e37ae613f7aea8cd6a3b - ``` + ```typescript file=/public/tutorials/app.mts#L1-L51 hash=8f6f776884b8e37ae613f7aea8cd6a3b + ``` 3. Run the program, see that a greeting from chain A is relayed to chain B. @@ -495,49 +495,58 @@ In production we will not have this, we need to create our own executing message 1. Replace `src/app.mts` with: - ```typescript file=/public/tutorials/app_v2.mts hash=a7b0f60aa6f1e48fc9994178ed3d5498 - ``` + ```typescript file=/public/tutorials/app_v2.mts hash=a7b0f60aa6f1e48fc9994178ed3d5498 + ```
- Explanation + Explanation + + 1. **Import Required Libraries** + + * Imports functions from `viem` for wallet creation, HTTP transport, and contract interactions. - 1. **Import Required Libraries** + * Imports `@eth-optimism/viem` utilities for handling OP-Stack-specific actions and interoperability. - * Imports functions from `viem` for wallet creation, HTTP transport, and contract interactions. - * Imports `@eth-optimism/viem` utilities for handling OP-Stack-specific actions and interoperability. - * Loads ABI definitions from `Greeter.json` and `GreetingSender.json` for contract interactions. + * Loads ABI definitions from `Greeter.json` and `GreetingSender.json` for contract interactions. - 2. **Initialize Wallet Clients** + 2. **Initialize Wallet Clients** - * Uses `privateKeyToAccount` to generate an account from an environment variable. - * Creates `walletA` for chain `supersimL2A` and `walletB` for chain `supersimL2B`, extending them with Viem's public and OP-Stack-specific actions. + * Uses `privateKeyToAccount` to generate an account from an environment variable. - 3. **Get Contract Instances** + * Creates `walletA` for chain `supersimL2A` and `walletB` for chain `supersimL2B`, extending them with Viem's public and OP-Stack-specific actions. - * Retrieves contract instances for `greeter` on `walletB` and `greetingSender` on `walletA` using `getContract`. - * The addresses are taken from environment variables, and the clients are set to the respective wallets. + 3. **Get Contract Instances** - 4. **Direct Greeting on Chain B** + * Retrieves contract instances for `greeter` on `walletB` and `greetingSender` on `walletA` using `getContract`. - * Calls `setGreeting` on `greeter` to store a greeting directly on chain B. - * Waits for the transaction to be confirmed using `waitForTransactionReceipt`. - * Reads and logs the greeting stored on chain B. + * The addresses are taken from environment variables, and the clients are set to the respective wallets. - 5. **Cross-Chain Greeting via Chain A** + 4. **Direct Greeting on Chain B** - * Calls `setGreeting` on `greetingSender` to send a greeting through chain A. - * Waits for the transaction receipt on chain A. + * Calls `setGreeting` on `greeter` to store a greeting directly on chain B. - 6. **Retrieve and Relay the Cross-Chain Message** + * Waits for the transaction to be confirmed using `waitForTransactionReceipt`. - * Extracts the message from the transaction receipt using `createInteropSentL2ToL2Messages`. - * Relays the message to chain B using `walletB.interop.relayMessage`. - * Waits for confirmation of the relay transaction. + * Reads and logs the greeting stored on chain B. - 7. **Verify the Updated Greeting on Chain B** + 5. **Cross-Chain Greeting via Chain A** - * Reads the greeting from `greeter` after the relay process. - * Logs the updated greeting, showing that it was successfully relayed from chain A to chain B. + * Calls `setGreeting` on `greetingSender` to send a greeting through chain A. + + * Waits for the transaction receipt on chain A. + + 6. **Retrieve and Relay the Cross-Chain Message** + + * Extracts the message from the transaction receipt using `createInteropSentL2ToL2Messages`. + + * Relays the message to chain B using `walletB.interop.relayMessage`. + + * Waits for confirmation of the relay transaction. + + 7. **Verify the Updated Greeting on Chain B** + + * Reads the greeting from `greeter` after the relay process. + * Logs the updated greeting, showing that it was successfully relayed from chain A to chain B.
2. Rerun the JavaScript program, and see that the message is relayed. @@ -552,7 +561,7 @@ In production we will not have this, we need to create our own executing message You can relay messages in exactly the same way you'd do it on Supersim. | Contract | Network | Address | - | --------------- | ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | + | ---------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `Greeter` | [Devnet 1](../tools/devnet#interop-devnet-1) | [`0x1A183FCf61053B7dcd2322BbE766f7E1946d3718`](https://sid.testnet.routescan.io/address/0x1A183FCf61053B7dcd2322BbE766f7E1946d3718) | | `GreetingSender` | [Devnet 0](../tools/devnet#interop-devnet-1) | [`0x9De9f84a4EB3616B44CF1d68cD1A9098Df6cB25f`](https://sid.testnet.routescan.io/address/0x9De9f84a4EB3616B44CF1d68cD1A9098Df6cB25f/contract/420120000/readContract?chainid=420120000) | @@ -561,7 +570,7 @@ In production we will not have this, we need to create our own executing message 1. In `src/app.mts`, replace these lines to update the chains and contract addresses. | Line number | New content | - | ----------: | ------------------------------------------------------------------------- | + | ----------: | -------------------------------------------------------------------------- | | 9 | `import { interopAlpha0, interopAlpha1 } from '@eth-optimism/viem/chains'` | | 23 | ` chain: interopAlpha0,` | | 31 | ` chain: interopAlpha1,` | @@ -574,22 +583,22 @@ In production we will not have this, we need to create our own executing message export PRIV_KEY=0x ``` - 3. Send ETH to the two L2 blockchains. + 3. Send ETH to the two L2 blockchains. - ```sh - cast send --rpc-url https://endpoints.omniatech.io/v1/eth/sepolia/public --private-key $PRIV_KEY --value 0.001ether 0x7385d89d38ab79984e7c84fab9ce5e6f4815468a - cast send --rpc-url https://endpoints.omniatech.io/v1/eth/sepolia/public --private-key $PRIV_KEY --value 0.001ether 0x55f5c4653dbcde7d1254f9c690a5d761b315500c - ``` + ```sh + cast send --rpc-url https://endpoints.omniatech.io/v1/eth/sepolia/public --private-key $PRIV_KEY --value 0.001ether 0x7385d89d38ab79984e7c84fab9ce5e6f4815468a + cast send --rpc-url https://endpoints.omniatech.io/v1/eth/sepolia/public --private-key $PRIV_KEY --value 0.001ether 0x55f5c4653dbcde7d1254f9c690a5d761b315500c + ``` - Wait a few minutes until you can see the ETH [on your explorer](https://sid.testnet.routescan.io/). + Wait a few minutes until you can see the ETH [on your explorer](https://sid.testnet.routescan.io/). - 3. Rerun the test. + 4. Rerun the test. ```sh npm start ``` - 4. You can see the transactions in a block explorer. + 5. You can see the transactions in a block explorer. * The first transaction, which sets the greeting directly, [on the `Greeter` contract on interop1](https://sid.testnet.routescan.io/address/0x1A183FCf61053B7dcd2322BbE766f7E1946d3718). * The second transaction, the initiation message for the cross chain greeting change, [on the `GreetingSender` contract on interop0](https://sid.testnet.routescan.io/address/0x9De9f84a4EB3616B44CF1d68cD1A9098Df6cB25f). diff --git a/words.txt b/words.txt index 76ee91283..f4402123e 100644 --- a/words.txt +++ b/words.txt @@ -338,6 +338,7 @@ Reown Reown's replayability replayor +reposts REQUIREDBLOCKS requiredblocks rollouts From 77e1423c21034328110951179d07325d27a55ccc Mon Sep 17 00:00:00 2001 From: soyboy Date: Fri, 14 Feb 2025 16:27:43 -0800 Subject: [PATCH 3/3] minor formatting change --- pages/notices/pectra-changes.mdx | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/pages/notices/pectra-changes.mdx b/pages/notices/pectra-changes.mdx index 7873c815f..106e8ec91 100644 --- a/pages/notices/pectra-changes.mdx +++ b/pages/notices/pectra-changes.mdx @@ -56,9 +56,7 @@ Node operators will need to upgrade to the respective releases before the activa ## For chain operators -The following sections are how chain operators can prepare the first part of the OP Stack's Pectra L1 support. This ensures OP Stack chains do not break when the L1 Pectra upgrade activates. - -Every chain operator will need to: +The following sections are how chain operators can prepare the first part of the OP Stack's Pectra L1 support. This ensures OP Stack chains do not break when the L1 Pectra upgrade activates. Every chain operator will need to: