From 682a7ed385a12ab409f151c836ae4545e3e020d7 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Tue, 5 Nov 2024 00:36:33 +0300 Subject: [PATCH 1/5] typo correction arabica-devnet.md --- how-to-guides/arabica-devnet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/how-to-guides/arabica-devnet.md b/how-to-guides/arabica-devnet.md index a32763e04f..e5462f94cc 100644 --- a/how-to-guides/arabica-devnet.md +++ b/how-to-guides/arabica-devnet.md @@ -24,7 +24,7 @@ it is a useful way to keep testing the latest changes in the software. Developers can still deploy on Mocha testnet their sovereign rollups if they chose to do so, it just will always lag behind Arabica devnet until Mocha -undergoes network upgrades upgrades in coordination with validators. +undergoes network upgrades in coordination with validators. ## Network details From edf43469ecb2e0886245815c7027a27a11d3e896 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Tue, 5 Nov 2024 00:43:41 +0300 Subject: [PATCH 2/5] typo correction arbitrum-integration.md --- how-to-guides/arbitrum-integration.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/how-to-guides/arbitrum-integration.md b/how-to-guides/arbitrum-integration.md index 2da9ea99f7..52b0dddb6b 100644 --- a/how-to-guides/arbitrum-integration.md +++ b/how-to-guides/arbitrum-integration.md @@ -57,14 +57,14 @@ The following represents a non-exhaustive list of considerations when running a ### Preimage Oracle Implementation -In order to support fraud proofs, this integration has the necessary code for a Nitro validator to populate its preimage mapping with Celestia hashes that then get "unpealed" in order to reveal the full data for a Blob. You can +In order to support fraud proofs, this integration has the necessary code for a Nitro validator to populate its preimage mapping with Celestia hashes that then get "unpeeled" in order to reveal the full data for a Blob. You can [read more about the "Hash Oracle Trick"](https://docs.arbitrum.io/inside-arbitrum-nitro/#readpreimage-and-the-hash-oracle-trick). The data structures and hashing functions for this can be found in the [`nitro/das/celestia/tree` folder](https://github.com/celestiaorg/nitro/tree/v2.3.1-rc.1/das/celestia/tree) You can see where the preimage oracle gets used in the fraud proof replay binary [here](https://github.com/celestiaorg/nitro/blob/966e631f1a03b49d49f25bea67a92b275d3bacb9/cmd/replay/main.go#L153-L294) -Something important to note is that the preimage oracle only keeps track of hashes for the rows in the Celestia data square in which a blob resides in, this way each Orbit chain with Celestia underneath does not need validators to recompute an entire Celestia Data Square, but instead, only have to compute the row roots for the rows in which it's data lives in, and the header data root, which is the binary merkle tree hash built using the row roots and column roots fetched from a Celestia node. Because only data roots that can be confirmed on Blobstream get accepted into the sequencer inbox, one can have a high degree of certainty that the canonical data root being unpealed as well as the row roots are in fact correct. +Something important to note is that the preimage oracle only keeps track of hashes for the rows in the Celestia data square in which a blob resides in, this way each Orbit chain with Celestia underneath does not need validators to recompute an entire Celestia Data Square, but instead, only have to compute the row roots for the rows in which it's data lives in, and the header data root, which is the binary merkle tree hash built using the row roots and column roots fetched from a Celestia node. Because only data roots that can be confirmed on Blobstream get accepted into the sequencer inbox, one can have a high degree of certainty that the canonical data root being unpeeled as well as the row roots are in fact correct. ### Blobstream X implementation From 32c008aab6206d55df6b3d63ce288e99613e89b8 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Tue, 5 Nov 2024 00:46:27 +0300 Subject: [PATCH 3/5] typo correction blobstream-offchain.md --- how-to-guides/blobstream-offchain.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/how-to-guides/blobstream-offchain.md b/how-to-guides/blobstream-offchain.md index e355497b38..4c99660a56 100644 --- a/how-to-guides/blobstream-offchain.md +++ b/how-to-guides/blobstream-offchain.md @@ -208,7 +208,7 @@ func (s *Sequencer) ProduceBlock(txs []json.RawMessage) (Block, error) { header := Header{ Height: uint64(len(s.Blocks) + 1), PreviousHash: lastBlock.Header.Hash(), - Namespce: s.Namespace, + Namespace: s.Namespace, Span: span, } From 6b68ab8bd6767f2549adbe8aad352e8cb3d855a3 Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Tue, 5 Nov 2024 00:51:14 +0300 Subject: [PATCH 4/5] typo correction blobstream-x-deploy.md --- how-to-guides/blobstream-x-deploy.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/how-to-guides/blobstream-x-deploy.md b/how-to-guides/blobstream-x-deploy.md index 8547be7825..86ace3a8f3 100644 --- a/how-to-guides/blobstream-x-deploy.md +++ b/how-to-guides/blobstream-x-deploy.md @@ -54,7 +54,7 @@ Assume we're deploying to a chain which chainID is 12345. The `.env` should look CREATE2_SALT= # The 'owner' of the contracts, recommended to be an EOA GUARDIAN= -# The default prover to fullfill requests for Functions that have not opted for a different prover +# The default prover to fulfill requests for Functions that have not opted for a different prover PROVER= # RPC URLs for each chain you want to deploy to RPC_12345= @@ -162,7 +162,7 @@ which will return the address of the function verifier that was deployed in the Now that the function verifier's contract is deployed and registered in the succinct gateway, we can define whitelisting rules for the proof submission. -by default, the whitelist status is set to `Default`. This means that only the default verifier, which was setup when [deploying the SuccinctGateway](#deploy-a-new-succinctgateway). And if you want to restrict the list of provers that can submit proofs to your registered function verifier, you can set the whitelisting status of the function verifier and then add a custom prover. Or even allow for permissionlss submission. +by default, the whitelist status is set to `Default`. This means that only the default verifier, which was setup when [deploying the SuccinctGateway](#deploy-a-new-succinctgateway). And if you want to restrict the list of provers that can submit proofs to your registered function verifier, you can set the whitelisting status of the function verifier and then add a custom prover. Or even allow for permissionless submission. #### Set Whitelist Status From cd92f24535ff67f9e0d00553790753dc91aebbbf Mon Sep 17 00:00:00 2001 From: Cypher Pepe <125112044+cypherpepe@users.noreply.github.com> Date: Tue, 5 Nov 2024 00:58:51 +0300 Subject: [PATCH 5/5] typo correction celestia-app-vesting.md --- how-to-guides/celestia-app-vesting.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/how-to-guides/celestia-app-vesting.md b/how-to-guides/celestia-app-vesting.md index 55c1a2d044..1e418ff6fe 100644 --- a/how-to-guides/celestia-app-vesting.md +++ b/how-to-guides/celestia-app-vesting.md @@ -45,7 +45,7 @@ Home directory: /var/folders/_8/ljj6hspn0kn09qf9fy8kdyh40000gn/T/celestia_app_XX --> Updating go.mod ``` -And set the location as the `CElESTIA_APP_HOME` variable. We will use this +And set the location as the `CELESTIA_APP_HOME` variable. We will use this for the remainder of the devnet section. ```bash