From f11a16953a6e046ccbf8e7ab43a087e997d4e2cc Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Fri, 6 Dec 2024 11:07:51 -0500 Subject: [PATCH 1/3] chore(deps): Bump codecov/codecov-action from 5.0.7 to 5.1.1 (#4085) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bumps [codecov/codecov-action](https://github.com/codecov/codecov-action) from 5.0.7 to 5.1.1.
Release notes

Sourced from codecov/codecov-action's releases.

v5.1.1

What's Changed

Full Changelog: https://github.com/codecov/codecov-action/compare/v5.1.0...v5.1.1

v5.1.0

What's Changed

Full Changelog: https://github.com/codecov/codecov-action/compare/v5.0.7...v5.1.0

Changelog

Sourced from codecov/codecov-action's changelog.

v5.1.1

What's Changed

Full Changelog: https://github.com/codecov/codecov-action/compare/v5.1.0..v5.1.1

v5.1.0

What's Changed

Full Changelog: https://github.com/codecov/codecov-action/compare/v5.0.7..v5.1.0

Commits

[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=codecov/codecov-action&package-manager=github_actions&previous-version=5.0.7&new-version=5.1.1)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) ---
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> --- .github/workflows/test.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/test.yml b/.github/workflows/test.yml index 3b0739c52d..3228c0ac22 100644 --- a/.github/workflows/test.yml +++ b/.github/workflows/test.yml @@ -41,7 +41,7 @@ jobs: run: make test-coverage - name: Upload coverage.txt - uses: codecov/codecov-action@v5.0.7 + uses: codecov/codecov-action@v5.1.1 with: file: ./coverage.txt From 521543d8a848894a85a9301091fc956ac700260a Mon Sep 17 00:00:00 2001 From: savvasmoke <136869149+savvar9991@users.noreply.github.com> Date: Tue, 10 Dec 2024 01:21:45 +1100 Subject: [PATCH 2/3] docs: fix transaction typos, grammar and documentation links (#4098) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 1. Fix typos in transaction-related terms: - "transacton" → "transaction" - "transcation" → "transaction" - "WantMsg" → "WantTx" 2. Fix grammar: - "blobs must be placed is a way" → "blobs must be placed in a way" 3. Update environment variable name for consistency: - "KNUUU_TIMEOUT" → "KNUU_TIMEOUT" 4. Fix apostrophe usage: - "TTL's" → "TTLs" 5. Update minikube documentation link: - Change from French version (kubernetes.io/fr/) to English version (kubernetes.io/docs/) --- specs/src/cat_pool.md | 4 ++-- specs/src/data_square_layout.md | 2 +- test/e2e/readme.md | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/specs/src/cat_pool.md b/specs/src/cat_pool.md index a71dc27cc3..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 @@ -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: 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. 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 818026ac446570605d3db582f2d261fb392e1973 Mon Sep 17 00:00:00 2001 From: Rootul P Date: Mon, 9 Dec 2024 09:26:57 -0500 Subject: [PATCH 3/3] feat: set defaults for `--v2-upgrade-height` (#4091) Closes https://github.com/celestiaorg/celestia-app/issues/3995 If a user specifies the `--v2-upgrade-height` flag then it takes precedence over any defaults. If the user doesn't specify a `--v2-upgrade-height` flag and the chainID is `arabica-11`, `mocha-4`, or `celestia` then the v2 upgrade height is set to the block height that was coordinated on those chains. See: https://docs.celestia.org/how-to-guides/network-upgrade-process#lemongrass-network-upgrade ## Testing 1. `./scripts/single-node.sh` doesn't set a v2 upgrade height 2. `./arabica.sh` if we remove the `--v2-upgrade-height` flag in the script, gets defaulted correctly 3. `./arabica.sh` if we override the `--v2-upgrade-height` flag in the script, that gets used --- cmd/celestia-appd/cmd/start.go | 15 +++++++++++++++ pkg/appconsts/chain_ids.go | 2 ++ pkg/appconsts/upgrade_heights.go | 13 +++++++++++++ 3 files changed, 30 insertions(+) create mode 100644 pkg/appconsts/upgrade_heights.go diff --git a/cmd/celestia-appd/cmd/start.go b/cmd/celestia-appd/cmd/start.go index de97d4dfa0..c43e5f3d75 100644 --- a/cmd/celestia-appd/cmd/start.go +++ b/cmd/celestia-appd/cmd/start.go @@ -14,6 +14,7 @@ import ( "strings" "time" + "github.com/celestiaorg/celestia-app/v3/pkg/appconsts" "github.com/cosmos/cosmos-sdk/client" "github.com/cosmos/cosmos-sdk/client/flags" "github.com/cosmos/cosmos-sdk/codec" @@ -117,6 +118,20 @@ is performed. Note, when enabled, gRPC will also be automatically enabled. return err } + switch clientCtx.ChainID { + case appconsts.ArabicaChainID: + serverCtx.Logger.Info(fmt.Sprintf("Since the chainID is %v, configuring the default v2 upgrade height to %v", appconsts.ArabicaChainID, appconsts.ArabicaUpgradeHeightV2)) + serverCtx.Viper.SetDefault(UpgradeHeightFlag, appconsts.ArabicaUpgradeHeightV2) + case appconsts.MochaChainID: + serverCtx.Logger.Info(fmt.Sprintf("Since the chainID is %v, configuring the default v2 upgrade height to %v", appconsts.MochaChainID, appconsts.MochaUpgradeHeightV2)) + serverCtx.Viper.SetDefault(UpgradeHeightFlag, appconsts.MochaUpgradeHeightV2) + case appconsts.MainnetChainID: + serverCtx.Logger.Info(fmt.Sprintf("Since the chainID is %v, configuring the default v2 upgrade height to %v", appconsts.MainnetChainID, appconsts.MainnetUpgradeHeightV2)) + serverCtx.Viper.SetDefault(UpgradeHeightFlag, appconsts.MainnetUpgradeHeightV2) + default: + serverCtx.Logger.Info(fmt.Sprintf("No default value exists for the v2 upgrade height when the chainID is %v", clientCtx.ChainID)) + } + withTM, _ := cmd.Flags().GetBool(flagWithTendermint) if !withTM { serverCtx.Logger.Info("starting ABCI without Tendermint") diff --git a/pkg/appconsts/chain_ids.go b/pkg/appconsts/chain_ids.go index 50c26932f9..056bc2606e 100644 --- a/pkg/appconsts/chain_ids.go +++ b/pkg/appconsts/chain_ids.go @@ -2,4 +2,6 @@ package appconsts const ( ArabicaChainID = "arabica-11" + MochaChainID = "mocha-4" + MainnetChainID = "celestia" ) diff --git a/pkg/appconsts/upgrade_heights.go b/pkg/appconsts/upgrade_heights.go new file mode 100644 index 0000000000..13ee0963f0 --- /dev/null +++ b/pkg/appconsts/upgrade_heights.go @@ -0,0 +1,13 @@ +package appconsts + +const ( + // ArabicaUpgradeHeightV2 is the block height at which the arabica-11 + // upgraded from app version 1 to 2. + ArabicaUpgradeHeightV2 = 1751707 + // MochaUpgradeHeightV2 is the block height at which the mocha-4 upgraded + // from app version 1 to 2. + MochaUpgradeHeightV2 = 2585031 + // MainnetUpgradeHeightV2 is the block height at which the celestia upgraded + // from app version 1 to 2. + MainnetUpgradeHeightV2 = 2371495 +)