From dee9ef6f28f9bd769c74cdfbc7c686139ec02306 Mon Sep 17 00:00:00 2001 From: DevEloperate Date: Tue, 3 Dec 2024 20:51:55 +0300 Subject: [PATCH 1/8] typo square_size.go --- app/square_size.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/square_size.go b/app/square_size.go index 4ed7f0ac5d..2351363692 100644 --- a/app/square_size.go +++ b/app/square_size.go @@ -10,7 +10,7 @@ func (app *App) MaxEffectiveSquareSize(ctx sdk.Context) int { // TODO: fix hack that forces the max square size for the first height to // 64. This is due to our fork of the sdk not initializing state before // BeginBlock of the first block. This is remedied in versions of the sdk - // and comet that have full support of PreparePropsoal, although + // and comet that have full support of PrepareProposal, although // celestia-app does not currently use those. see this PR for more details // https://github.com/cosmos/cosmos-sdk/pull/14505 if ctx.BlockHeader().Height <= 1 { From 1364b39d4adef86ff337b4f1019d86c5000d7827 Mon Sep 17 00:00:00 2001 From: DevEloperate Date: Tue, 3 Dec 2024 20:52:55 +0300 Subject: [PATCH 2/8] typo adr-021-restricted-block-size.md --- docs/architecture/adr-021-restricted-block-size.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture/adr-021-restricted-block-size.md b/docs/architecture/adr-021-restricted-block-size.md index 6f372e5952..d7dffcf267 100644 --- a/docs/architecture/adr-021-restricted-block-size.md +++ b/docs/architecture/adr-021-restricted-block-size.md @@ -106,7 +106,7 @@ func (app *App) GovMaxSquareSize(ctx sdk.Context) int { // TODO: fix hack that forces the max square size for the first height to // 64. This is due to tendermint not technically supposed to be calling // PrepareProposal when heights are not >= 1. This is remedied in versions - // of the sdk and comet that have full support of PreparePropsoal, although + // of the sdk and comet that have full support of PrepareProposal, although // celestia-app does not currently use those. see this PR for more // details https://github.com/cosmos/cosmos-sdk/pull/14505 if ctx.BlockHeader().Height == 0 { From 572af0e32aff52428c1b913a21e139bafa7a4cba Mon Sep 17 00:00:00 2001 From: DevEloperate Date: Tue, 3 Dec 2024 20:54:11 +0300 Subject: [PATCH 3/8] typo max_total_blob_size_ante.go --- x/blob/ante/max_total_blob_size_ante.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x/blob/ante/max_total_blob_size_ante.go b/x/blob/ante/max_total_blob_size_ante.go index 3a9af081c1..98cd67549f 100644 --- a/x/blob/ante/max_total_blob_size_ante.go +++ b/x/blob/ante/max_total_blob_size_ante.go @@ -62,7 +62,7 @@ func (d MaxTotalBlobSizeDecorator) getMaxSquareSize(ctx sdk.Context) int { // TODO: fix hack that forces the max square size for the first height to // 64. This is due to our fork of the sdk not initializing state before // BeginBlock of the first block. This is remedied in versions of the sdk - // and comet that have full support of PreparePropsoal, although + // and comet that have full support of PrepareProposal, although // celestia-app does not currently use those. see this PR for more details // https://github.com/cosmos/cosmos-sdk/pull/14505 if ctx.BlockHeader().Height <= 1 { From e1b0556a64dd8d65760b126cbc39e941d0bd6120 Mon Sep 17 00:00:00 2001 From: DevEloperate Date: Tue, 3 Dec 2024 20:54:32 +0300 Subject: [PATCH 4/8] typo blob_share_decorator.go --- x/blob/ante/blob_share_decorator.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x/blob/ante/blob_share_decorator.go b/x/blob/ante/blob_share_decorator.go index 90eb7780c6..4c0c0361b0 100644 --- a/x/blob/ante/blob_share_decorator.go +++ b/x/blob/ante/blob_share_decorator.go @@ -59,7 +59,7 @@ func (d BlobShareDecorator) getMaxSquareSize(ctx sdk.Context) int { // TODO: fix hack that forces the max square size for the first height to // 64. This is due to our fork of the sdk not initializing state before // BeginBlock of the first block. This is remedied in versions of the sdk - // and comet that have full support of PreparePropsoal, although + // and comet that have full support of PrepareProposal, although // celestia-app does not currently use those. see this PR for more details // https://github.com/cosmos/cosmos-sdk/pull/14505 if ctx.BlockHeader().Height <= 1 { From c23b4a39dc8bd2a797e1c5ce6bae7f3681fca3e7 Mon Sep 17 00:00:00 2001 From: DevEloperate Date: Tue, 3 Dec 2024 20:56:01 +0300 Subject: [PATCH 5/8] typo cat_pool.md --- specs/src/cat_pool.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/src/cat_pool.md b/specs/src/cat_pool.md index 22ad999aec..fd7439966f 100644 --- a/specs/src/cat_pool.md +++ b/specs/src/cat_pool.md @@ -60,7 +60,7 @@ Given this criteria, it is feasible, yet unlikely that a node receives two `Seen A `SeenTx` MAY be sent for each transaction currently in the transaction pool when a connection with a peer is first established. This acts as a mechanism for syncing pool state across peers. -The `SeenTx` message MUST only be broadcasted after validation and storage. Although it is possible that a node later drops a transaction under load shedding, a `SeenTx` should give as strong guarantees as possible that the node can be relied upon by others that don't yet have the transcation to obtain it. +The `SeenTx` message MUST only be broadcasted after validation and storage. Although it is possible that a node later drops a transaction under load shedding, a `SeenTx` should give as strong guarantees as possible that the node can be relied upon by others that don't yet have the transaction to obtain it. > **Note:** > Inbound transactions submitted via the RPC do not trigger a `SeenTx` message as it is assumed that the node is the first to see the transaction and by gossiping it to others it is implied that the node has seen the transaction. From ffa749ef724efad8fb5e32d1d9dc7c0ee9267b9b Mon Sep 17 00:00:00 2001 From: DevEloperate Date: Tue, 3 Dec 2024 20:57:46 +0300 Subject: [PATCH 6/8] typo adr-011-optimistic-blob-size-independent-inclusion-proofs-and-pfb-fraud-proofs.md --- ...ob-size-independent-inclusion-proofs-and-pfb-fraud-proofs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture/adr-011-optimistic-blob-size-independent-inclusion-proofs-and-pfb-fraud-proofs.md b/docs/architecture/adr-011-optimistic-blob-size-independent-inclusion-proofs-and-pfb-fraud-proofs.md index 599f28eb18..80be2d77ee 100644 --- a/docs/architecture/adr-011-optimistic-blob-size-independent-inclusion-proofs-and-pfb-fraud-proofs.md +++ b/docs/architecture/adr-011-optimistic-blob-size-independent-inclusion-proofs-and-pfb-fraud-proofs.md @@ -51,7 +51,7 @@ A PFB Fraud Proof = PFB Inclusion Proof + Blob Inclusion Proof After you verify the PFB Inclusion Proof you will get the: - index where the blob is located -- how long the bob is +- how long the blob is - the commitment of the blob With the information that you now confirmed you can confirm the blob inclusion proof of the shares that start at the index for the given length. From a2b5c12d40c87d1a5ac4d68ef105ab93cb8ce00e Mon Sep 17 00:00:00 2001 From: DevEloperate Date: Tue, 3 Dec 2024 21:09:15 +0300 Subject: [PATCH 7/8] typo README.md --- x/tokenfilter/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x/tokenfilter/README.md b/x/tokenfilter/README.md index 3345d01900..2792ab70e2 100644 --- a/x/tokenfilter/README.md +++ b/x/tokenfilter/README.md @@ -7,7 +7,7 @@ their native token within their state machine. ## Context -When tokens are transferred through the IBC transfer module, the denomination of that token is modified at each hop. It's more accurate to think of the tokens transferring to another network to actually remain held in escrow at the origin chain and the destination chain minting a "wrapped" equivalent. Thus tokens moved to a non-native state machine are beholdent to the security of both chains. The denomination is denoted as the path it's taken from the origin chain. To provide an example, imagine 3 chains: A, B and C with native tokens "a", "b", "c". With IBC's transfer module, when a user transfers token "a" from A to B, the wrapped token is prefixed with the source port and source channel (i.e. `portidone/channel-0/a`), this is Ba. If the token is further transferred to C it becomes BCa (or `portidtwo/channel-1/portidone/channel-0/a`). This token is now beholdent to the security of B, C and A. Also note that this is different if "a" were to go directly to C. In other words: `Ca != BCa`. +When tokens are transferred through the IBC transfer module, the denomination of that token is modified at each hop. It's more accurate to think of the tokens transferring to another network to actually remain held in escrow at the origin chain and the destination chain minting a "wrapped" equivalent. Thus tokens moved to a non-native state machine are beholdent to the security of both chains. The denomination is denoted as the path it's taken from the origin chain. To provide an example, imagine 3 chains: A, B and C with native tokens "a", "b", "c". With IBC's transfer module, when a user transfers token "a" from A to B, the wrapped token is prefixed with the source port and source channel (i.e. `portidone/channel-0/a`), this is Ba. If the token is further transferred to C it becomes BCa (or `portidtwo/channel-1/portidone/channel-0/a`). This token is now beholden to the security of B, C and A. Also note that this is different if "a" were to go directly to C. In other words: `Ca != BCa`. This context is important in recognising when a native token is returning to its origin state machine. Each IBC packet contains metadata including the source port and channel. Therefore if the denomination of the token is prefixed with the same source port and channel as detailed in the packet, we can conclude that the denomination originally came from the receiving chain. From bcc952f4beff71c1e052f060c68748fa92d2a8ea Mon Sep 17 00:00:00 2001 From: DevEloperate Date: Tue, 3 Dec 2024 21:09:44 +0300 Subject: [PATCH 8/8] typo README.md --- x/tokenfilter/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/x/tokenfilter/README.md b/x/tokenfilter/README.md index 2792ab70e2..ca7a51b397 100644 --- a/x/tokenfilter/README.md +++ b/x/tokenfilter/README.md @@ -7,7 +7,7 @@ their native token within their state machine. ## Context -When tokens are transferred through the IBC transfer module, the denomination of that token is modified at each hop. It's more accurate to think of the tokens transferring to another network to actually remain held in escrow at the origin chain and the destination chain minting a "wrapped" equivalent. Thus tokens moved to a non-native state machine are beholdent to the security of both chains. The denomination is denoted as the path it's taken from the origin chain. To provide an example, imagine 3 chains: A, B and C with native tokens "a", "b", "c". With IBC's transfer module, when a user transfers token "a" from A to B, the wrapped token is prefixed with the source port and source channel (i.e. `portidone/channel-0/a`), this is Ba. If the token is further transferred to C it becomes BCa (or `portidtwo/channel-1/portidone/channel-0/a`). This token is now beholden to the security of B, C and A. Also note that this is different if "a" were to go directly to C. In other words: `Ca != BCa`. +When tokens are transferred through the IBC transfer module, the denomination of that token is modified at each hop. It's more accurate to think of the tokens transferring to another network to actually remain held in escrow at the origin chain and the destination chain minting a "wrapped" equivalent. Thus tokens moved to a non-native state machine are beholden to the security of both chains. The denomination is denoted as the path it's taken from the origin chain. To provide an example, imagine 3 chains: A, B and C with native tokens "a", "b", "c". With IBC's transfer module, when a user transfers token "a" from A to B, the wrapped token is prefixed with the source port and source channel (i.e. `portidone/channel-0/a`), this is Ba. If the token is further transferred to C it becomes BCa (or `portidtwo/channel-1/portidone/channel-0/a`). This token is now beholden to the security of B, C and A. Also note that this is different if "a" were to go directly to C. In other words: `Ca != BCa`. This context is important in recognising when a native token is returning to its origin state machine. Each IBC packet contains metadata including the source port and channel. Therefore if the denomination of the token is prefixed with the same source port and channel as detailed in the packet, we can conclude that the denomination originally came from the receiving chain.