From 5ed2ea786eab9521d01206a7e927084e9d679797 Mon Sep 17 00:00:00 2001 From: savvasmoke <136869149+savvar9991@users.noreply.github.com> Date: Mon, 9 Dec 2024 13:34:56 +1100 Subject: [PATCH 1/3] Update readme.md - Standardize environment variable naming: use `KNUU_TIMEOUT` instead of `KNUUU_TIMEOUT` to match with `KNUU_NAMESPACE` - Update minikube documentation link to use the English version instead of French - Fix formatting issues --- test/e2e/readme.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/test/e2e/readme.md b/test/e2e/readme.md index ab0dbe8264..913ee84862 100644 --- a/test/e2e/readme.md +++ b/test/e2e/readme.md @@ -30,7 +30,7 @@ make test-e2e E2ESimple **Optional parameters**: -- `KNUUU_TIMEOUT` can be used to override the default timeout of 60 minutes for the tests. +- `KNUU_TIMEOUT` can be used to override the default timeout of 60 minutes for the tests. ## Observation @@ -56,7 +56,7 @@ This will back up your default kubernetes configuration. If you use a different ### Install minikube -Minikube is required to be installed on your machine. If you have a linux machine, follow the [minikube docs](https://kubernetes.io/fr/docs/tasks/tools/install-minikube/). If you're on macOS ARM, this [tutorial](https://devopscube.com/minikube-mac/) can be helpful to run it using qemu. +Minikube is required to be installed on your machine. If you have a linux machine, follow the [minikube docs](https://kubernetes.io/docs/tasks/tools/install-minikube/). If you're on macOS ARM, this [tutorial](https://devopscube.com/minikube-mac/) can be helpful to run it using qemu. ### Create namespace From 026b5a6afd68b8ba95f5ecd1b8e76175e0dee5b7 Mon Sep 17 00:00:00 2001 From: savvasmoke <136869149+savvar9991@users.noreply.github.com> Date: Mon, 9 Dec 2024 14:03:53 +1100 Subject: [PATCH 2/3] fix-typo Update cat_pool.md --- specs/src/cat_pool.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/specs/src/cat_pool.md b/specs/src/cat_pool.md index 22ad999aec..ccc5caa74a 100644 --- a/specs/src/cat_pool.md +++ b/specs/src/cat_pool.md @@ -41,7 +41,7 @@ Both `SeenTx` and `WantTx` contain the sha256 hash of the raw transaction bytes. Both messages are sent across a new channel with the ID: `byte(0x31)`. This enables cross compatibility as discussed in greater detail below. > **Note:** -> The term `SeenTx` is used over the more common `HasTx` because the transaction pool contains sophisticated eviction logic. TTL's, higher priority transactions and reCheckTx may mean that a transaction pool *had* a transaction but does not have it any more. Semantically it's more appropriate to use `SeenTx` to imply not the presence of a transaction but that the node has seen it and dealt with it accordingly. +> The term `SeenTx` is used over the more common `HasTx` because the transaction pool contains sophisticated eviction logic. TTLs, higher priority transactions and reCheckTx may mean that a transaction pool *had* a transaction but does not have it any more. Semantically it's more appropriate to use `SeenTx` to imply not the presence of a transaction but that the node has seen it and dealt with it accordingly. ## Outbound logic @@ -53,14 +53,14 @@ A node in the protocol has two distinct modes: "broadcast" and "request/response A `SeenTx` is broadcasted to ALL nodes upon receiving a "new" transaction from a peer. The transaction pool does not need to track every unique inbound transaction, therefore "new" is identified as: - The node does not currently have the transaction -- The node did not recently reject the transacton or has recently seen the same transaction committed (subject to the size of the cache) +- The node did not recently reject the transaction or has recently seen the same transaction committed (subject to the size of the cache) - The node did not recently evict the transaction (subject to the size of the cache) Given this criteria, it is feasible, yet unlikely that a node receives two `SeenTx` messages from the same peer for the same transaction. 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. @@ -88,7 +88,7 @@ Upon receiving a `SeenTx` message: - If the node does not have the transaction but recently evicted it, it MAY choose to rerequest the transaction if it has adequate resources now to process it. - If the node has not seen the transaction or does not have any pending requests for that transaction, it can do one of two things: - It MAY immediately request the tx from the peer with a `WantTx`. - - If the node is connected to the peer specified in `FROM`, it is likely, from a non-byzantine peer, that the node will also shortly receive the transaction from the peer. It MAY wait for a `Txs` message for a bounded amount of time but MUST eventually send a `WantMsg` message to either the original peer or any other peer that *has* the specified transaction. + - If the node is connected to the peer specified in `FROM`, it is likely, from a non-byzantine peer, that the node will also shortly receive the transaction from the peer. It MAY wait for a `Txs` message for a bounded amount of time but MUST eventually send a `WantTx` message to either the original peer or any other peer that *has* the specified transaction. Upon receiving a `WantTx` message: From 9af724d9a3db6aa606d2ff23f579f08da5a5450e Mon Sep 17 00:00:00 2001 From: savvasmoke <136869149+savvar9991@users.noreply.github.com> Date: Mon, 9 Dec 2024 15:47:23 +1100 Subject: [PATCH 3/3] Update data_square_layout.md --- specs/src/data_square_layout.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/src/data_square_layout.md b/specs/src/data_square_layout.md index 70e476250f..e7eb64d226 100644 --- a/specs/src/data_square_layout.md +++ b/specs/src/data_square_layout.md @@ -39,7 +39,7 @@ The order of blobs in a namespace is dictated by the priority of the PFBs that p Transactions can pay fees for a blob to be included in the same block as the transaction itself. It may seem natural to bundle the `MsgPayForBlobs` transaction that pays for a number of blobs with these blobs (which is the case in other blockchains with native execution, e.g. calldata in Ethereum transactions or OP_RETURN data in Bitcoin transactions), however this would mean that processes validating the state of the Celestia network would need to download all blob data. PayForBlob transactions must therefore only include a commitment to (i.e. some hash of) the blob they pay fees for. If implemented naively (e.g. with a simple hash of the blob, or a simple binary Merkle tree root of the blob), this can lead to a data availability problem, as there are no guarantees that the data behind these commitments is actually part of the block data. -To that end, we impose some additional rules onto _blobs only_: blobs must be placed is a way such that both the transaction sender and the block producer can be held accountable—a necessary property for e.g. fee burning. Accountable in this context means that +To that end, we impose some additional rules onto _blobs only_: blobs must be placed in a way such that both the transaction sender and the block producer can be held accountable—a necessary property for e.g. fee burning. Accountable in this context means that 1. The transaction sender must pay sufficient fees for blob inclusion. 1. The block proposer cannot claim that a blob was included when it was not (which implies that a transaction and the blob it pays for must be included in the same block). In addition all blobs must be accompanied by a PayForBlob transaction.