diff --git a/patches/.changelog/config.toml.patch b/patches/.changelog/config.toml.patch new file mode 100644 index 00000000000..dbeab699a7c --- /dev/null +++ b/patches/.changelog/config.toml.patch @@ -0,0 +1,7 @@ +diff --git a/.changelog/config.toml b/.changelog/config.toml +deleted file mode 100644 +index de0fee50c..000000000 +--- a/.changelog/config.toml ++++ /dev/null +@@ -1 +0,0 @@ +-project_url = 'https://github.com/cometbft/cometbft' diff --git a/patches/.changelog/epilogue.md.patch b/patches/.changelog/epilogue.md.patch new file mode 100644 index 00000000000..de99ac4058f --- /dev/null +++ b/patches/.changelog/epilogue.md.patch @@ -0,0 +1,20 @@ +diff --git a/.changelog/epilogue.md b/.changelog/epilogue.md +deleted file mode 100644 +index 1e68f6b72..000000000 +--- a/.changelog/epilogue.md ++++ /dev/null +@@ -1,14 +0,0 @@ +---- +- +-CometBFT is a fork of [Tendermint +-Core](https://github.com/tendermint/tendermint) as of late December 2022. +- +-## Bug bounty +- +-Friendly reminder, we have a [bug bounty program](https://hackerone.com/cosmos). +- +-## Previous changes +- +-For changes released before the creation of CometBFT, please refer to the +-Tendermint Core +-[CHANGELOG.md](https://github.com/tendermint/tendermint/blob/a9feb1c023e172b542c972605311af83b777855b/CHANGELOG.md). diff --git a/patches/.changelog/unreleased/.gitkeep.patch b/patches/.changelog/unreleased/.gitkeep.patch new file mode 100644 index 00000000000..cc02379cd0b --- /dev/null +++ b/patches/.changelog/unreleased/.gitkeep.patch @@ -0,0 +1,3 @@ +diff --git a/.changelog/unreleased/.gitkeep b/.changelog/unreleased/.gitkeep +deleted file mode 100644 +index e69de29bb..000000000 diff --git a/patches/.changelog/v0.34.27/breaking-changes/152-rename-binary-docker.md.patch b/patches/.changelog/v0.34.27/breaking-changes/152-rename-binary-docker.md.patch new file mode 100644 index 00000000000..e8fdad8a350 --- /dev/null +++ b/patches/.changelog/v0.34.27/breaking-changes/152-rename-binary-docker.md.patch @@ -0,0 +1,8 @@ +diff --git a/.changelog/v0.34.27/breaking-changes/152-rename-binary-docker.md b/.changelog/v0.34.27/breaking-changes/152-rename-binary-docker.md +deleted file mode 100644 +index 3870f96f9..000000000 +--- a/.changelog/v0.34.27/breaking-changes/152-rename-binary-docker.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- Rename binary to `cometbft` and Docker image to `cometbft/cometbft` +- ([\#152](https://github.com/cometbft/cometbft/pull/152)) diff --git a/patches/.changelog/v0.34.27/breaking-changes/211-deprecate-tmhome.md.patch b/patches/.changelog/v0.34.27/breaking-changes/211-deprecate-tmhome.md.patch new file mode 100644 index 00000000000..f70150981e4 --- /dev/null +++ b/patches/.changelog/v0.34.27/breaking-changes/211-deprecate-tmhome.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.27/breaking-changes/211-deprecate-tmhome.md b/.changelog/v0.34.27/breaking-changes/211-deprecate-tmhome.md +deleted file mode 100644 +index d2bded0f2..000000000 +--- a/.changelog/v0.34.27/breaking-changes/211-deprecate-tmhome.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- The `TMHOME` environment variable was renamed to `CMTHOME`, and all +- environment variables starting with `TM_` are instead prefixed with `CMT_` +- ([\#211](https://github.com/cometbft/cometbft/issues/211)) diff --git a/patches/.changelog/v0.34.27/breaking-changes/360-update-to-go-119.md.patch b/patches/.changelog/v0.34.27/breaking-changes/360-update-to-go-119.md.patch new file mode 100644 index 00000000000..5b5843dab5e --- /dev/null +++ b/patches/.changelog/v0.34.27/breaking-changes/360-update-to-go-119.md.patch @@ -0,0 +1,8 @@ +diff --git a/.changelog/v0.34.27/breaking-changes/360-update-to-go-119.md b/.changelog/v0.34.27/breaking-changes/360-update-to-go-119.md +deleted file mode 100644 +index 97fafda93..000000000 +--- a/.changelog/v0.34.27/breaking-changes/360-update-to-go-119.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- Use Go 1.19 to build CometBFT, since Go 1.18 has reached end-of-life. +- ([\#360](https://github.com/cometbft/cometbft/issues/360)) diff --git a/patches/.changelog/v0.34.27/bug-fixes/383-txindexer-fix-slash-parsing.md.patch b/patches/.changelog/v0.34.27/bug-fixes/383-txindexer-fix-slash-parsing.md.patch new file mode 100644 index 00000000000..f730c08e06a --- /dev/null +++ b/patches/.changelog/v0.34.27/bug-fixes/383-txindexer-fix-slash-parsing.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.27/bug-fixes/383-txindexer-fix-slash-parsing.md b/.changelog/v0.34.27/bug-fixes/383-txindexer-fix-slash-parsing.md +deleted file mode 100644 +index c08824da9..000000000 +--- a/.changelog/v0.34.27/bug-fixes/383-txindexer-fix-slash-parsing.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- `[state/kvindexer]` Resolved crashes when event values contained slashes, +- introduced after adding event sequences. +- (\#[383](https://github.com/cometbft/cometbft/pull/383): @jmalicevic) diff --git a/patches/.changelog/v0.34.27/bug-fixes/386-quick-fix-needproofblock.md.patch b/patches/.changelog/v0.34.27/bug-fixes/386-quick-fix-needproofblock.md.patch new file mode 100644 index 00000000000..5cc841cb1ec --- /dev/null +++ b/patches/.changelog/v0.34.27/bug-fixes/386-quick-fix-needproofblock.md.patch @@ -0,0 +1,12 @@ +diff --git a/.changelog/v0.34.27/bug-fixes/386-quick-fix-needproofblock.md b/.changelog/v0.34.27/bug-fixes/386-quick-fix-needproofblock.md +deleted file mode 100644 +index d3d2f5b73..000000000 +--- a/.changelog/v0.34.27/bug-fixes/386-quick-fix-needproofblock.md ++++ /dev/null +@@ -1,6 +0,0 @@ +-- `[consensus]` Short-term fix for the case when `needProofBlock` cannot find +- previous block meta by defaulting to the creation of a new proof block. +- ([\#386](https://github.com/cometbft/cometbft/pull/386): @adizere) +- - Special thanks to the [Vega.xyz](https://vega.xyz/) team, and in particular +- to Zohar (@ze97286), for reporting the problem and working with us to get to +- a fix. diff --git a/patches/.changelog/v0.34.27/bug-fixes/4-busy-loop-send-block-part.md.patch b/patches/.changelog/v0.34.27/bug-fixes/4-busy-loop-send-block-part.md.patch new file mode 100644 index 00000000000..9077ecd337b --- /dev/null +++ b/patches/.changelog/v0.34.27/bug-fixes/4-busy-loop-send-block-part.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.27/bug-fixes/4-busy-loop-send-block-part.md b/.changelog/v0.34.27/bug-fixes/4-busy-loop-send-block-part.md +deleted file mode 100644 +index 414ec44cb..000000000 +--- a/.changelog/v0.34.27/bug-fixes/4-busy-loop-send-block-part.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- `[consensus]` Fixed a busy loop that happened when sending of a block part +- failed by sleeping in case of error. +- ([\#4](https://github.com/informalsystems/tendermint/pull/4)) diff --git a/patches/.changelog/v0.34.27/bug-fixes/9936-p2p-fix-envelope-sending.md.patch b/patches/.changelog/v0.34.27/bug-fixes/9936-p2p-fix-envelope-sending.md.patch new file mode 100644 index 00000000000..a07dd3c63b7 --- /dev/null +++ b/patches/.changelog/v0.34.27/bug-fixes/9936-p2p-fix-envelope-sending.md.patch @@ -0,0 +1,11 @@ +diff --git a/.changelog/v0.34.27/bug-fixes/9936-p2p-fix-envelope-sending.md b/.changelog/v0.34.27/bug-fixes/9936-p2p-fix-envelope-sending.md +deleted file mode 100644 +index fd38b79b9..000000000 +--- a/.changelog/v0.34.27/bug-fixes/9936-p2p-fix-envelope-sending.md ++++ /dev/null +@@ -1,5 +0,0 @@ +-- `[p2p]` Correctly use non-blocking `TrySendEnvelope` method when attempting to +- send messages, as opposed to the blocking `SendEnvelope` method. It is unclear +- whether this has a meaningful impact on P2P performance, but this patch does +- correct the underlying behaviour to what it should be +- ([tendermint/tendermint\#9936](https://github.com/tendermint/tendermint/pull/9936)) diff --git a/patches/.changelog/v0.34.27/dependencies/160-tmdb-to-cometbftdb.md.patch b/patches/.changelog/v0.34.27/dependencies/160-tmdb-to-cometbftdb.md.patch new file mode 100644 index 00000000000..7fca15df2d3 --- /dev/null +++ b/patches/.changelog/v0.34.27/dependencies/160-tmdb-to-cometbftdb.md.patch @@ -0,0 +1,10 @@ +diff --git a/.changelog/v0.34.27/dependencies/160-tmdb-to-cometbftdb.md b/.changelog/v0.34.27/dependencies/160-tmdb-to-cometbftdb.md +deleted file mode 100644 +index e4c135131..000000000 +--- a/.changelog/v0.34.27/dependencies/160-tmdb-to-cometbftdb.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- Replace [tm-db](https://github.com/tendermint/tm-db) with +- [cometbft-db](https://github.com/cometbft/cometbft-db) +- ([\#160](https://github.com/cometbft/cometbft/pull/160)) +\ No newline at end of file diff --git a/patches/.changelog/v0.34.27/dependencies/165-bump-tmloadtest.md.patch b/patches/.changelog/v0.34.27/dependencies/165-bump-tmloadtest.md.patch new file mode 100644 index 00000000000..eb4e63c6cfc --- /dev/null +++ b/patches/.changelog/v0.34.27/dependencies/165-bump-tmloadtest.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.27/dependencies/165-bump-tmloadtest.md b/.changelog/v0.34.27/dependencies/165-bump-tmloadtest.md +deleted file mode 100644 +index 175163ac0..000000000 +--- a/.changelog/v0.34.27/dependencies/165-bump-tmloadtest.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- Bump tm-load-test to v1.3.0 to remove implicit dependency on Tendermint Core +- ([\#165](https://github.com/cometbft/cometbft/pull/165)) +\ No newline at end of file diff --git a/patches/.changelog/v0.34.27/dependencies/9787-btcec-dep-update.md.patch b/patches/.changelog/v0.34.27/dependencies/9787-btcec-dep-update.md.patch new file mode 100644 index 00000000000..8c22ebab132 --- /dev/null +++ b/patches/.changelog/v0.34.27/dependencies/9787-btcec-dep-update.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.27/dependencies/9787-btcec-dep-update.md b/.changelog/v0.34.27/dependencies/9787-btcec-dep-update.md +deleted file mode 100644 +index d155748e0..000000000 +--- a/.changelog/v0.34.27/dependencies/9787-btcec-dep-update.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- `[crypto]` Update to use btcec v2 and the latest btcutil +- ([tendermint/tendermint\#9787](https://github.com/tendermint/tendermint/pull/9787): +- @wcsiu) diff --git a/patches/.changelog/v0.34.27/features/9759-kvindexer-match-event.md.patch b/patches/.changelog/v0.34.27/features/9759-kvindexer-match-event.md.patch new file mode 100644 index 00000000000..67ed7f57561 --- /dev/null +++ b/patches/.changelog/v0.34.27/features/9759-kvindexer-match-event.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.27/features/9759-kvindexer-match-event.md b/.changelog/v0.34.27/features/9759-kvindexer-match-event.md +deleted file mode 100644 +index 281f6cd1f..000000000 +--- a/.changelog/v0.34.27/features/9759-kvindexer-match-event.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- `[rpc]` Add `match_event` query parameter to indicate to the RPC that it +- should match events _within_ attributes, not only within a height +- ([tendermint/tendermint\#9759](https://github.com/tendermint/tendermint/pull/9759)) diff --git a/patches/.changelog/v0.34.27/improvements/136-remove-tm-signer-harness.md.patch b/patches/.changelog/v0.34.27/improvements/136-remove-tm-signer-harness.md.patch new file mode 100644 index 00000000000..9849d3bf7b4 --- /dev/null +++ b/patches/.changelog/v0.34.27/improvements/136-remove-tm-signer-harness.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.27/improvements/136-remove-tm-signer-harness.md b/.changelog/v0.34.27/improvements/136-remove-tm-signer-harness.md +deleted file mode 100644 +index 6eb6c2158..000000000 +--- a/.changelog/v0.34.27/improvements/136-remove-tm-signer-harness.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- `[tools/tm-signer-harness]` Remove the folder as it is unused +- ([\#136](https://github.com/cometbft/cometbft/issues/136)) +\ No newline at end of file diff --git a/patches/.changelog/v0.34.27/improvements/204-version-commit-hash.md.patch b/patches/.changelog/v0.34.27/improvements/204-version-commit-hash.md.patch new file mode 100644 index 00000000000..fa5fc97a539 --- /dev/null +++ b/patches/.changelog/v0.34.27/improvements/204-version-commit-hash.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.27/improvements/204-version-commit-hash.md b/.changelog/v0.34.27/improvements/204-version-commit-hash.md +deleted file mode 100644 +index 675a1a292..000000000 +--- a/.changelog/v0.34.27/improvements/204-version-commit-hash.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- Append the commit hash to the version of CometBFT being built +- ([\#204](https://github.com/cometbft/cometbft/pull/204)) +\ No newline at end of file diff --git a/patches/.changelog/v0.34.27/improvements/314-prio-mempool-badtxlog.md.patch b/patches/.changelog/v0.34.27/improvements/314-prio-mempool-badtxlog.md.patch new file mode 100644 index 00000000000..9063c773b6b --- /dev/null +++ b/patches/.changelog/v0.34.27/improvements/314-prio-mempool-badtxlog.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.27/improvements/314-prio-mempool-badtxlog.md b/.changelog/v0.34.27/improvements/314-prio-mempool-badtxlog.md +deleted file mode 100644 +index ba4ac031e..000000000 +--- a/.changelog/v0.34.27/improvements/314-prio-mempool-badtxlog.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- `[mempool/v1]` Suppress "rejected bad transaction" in priority mempool logs by +- reducing log level from info to debug +- ([\#314](https://github.com/cometbft/cometbft/pull/314): @JayT106) diff --git a/patches/.changelog/v0.34.27/improvements/56-rpc-cache-rpc-responses.md.patch b/patches/.changelog/v0.34.27/improvements/56-rpc-cache-rpc-responses.md.patch new file mode 100644 index 00000000000..ba90a31ce7a --- /dev/null +++ b/patches/.changelog/v0.34.27/improvements/56-rpc-cache-rpc-responses.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.27/improvements/56-rpc-cache-rpc-responses.md b/.changelog/v0.34.27/improvements/56-rpc-cache-rpc-responses.md +deleted file mode 100644 +index 344b3df93..000000000 +--- a/.changelog/v0.34.27/improvements/56-rpc-cache-rpc-responses.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- `[e2e]` Add functionality for uncoordinated (minor) upgrades +- ([\#56](https://github.com/tendermint/tendermint/pull/56)) +\ No newline at end of file diff --git a/patches/.changelog/v0.34.27/improvements/9733-consensus-metrics.md.patch b/patches/.changelog/v0.34.27/improvements/9733-consensus-metrics.md.patch new file mode 100644 index 00000000000..296af5d41e0 --- /dev/null +++ b/patches/.changelog/v0.34.27/improvements/9733-consensus-metrics.md.patch @@ -0,0 +1,10 @@ +diff --git a/.changelog/v0.34.27/improvements/9733-consensus-metrics.md b/.changelog/v0.34.27/improvements/9733-consensus-metrics.md +deleted file mode 100644 +index 77d8c743e..000000000 +--- a/.changelog/v0.34.27/improvements/9733-consensus-metrics.md ++++ /dev/null +@@ -1,4 +0,0 @@ +-- `[consensus]` Add `consensus_block_gossip_parts_received` and +- `consensus_step_duration_seconds` metrics in order to aid in investigating the +- impact of database compaction on consensus performance +- ([tendermint/tendermint\#9733](https://github.com/tendermint/tendermint/pull/9733)) diff --git a/patches/.changelog/v0.34.27/improvements/9759-kvindexer-match-event.md.patch b/patches/.changelog/v0.34.27/improvements/9759-kvindexer-match-event.md.patch new file mode 100644 index 00000000000..9b13beafc01 --- /dev/null +++ b/patches/.changelog/v0.34.27/improvements/9759-kvindexer-match-event.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.27/improvements/9759-kvindexer-match-event.md b/.changelog/v0.34.27/improvements/9759-kvindexer-match-event.md +deleted file mode 100644 +index 8b5757cb8..000000000 +--- a/.changelog/v0.34.27/improvements/9759-kvindexer-match-event.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- `[state/kvindexer]` Add `match.event` keyword to support condition evaluation +- based on the event the attributes belong to +- ([tendermint/tendermint\#9759](https://github.com/tendermint/tendermint/pull/9759)) diff --git a/patches/.changelog/v0.34.27/improvements/9764-p2p-fix-logspam.md.patch b/patches/.changelog/v0.34.27/improvements/9764-p2p-fix-logspam.md.patch new file mode 100644 index 00000000000..3dc8234736b --- /dev/null +++ b/patches/.changelog/v0.34.27/improvements/9764-p2p-fix-logspam.md.patch @@ -0,0 +1,10 @@ +diff --git a/.changelog/v0.34.27/improvements/9764-p2p-fix-logspam.md b/.changelog/v0.34.27/improvements/9764-p2p-fix-logspam.md +deleted file mode 100644 +index 78fa6844f..000000000 +--- a/.changelog/v0.34.27/improvements/9764-p2p-fix-logspam.md ++++ /dev/null +@@ -1,4 +0,0 @@ +-- `[p2p]` Reduce log spam through reducing log level of "Dialing peer" and +- "Added peer" messages from info to debug +- ([tendermint/tendermint\#9764](https://github.com/tendermint/tendermint/pull/9764): +- @faddat) diff --git a/patches/.changelog/v0.34.27/improvements/9776-consensus-vote-bandwidth.md.patch b/patches/.changelog/v0.34.27/improvements/9776-consensus-vote-bandwidth.md.patch new file mode 100644 index 00000000000..09de3f8aa93 --- /dev/null +++ b/patches/.changelog/v0.34.27/improvements/9776-consensus-vote-bandwidth.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.27/improvements/9776-consensus-vote-bandwidth.md b/.changelog/v0.34.27/improvements/9776-consensus-vote-bandwidth.md +deleted file mode 100644 +index 2bfdd05ac..000000000 +--- a/.changelog/v0.34.27/improvements/9776-consensus-vote-bandwidth.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- `[consensus]` Reduce bandwidth consumption of consensus votes by roughly 50% +- through fixing a small logic bug +- ([tendermint/tendermint\#9776](https://github.com/tendermint/tendermint/pull/9776)) diff --git a/patches/.changelog/v0.34.27/summary.md.patch b/patches/.changelog/v0.34.27/summary.md.patch new file mode 100644 index 00000000000..cd4692f87fa --- /dev/null +++ b/patches/.changelog/v0.34.27/summary.md.patch @@ -0,0 +1,23 @@ +diff --git a/.changelog/v0.34.27/summary.md b/.changelog/v0.34.27/summary.md +deleted file mode 100644 +index e4a13db50..000000000 +--- a/.changelog/v0.34.27/summary.md ++++ /dev/null +@@ -1,17 +0,0 @@ +-*Feb 27, 2023* +- +-This is the first official release of CometBFT - a fork of [Tendermint +-Core](https://github.com/tendermint/tendermint). This particular release is +-intended to be compatible with the Tendermint Core v0.34 release series. +- +-For details as to how to upgrade to CometBFT from Tendermint Core, please see +-our [upgrading guidelines](./UPGRADING.md). +- +-If you have any questions, comments, concerns or feedback on this release, we +-would love to hear from you! Please contact us via [GitHub +-Discussions](https://github.com/cometbft/cometbft/discussions), +-[Discord](https://discord.gg/cosmosnetwork) (in the `#cometbft` channel) or +-[Telegram](https://t.me/CometBFT). +- +-Special thanks to @wcsiu, @ze97286, @faddat and @JayT106 for their contributions +-to this release! diff --git a/patches/.changelog/v0.34.28/breaking-changes/558-tm10011.md.patch b/patches/.changelog/v0.34.28/breaking-changes/558-tm10011.md.patch new file mode 100644 index 00000000000..e875bc86549 --- /dev/null +++ b/patches/.changelog/v0.34.28/breaking-changes/558-tm10011.md.patch @@ -0,0 +1,8 @@ +diff --git a/.changelog/v0.34.28/breaking-changes/558-tm10011.md b/.changelog/v0.34.28/breaking-changes/558-tm10011.md +deleted file mode 100644 +index d1b9fca4a..000000000 +--- a/.changelog/v0.34.28/breaking-changes/558-tm10011.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- `[crypto/merkle]` Do not allow verification of Merkle Proofs against empty trees (`nil` root). `Proof.ComputeRootHash` now panics when it encounters an error, but `Proof.Verify` does not panic +- ([\#558](https://github.com/cometbft/cometbft/issues/558)) diff --git a/patches/.changelog/v0.34.28/bug-fixes/496-error-on-applyblock-should-panic.md.patch b/patches/.changelog/v0.34.28/bug-fixes/496-error-on-applyblock-should-panic.md.patch new file mode 100644 index 00000000000..10314d10730 --- /dev/null +++ b/patches/.changelog/v0.34.28/bug-fixes/496-error-on-applyblock-should-panic.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.28/bug-fixes/496-error-on-applyblock-should-panic.md b/.changelog/v0.34.28/bug-fixes/496-error-on-applyblock-should-panic.md +deleted file mode 100644 +index 55e9c874f..000000000 +--- a/.changelog/v0.34.28/bug-fixes/496-error-on-applyblock-should-panic.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- `[consensus]` Unexpected error conditions in `ApplyBlock` are non-recoverable, so ignoring the error and carrying on is a bug. We replaced a `return` that disregarded the error by a `panic`. +- ([\#496](https://github.com/cometbft/cometbft/pull/496)) +\ No newline at end of file diff --git a/patches/.changelog/v0.34.28/bug-fixes/524-rename-peerstate-tojson.md.patch b/patches/.changelog/v0.34.28/bug-fixes/524-rename-peerstate-tojson.md.patch new file mode 100644 index 00000000000..42ce64c3893 --- /dev/null +++ b/patches/.changelog/v0.34.28/bug-fixes/524-rename-peerstate-tojson.md.patch @@ -0,0 +1,8 @@ +diff --git a/.changelog/v0.34.28/bug-fixes/524-rename-peerstate-tojson.md b/.changelog/v0.34.28/bug-fixes/524-rename-peerstate-tojson.md +deleted file mode 100644 +index b9a43b3ce..000000000 +--- a/.changelog/v0.34.28/bug-fixes/524-rename-peerstate-tojson.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- `[consensus]` Rename `(*PeerState).ToJSON` to `MarshalJSON` to fix a logging data race +- ([\#524](https://github.com/cometbft/cometbft/pull/524)) diff --git a/patches/.changelog/v0.34.28/bug-fixes/575-fix-light-client-panic.md.patch b/patches/.changelog/v0.34.28/bug-fixes/575-fix-light-client-panic.md.patch new file mode 100644 index 00000000000..c0b96faa41c --- /dev/null +++ b/patches/.changelog/v0.34.28/bug-fixes/575-fix-light-client-panic.md.patch @@ -0,0 +1,13 @@ +diff --git a/.changelog/v0.34.28/bug-fixes/575-fix-light-client-panic.md b/.changelog/v0.34.28/bug-fixes/575-fix-light-client-panic.md +deleted file mode 100644 +index 0ec55b923..000000000 +--- a/.changelog/v0.34.28/bug-fixes/575-fix-light-client-panic.md ++++ /dev/null +@@ -1,6 +0,0 @@ +-- `[light]` Fixed an edge case where a light client would panic when attempting +- to query a node that (1) has started from a non-zero height and (2) does +- not yet have any data. The light client will now, correctly, not panic +- _and_ keep the node in its list of providers in the same way it would if +- it queried a node starting from height zero that does not yet have data +- ([\#575](https://github.com/cometbft/cometbft/issues/575)) +\ No newline at end of file diff --git a/patches/.changelog/v0.34.28/improvements/475-upgrade-go-schnorrkel.md.patch b/patches/.changelog/v0.34.28/improvements/475-upgrade-go-schnorrkel.md.patch new file mode 100644 index 00000000000..b4e1ab8c148 --- /dev/null +++ b/patches/.changelog/v0.34.28/improvements/475-upgrade-go-schnorrkel.md.patch @@ -0,0 +1,7 @@ +diff --git a/.changelog/v0.34.28/improvements/475-upgrade-go-schnorrkel.md b/.changelog/v0.34.28/improvements/475-upgrade-go-schnorrkel.md +deleted file mode 100644 +index bdaf96c14..000000000 +--- a/.changelog/v0.34.28/improvements/475-upgrade-go-schnorrkel.md ++++ /dev/null +@@ -1 +0,0 @@ +-- `[crypto/sr25519]` Upgrade to go-schnorrkel@v1.0.0 ([\#475](https://github.com/cometbft/cometbft/issues/475)) diff --git a/patches/.changelog/v0.34.28/improvements/638-json-rpc-error-message.md.patch b/patches/.changelog/v0.34.28/improvements/638-json-rpc-error-message.md.patch new file mode 100644 index 00000000000..c0a18783081 --- /dev/null +++ b/patches/.changelog/v0.34.28/improvements/638-json-rpc-error-message.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.28/improvements/638-json-rpc-error-message.md b/.changelog/v0.34.28/improvements/638-json-rpc-error-message.md +deleted file mode 100644 +index 6922091fd..000000000 +--- a/.changelog/v0.34.28/improvements/638-json-rpc-error-message.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- `[jsonrpc/client]` Improve the error message for client errors stemming from +- bad HTTP responses. +- ([cometbft/cometbft\#638](https://github.com/cometbft/cometbft/pull/638)) diff --git a/patches/.changelog/v0.34.28/summary.md.patch b/patches/.changelog/v0.34.28/summary.md.patch new file mode 100644 index 00000000000..78c632854f1 --- /dev/null +++ b/patches/.changelog/v0.34.28/summary.md.patch @@ -0,0 +1,12 @@ +diff --git a/.changelog/v0.34.28/summary.md b/.changelog/v0.34.28/summary.md +deleted file mode 100644 +index ba3efa9d7..000000000 +--- a/.changelog/v0.34.28/summary.md ++++ /dev/null +@@ -1,6 +0,0 @@ +-*April 26, 2023* +- +-This release fixes several bugs, and has had to introduce one small Go +-API-breaking change in the `crypto/merkle` package in order to address what +-could be a security issue for some users who directly and explicitly make use of +-that code. diff --git a/patches/.changelog/v0.34.29/bug-fixes/771-kvindexer-parsing-big-ints.md.patch b/patches/.changelog/v0.34.29/bug-fixes/771-kvindexer-parsing-big-ints.md.patch new file mode 100644 index 00000000000..801c3828c5a --- /dev/null +++ b/patches/.changelog/v0.34.29/bug-fixes/771-kvindexer-parsing-big-ints.md.patch @@ -0,0 +1,8 @@ +diff --git a/.changelog/v0.34.29/bug-fixes/771-kvindexer-parsing-big-ints.md b/.changelog/v0.34.29/bug-fixes/771-kvindexer-parsing-big-ints.md +deleted file mode 100644 +index 4a0000db6..000000000 +--- a/.changelog/v0.34.29/bug-fixes/771-kvindexer-parsing-big-ints.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- `[state/kvindex]` Querying event attributes that are bigger than int64 is now +- enabled. ([\#771](https://github.com/cometbft/cometbft/pull/771)) diff --git a/patches/.changelog/v0.34.29/bug-fixes/771-pubsub-parsing-big-ints.md.patch b/patches/.changelog/v0.34.29/bug-fixes/771-pubsub-parsing-big-ints.md.patch new file mode 100644 index 00000000000..6d3c1932193 --- /dev/null +++ b/patches/.changelog/v0.34.29/bug-fixes/771-pubsub-parsing-big-ints.md.patch @@ -0,0 +1,10 @@ +diff --git a/.changelog/v0.34.29/bug-fixes/771-pubsub-parsing-big-ints.md b/.changelog/v0.34.29/bug-fixes/771-pubsub-parsing-big-ints.md +deleted file mode 100644 +index fc5f25a90..000000000 +--- a/.changelog/v0.34.29/bug-fixes/771-pubsub-parsing-big-ints.md ++++ /dev/null +@@ -1,4 +0,0 @@ +-- `[pubsub]` Pubsub queries are now able to parse big integers (larger than +- int64). Very big floats are also properly parsed into very big integers +- instead of being truncated to int64. +- ([\#771](https://github.com/cometbft/cometbft/pull/771)) diff --git a/patches/.changelog/v0.34.29/improvements/654-rpc-rm-response-data-logs.md.patch b/patches/.changelog/v0.34.29/improvements/654-rpc-rm-response-data-logs.md.patch new file mode 100644 index 00000000000..93580fd84bd --- /dev/null +++ b/patches/.changelog/v0.34.29/improvements/654-rpc-rm-response-data-logs.md.patch @@ -0,0 +1,10 @@ +diff --git a/.changelog/v0.34.29/improvements/654-rpc-rm-response-data-logs.md b/.changelog/v0.34.29/improvements/654-rpc-rm-response-data-logs.md +deleted file mode 100644 +index 3fddfee8e..000000000 +--- a/.changelog/v0.34.29/improvements/654-rpc-rm-response-data-logs.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- `[rpc]` Remove response data from response failure logs in order +- to prevent large quantities of log data from being produced +- ([\#654](https://github.com/cometbft/cometbft/issues/654)) +\ No newline at end of file diff --git a/patches/.changelog/v0.34.29/security-fixes/788-rpc-client-pw.md.patch b/patches/.changelog/v0.34.29/security-fixes/788-rpc-client-pw.md.patch new file mode 100644 index 00000000000..21f171b4174 --- /dev/null +++ b/patches/.changelog/v0.34.29/security-fixes/788-rpc-client-pw.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.29/security-fixes/788-rpc-client-pw.md b/.changelog/v0.34.29/security-fixes/788-rpc-client-pw.md +deleted file mode 100644 +index 430b7b5ac..000000000 +--- a/.changelog/v0.34.29/security-fixes/788-rpc-client-pw.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- `[rpc/jsonrpc/client]` **Low severity** - Prevent RPC +- client credentials from being inadvertently dumped to logs +- ([\#788](https://github.com/cometbft/cometbft/pull/788)) diff --git a/patches/.changelog/v0.34.29/security-fixes/794-cli-debug-kill-unsafe-cast.md.patch b/patches/.changelog/v0.34.29/security-fixes/794-cli-debug-kill-unsafe-cast.md.patch new file mode 100644 index 00000000000..4e38a16c749 --- /dev/null +++ b/patches/.changelog/v0.34.29/security-fixes/794-cli-debug-kill-unsafe-cast.md.patch @@ -0,0 +1,8 @@ +diff --git a/.changelog/v0.34.29/security-fixes/794-cli-debug-kill-unsafe-cast.md b/.changelog/v0.34.29/security-fixes/794-cli-debug-kill-unsafe-cast.md +deleted file mode 100644 +index 782eccd9d..000000000 +--- a/.changelog/v0.34.29/security-fixes/794-cli-debug-kill-unsafe-cast.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- `[cmd/cometbft/commands/debug/kill]` **Low severity** - Fix unsafe int cast in +- `debug kill` command ([\#794](https://github.com/cometbft/cometbft/pull/794)) diff --git a/patches/.changelog/v0.34.29/security-fixes/865-fix-peerstate-marshaljson.md.patch b/patches/.changelog/v0.34.29/security-fixes/865-fix-peerstate-marshaljson.md.patch new file mode 100644 index 00000000000..73b4a9468ab --- /dev/null +++ b/patches/.changelog/v0.34.29/security-fixes/865-fix-peerstate-marshaljson.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.29/security-fixes/865-fix-peerstate-marshaljson.md b/.changelog/v0.34.29/security-fixes/865-fix-peerstate-marshaljson.md +deleted file mode 100644 +index fdd9172c2..000000000 +--- a/.changelog/v0.34.29/security-fixes/865-fix-peerstate-marshaljson.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- `[consensus]` **Low severity** - Avoid recursive call after rename to +- `(*PeerState).MarshalJSON` +- ([\#863](https://github.com/cometbft/cometbft/pull/863)) diff --git a/patches/.changelog/v0.34.29/security-fixes/890-mempool-fix-cache.md.patch b/patches/.changelog/v0.34.29/security-fixes/890-mempool-fix-cache.md.patch new file mode 100644 index 00000000000..bcf936df75b --- /dev/null +++ b/patches/.changelog/v0.34.29/security-fixes/890-mempool-fix-cache.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.29/security-fixes/890-mempool-fix-cache.md b/.changelog/v0.34.29/security-fixes/890-mempool-fix-cache.md +deleted file mode 100644 +index bad30efc7..000000000 +--- a/.changelog/v0.34.29/security-fixes/890-mempool-fix-cache.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- `[mempool/clist_mempool]` **Low severity** - Prevent a transaction from +- appearing twice in the mempool +- ([\#890](https://github.com/cometbft/cometbft/pull/890): @otrack) diff --git a/patches/.changelog/v0.34.29/summary.md.patch b/patches/.changelog/v0.34.29/summary.md.patch new file mode 100644 index 00000000000..8d48eeab516 --- /dev/null +++ b/patches/.changelog/v0.34.29/summary.md.patch @@ -0,0 +1,10 @@ +diff --git a/.changelog/v0.34.29/summary.md b/.changelog/v0.34.29/summary.md +deleted file mode 100644 +index 7ecb27394..000000000 +--- a/.changelog/v0.34.29/summary.md ++++ /dev/null +@@ -1,4 +0,0 @@ +-*June 14, 2023* +- +-Provides several minor bug fixes, as well as fixes for several low-severity +-security issues. diff --git a/patches/.changelog/v0.34.30/build/1351-bump-go-120.md.patch b/patches/.changelog/v0.34.30/build/1351-bump-go-120.md.patch new file mode 100644 index 00000000000..df5b2d5f0a5 --- /dev/null +++ b/patches/.changelog/v0.34.30/build/1351-bump-go-120.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.30/build/1351-bump-go-120.md b/.changelog/v0.34.30/build/1351-bump-go-120.md +deleted file mode 100644 +index 12091e3b6..000000000 +--- a/.changelog/v0.34.30/build/1351-bump-go-120.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- Bump Go version used to v1.20 since v1.19 has reached EOL +- ([\#1351](https://github.com/cometbft/cometbft/pull/1351)) +\ No newline at end of file diff --git a/patches/.changelog/v0.34.30/features/1512-metric-mempool-size-bytes.md.patch b/patches/.changelog/v0.34.30/features/1512-metric-mempool-size-bytes.md.patch new file mode 100644 index 00000000000..29ed59103a5 --- /dev/null +++ b/patches/.changelog/v0.34.30/features/1512-metric-mempool-size-bytes.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.30/features/1512-metric-mempool-size-bytes.md b/.changelog/v0.34.30/features/1512-metric-mempool-size-bytes.md +deleted file mode 100644 +index b935dc408..000000000 +--- a/.changelog/v0.34.30/features/1512-metric-mempool-size-bytes.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- `[metrics]` Add metric for mempool size in bytes `SizeBytes`. +- ([\#1512](https://github.com/cometbft/cometbft/pull/1512)) +\ No newline at end of file diff --git a/patches/.changelog/v0.34.30/improvements/1210-close-evidence-db.md.patch b/patches/.changelog/v0.34.30/improvements/1210-close-evidence-db.md.patch new file mode 100644 index 00000000000..0345a47ffbd --- /dev/null +++ b/patches/.changelog/v0.34.30/improvements/1210-close-evidence-db.md.patch @@ -0,0 +1,7 @@ +diff --git a/.changelog/v0.34.30/improvements/1210-close-evidence-db.md b/.changelog/v0.34.30/improvements/1210-close-evidence-db.md +deleted file mode 100644 +index e32bc87db..000000000 +--- a/.changelog/v0.34.30/improvements/1210-close-evidence-db.md ++++ /dev/null +@@ -1 +0,0 @@ +-- `[node]` Close evidence.db OnStop ([cometbft/cometbft\#1210](https://github.com/cometbft/cometbft/pull/1210): @chillyvee) diff --git a/patches/.changelog/v0.34.30/improvements/1558-experimental-gossip-limiting.md.patch b/patches/.changelog/v0.34.30/improvements/1558-experimental-gossip-limiting.md.patch new file mode 100644 index 00000000000..cb89421caf5 --- /dev/null +++ b/patches/.changelog/v0.34.30/improvements/1558-experimental-gossip-limiting.md.patch @@ -0,0 +1,15 @@ +diff --git a/.changelog/v0.34.30/improvements/1558-experimental-gossip-limiting.md b/.changelog/v0.34.30/improvements/1558-experimental-gossip-limiting.md +deleted file mode 100644 +index c6606aa94..000000000 +--- a/.changelog/v0.34.30/improvements/1558-experimental-gossip-limiting.md ++++ /dev/null +@@ -1,9 +0,0 @@ +-- `[mempool]` Add experimental feature to limit the number of persistent peers and non-persistent +- peers to which the node gossip transactions (only for "v0" mempool). +- ([\#1558](https://github.com/cometbft/cometbft/pull/1558), +- ([\#1584](https://github.com/cometbft/cometbft/pull/1584)) +-- `[config]` Add mempool parameters `experimental_max_gossip_connections_to_persistent_peers` and +- `experimental_max_gossip_connections_to_non_persistent_peers` for limiting the number of peers to +- which the node gossip transactions. +- ([\#1558](https://github.com/cometbft/cometbft/pull/1558)) +- ([\#1584](https://github.com/cometbft/cometbft/pull/1584)) diff --git a/patches/.changelog/v0.34.30/improvements/857-make-handshake-cancelable.md.patch b/patches/.changelog/v0.34.30/improvements/857-make-handshake-cancelable.md.patch new file mode 100644 index 00000000000..2c9c6cc376e --- /dev/null +++ b/patches/.changelog/v0.34.30/improvements/857-make-handshake-cancelable.md.patch @@ -0,0 +1,7 @@ +diff --git a/.changelog/v0.34.30/improvements/857-make-handshake-cancelable.md b/.changelog/v0.34.30/improvements/857-make-handshake-cancelable.md +deleted file mode 100644 +index 16b447f6d..000000000 +--- a/.changelog/v0.34.30/improvements/857-make-handshake-cancelable.md ++++ /dev/null +@@ -1 +0,0 @@ +-- `[node]` Make handshake cancelable ([cometbft/cometbft\#857](https://github.com/cometbft/cometbft/pull/857)) diff --git a/patches/.changelog/v0.34.30/summary.md.patch b/patches/.changelog/v0.34.30/summary.md.patch new file mode 100644 index 00000000000..5244fe9e36b --- /dev/null +++ b/patches/.changelog/v0.34.30/summary.md.patch @@ -0,0 +1,11 @@ +diff --git a/.changelog/v0.34.30/summary.md b/.changelog/v0.34.30/summary.md +deleted file mode 100644 +index f1e5c7f75..000000000 +--- a/.changelog/v0.34.30/summary.md ++++ /dev/null +@@ -1,5 +0,0 @@ +-*November 17, 2023* +- +-This release contains, among other things, an opt-in, experimental feature to +-help reduce the bandwidth consumption associated with the mempool's transaction +-gossip. diff --git a/patches/.changelog/v0.34.31/bug-fixes/1654-semaphore-wait.md.patch b/patches/.changelog/v0.34.31/bug-fixes/1654-semaphore-wait.md.patch new file mode 100644 index 00000000000..806d8cdb7e6 --- /dev/null +++ b/patches/.changelog/v0.34.31/bug-fixes/1654-semaphore-wait.md.patch @@ -0,0 +1,10 @@ +diff --git a/.changelog/v0.34.31/bug-fixes/1654-semaphore-wait.md b/.changelog/v0.34.31/bug-fixes/1654-semaphore-wait.md +deleted file mode 100644 +index 9d0fb80ad..000000000 +--- a/.changelog/v0.34.31/bug-fixes/1654-semaphore-wait.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-- `[mempool]` Avoid infinite wait in transaction sending routine when +- using experimental parameters to limiting transaction gossiping to peers +- ([\#1654](https://github.com/cometbft/cometbft/pull/1654)) +\ No newline at end of file diff --git a/patches/.changelog/v0.34.31/summary.md.patch b/patches/.changelog/v0.34.31/summary.md.patch new file mode 100644 index 00000000000..3a85cee691d --- /dev/null +++ b/patches/.changelog/v0.34.31/summary.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.31/summary.md b/.changelog/v0.34.31/summary.md +deleted file mode 100644 +index dbf368004..000000000 +--- a/.changelog/v0.34.31/summary.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-*November 27, 2023* +- +-Fixes a small bug in the mempool for an experimental feature. diff --git a/patches/.changelog/v0.34.32/bug-fixes/1749-light-client-attack-verify-all-sigs.md.patch b/patches/.changelog/v0.34.32/bug-fixes/1749-light-client-attack-verify-all-sigs.md.patch new file mode 100644 index 00000000000..14f79ce1671 --- /dev/null +++ b/patches/.changelog/v0.34.32/bug-fixes/1749-light-client-attack-verify-all-sigs.md.patch @@ -0,0 +1,10 @@ +diff --git a/.changelog/v0.34.32/bug-fixes/1749-light-client-attack-verify-all-sigs.md b/.changelog/v0.34.32/bug-fixes/1749-light-client-attack-verify-all-sigs.md +deleted file mode 100644 +index 1115c4d19..000000000 +--- a/.changelog/v0.34.32/bug-fixes/1749-light-client-attack-verify-all-sigs.md ++++ /dev/null +@@ -1,4 +0,0 @@ +-- `[evidence]` When `VerifyCommitLight` & `VerifyCommitLightTrusting` are called as part +- of evidence verification, all signatures present in the evidence must be verified +- ([\#1749](https://github.com/cometbft/cometbft/pull/1749)) +- diff --git a/patches/.changelog/v0.34.32/improvements/1715-validate-validator-address.md.patch b/patches/.changelog/v0.34.32/improvements/1715-validate-validator-address.md.patch new file mode 100644 index 00000000000..9ec39c41c94 --- /dev/null +++ b/patches/.changelog/v0.34.32/improvements/1715-validate-validator-address.md.patch @@ -0,0 +1,7 @@ +diff --git a/.changelog/v0.34.32/improvements/1715-validate-validator-address.md b/.changelog/v0.34.32/improvements/1715-validate-validator-address.md +deleted file mode 100644 +index ec7f2c7da..000000000 +--- a/.changelog/v0.34.32/improvements/1715-validate-validator-address.md ++++ /dev/null +@@ -1 +0,0 @@ +-- `[types]` Validate `Validator#Address` in `ValidateBasic` ([\#1715](https://github.com/cometbft/cometbft/pull/1715)) diff --git a/patches/.changelog/v0.34.32/improvements/1730-increase-abci-socket-message-size-limit.md.patch b/patches/.changelog/v0.34.32/improvements/1730-increase-abci-socket-message-size-limit.md.patch new file mode 100644 index 00000000000..69587891237 --- /dev/null +++ b/patches/.changelog/v0.34.32/improvements/1730-increase-abci-socket-message-size-limit.md.patch @@ -0,0 +1,7 @@ +diff --git a/.changelog/v0.34.32/improvements/1730-increase-abci-socket-message-size-limit.md b/.changelog/v0.34.32/improvements/1730-increase-abci-socket-message-size-limit.md +deleted file mode 100644 +index 5246eb57f..000000000 +--- a/.changelog/v0.34.32/improvements/1730-increase-abci-socket-message-size-limit.md ++++ /dev/null +@@ -1 +0,0 @@ +-- `[abci]` Increase ABCI socket message size limit to 2GB ([\#1730](https://github.com/cometbft/cometbft/pull/1730): @troykessler) diff --git a/patches/.changelog/v0.34.32/improvements/2094-e2e-load-max-txs.md.patch b/patches/.changelog/v0.34.32/improvements/2094-e2e-load-max-txs.md.patch new file mode 100644 index 00000000000..333e87d0ffa --- /dev/null +++ b/patches/.changelog/v0.34.32/improvements/2094-e2e-load-max-txs.md.patch @@ -0,0 +1,8 @@ +diff --git a/.changelog/v0.34.32/improvements/2094-e2e-load-max-txs.md b/.changelog/v0.34.32/improvements/2094-e2e-load-max-txs.md +deleted file mode 100644 +index 31ca79cfe..000000000 +--- a/.changelog/v0.34.32/improvements/2094-e2e-load-max-txs.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- `[e2e]` Add manifest option `load_max_txs` to limit the number of transactions generated by the +- `load` command. ([\#2094](https://github.com/cometbft/cometbft/pull/2094)) diff --git a/patches/.changelog/v0.34.32/improvements/2328-e2e-log-sent-txs.md.patch b/patches/.changelog/v0.34.32/improvements/2328-e2e-log-sent-txs.md.patch new file mode 100644 index 00000000000..7bb4a3a2a48 --- /dev/null +++ b/patches/.changelog/v0.34.32/improvements/2328-e2e-log-sent-txs.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.32/improvements/2328-e2e-log-sent-txs.md b/.changelog/v0.34.32/improvements/2328-e2e-log-sent-txs.md +deleted file mode 100644 +index e1b69899f..000000000 +--- a/.changelog/v0.34.32/improvements/2328-e2e-log-sent-txs.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- `[e2e]` Log the number of transactions that were sent successfully or failed. +- ([\#2328](https://github.com/cometbft/cometbft/pull/2328)) +\ No newline at end of file diff --git a/patches/.changelog/v0.34.32/summary.md.patch b/patches/.changelog/v0.34.32/summary.md.patch new file mode 100644 index 00000000000..e4608bc977f --- /dev/null +++ b/patches/.changelog/v0.34.32/summary.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.32/summary.md b/.changelog/v0.34.32/summary.md +deleted file mode 100644 +index 101767876..000000000 +--- a/.changelog/v0.34.32/summary.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-*March 12, 2024* +- +-This release fixes a security bug in the light client. diff --git a/patches/.changelog/v0.34.33/bug-fixes/2774-bitarray-unmarshal-json.md.patch b/patches/.changelog/v0.34.33/bug-fixes/2774-bitarray-unmarshal-json.md.patch new file mode 100644 index 00000000000..7e53d7b059f --- /dev/null +++ b/patches/.changelog/v0.34.33/bug-fixes/2774-bitarray-unmarshal-json.md.patch @@ -0,0 +1,8 @@ +diff --git a/.changelog/v0.34.33/bug-fixes/2774-bitarray-unmarshal-json.md b/.changelog/v0.34.33/bug-fixes/2774-bitarray-unmarshal-json.md +deleted file mode 100644 +index 1c51af49d..000000000 +--- a/.changelog/v0.34.33/bug-fixes/2774-bitarray-unmarshal-json.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- [`bits`] prevent `BitArray.UnmarshalJSON` from crashing on 0 bits +- ([\#2774](https://github.com/cometbft/cometbft/pull/2774)) diff --git a/patches/.changelog/v0.34.33/dependencies/2783-update-cometbft-db.md.patch b/patches/.changelog/v0.34.33/dependencies/2783-update-cometbft-db.md.patch new file mode 100644 index 00000000000..8cc762a1819 --- /dev/null +++ b/patches/.changelog/v0.34.33/dependencies/2783-update-cometbft-db.md.patch @@ -0,0 +1,8 @@ +diff --git a/.changelog/v0.34.33/dependencies/2783-update-cometbft-db.md b/.changelog/v0.34.33/dependencies/2783-update-cometbft-db.md +deleted file mode 100644 +index 7d1c67e07..000000000 +--- a/.changelog/v0.34.33/dependencies/2783-update-cometbft-db.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- Bump cometbft-db version to v0.9.1, which brings support for RocksDB v8. +- ([\#2783](https://github.com/cometbft/cometbft/pull/2783)) diff --git a/patches/.changelog/v0.34.33/dependencies/2784-update-go.md.patch b/patches/.changelog/v0.34.33/dependencies/2784-update-go.md.patch new file mode 100644 index 00000000000..7020962e496 --- /dev/null +++ b/patches/.changelog/v0.34.33/dependencies/2784-update-go.md.patch @@ -0,0 +1,8 @@ +diff --git a/.changelog/v0.34.33/dependencies/2784-update-go.md b/.changelog/v0.34.33/dependencies/2784-update-go.md +deleted file mode 100644 +index 6185be4b6..000000000 +--- a/.changelog/v0.34.33/dependencies/2784-update-go.md ++++ /dev/null +@@ -1,2 +0,0 @@ +-- Bump Go version used to v1.21 since v1.20 has reached EOL +- ([\#2784](https://github.com/cometbft/cometbft/pull/2784)) diff --git a/patches/.changelog/v0.34.33/summary.md.patch b/patches/.changelog/v0.34.33/summary.md.patch new file mode 100644 index 00000000000..3c13cbabd58 --- /dev/null +++ b/patches/.changelog/v0.34.33/summary.md.patch @@ -0,0 +1,9 @@ +diff --git a/.changelog/v0.34.33/summary.md b/.changelog/v0.34.33/summary.md +deleted file mode 100644 +index 7d173c605..000000000 +--- a/.changelog/v0.34.33/summary.md ++++ /dev/null +@@ -1,3 +0,0 @@ +-*April 26, 2024* +- +-This release bumps Go version to 1.21. diff --git a/patches/.github/CODEOWNERS.patch b/patches/.github/CODEOWNERS.patch new file mode 100644 index 00000000000..4db39e705e0 --- /dev/null +++ b/patches/.github/CODEOWNERS.patch @@ -0,0 +1,12 @@ +diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS +index 87f93c4cd..70e3c0df6 100644 +--- a/.github/CODEOWNERS ++++ b/.github/CODEOWNERS +@@ -7,6 +7,4 @@ + # global owners are only requested if there isn't a more specific + # codeowner specified below. For this reason, the global codeowners + # are often repeated in package-level definitions. +-* @CometBFT/engineering +- +-/spec @CometBFT/research @CometBFT/engineering ++* @celestiaorg/celestia-core diff --git a/patches/.github/auto_request_review.yml.patch b/patches/.github/auto_request_review.yml.patch new file mode 100644 index 00000000000..d4eff3c4b31 --- /dev/null +++ b/patches/.github/auto_request_review.yml.patch @@ -0,0 +1,20 @@ +diff --git a/.github/auto_request_review.yml b/.github/auto_request_review.yml +new file mode 100644 +index 000000000..32ab61b10 +--- /dev/null ++++ b/.github/auto_request_review.yml +@@ -0,0 +1,14 @@ ++# More info at https://github.com/necojackarc/auto-request-review ++reviewers: ++ defaults: ++ - cmwaters ++ - evan-forbes ++ - ninabarbakadze ++ - rach-id ++ - rootulp ++ ++options: ++ ignore_draft: true ++ ignored_keywords: ++ - DO NOT REVIEW ++ enable_group_assignment: false diff --git a/patches/.github/dependabot.yml.patch b/patches/.github/dependabot.yml.patch new file mode 100644 index 00000000000..30977476878 --- /dev/null +++ b/patches/.github/dependabot.yml.patch @@ -0,0 +1,17 @@ +diff --git a/.github/dependabot.yml b/.github/dependabot.yml +new file mode 100644 +index 000000000..7092c7ab8 +--- /dev/null ++++ b/.github/dependabot.yml +@@ -0,0 +1,11 @@ ++version: 2 ++updates: ++ - package-ecosystem: gomod ++ directory: "/" ++ schedule: ++ interval: daily ++ open-pull-requests-limit: 10 ++ labels: ++ - T:dependencies ++ allow: ++ - dependency-name: "*/celestiaorg/*" diff --git a/patches/.github/mergify.yml.patch b/patches/.github/mergify.yml.patch new file mode 100644 index 00000000000..8da58cbdc0f --- /dev/null +++ b/patches/.github/mergify.yml.patch @@ -0,0 +1,25 @@ +diff --git a/.github/mergify.yml b/.github/mergify.yml +deleted file mode 100644 +index 257c3f5a7..000000000 +--- a/.github/mergify.yml ++++ /dev/null +@@ -1,19 +0,0 @@ +-queue_rules: +- - name: default +- conditions: +- - base=v0.34.x +- - label=S:automerge +- +-pull_request_rules: +- - name: Automerge to v0.34.x +- conditions: +- - base=v0.34.x +- - label=S:automerge +- actions: +- queue: +- method: squash +- name: default +- commit_message_template: | +- {{ title }} (#{{ number }}) +- +- {{ body }} diff --git a/patches/.github/workflows/check-generated.yml.patch b/patches/.github/workflows/check-generated.yml.patch new file mode 100644 index 00000000000..4b1cff032e0 --- /dev/null +++ b/patches/.github/workflows/check-generated.yml.patch @@ -0,0 +1,88 @@ +diff --git a/.github/workflows/check-generated.yml b/.github/workflows/check-generated.yml +index a3cc8e8d2..628604fdd 100644 +--- a/.github/workflows/check-generated.yml ++++ b/.github/workflows/check-generated.yml +@@ -7,57 +7,54 @@ name: Check generated code + on: + pull_request: + branches: +- - main +- - v0.34.x ++ - v0.34.x-celestia + + permissions: + contents: read + + jobs: +- check-mocks: +- runs-on: ubuntu-latest +- steps: +- - uses: actions/setup-go@v5 +- with: +- go-version: "1.21" ++ # Mocks have been disabled. See https://github.com/celestiaorg/celestia-core/pull/917 ++ # check-mocks: ++ # runs-on: ubuntu-latest ++ # steps: ++ # - uses: actions/setup-go@v3 ++ # with: ++ # go-version: "1.22.2" + +- - uses: actions/checkout@v4 ++ # - uses: actions/checkout@v3 + +- - name: "Check generated mocks" +- run: | +- set -euo pipefail ++ # - name: "Check generated mocks" ++ # run: | ++ # set -euo pipefail + +- make mockery ++ # make mockery + +- git add . +- if ! git diff HEAD --stat --exit-code ; then +- echo ">> ERROR:" +- echo ">>" +- echo ">> Generated mocks require update (either Mockery or source files may have changed)." +- echo ">> Ensure your tools are up-to-date, re-run 'make mockery' and update this PR." +- echo ">>" +- exit 1 +- fi ++ # if ! git diff --stat --exit-code ; then ++ # echo ">> ERROR:" ++ # echo ">>" ++ # echo ">> Generated mocks require update (either Mockery or source files may have changed)." ++ # echo ">> Ensure your tools are up-to-date, re-run 'make mockery' and update this PR." ++ # echo ">>" ++ # exit 1 ++ # fi + + check-proto: + runs-on: ubuntu-latest + steps: +- - uses: actions/setup-go@v5 +- with: +- go-version: '1.21' +- + - uses: actions/checkout@v4 + with: + fetch-depth: 1 # we need a .git directory to run git diff ++ - uses: actions/setup-go@v5 ++ with: ++ go-version-file: "go.mod" ++ + + - name: "Check protobuf generated code" + run: | + set -euo pipefail + + make proto-gen +- +- git add . +- if ! git diff HEAD --stat --exit-code ; then ++ if ! git diff --stat --exit-code ; then + echo ">> ERROR:" + echo ">>" + echo ">> Protobuf generated code requires update (either tools or .proto files may have changed)." diff --git a/patches/.github/workflows/cometbft-docker.yml.patch b/patches/.github/workflows/cometbft-docker.yml.patch new file mode 100644 index 00000000000..7b5e604a041 --- /dev/null +++ b/patches/.github/workflows/cometbft-docker.yml.patch @@ -0,0 +1,43 @@ +diff --git a/.github/workflows/cometbft-docker.yml b/.github/workflows/cometbft-docker.yml +index bd3ff2208..e70c65469 100644 +--- a/.github/workflows/cometbft-docker.yml ++++ b/.github/workflows/cometbft-docker.yml +@@ -1,11 +1,9 @@ +-name: Docker +-# Rebuilds the CometBFT docker image on every push to main and creation of tags +-# and pushes the image to https://hub.docker.com/r/cometbft/cometbft ++name: Build Docker ++# Rebuilds the tendermint docker image on every push to default branch and creation of tags. + on: + push: + branches: +- - main +- - v0.34.x ++ - v[0-9]+.[0-9]+.x-celestia + tags: + - "v[0-9]+.[0-9]+.[0-9]+" # Push events to matching v*, i.e. v1.0, v20.15.10 + - "v[0-9]+.[0-9]+.[0-9]+-alpha.[0-9]+" # e.g. v0.37.0-alpha.1, v0.38.0-alpha.10 +@@ -42,20 +40,12 @@ jobs: + platforms: all + + - name: Set up Docker Build +- uses: docker/setup-buildx-action@v3.3.0 ++ uses: docker/setup-buildx-action@v3.0.0 + +- - name: Login to DockerHub +- if: ${{ github.event_name != 'pull_request' }} +- uses: docker/login-action@v3.1.0 +- with: +- username: ${{ secrets.DOCKERHUB_USERNAME }} +- password: ${{ secrets.DOCKERHUB_TOKEN }} +- +- - name: Publish to Docker Hub +- uses: docker/build-push-action@v5.3.0 ++ - name: Build but do not Publish to Docker Hub ++ uses: docker/build-push-action@v5 + with: + context: . + file: ./DOCKER/Dockerfile + platforms: linux/amd64,linux/arm64 +- push: ${{ github.event_name != 'pull_request' }} + tags: ${{ steps.prep.outputs.tags }} diff --git a/patches/.github/workflows/coverage.yml.patch b/patches/.github/workflows/coverage.yml.patch new file mode 100644 index 00000000000..31cdc53c2cc --- /dev/null +++ b/patches/.github/workflows/coverage.yml.patch @@ -0,0 +1,128 @@ +diff --git a/.github/workflows/coverage.yml b/.github/workflows/coverage.yml +index 86ed7e634..e7b9cd20b 100644 +--- a/.github/workflows/coverage.yml ++++ b/.github/workflows/coverage.yml +@@ -3,35 +3,9 @@ on: + pull_request: + push: + branches: +- - v0.34.x ++ - v0.34.x-celestia + + jobs: +- split-test-files: +- runs-on: ubuntu-latest +- steps: +- - uses: actions/checkout@v4 +- - name: Create a file with all the pkgs +- run: go list ./... > pkgs.txt +- - name: Split pkgs into 4 files +- run: split -d -n l/4 pkgs.txt pkgs.txt.part. +- # cache multiple +- - uses: actions/upload-artifact@v4 +- with: +- name: "${{ github.sha }}-00" +- path: ./pkgs.txt.part.00 +- - uses: actions/upload-artifact@v4 +- with: +- name: "${{ github.sha }}-01" +- path: ./pkgs.txt.part.01 +- - uses: actions/upload-artifact@v4 +- with: +- name: "${{ github.sha }}-02" +- path: ./pkgs.txt.part.02 +- - uses: actions/upload-artifact@v4 +- with: +- name: "${{ github.sha }}-03" +- path: ./pkgs.txt.part.03 +- + build-linux: + name: Build + runs-on: ubuntu-latest +@@ -43,10 +17,10 @@ jobs: + env: + GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}" + steps: ++ - uses: actions/checkout@v4 + - uses: actions/setup-go@v5 + with: +- go-version: "1.21" +- - uses: actions/checkout@v4 ++ go-version-file: "go.mod" + - uses: technote-space/get-diff-action@v6 + with: + PATTERNS: | +@@ -55,38 +29,30 @@ jobs: + go.sum + - name: install + run: GOOS=linux GOARCH=${{ matrix.goarch }} make build +- if: "env.GIT_DIFF != ''" ++ if: env.GIT_DIFF + + tests: + runs-on: ubuntu-latest +- needs: split-test-files + strategy: +- fail-fast: false +- matrix: +- part: ["00", "01", "02", "03"] ++ fail-fast: true + steps: ++ - uses: actions/checkout@v4 + - uses: actions/setup-go@v5 + with: +- go-version: "1.21" +- - uses: actions/checkout@v4 ++ go-version-file: "go.mod" + - uses: technote-space/get-diff-action@v6 + with: + PATTERNS: | + **/**.go + go.mod + go.sum +- - uses: actions/download-artifact@v4 +- with: +- name: "${{ github.sha }}-${{ matrix.part }}" +- if: env.GIT_DIFF + - name: test & coverage report creation +- run: | +- cat pkgs.txt.part.${{ matrix.part }} | xargs go test -mod=readonly -timeout 8m -race -coverprofile=${{ matrix.part }}profile.out -covermode=atomic ++ run: go test ./... -mod=readonly -timeout 15m -race -coverprofile=profile.out -covermode=atomic + if: env.GIT_DIFF + - uses: actions/upload-artifact@v4 + with: +- name: "${{ github.sha }}-${{ matrix.part }}-coverage" +- path: ./${{ matrix.part }}profile.out ++ name: "${{ github.sha }}-coverage" ++ path: ./profile.out + + upload-coverage-report: + runs-on: ubuntu-latest +@@ -99,24 +65,12 @@ jobs: + **/**.go + go.mod + go.sum +- - uses: actions/download-artifact@v4 +- with: +- name: "${{ github.sha }}-00-coverage" +- if: env.GIT_DIFF +- - uses: actions/download-artifact@v4 +- with: +- name: "${{ github.sha }}-01-coverage" +- if: env.GIT_DIFF +- - uses: actions/download-artifact@v4 +- with: +- name: "${{ github.sha }}-02-coverage" +- if: env.GIT_DIFF +- - uses: actions/download-artifact@v4 ++ - uses: actions/download-artifact@v4.1.8 + with: +- name: "${{ github.sha }}-03-coverage" ++ name: "${{ github.sha }}-coverage" + if: env.GIT_DIFF + - run: | +- cat ./*profile.out | grep -v "mode: atomic" >> coverage.txt ++ cat ./profile.out | grep -v "mode: atomic" >> coverage.txt + if: env.GIT_DIFF + - uses: codecov/codecov-action@v4 + with: diff --git a/patches/.github/workflows/e2e-manual.yml.patch b/patches/.github/workflows/e2e-manual.yml.patch new file mode 100644 index 00000000000..e36be458029 --- /dev/null +++ b/patches/.github/workflows/e2e-manual.yml.patch @@ -0,0 +1,18 @@ +diff --git a/.github/workflows/e2e-manual.yml b/.github/workflows/e2e-manual.yml +index 864ed2fa9..577720d72 100644 +--- a/.github/workflows/e2e-manual.yml ++++ b/.github/workflows/e2e-manual.yml +@@ -14,11 +14,11 @@ jobs: + runs-on: ubuntu-latest + timeout-minutes: 60 + steps: ++ - uses: actions/checkout@v4 + - uses: actions/setup-go@v5 + with: +- go-version: '1.21' ++ go-version-file: "go.mod" + +- - uses: actions/checkout@v4 + + - name: Build + working-directory: test/e2e diff --git a/patches/.github/workflows/e2e-nightly-34x.yml.patch b/patches/.github/workflows/e2e-nightly-34x.yml.patch new file mode 100644 index 00000000000..7da2b71f7f7 --- /dev/null +++ b/patches/.github/workflows/e2e-nightly-34x.yml.patch @@ -0,0 +1,54 @@ +diff --git a/.github/workflows/e2e-nightly-34x.yml b/.github/workflows/e2e-nightly-34x.yml +index 7c8e5c842..ca17fa672 100644 +--- a/.github/workflows/e2e-nightly-34x.yml ++++ b/.github/workflows/e2e-nightly-34x.yml +@@ -21,13 +21,13 @@ jobs: + runs-on: ubuntu-latest + timeout-minutes: 60 + steps: +- - uses: actions/setup-go@v5 ++ - uses: actions/checkout@v4 + with: +- go-version: '1.21' ++ ref: 'v0.34.x-celestia' + +- - uses: actions/checkout@v4 ++ - uses: actions/setup-go@v5 + with: +- ref: 'v0.34.x' ++ go-version-file: "go.mod" + + - name: Build + working-directory: test/e2e +@@ -49,14 +49,14 @@ jobs: + runs-on: ubuntu-latest + steps: + - name: Notify Slack on failure +- uses: rtCamp/action-slack-notify@4e5fb42d249be6a45a298f3c9543b111b02f7907 ++ uses: rtCamp/action-slack-notify@b24d75fe0e728a4bf9fc42ee217caa686d141ee8 + env: + SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }} + SLACK_CHANNEL: cometbft-engineering + SLACK_USERNAME: Nightly E2E Tests + SLACK_ICON_EMOJI: ':skull:' + SLACK_COLOR: danger +- SLACK_MESSAGE: Nightly E2E tests failed on v0.34.x ++ SLACK_MESSAGE: Nightly E2E tests failed on v0.34.x-celestia + SLACK_FOOTER: '' + + e2e-nightly-success: # may turn this off once they seem to pass consistently +@@ -65,12 +65,12 @@ jobs: + runs-on: ubuntu-latest + steps: + - name: Notify Slack on success +- uses: rtCamp/action-slack-notify@4e5fb42d249be6a45a298f3c9543b111b02f7907 ++ uses: rtCamp/action-slack-notify@b24d75fe0e728a4bf9fc42ee217caa686d141ee8 + env: + SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }} + SLACK_CHANNEL: cometbft-engineering + SLACK_USERNAME: Nightly E2E Tests + SLACK_ICON_EMOJI: ':white_check_mark:' + SLACK_COLOR: good +- SLACK_MESSAGE: Nightly E2E tests passed on v0.34.x ++ SLACK_MESSAGE: Nightly E2E tests passed on v0.34.x-celestia + SLACK_FOOTER: '' diff --git a/patches/.github/workflows/e2e.yml.patch b/patches/.github/workflows/e2e.yml.patch new file mode 100644 index 00000000000..f7340098406 --- /dev/null +++ b/patches/.github/workflows/e2e.yml.patch @@ -0,0 +1,32 @@ +diff --git a/.github/workflows/e2e.yml b/.github/workflows/e2e.yml +index cc9e654e3..d4dbb1445 100644 +--- a/.github/workflows/e2e.yml ++++ b/.github/workflows/e2e.yml +@@ -12,10 +12,10 @@ jobs: + runs-on: ubuntu-latest + timeout-minutes: 15 + steps: ++ - uses: actions/checkout@v4 + - uses: actions/setup-go@v5 + with: +- go-version: '1.21' +- - uses: actions/checkout@v4 ++ go-version-file: "go.mod" + - uses: technote-space/get-diff-action@v6 + with: + PATTERNS: | +@@ -27,12 +27,12 @@ jobs: + working-directory: test/e2e + # Run two make jobs in parallel, since we can't run steps in parallel. + run: make -j2 docker runner +- if: "env.GIT_DIFF != ''" ++ if: env.GIT_DIFF + + - name: Run CI testnet + working-directory: test/e2e + run: ./build/runner -f networks/ci.toml +- if: "env.GIT_DIFF != ''" ++ if: env.GIT_DIFF + + - name: Emit logs on failure + if: ${{ failure() }} diff --git a/patches/.github/workflows/fuzz-nightly.yml.patch b/patches/.github/workflows/fuzz-nightly.yml.patch new file mode 100644 index 00000000000..2a231330085 --- /dev/null +++ b/patches/.github/workflows/fuzz-nightly.yml.patch @@ -0,0 +1,27 @@ +diff --git a/.github/workflows/fuzz-nightly.yml b/.github/workflows/fuzz-nightly.yml +index 7457a805d..7f847dc1c 100644 +--- a/.github/workflows/fuzz-nightly.yml ++++ b/.github/workflows/fuzz-nightly.yml +@@ -9,11 +9,10 @@ jobs: + fuzz-nightly-test: + runs-on: ubuntu-latest + steps: ++ - uses: actions/checkout@v4 + - uses: actions/setup-go@v5 + with: +- go-version: '1.21' +- +- - uses: actions/checkout@v4 ++ go-version-file: "go.mod" + + - name: Install go-fuzz + working-directory: test/fuzz +@@ -72,7 +71,7 @@ jobs: + runs-on: ubuntu-latest + steps: + - name: Notify Slack if any crashers +- uses: rtCamp/action-slack-notify@4e5fb42d249be6a45a298f3c9543b111b02f7907 ++ uses: rtCamp/action-slack-notify@b24d75fe0e728a4bf9fc42ee217caa686d141ee8 + env: + SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK }} + SLACK_CHANNEL: cometbft-engineering diff --git a/patches/.github/workflows/govulncheck.yml.patch b/patches/.github/workflows/govulncheck.yml.patch new file mode 100644 index 00000000000..b9040e649fc --- /dev/null +++ b/patches/.github/workflows/govulncheck.yml.patch @@ -0,0 +1,32 @@ +diff --git a/.github/workflows/govulncheck.yml b/.github/workflows/govulncheck.yml +index 9ea5879f2..a798d1920 100644 +--- a/.github/workflows/govulncheck.yml ++++ b/.github/workflows/govulncheck.yml +@@ -8,17 +8,16 @@ on: + pull_request: + push: + branches: +- - v0.34.x ++ - v[0-9]+.[0-9]+.x-celestia + + jobs: + govulncheck: + runs-on: ubuntu-latest + steps: +- - uses: actions/setup-go@v5 +- with: +- go-version: "1.21" +- check-latest: true + - uses: actions/checkout@v4 ++ - uses: actions/setup-go@v3 ++ with: ++ go-version-file: "go.mod" + - uses: technote-space/get-diff-action@v6 + with: + PATTERNS: | +@@ -28,4 +27,4 @@ jobs: + Makefile + - name: govulncheck + run: make vulncheck +- if: "env.GIT_DIFF != ''" ++ if: env.GIT_DIFF diff --git a/patches/.github/workflows/lint.yml.patch b/patches/.github/workflows/lint.yml.patch new file mode 100644 index 00000000000..754396e4067 --- /dev/null +++ b/patches/.github/workflows/lint.yml.patch @@ -0,0 +1,50 @@ +diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml +index a914b9559..8312477d5 100644 +--- a/.github/workflows/lint.yml ++++ b/.github/workflows/lint.yml +@@ -10,9 +10,17 @@ name: Golang Linter + + on: + pull_request: ++ paths: ++ - '**/*.go' ++ - 'go.mod' ++ - 'go.sum' + push: + branches: +- - v0.34.x ++ - v[0-9]+.[0-9]+.x-celestia ++ paths: ++ - '**/*.go' ++ - 'go.mod' ++ - 'go.sum' + + jobs: + golangci: +@@ -21,21 +29,13 @@ jobs: + timeout-minutes: 8 + steps: + - uses: actions/checkout@v4 ++ + - uses: actions/setup-go@v5 + with: +- go-version: '1.21' +- - uses: technote-space/get-diff-action@v6 +- with: +- PATTERNS: | +- **/**.go +- go.mod +- go.sum +- - uses: golangci/golangci-lint-action@v4 ++ go-version-file: 'go.mod' ++ ++ - uses: golangci/golangci-lint-action@v6.1.0 + with: +- # Required: the version of golangci-lint is required and +- # must be specified without patch version: we always use the +- # latest patch version. +- version: latest ++ version: v1.61.0 + args: --timeout 10m + github-token: ${{ secrets.github_token }} +- if: env.GIT_DIFF diff --git a/patches/.github/workflows/pr-review-requester.yml.patch b/patches/.github/workflows/pr-review-requester.yml.patch new file mode 100644 index 00000000000..1c284871e78 --- /dev/null +++ b/patches/.github/workflows/pr-review-requester.yml.patch @@ -0,0 +1,29 @@ +diff --git a/.github/workflows/pr-review-requester.yml b/.github/workflows/pr-review-requester.yml +new file mode 100644 +index 000000000..487f52bc9 +--- /dev/null ++++ b/.github/workflows/pr-review-requester.yml +@@ -0,0 +1,23 @@ ++name: pr-review-requester ++ ++on: ++ # pull_request_target is used to allow forks write permissions when running ++ # this workflow. With the pull_request trigger, forks do not have any write ++ # access for security reasons, however write access is needed in order to ++ # request reviews. Since this workflow is simply requesting reviewers, it is ++ # safe to allow forks write access. ++ pull_request_target: ++ ++jobs: ++ auto-request-review: ++ name: Auto request reviews ++ uses: celestiaorg/.github/.github/workflows/reusable_housekeeping.yml@v0.5.0 ++ secrets: inherit ++ # write access for issues and pull requests is needed because the called ++ # workflow requires write access to issues and pull requests and the ++ # permissions must match ++ permissions: ++ issues: write ++ pull-requests: write ++ with: ++ run-auto-request-review: true diff --git a/patches/.github/workflows/pre-release.yml.patch b/patches/.github/workflows/pre-release.yml.patch new file mode 100644 index 00000000000..3f253cc96fe --- /dev/null +++ b/patches/.github/workflows/pre-release.yml.patch @@ -0,0 +1,22 @@ +diff --git a/.github/workflows/pre-release.yml b/.github/workflows/pre-release.yml +index 4428ecf83..217311ec8 100644 +--- a/.github/workflows/pre-release.yml ++++ b/.github/workflows/pre-release.yml +@@ -18,7 +18,7 @@ jobs: + + - uses: actions/setup-go@v5 + with: +- go-version: '1.21' ++ go-version-file: "go.mod" + + # Similar check to ./release-version.yml, but enforces this when pushing + # tags. The ./release-version.yml check can be bypassed and is mainly +@@ -57,7 +57,7 @@ jobs: + runs-on: ubuntu-latest + steps: + - name: Notify Slack upon pre-release +- uses: slackapi/slack-github-action@v1.26.0 ++ uses: slackapi/slack-github-action@v1.24.0 + env: + SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }} + SLACK_WEBHOOK_TYPE: INCOMING_WEBHOOK diff --git a/patches/.github/workflows/proto-lint.yml.patch b/patches/.github/workflows/proto-lint.yml.patch new file mode 100644 index 00000000000..870ca14e3ba --- /dev/null +++ b/patches/.github/workflows/proto-lint.yml.patch @@ -0,0 +1,22 @@ +diff --git a/.github/workflows/proto-lint.yml b/.github/workflows/proto-lint.yml +index de3ec9154..8ca233b00 100644 +--- a/.github/workflows/proto-lint.yml ++++ b/.github/workflows/proto-lint.yml +@@ -5,7 +5,7 @@ on: + - 'proto/**' + push: + branches: +- - v0.34.x ++ - v0.34.x-celestia + paths: + - 'proto/**' + +@@ -15,7 +15,7 @@ jobs: + timeout-minutes: 5 + steps: + - uses: actions/checkout@v4 +- - uses: bufbuild/buf-setup-action@v1.30.1 ++ - uses: bufbuild/buf-setup-action@v1.26.1 + - uses: bufbuild/buf-lint-action@v1 + with: + input: 'proto' diff --git a/patches/.github/workflows/release-version.yml.patch b/patches/.github/workflows/release-version.yml.patch new file mode 100644 index 00000000000..57030184e90 --- /dev/null +++ b/patches/.github/workflows/release-version.yml.patch @@ -0,0 +1,13 @@ +diff --git a/.github/workflows/release-version.yml b/.github/workflows/release-version.yml +index 96cc598ed..cbc9929fb 100644 +--- a/.github/workflows/release-version.yml ++++ b/.github/workflows/release-version.yml +@@ -15,7 +15,7 @@ jobs: + + - uses: actions/setup-go@v5 + with: +- go-version: '1.21' ++ go-version-file: "go.mod" + + - name: Check version + run: | diff --git a/patches/.github/workflows/release.yml.patch b/patches/.github/workflows/release.yml.patch new file mode 100644 index 00000000000..8a9f2c50108 --- /dev/null +++ b/patches/.github/workflows/release.yml.patch @@ -0,0 +1,59 @@ +diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml +index ef0213700..36e3395e7 100644 +--- a/.github/workflows/release.yml ++++ b/.github/workflows/release.yml +@@ -16,24 +16,7 @@ jobs: + + - uses: actions/setup-go@v5 + with: +- go-version: '1.21' +- +- # Similar check to ./release-version.yml, but enforces this when pushing +- # tags. The ./release-version.yml check can be bypassed and is mainly +- # present for informational purposes. +- - name: Check release version +- run: | +- # We strip the refs/tags/v prefix of the tag name. +- TAG_VERSION=${GITHUB_REF#refs/tags/v} +- # Get the version of the code, which has no "v" prefix. +- CODE_VERSION=`go run ./cmd/cometbft/ version` +- if [ "$TAG_VERSION" != "$CODE_VERSION" ]; then +- echo "" +- echo "Tag version ${TAG_VERSION} does not match code version ${CODE_VERSION}" +- echo "" +- echo "Please either fix the release tag or the version of the software in version/version.go." +- exit 1 +- fi ++ go-version-file: "go.mod" + + - name: Generate release notes + run: | +@@ -49,28 +32,3 @@ jobs: + args: release --clean --release-notes ../release_notes.md + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} +- +- release-success: +- needs: release +- if: ${{ success() }} +- runs-on: ubuntu-latest +- steps: +- - name: Notify Slack upon release +- uses: slackapi/slack-github-action@v1.26.0 +- env: +- SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }} +- SLACK_WEBHOOK_TYPE: INCOMING_WEBHOOK +- RELEASE_URL: "${{ github.server_url }}/${{ github.repository }}/releases/tag/${{ github.ref_name }}" +- with: +- payload: | +- { +- "blocks": [ +- { +- "type": "section", +- "text": { +- "type": "mrkdwn", +- "text": ":rocket: New CometBFT release: <${{ env.RELEASE_URL }}|${{ github.ref_name }}>" +- } +- } +- ] +- } diff --git a/patches/.github/workflows/testapp-docker.yml.patch b/patches/.github/workflows/testapp-docker.yml.patch new file mode 100644 index 00000000000..f0fdfab2c61 --- /dev/null +++ b/patches/.github/workflows/testapp-docker.yml.patch @@ -0,0 +1,25 @@ +diff --git a/.github/workflows/testapp-docker.yml b/.github/workflows/testapp-docker.yml +index 28d14126d..e9f84e525 100644 +--- a/.github/workflows/testapp-docker.yml ++++ b/.github/workflows/testapp-docker.yml +@@ -42,17 +42,17 @@ jobs: + platforms: all + + - name: Set up Docker Build +- uses: docker/setup-buildx-action@v3.3.0 ++ uses: docker/setup-buildx-action@v3.0.0 + + - name: Login to DockerHub + if: ${{ github.event_name != 'pull_request' }} +- uses: docker/login-action@v3.1.0 ++ uses: docker/login-action@v3.0.0 + with: + username: ${{ secrets.DOCKERHUB_USERNAME }} + password: ${{ secrets.DOCKERHUB_TOKEN }} + + - name: Publish to Docker Hub +- uses: docker/build-push-action@v5.3.0 ++ uses: docker/build-push-action@v5.0.0 + with: + context: . + file: ./test/e2e/docker/Dockerfile diff --git a/patches/.github/workflows/tests.yml.patch b/patches/.github/workflows/tests.yml.patch new file mode 100644 index 00000000000..83edcb786b0 --- /dev/null +++ b/patches/.github/workflows/tests.yml.patch @@ -0,0 +1,129 @@ +diff --git a/.github/workflows/tests.yml b/.github/workflows/tests.yml +index 3d8a796da..3ce0eece9 100644 +--- a/.github/workflows/tests.yml ++++ b/.github/workflows/tests.yml +@@ -6,7 +6,8 @@ on: + pull_request: + push: + branches: +- - v0.34.x ++ - v[0-9]+.[0-9]+.x-celestia ++ - release/** + + jobs: + cleanup-runs: +@@ -22,10 +23,10 @@ jobs: + runs-on: ubuntu-latest + timeout-minutes: 5 + steps: ++ - uses: actions/checkout@v4 + - uses: actions/setup-go@v5 + with: +- go-version: "1.21" +- - uses: actions/checkout@v4 ++ go-version-file: "go.mod" + - uses: technote-space/get-diff-action@v6 + with: + PATTERNS: | +@@ -34,7 +35,7 @@ jobs: + go.sum + - name: install + run: make install install_abci +- if: "env.GIT_DIFF != ''" ++ if: env.GIT_DIFF + - uses: actions/cache@v4 + with: + path: ~/go/pkg/mod +@@ -54,10 +55,10 @@ jobs: + needs: build + timeout-minutes: 5 + steps: ++ - uses: actions/checkout@v4 + - uses: actions/setup-go@v5 + with: +- go-version: "1.21" +- - uses: actions/checkout@v4 ++ go-version-file: "go.mod" + - uses: technote-space/get-diff-action@v6 + with: + PATTERNS: | +@@ -86,10 +87,10 @@ jobs: + needs: build + timeout-minutes: 5 + steps: ++ - uses: actions/checkout@v4 + - uses: actions/setup-go@v5 + with: +- go-version: "1.21" +- - uses: actions/checkout@v4 ++ go-version-file: "go.mod" + - uses: technote-space/get-diff-action@v6 + with: + PATTERNS: | +@@ -112,34 +113,35 @@ jobs: + shell: bash + if: env.GIT_DIFF + +- test_apps: +- runs-on: ubuntu-latest +- needs: build +- timeout-minutes: 5 +- steps: +- - uses: actions/setup-go@v5 +- with: +- go-version: "1.21" +- - uses: actions/checkout@v4 +- - uses: technote-space/get-diff-action@v6 +- with: +- PATTERNS: | +- **/**.go +- go.mod +- go.sum +- - uses: actions/cache@v4 +- with: +- path: ~/go/pkg/mod +- key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }} +- restore-keys: | +- ${{ runner.os }}-go- +- if: env.GIT_DIFF +- - uses: actions/cache@v4 +- with: +- path: ~/go/bin +- key: ${{ runner.os }}-${{ github.sha }}-tm-binary +- if: env.GIT_DIFF +- - name: test_apps +- run: test/app/test.sh +- shell: bash +- if: env.GIT_DIFF ++ # TODO: re-enable this test after upgrading to cometbft v0.37.x ++ # test_apps: ++ # runs-on: ubuntu-latest ++ # needs: build ++ # timeout-minutes: 5 ++ # steps: ++ # - uses: actions/setup-go@v3 ++ # with: ++ # go-version: "1.22.6" ++ # - uses: actions/checkout@v3 ++ # - uses: technote-space/get-diff-action@v6 ++ # with: ++ # PATTERNS: | ++ # **/**.go ++ # go.mod ++ # go.sum ++ # - uses: actions/cache@v3 ++ # with: ++ # path: ~/go/pkg/mod ++ # key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }} ++ # restore-keys: | ++ # ${{ runner.os }}-go- ++ # if: env.GIT_DIFF ++ # - uses: actions/cache@v3 ++ # with: ++ # path: ~/go/bin ++ # key: ${{ runner.os }}-${{ github.sha }}-tm-binary ++ # if: env.GIT_DIFF ++ # - name: test_apps ++ # run: test/app/test.sh ++ # shell: bash ++ # if: env.GIT_DIFF diff --git a/patches/.golangci.yml.patch b/patches/.golangci.yml.patch new file mode 100644 index 00000000000..bb3a56b8dd9 --- /dev/null +++ b/patches/.golangci.yml.patch @@ -0,0 +1,60 @@ +diff --git a/.golangci.yml b/.golangci.yml +index 278a50ff7..b840449cd 100644 +--- a/.golangci.yml ++++ b/.golangci.yml +@@ -1,21 +1,16 @@ +-run: +- skip-files: +- - "libs/pubsub/query/query.peg.go" +- + linters: + enable: + - asciicheck + - bodyclose +- - depguard + - dogsled + - dupl + - errcheck +- - exportloopref ++ # - copyloopvar + - goconst + - gofmt + - goimports + #- revive +- - gosec ++ # - gosec + - gosimple + - govet + - ineffassign +@@ -31,6 +26,8 @@ linters: + - unused + + issues: ++ exclude-files: ++ - "libs/pubsub/query/query.peg.go" + exclude-rules: + - path: _test\.go + linters: +@@ -47,10 +44,6 @@ issues: + linters-settings: + dogsled: + max-blank-identifiers: 3 +- golint: +- min-confidence: 0 +- maligned: +- suggest-new: true + goconst: + ignore-tests: true + depguard: +@@ -91,6 +84,11 @@ linters-settings: + - github.com/spf13 + - github.com/stretchr/testify/require + - github.com/syndtr/goleveldb ++ # celestia-core specific ++ - github.com/influxdata/influxdb-client-go/v2 ++ - github.com/grafana/pyroscope-go ++ - github.com/grafana/otel-profiling-go ++ - github.com/celestiaorg/nmt + test: + files: + - "$test" diff --git a/patches/.mergify.yml.patch b/patches/.mergify.yml.patch new file mode 100644 index 00000000000..ddb15340471 --- /dev/null +++ b/patches/.mergify.yml.patch @@ -0,0 +1,16 @@ +diff --git a/.mergify.yml b/.mergify.yml +deleted file mode 100644 +index b1bef433d..000000000 +--- a/.mergify.yml ++++ /dev/null +@@ -1,10 +0,0 @@ +-pull_request_rules: +- - name: Automerge to master +- conditions: +- - base=master +- - label=S:automerge +- actions: +- merge: +- method: squash +- strict: true +- commit_message: title+body diff --git a/patches/CHANGELOG.md.patch b/patches/CHANGELOG.md.patch new file mode 100644 index 00000000000..3a36431180d --- /dev/null +++ b/patches/CHANGELOG.md.patch @@ -0,0 +1,269 @@ +diff --git a/CHANGELOG.md b/CHANGELOG.md +deleted file mode 100644 +index f2719d798..000000000 +--- a/CHANGELOG.md ++++ /dev/null +@@ -1,263 +0,0 @@ +-# CHANGELOG +- +-## v0.34.33 +- +-*April 26, 2024* +- +-This release bumps Go version to 1.21. +- +-### BUG FIXES +- +-- [`bits`] prevent `BitArray.UnmarshalJSON` from crashing on 0 bits +- ([\#2774](https://github.com/cometbft/cometbft/pull/2774)) +- +-### DEPENDENCIES +- +-- Bump cometbft-db version to v0.9.1, which brings support for RocksDB v8. +- ([\#2783](https://github.com/cometbft/cometbft/pull/2783)) +-- Bump Go version used to v1.21 since v1.20 has reached EOL +- ([\#2784](https://github.com/cometbft/cometbft/pull/2784)) +- +-## v0.34.32 +- +-*March 12, 2024* +- +-This release fixes a security bug in the light client. +- +-### BUG FIXES +- +-- `[evidence]` When `VerifyCommitLight` & `VerifyCommitLightTrusting` are called as part +- of evidence verification, all signatures present in the evidence must be verified +- ([\#1749](https://github.com/cometbft/cometbft/pull/1749)) +- +-### IMPROVEMENTS +- +-- `[types]` Validate `Validator#Address` in `ValidateBasic` ([\#1715](https://github.com/cometbft/cometbft/pull/1715)) +-- `[abci]` Increase ABCI socket message size limit to 2GB ([\#1730](https://github.com/cometbft/cometbft/pull/1730): @troykessler) +-- `[e2e]` Add manifest option `load_max_txs` to limit the number of transactions generated by the +- `load` command. ([\#2094](https://github.com/cometbft/cometbft/pull/2094)) +-- `[e2e]` Log the number of transactions that were sent successfully or failed. +- ([\#2328](https://github.com/cometbft/cometbft/pull/2328)) +- +-## v0.34.31 +- +-*November 27, 2023* +- +-Fixes a small bug in the mempool for an experimental feature. +- +-### BUG FIXES +- +-- `[mempool]` Avoid infinite wait in transaction sending routine when +- using experimental parameters to limiting transaction gossiping to peers +- ([\#1654](https://github.com/cometbft/cometbft/pull/1654)) +- +-## v0.34.30 +- +-*November 17, 2023* +- +-This release contains, among other things, an opt-in, experimental feature to +-help reduce the bandwidth consumption associated with the mempool's transaction +-gossip. +- +-### BUILD +- +-- Bump Go version used to v1.20 since v1.19 has reached EOL +- ([\#1351](https://github.com/cometbft/cometbft/pull/1351)) +- +-### FEATURES +- +-- `[metrics]` Add metric for mempool size in bytes `SizeBytes`. +- ([\#1512](https://github.com/cometbft/cometbft/pull/1512)) +- +-### IMPROVEMENTS +- +-- `[node]` Make handshake cancelable ([cometbft/cometbft\#857](https://github.com/cometbft/cometbft/pull/857)) +-- `[node]` Close evidence.db OnStop ([cometbft/cometbft\#1210](https://github.com/cometbft/cometbft/pull/1210): @chillyvee) +-- `[mempool]` Add experimental feature to limit the number of persistent peers and non-persistent +- peers to which the node gossip transactions (only for "v0" mempool). +- ([\#1558](https://github.com/cometbft/cometbft/pull/1558), +- ([\#1584](https://github.com/cometbft/cometbft/pull/1584)) +-- `[config]` Add mempool parameters `experimental_max_gossip_connections_to_persistent_peers` and +- `experimental_max_gossip_connections_to_non_persistent_peers` for limiting the number of peers to +- which the node gossip transactions. +- ([\#1558](https://github.com/cometbft/cometbft/pull/1558)) +- ([\#1584](https://github.com/cometbft/cometbft/pull/1584)) +- +-## v0.34.29 +- +-*June 14, 2023* +- +-Provides several minor bug fixes, as well as fixes for several low-severity +-security issues. +- +-### BUG FIXES +- +-- `[state/kvindex]` Querying event attributes that are bigger than int64 is now +- enabled. ([\#771](https://github.com/cometbft/cometbft/pull/771)) +-- `[pubsub]` Pubsub queries are now able to parse big integers (larger than +- int64). Very big floats are also properly parsed into very big integers +- instead of being truncated to int64. +- ([\#771](https://github.com/cometbft/cometbft/pull/771)) +- +-### IMPROVEMENTS +- +-- `[rpc]` Remove response data from response failure logs in order +- to prevent large quantities of log data from being produced +- ([\#654](https://github.com/cometbft/cometbft/issues/654)) +- +-### SECURITY FIXES +- +-- `[rpc/jsonrpc/client]` **Low severity** - Prevent RPC +- client credentials from being inadvertently dumped to logs +- ([\#788](https://github.com/cometbft/cometbft/pull/788)) +-- `[cmd/cometbft/commands/debug/kill]` **Low severity** - Fix unsafe int cast in +- `debug kill` command ([\#794](https://github.com/cometbft/cometbft/pull/794)) +-- `[consensus]` **Low severity** - Avoid recursive call after rename to +- `(*PeerState).MarshalJSON` +- ([\#863](https://github.com/cometbft/cometbft/pull/863)) +-- `[mempool/clist_mempool]` **Low severity** - Prevent a transaction from +- appearing twice in the mempool +- ([\#890](https://github.com/cometbft/cometbft/pull/890): @otrack) +- +-## v0.34.28 +- +-*April 26, 2023* +- +-This release fixes several bugs, and has had to introduce one small Go +-API-breaking change in the `crypto/merkle` package in order to address what +-could be a security issue for some users who directly and explicitly make use of +-that code. +- +-### BREAKING CHANGES +- +-- `[crypto/merkle]` Do not allow verification of Merkle Proofs against empty trees (`nil` root). `Proof.ComputeRootHash` now panics when it encounters an error, but `Proof.Verify` does not panic +- ([\#558](https://github.com/cometbft/cometbft/issues/558)) +- +-### BUG FIXES +- +-- `[consensus]` Unexpected error conditions in `ApplyBlock` are non-recoverable, so ignoring the error and carrying on is a bug. We replaced a `return` that disregarded the error by a `panic`. +- ([\#496](https://github.com/cometbft/cometbft/pull/496)) +-- `[consensus]` Rename `(*PeerState).ToJSON` to `MarshalJSON` to fix a logging data race +- ([\#524](https://github.com/cometbft/cometbft/pull/524)) +-- `[light]` Fixed an edge case where a light client would panic when attempting +- to query a node that (1) has started from a non-zero height and (2) does +- not yet have any data. The light client will now, correctly, not panic +- _and_ keep the node in its list of providers in the same way it would if +- it queried a node starting from height zero that does not yet have data +- ([\#575](https://github.com/cometbft/cometbft/issues/575)) +- +-### IMPROVEMENTS +- +-- `[crypto/sr25519]` Upgrade to go-schnorrkel@v1.0.0 ([\#475](https://github.com/cometbft/cometbft/issues/475)) +-- `[jsonrpc/client]` Improve the error message for client errors stemming from +- bad HTTP responses. +- ([cometbft/cometbft\#638](https://github.com/cometbft/cometbft/pull/638)) +- +-## v0.34.27 +- +-*Feb 27, 2023* +- +-This is the first official release of CometBFT - a fork of [Tendermint +-Core](https://github.com/tendermint/tendermint). This particular release is +-intended to be compatible with the Tendermint Core v0.34 release series. +- +-For details as to how to upgrade to CometBFT from Tendermint Core, please see +-our [upgrading guidelines](./UPGRADING.md). +- +-If you have any questions, comments, concerns or feedback on this release, we +-would love to hear from you! Please contact us via [GitHub +-Discussions](https://github.com/cometbft/cometbft/discussions), +-[Discord](https://discord.gg/cosmosnetwork) (in the `#cometbft` channel) or +-[Telegram](https://t.me/CometBFT). +- +-Special thanks to @wcsiu, @ze97286, @faddat and @JayT106 for their contributions +-to this release! +- +-### BREAKING CHANGES +- +-- Rename binary to `cometbft` and Docker image to `cometbft/cometbft` +- ([\#152](https://github.com/cometbft/cometbft/pull/152)) +-- The `TMHOME` environment variable was renamed to `CMTHOME`, and all +- environment variables starting with `TM_` are instead prefixed with `CMT_` +- ([\#211](https://github.com/cometbft/cometbft/issues/211)) +-- Use Go 1.19 to build CometBFT, since Go 1.18 has reached end-of-life. +- ([\#360](https://github.com/cometbft/cometbft/issues/360)) +- +-### BUG FIXES +- +-- `[consensus]` Fixed a busy loop that happened when sending of a block part +- failed by sleeping in case of error. +- ([\#4](https://github.com/informalsystems/tendermint/pull/4)) +-- `[state/kvindexer]` Resolved crashes when event values contained slashes, +- introduced after adding event sequences. +- (\#[383](https://github.com/cometbft/cometbft/pull/383): @jmalicevic) +-- `[consensus]` Short-term fix for the case when `needProofBlock` cannot find +- previous block meta by defaulting to the creation of a new proof block. +- ([\#386](https://github.com/cometbft/cometbft/pull/386): @adizere) +- - Special thanks to the [Vega.xyz](https://vega.xyz/) team, and in particular +- to Zohar (@ze97286), for reporting the problem and working with us to get to +- a fix. +-- `[p2p]` Correctly use non-blocking `TrySendEnvelope` method when attempting to +- send messages, as opposed to the blocking `SendEnvelope` method. It is unclear +- whether this has a meaningful impact on P2P performance, but this patch does +- correct the underlying behaviour to what it should be +- ([tendermint/tendermint\#9936](https://github.com/tendermint/tendermint/pull/9936)) +- +-### DEPENDENCIES +- +-- Replace [tm-db](https://github.com/tendermint/tm-db) with +- [cometbft-db](https://github.com/cometbft/cometbft-db) +- ([\#160](https://github.com/cometbft/cometbft/pull/160)) +-- Bump tm-load-test to v1.3.0 to remove implicit dependency on Tendermint Core +- ([\#165](https://github.com/cometbft/cometbft/pull/165)) +-- `[crypto]` Update to use btcec v2 and the latest btcutil +- ([tendermint/tendermint\#9787](https://github.com/tendermint/tendermint/pull/9787): +- @wcsiu) +- +-### FEATURES +- +-- `[rpc]` Add `match_event` query parameter to indicate to the RPC that it +- should match events _within_ attributes, not only within a height +- ([tendermint/tendermint\#9759](https://github.com/tendermint/tendermint/pull/9759)) +- +-### IMPROVEMENTS +- +-- `[e2e]` Add functionality for uncoordinated (minor) upgrades +- ([\#56](https://github.com/tendermint/tendermint/pull/56)) +-- `[tools/tm-signer-harness]` Remove the folder as it is unused +- ([\#136](https://github.com/cometbft/cometbft/issues/136)) +-- Append the commit hash to the version of CometBFT being built +- ([\#204](https://github.com/cometbft/cometbft/pull/204)) +-- `[mempool/v1]` Suppress "rejected bad transaction" in priority mempool logs by +- reducing log level from info to debug +- ([\#314](https://github.com/cometbft/cometbft/pull/314): @JayT106) +-- `[consensus]` Add `consensus_block_gossip_parts_received` and +- `consensus_step_duration_seconds` metrics in order to aid in investigating the +- impact of database compaction on consensus performance +- ([tendermint/tendermint\#9733](https://github.com/tendermint/tendermint/pull/9733)) +-- `[state/kvindexer]` Add `match.event` keyword to support condition evaluation +- based on the event the attributes belong to +- ([tendermint/tendermint\#9759](https://github.com/tendermint/tendermint/pull/9759)) +-- `[p2p]` Reduce log spam through reducing log level of "Dialing peer" and +- "Added peer" messages from info to debug +- ([tendermint/tendermint\#9764](https://github.com/tendermint/tendermint/pull/9764): +- @faddat) +-- `[consensus]` Reduce bandwidth consumption of consensus votes by roughly 50% +- through fixing a small logic bug +- ([tendermint/tendermint\#9776](https://github.com/tendermint/tendermint/pull/9776)) +- +---- +- +-CometBFT is a fork of [Tendermint +-Core](https://github.com/tendermint/tendermint) as of late December 2022. +- +-## Bug bounty +- +-Friendly reminder, we have a [bug bounty program](https://hackerone.com/cosmos). +- +-## Previous changes +- +-For changes released before the creation of CometBFT, please refer to the +-Tendermint Core +-[CHANGELOG.md](https://github.com/tendermint/tendermint/blob/a9feb1c023e172b542c972605311af83b777855b/CHANGELOG.md). +- diff --git a/patches/CODE_OF_CONDUCT.md.patch b/patches/CODE_OF_CONDUCT.md.patch new file mode 100644 index 00000000000..e977992b892 --- /dev/null +++ b/patches/CODE_OF_CONDUCT.md.patch @@ -0,0 +1,115 @@ +diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md +deleted file mode 100644 +index 3f93f1e5e..000000000 +--- a/CODE_OF_CONDUCT.md ++++ /dev/null +@@ -1,109 +0,0 @@ +-# The CometBFT Code of Conduct +- +-This code of conduct applies to all projects run by the CometBFT team and +-hence to CometBFT. +- +----- +- +-# Conduct +- +-## Contact: conduct@informal.systems +- +-* We are committed to providing a friendly, safe and welcoming environment for +- all, regardless of level of experience, gender, gender identity and +- expression, sexual orientation, disability, personal appearance, body size, +- race, ethnicity, age, religion, nationality, or other similar characteristics. +- +-* On Slack, please avoid using overtly sexual nicknames or other nicknames that +- might detract from a friendly, safe and welcoming environment for all. +- +-* Please be kind and courteous. There’s no need to be mean or rude. +- +-* Respect that people have differences of opinion and that every design or +- implementation choice carries a trade-off and numerous costs. There is seldom +- a right answer. +- +-* Please keep unstructured critique to a minimum. If you have solid ideas you +- want to experiment with, make a fork and see how it works. +- +-* We will exclude you from interaction if you insult, demean or harass anyone. +- That is not welcome behavior. We interpret the term “harassment” as including +- the definition in the [Citizen Code of Conduct][ccoc]; if you have any lack of +- clarity about what might be included in that concept, please read their +- definition. In particular, we don’t tolerate behavior that excludes people in +- socially marginalized groups. +- +-* Private harassment is also unacceptable. No matter who you are, if you feel +- you have been or are being harassed or made uncomfortable by a community +- member, please get in touch with one of the channel admins or the contact address above +- immediately. Whether you’re a regular contributor or a newcomer, we care about +- making this community a safe place for you and we’ve got your back. +- +-* Likewise any spamming, trolling, flaming, baiting or other attention-stealing +- behavior is not welcome. +- +----- +- +-# Moderation +- +-These are the policies for upholding our community’s standards of conduct. If +-you feel that a thread needs moderation, please contact the above mentioned +-person. +- +-1. Remarks that violate the CometBFT/Cosmos standards of conduct, including +- hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. +- (Cursing is allowed, but never targeting another user, and never in a hateful +- manner.) +- +-2. Remarks that moderators find inappropriate, whether listed in the code of +- conduct or not, are also not allowed. +- +-3. Moderators will first respond to such remarks with a warning. +- +-4. If the warning is unheeded, the user will be “kicked,” i.e., kicked out of +- the communication channel to cool off. +- +-5. If the user comes back and continues to make trouble, they will be banned, +- i.e., indefinitely excluded. +- +-6. Moderators may choose at their discretion to un-ban the user if it was a +- first offense and they offer the offended party a genuine apology. +- +-7. If a moderator bans someone and you think it was unjustified, please take it +- up with that moderator, or with a different moderator, in private. Complaints +- about bans in-channel are not allowed. +- +-8. Moderators are held to a higher standard than other community members. If a +- moderator creates an inappropriate situation, they should expect less leeway +- than others. +- +-In the CometBFT/Cosmos community we strive to go the extra step to look out +-for each other. Don’t just aim to be technically unimpeachable, try to be your +-best self. In particular, avoid flirting with offensive or sensitive issues, +-particularly if they’re off-topic; this all too often leads to unnecessary +-fights, hurt feelings, and damaged trust; worse, it can drive people away +-from the community entirely. +- +-And if someone takes issue with something you said or did, resist the urge to be +-defensive. Just stop doing what it was they complained about and apologize. Even +-if you feel you were misinterpreted or unfairly accused, chances are good there +-was something you could’ve communicated better — remember that it’s your +-responsibility to make your fellow Cosmonauts comfortable. Everyone wants to +-get along and we are all here first and foremost because we want to talk +-about cool technology. You will find that people will be eager to assume +-good intent and forgive as long as you earn their trust. +- +-The enforcement policies listed above apply to all official CometBFT/Cosmos +-venues. For other projects adopting the CometBFT/Cosmos Code of Conduct, +-please contact the maintainers of those projects for enforcement. If you wish to +-use this code of conduct for your own project, consider explicitly mentioning +-your moderation policy or making a copy with your own moderation policy so as to +-avoid confusion. +- +-\*Adapted from the [Node.js Policy on Trolling][node-trolling-policy], the +-[Contributor Covenant v1.3.0][ccov] and the [Rust Code of Conduct][rust-coc]. +- +-[ccoc]: https://github.com/stumpsyn/policies/blob/master/citizen_code_of_conduct.md +-[node-trolling-policy]: http://blog.izs.me/post/30036893703/policy-on-trolling +-[ccov]: http://contributor-covenant.org/version/1/3/0/ +-[rust-coc]: https://www.rust-lang.org/en-US/conduct.html diff --git a/patches/CONTRIBUTING.md.patch b/patches/CONTRIBUTING.md.patch new file mode 100644 index 00000000000..29508fa5299 --- /dev/null +++ b/patches/CONTRIBUTING.md.patch @@ -0,0 +1,396 @@ +diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md +deleted file mode 100644 +index 812e329e6..000000000 +--- a/CONTRIBUTING.md ++++ /dev/null +@@ -1,390 +0,0 @@ +-# Contributing +- +-Thank you for your interest in contributing to CometBFT! Before contributing, it +-may be helpful to understand the goal of the project. The goal of CometBFT is to +-develop a BFT consensus engine robust enough to support permissionless +-value-carrying networks. While all contributions are welcome, contributors +-should bear this goal in mind in deciding if they should target the main +-CometBFT project or a potential fork. When targeting the main CometBFT project, +-the following process leads to the best chance of landing changes in `main`. +- +-All work on the code base should be motivated by a [GitHub +-Issue](https://github.com/cometbft/cometbft/issues). +-[Search](https://github.com/cometbft/cometbft/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) +-is a good place to start when looking for places to contribute. If you would +-like to work on an issue which already exists, please indicate so by leaving a +-comment. +- +-All new contributions should start with a [GitHub +-Issue](https://github.com/cometbft/cometbft/issues/new/choose). The issue helps +-capture the problem you're trying to solve and allows for early feedback. Once +-the issue is created the process can proceed in different directions depending +-on how well defined the problem and potential solution are. If the change is +-simple and well understood, maintainers will indicate their support with a +-heartfelt emoji. +- +-If the issue would benefit from thorough discussion, maintainers may request +-that you create a [Request For +-Comment](https://github.com/cometbft/cometbft/tree/main/docs/rfc) in the +-CometBFT repo. Discussion at the RFC stage will build collective +-understanding of the dimensions of the problems and help structure conversations +-around trade-offs. +- +-When the problem is well understood but the solution leads to large structural +-changes to the code base, these changes should be proposed in the form of an +-[Architectural Decision Record (ADR)](./docs/architecture/). The ADR will help +-build consensus on an overall strategy to ensure the code base maintains +-coherence in the larger context. If you are not comfortable with writing an ADR, +-you can open a less-formal issue and the maintainers will help you turn it into +-an ADR. +- +-> How to pick a number for the ADR? +- +-Find the largest existing ADR number and bump it by 1. +- +-When the problem as well as proposed solution are well understood, +-changes should start with a [draft +-pull request](https://github.blog/2019-02-14-introducing-draft-pull-requests/) +-against `main`. The draft signals that work is underway. When the work +-is ready for feedback, hitting "Ready for Review" will signal to the +-maintainers to take a look. +- +-![Contributing flow](./docs/imgs/contributing.png) +- +-Each stage of the process is aimed at creating feedback cycles which align contributors and maintainers to make sure: +- +-- Contributors don’t waste their time implementing/proposing features which won’t land in `main`. +-- Maintainers have the necessary context in order to support and review contributions. +- +- +-## Forking +- +-Please note that Go requires code to live under absolute paths, which complicates forking. +-While my fork lives at `https://github.com/ebuchman/cometbft`, +-the code should never exist at `$GOPATH/src/github.com/ebuchman/cometbft`. +-Instead, we use `git remote` to add the fork as a new remote for the original repo, +-`$GOPATH/src/github.com/cometbft/cometbft`, and do all the work there. +- +-For instance, to create a fork and work on a branch of it, I would: +- +-- Create the fork on GitHub, using the fork button. +-- Go to the original repo checked out locally (i.e. `$GOPATH/src/github.com/cometbft/cometbft`) +-- `git remote rename origin upstream` +-- `git remote add origin git@github.com:ebuchman/basecoin.git` +- +-Now `origin` refers to my fork and `upstream` refers to the CometBFT version. +-So I can `git push -u origin main` to update my fork, and make pull requests to CometBFT from there. +-Of course, replace `ebuchman` with your git handle. +- +-To pull in updates from the origin repo, run +- +-- `git fetch upstream` +-- `git rebase upstream/main` (or whatever branch you want) +- +-## Dependencies +- +-We use [go modules](https://github.com/golang/go/wiki/Modules) to manage dependencies. +- +-That said, the `main` branch of every CometBFT repository should just build +-with `go get`, which means they should be kept up-to-date with their +-dependencies so we can get away with telling people they can just `go get` our +-software. +- +-Since some dependencies are not under our control, a third party may break our +-build, in which case we can fall back on `go mod tidy`. Even for dependencies under our control, go helps us to +-keep multiple repos in sync as they evolve. Anything with an executable, such +-as apps, tools, and the core, should use dep. +- +-Run `go list -u -m all` to get a list of dependencies that may not be +-up-to-date. +- +-When updating dependencies, please only update the particular dependencies you +-need. Instead of running `go get -u=patch`, which will update anything, +-specify exactly the dependency you want to update. +- +-## Protobuf +- +-We use [Protocol Buffers](https://developers.google.com/protocol-buffers) along +-with [`gogoproto`](https://github.com/cosmos/gogoproto) to generate code for use +-across CometBFT. +- +-To generate proto stubs, lint, and check protos for breaking changes, you will +-need to install [buf](https://buf.build/) and `gogoproto`. Then, from the root +-of the repository, run: +- +-```bash +-# Lint all of the .proto files +-make proto-lint +- +-# Check if any of your local changes (prior to committing to the Git repository) +-# are breaking +-make proto-check-breaking +- +-# Generate Go code from the .proto files +-make proto-gen +-``` +- +-To automatically format `.proto` files, you will need +-[`clang-format`](https://clang.llvm.org/docs/ClangFormat.html) installed. Once +-installed, you can run: +- +-```bash +-make proto-format +-``` +- +-### Visual Studio Code +- +-If you are a VS Code user, you may want to add the following to your `.vscode/settings.json`: +- +-```json +-{ +- "protoc": { +- "options": [ +- "--proto_path=${workspaceRoot}/proto", +- ] +- } +-} +-``` +- +-## Changelog +- +-To manage and generate our changelog, we currently use [unclog](https://github.com/informalsystems/unclog). +- +-Every fix, improvement, feature, or breaking change should be made in a +-pull-request that includes a file +-`.changelog/unreleased/${category}/${issue-or-pr-number}-${description}.md`, +-where: +-- `category` is one of `improvements`, `breaking-changes`, `bug-fixes`, +- `features` and if multiple apply, create multiple files; +-- `description` is a short (4 to 6 word), hyphen separated description of the +- fix, starting the component changed; and, +-- `issue or PR number` is the CometBFT issue number, if one exists, or the PR +- number, otherwise. +- +-For examples, see the [.changelog](.changelog) folder. +- +-A feature can also be worked on a feature branch, if its size and/or risk +-justifies it (see [below](#branching-model-and-release)). +- +-### What does a good changelog entry look like? +- +-Changelog entries should answer the question: "what is important about this +-change for users to know?" or "what problem does this solve for users?". It +-should not simply be a reiteration of the title of the associated PR, unless the +-title of the PR _very_ clearly explains the benefit of a change to a user. +- +-Some good examples of changelog entry descriptions: +- +-```md +-- [consensus] \#1111 Small transaction throughput improvement (approximately +- 3-5\% from preliminary tests) through refactoring the way we use channels +-- [mempool] \#1112 Refactor Go API to be able to easily swap out the current +- mempool implementation in CometBFT forks +-- [p2p] \#1113 Automatically ban peers when their messages are unsolicited or +- are received too frequently +-``` +- +-Some bad examples of changelog entry descriptions: +- +-```md +-- [consensus] \#1111 Refactor channel usage +-- [mempool] \#1112 Make API generic +-- [p2p] \#1113 Ban for PEX message abuse +-``` +- +-For more on how to write good changelog entries, see: +- +-- +-- +-- +- +-### Changelog entry format +- +-Changelog entries should be formatted as follows: +- +-```md +-- [module] \#xxx Some description of the change (@contributor) +-``` +- +-Here, `module` is the part of the code that changed (typically a top-level Go +-package), `xxx` is the pull-request number, and `contributor` is the author/s of +-the change. +- +-It's also acceptable for `xxx` to refer to the relevant issue number, but +-pull-request numbers are preferred. Note this means pull-requests should be +-opened first so the changelog can then be updated with the pull-request's +-number. There is no need to include the full link, as this will be added +-automatically during release. But please include the backslash and pound, eg. +-`\#2313`. +- +-Changelog entries should be ordered alphabetically according to the `module`, +-and numerically according to the pull-request number. +- +-Changes with multiple classifications should be doubly included (eg. a bug fix +-that is also a breaking change should be recorded under both). +- +-Breaking changes are further subdivided according to the APIs/users they impact. +-Any change that affects multiple APIs/users should be recorded multiply - for +-instance, a change to the `Blockchain Protocol` that removes a field from the +-header should also be recorded under `CLI/RPC/Config` since the field will be +-removed from the header in RPC responses as well. +- +-## Branching Model and Release +- +-The main development branch is `main`. +- +-Every release is maintained in a release branch named `vX.Y.Z`. +- +-Pending minor releases have long-lived release candidate ("RC") branches. Minor +-release changes should be merged to these long-lived RC branches at the same +-time that the changes are merged to `main`. +- +-If a feature's size is big and/or its risk is high, it can be implemented in a +-feature branch. While the feature work is in progress, pull requests are open +-and squash merged against the feature branch. Branch `main` is periodically +-merged (merge commit) into the feature branch, to reduce branch divergence. When +-the feature is complete, the feature branch is merged back (merge commit) into +-`main`. The moment of the final merge can be carefully chosen so as to land +-different features in different releases. +- +-Note, all pull requests should be squash merged except for merging to a release +-branch (named `vX.Y`). This keeps the commit history clean and makes it easy to +-reference the pull request where a change was introduced. +- +-### Development Procedure +- +-The latest state of development is on `main`, which must never fail `make test`. +-_Never_ force push `main`, unless fixing broken git history (which we rarely do +-anyways). +- +-To begin contributing, create a development branch either on +-`github.com/cometbft/cometbft`, or your fork (using `git remote add origin`). +- +-Make changes, and before submitting a pull request, update the changelog to +-record your change. Also, run either `git rebase` or `git merge` on top of the +-latest `main`. (Since pull requests are squash-merged, either is fine!) +- +-Update the `UPGRADING.md` if the change you've made is breaking and the +-instructions should be in place for a user on how he/she can upgrade its +-software (ABCI application, CometBFT blockchain, light client, wallet). +- +-Sometimes (often!) pull requests get out-of-date with `main`, as other people +-merge different pull requests to `main`. It is our convention that pull request +-authors are responsible for updating their branches with `main`. (This also +-means that you shouldn't update someone else's branch for them; even if it seems +-like you're doing them a favor, you may be interfering with their git flow in +-some way!) +- +-#### Merging Pull Requests +- +-It is also our convention that authors merge their own pull requests, when +-possible. External contributors may not have the necessary permissions to do +-this, in which case, a member of the core team will merge the pull request once +-it's been approved. +- +-Before merging a pull request: +- +-- Ensure pull branch is up-to-date with a recent `main` (GitHub won't let you +- merge without this!) +-- Run `make test` to ensure that all tests pass +-- [Squash](https://stackoverflow.com/questions/5189560/squash-my-last-x-commits-together-using-git) +- merge pull request +- +-#### Pull Requests for Minor Releases +- +-If your change should be included in a minor release, please also open a PR +-against the long-lived minor release candidate branch (e.g., `rc1/v0.33.5`) +-_immediately after your change has been merged to main_. +- +-You can do this by cherry-picking your commit off `main`: +- +-```sh +-$ git checkout rc1/v0.33.5 +-$ git checkout -b {new branch name} +-$ git cherry-pick {commit SHA from main} +-# may need to fix conflicts, and then use git add and git cherry-pick --continue +-$ git push origin {new branch name} +-``` +- +-After this, you can open a PR. Please note in the PR body if there were merge +-conflicts so that reviewers can be sure to take a thorough look. +- +-### Git Commit Style +- +-We follow the [Go style guide on commit +-messages](https://tip.golang.org/doc/contribute.html#commit_messages). Write +-concise commits that start with the package name and have a description that +-finishes the sentence "This change modifies CometBFT to...". For example, +- +-```sh +-cmd/debug: execute p.Signal only when p is not nil +- +-[potentially longer description in the body] +- +-Fixes #nnnn +-``` +- +-Each PR should have one commit once it lands on `main`; this can be accomplished +-by using the "squash and merge" button on GitHub. Be sure to edit your commit +-message, though! +- +-## Testing +- +-### Unit tests +- +-Unit tests are located in `_test.go` files as directed by [the Go testing +-package](https://golang.org/pkg/testing/). If you're adding or removing a +-function, please check there's a `TestType_Method` test for it. +- +-Run: `make test` +- +-### Integration tests +- +-Integration tests are also located in `_test.go` files. What differentiates +-them is a more complicated setup, which usually involves setting up two or more +-components. +- +-Run: `make test_integrations` +- +-### End-to-end tests +- +-End-to-end tests are used to verify a fully integrated CometBFT network. +- +-See [README](./test/e2e/README.md) for details. +- +-Run: +- +-```sh +-cd test/e2e && \ +- make && \ +- ./build/runner -f networks/ci.toml +-``` +- +-### Fuzz tests (ADVANCED) +- +-*NOTE: if you're just submitting your first PR, you won't need to touch these +-most probably (99.9%)*. +- +-[Fuzz tests](https://en.wikipedia.org/wiki/Fuzzing) can be found inside the +-`./test/fuzz` directory. See [README.md](./test/fuzz/README.md) for details. +- +-Run: `cd test/fuzz && make fuzz-{PACKAGE-COMPONENT}` +- +-### RPC Testing +- +-**If you contribute to the RPC endpoints it's important to document your +-changes in the [Openapi file](./rpc/openapi/openapi.yaml)**. +- +-To test your changes you must install `nodejs` and run: +- +-```bash +-npm i -g dredd +-make build-linux build-contract-tests-hooks +-make contract-tests +-``` +- +-**WARNING: these are currently broken due to +-not supporting complete OpenAPI 3**. +- +-This command will popup a network and check every endpoint against what has +-been documented. diff --git a/patches/DOCKER/Dockerfile.patch b/patches/DOCKER/Dockerfile.patch new file mode 100644 index 00000000000..fa8204a49f0 --- /dev/null +++ b/patches/DOCKER/Dockerfile.patch @@ -0,0 +1,17 @@ +diff --git a/DOCKER/Dockerfile b/DOCKER/Dockerfile +index 3649cc5a0..b7596f4b5 100644 +--- a/DOCKER/Dockerfile ++++ b/DOCKER/Dockerfile +@@ -1,6 +1,6 @@ + # Use a build arg to ensure that both stages use the same, + # hopefully current, go version. +-ARG GOLANG_BASE_IMAGE=golang:1.21-alpine ++ARG GOLANG_BASE_IMAGE=golang:1.23.1-alpine + + # stage 1 Generate CometBFT Binary + FROM --platform=$BUILDPLATFORM $GOLANG_BASE_IMAGE as builder +@@ -58,4 +58,3 @@ CMD ["node"] + + # Expose the data directory as a volume since there's mutable state in there + VOLUME [ "$CMTHOME" ] +- diff --git a/patches/Makefile.patch b/patches/Makefile.patch new file mode 100644 index 00000000000..8ec4128e680 --- /dev/null +++ b/patches/Makefile.patch @@ -0,0 +1,94 @@ +diff --git a/Makefile b/Makefile +index c28d6da75..0de347654 100644 +--- a/Makefile ++++ b/Makefile +@@ -10,6 +10,7 @@ BUILD_FLAGS = -mod=readonly -ldflags "$(LD_FLAGS)" + HTTPS_GIT := https://github.com/cometbft/cometbft.git + CGO_ENABLED ?= 0 + ++BUF_VERSION := v1.31.0 + # handle nostrip + ifeq (,$(findstring nostrip,$(COMETBFT_BUILD_OPTIONS))) + BUILD_FLAGS += -trimpath +@@ -108,7 +109,7 @@ ifeq (linux/riscv64,$(findstring linux/riscv64,$(TARGETPLATFORM))) + GOARCH=riscv64 + endif + +-all: check build test install ++all: build test install + .PHONY: all + + include tests.mk +@@ -117,6 +118,8 @@ include tests.mk + ### Build CometBFT ### + ############################################################################### + ++ ++ + build: + CGO_ENABLED=$(CGO_ENABLED) go build $(BUILD_FLAGS) -tags '$(BUILD_TAGS)' -o $(OUTPUT) ./cmd/cometbft/ + .PHONY: build +@@ -150,17 +153,19 @@ ifeq (,$(shell which clang-format)) + endif + .PHONY: check-proto-format-deps + ++#? proto-gen: Generate protobuf files + proto-gen: check-proto-deps + @echo "Generating Protobuf files" +- @go run github.com/bufbuild/buf/cmd/buf generate ++ @go run github.com/bufbuild/buf/cmd/buf@$(BUF_VERSION) generate + @mv ./proto/tendermint/abci/types.pb.go ./abci/types/ ++ @cp ./proto/tendermint/rpc/grpc/types.pb.go ./rpc/grpc + .PHONY: proto-gen + + # These targets are provided for convenience and are intended for local + # execution only. + proto-lint: check-proto-deps + @echo "Linting Protobuf files" +- @go run github.com/bufbuild/buf/cmd/buf lint ++ @go run github.com/bufbuild/buf/cmd/buf@$(BUF_VERSION) lint + .PHONY: proto-lint + + proto-format: check-proto-format-deps +@@ -173,11 +178,11 @@ proto-check-breaking: check-proto-deps + @echo "Note: This is only useful if your changes have not yet been committed." + @echo " Otherwise read up on buf's \"breaking\" command usage:" + @echo " https://docs.buf.build/breaking/usage" +- @go run github.com/bufbuild/buf/cmd/buf breaking --against ".git" ++ @go run github.com/bufbuild/buf/cmd/buf@$(BUF_VERSION) breaking --against ".git" + .PHONY: proto-check-breaking + + proto-check-breaking-ci: +- @go run github.com/bufbuild/buf/cmd/buf breaking --against $(HTTPS_GIT)#branch=v0.34.x ++ @go run github.com/bufbuild/buf/cmd/buf@$(BUF_VERSION) breaking --against $(HTTPS_GIT)#branch=v0.34.x-celestia + .PHONY: proto-check-breaking-ci + + ############################################################################### +@@ -256,7 +261,7 @@ format: + + lint: + @echo "--> Running linter" +- @go run github.com/golangci/golangci-lint/cmd/golangci-lint@latest run ++ @go run github.com/golangci/golangci-lint/cmd/golangci-lint@v1.61.0 run + .PHONY: lint + + vulncheck: +@@ -312,15 +317,15 @@ build_c-amazonlinux: + # Run a 4-node testnet locally + localnet-start: localnet-stop build-docker-localnode + @if ! [ -f build/node0/config/genesis.json ]; then docker run --rm -v $(CURDIR)/build:/cometbft:Z cometbft/localnode testnet --config /etc/cometbft/config-template.toml --o . --starting-ip-address 192.167.10.2; fi +- docker-compose up ++ docker compose up + .PHONY: localnet-start + + # Stop testnet + localnet-stop: +- docker-compose down ++ docker compose down + .PHONY: localnet-stop + +-# Build hooks for dredd, to skip or add information on some steps ++#? build-contract-tests-hooks: Build hooks for dredd, to skip or add information on some steps + build-contract-tests-hooks: + ifeq ($(OS),Windows_NT) + go build -mod=readonly $(BUILD_FLAGS) -o build/contract_tests.exe ./cmd/contract_tests diff --git a/patches/README.md.patch b/patches/README.md.patch new file mode 100644 index 00000000000..2e565352d3d --- /dev/null +++ b/patches/README.md.patch @@ -0,0 +1,251 @@ +diff --git a/README.md b/README.md +index 4b9ef7cd0..98d8a77f9 100644 +--- a/README.md ++++ b/README.md +@@ -1,185 +1,86 @@ +-# CometBFT ++# celestia-core + +-[Byzantine-Fault Tolerant][bft] [State Machine Replication][smr]. Or +-[Blockchain], for short. ++[![Go Reference](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/celestiaorg/celestia-core) ++[![GitHub Release](https://img.shields.io/github/v/release/celestiaorg/celestia-core)](https://github.com/celestiaorg/celestia-core/releases/latest) ++[![Go Report Card](https://goreportcard.com/badge/github.com/celestiaorg/celestia-core)](https://goreportcard.com/report/github.com/celestiaorg/celestia-core) ++[![Lint](https://github.com/celestiaorg/celestia-core/actions/workflows/lint.yml/badge.svg)](https://github.com/celestiaorg/celestia-core/actions/workflows/lint.yml) ++[![Tests](https://github.com/celestiaorg/celestia-core/actions/workflows/tests.yml/badge.svg)](https://github.com/celestiaorg/celestia-core/actions/workflows/tests.yml) + +-[![Version][version-badge]][version-url] +-[![API Reference][api-badge]][api-url] +-[![Go version][go-badge]][go-url] +-[![Discord chat][discord-badge]][discord-url] +-[![License][license-badge]][license-url] +-[![Sourcegraph][sg-badge]][sg-url] ++celestia-core is a fork of [cometbft/cometbft](https://github.com/cometbft/cometbft), an implementation of the Tendermint protocol, with the following changes: + +-| Branch | Tests | Linting | +-|---------|------------------------------------------|---------------------------------------| +-| main | [![Tests][tests-badge]][tests-url] | [![Lint][lint-badge]][lint-url] | +-| v0.37.x | [![Tests][tests-badge-v037x]][tests-url] | [![Lint][lint-badge-v037x]][lint-url] | +-| v0.34.x | [![Tests][tests-badge-v034x]][tests-url] | [![Lint][lint-badge-v034x]][lint-url] | ++1. Early adoption of the ABCI++ methods: `PrepareProposal` and `ProcessProposal` because they haven't yet landed in a CometBFT release. ++1. Modifications to how `DataHash` in the block header is determined. In CometBFT, `DataHash` is based on the transactions included in a block. In Celestia, block data (including transactions) are erasure coded into a data square to enable data availability sampling. In order for the header to contain a commitment to this data square, `DataHash` was modified to be the Merkle root of the row and column roots of the erasure coded data square. See [ADR 008](https://github.com/celestiaorg/celestia-core/blob/v0.34.x-celestia/docs/celestia-architecture/adr-008-updating-to-tendermint-v0.35.x.md?plain=1#L20) for the motivation or [celestia-app/pkg/da/data_availability_header.go](https://github.com/celestiaorg/celestia-app/blob/2f89956b22c4c3cfdec19b3b8601095af6f69804/pkg/da/data_availability_header.go) for the implementation. Note on the implementation: celestia-app computes the hash in prepare_proposal and returns it to CometBFT via [`blockData.Hash`](https://github.com/celestiaorg/celestia-app/blob/5bbdac2d3f46662a34b2111602b8f964d6e6fba5/app/prepare_proposal.go#L78) so a modification to celestia-core isn't strictly necessary but [comments](https://github.com/celestiaorg/celestia-core/blob/2ec23f804691afc196d0104616e6c880d4c1ca41/types/block.go#L1041-L1042) were added. + +-CometBFT is a Byzantine Fault Tolerant (BFT) middleware that takes a +-state transition machine - written in any programming language - and securely +-replicates it on many machines. + +-It is a fork of [Tendermint Core][tm-core] and implements the Tendermint +-consensus algorithm. ++See [./docs/celestia-architecture](./docs/celestia-architecture/) for architecture decision records (ADRs) on Celestia modifications. + +-For protocol details, refer to the [CometBFT Specification](./spec/README.md). ++## Diagram + +-For detailed analysis of the consensus protocol, including safety and liveness +-proofs, read our paper, "[The latest gossip on BFT +-consensus](https://arxiv.org/abs/1807.04938)". ++```ascii ++ ^ +-------------------------------+ ^ ++ | | | | ++ | | State-machine = Application | | ++ | | | | celestia-app (built with Cosmos SDK) ++ | | ^ + | | ++ | +----------- | ABCI | ----------+ v ++Celestia | | + v | ^ ++validator or | | | | ++full consensus | | Consensus | | ++node | | | | ++ | +-------------------------------+ | celestia-core (fork of CometBFT) ++ | | | | ++ | | Networking | | ++ | | | | ++ v +-------------------------------+ v ++``` + +-## Documentation ++## Install + +-Complete documentation can be found on the +-[website](https://docs.cometbft.com/). ++See + +-## Releases ++## Usage + +-Please do not depend on `main` as your production branch. Use +-[releases](https://github.com/cometbft/cometbft/releases) instead. ++See + +-If you intend to run CometBFT in production, we're happy to help. To contact +-us, in order of preference: +- +-- [Create a new discussion on +- GitHub](https://github.com/cometbft/cometbft/discussions) +-- Reach out to us via [Telegram](https://t.me/CometBFT) +-- [Join the Cosmos Network Discord](https://discord.gg/cosmosnetwork) and +- discuss in +- [`#cometbft`](https://discord.com/channels/669268347736686612/1069933855307472906) +- +-More on how releases are conducted can be found [here](./RELEASES.md). +- +-## Security ++## Contributing + +-To report a security vulnerability, see our [bug bounty +-program](https://hackerone.com/cosmos). For examples of the kinds of bugs we're +-looking for, see [our security policy](SECURITY.md). ++This repo intends on preserving the minimal possible diff with [cometbft/cometbft](https://github.com/cometbft/cometbft) to make fetching upstream changes easy. If the proposed contribution is + +-## Minimum requirements ++- **specific to Celestia**: consider if [celestia-app](https://github.com/celestiaorg/celestia-app) is a better target ++- **not specific to Celestia**: consider making the contribution upstream in CometBFT + +-| Requirement | Notes | +-|-------------|-------------------| +-| Go version | Go 1.21 or higher | ++1. [Install Go](https://go.dev/doc/install) 1.23.1+ ++2. Fork this repo ++3. Clone your fork ++4. Find an issue to work on (see [good first issues](https://github.com/celestiaorg/celestia-core/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22)) ++5. Work on a change in a branch on your fork ++6. When your change is ready, push your branch and create a PR that targets this repo + +-### Install ++### Helpful Commands + +-See the [install instructions](./docs/introduction/install.md). ++```sh ++# Build a new CometBFT binary and output to build/comet ++make build + +-### Quick Start ++# Install CometBFT binary ++make install + +-- [Single node](./docs/introduction/quick-start.md) +-- [Local cluster using docker-compose](./docs/networks/docker-compose.md) ++# Run tests ++make test + +-## Contributing ++# If you modified any protobuf definitions in a `*.proto` file then ++# you may need to lint, format, and generate updated `*.pb.go` files ++make proto-lint ++make proto-format ++make proto-gen ++``` + +-Please abide by the [Code of Conduct](CODE_OF_CONDUCT.md) in all interactions. ++## Branches + +-Before contributing to the project, please take a look at the [contributing +-guidelines](CONTRIBUTING.md) and the [style guide](STYLE_GUIDE.md). You may also +-find it helpful to read the [specifications](./spec/README.md), and familiarize +-yourself with our [Architectural Decision Records +-(ADRs)](./docs/architecture/README.md) and [Request For Comments +-(RFCs)](./docs/rfc/README.md). ++The canonical branches in this repo are based on CometBFT releases. For example: [`v0.34.x-celestia`](https://github.com/celestiaorg/celestia-core/tree/v0.34.x-celestia) is based on the CometBFT `v0.34.x` release branch and contains Celestia-specific changes. + + ## Versioning + +-### Semantic Versioning +- +-CometBFT uses [Semantic Versioning](http://semver.org/) to determine when and +-how the version changes. According to SemVer, anything in the public API can +-change at any time before version 1.0.0 +- +-To provide some stability to users of 0.X.X versions of CometBFT, the MINOR +-version is used to signal breaking changes across CometBFT's API. This API +-includes all publicly exposed types, functions, and methods in non-internal Go +-packages as well as the types and methods accessible via the CometBFT RPC +-interface. +- +-Breaking changes to these public APIs will be documented in the CHANGELOG. +- +-### Upgrades +- +-In an effort to avoid accumulating technical debt prior to 1.0.0, we do not +-guarantee that breaking changes (i.e. bumps in the MINOR version) will work with +-existing CometBFT blockchains. In these cases you will have to start a new +-blockchain, or write something custom to get the old data into the new chain. +-However, any bump in the PATCH version should be compatible with existing +-blockchain histories. +- +-For more information on upgrading, see [UPGRADING.md](./UPGRADING.md). +- +-### Supported Versions +- +-Because we are a small core team, we have limited capacity to ship patch +-updates, including security updates. Consequently, we strongly recommend keeping +-CometBFT up-to-date. Upgrading instructions can be found in +-[UPGRADING.md](./UPGRADING.md). +- +-Currently supported versions include: +- +-- v0.34.x: The CometBFT v0.34 series is compatible with the Tendermint Core +- v0.34 series +-- v0.37.x: (release candidate) +- +-## Resources +- +-### Libraries +- +-- [Cosmos SDK](http://github.com/cosmos/cosmos-sdk); A framework for building +- applications in Golang +-- [Tendermint in Rust](https://github.com/informalsystems/tendermint-rs) +-- [ABCI Tower](https://github.com/penumbra-zone/tower-abci) +- +-### Applications +- +-- [Cosmos Hub](https://hub.cosmos.network/) +-- [Terra](https://www.terra.money/) +-- [Celestia](https://celestia.org/) +-- [Anoma](https://anoma.network/) +-- [Vocdoni](https://docs.vocdoni.io/) +- +-### Research +- +-Below are links to the original Tendermint consensus algorithm and relevant +-whitepapers which CosmosBFT will continue to build on. +- +-- [The latest gossip on BFT consensus](https://arxiv.org/abs/1807.04938) +-- [Master's Thesis on Tendermint](https://atrium.lib.uoguelph.ca/xmlui/handle/10214/9769) +-- [Original Whitepaper: "Tendermint: Consensus Without Mining"](https://tendermint.com/static/docs/tendermint.pdf) +- +-## Join us +- +-CometBFT is currently maintained by [Informal +-Systems](https://informal.systems). If you'd like to work full-time on CometBFT, +-[we're hiring](https://informal.systems/careers)! +- +-Funding for CometBFT development comes primarily from the [Interchain +-Foundation](https://interchain.io), a Swiss non-profit. Informal Systems also +-maintains [cometbft.com](https://cometbft.com). +- +-[bft]: https://en.wikipedia.org/wiki/Byzantine_fault_tolerance +-[smr]: https://en.wikipedia.org/wiki/State_machine_replication +-[Blockchain]: https://en.wikipedia.org/wiki/Blockchain +-[version-badge]: https://img.shields.io/github/v/release/cometbft/cometbft.svg +-[version-url]: https://github.com/cometbft/cometbft/releases/latest +-[api-badge]: https://camo.githubusercontent.com/915b7be44ada53c290eb157634330494ebe3e30a/68747470733a2f2f676f646f632e6f72672f6769746875622e636f6d2f676f6c616e672f6764646f3f7374617475732e737667 +-[api-url]: https://pkg.go.dev/github.com/cometbft/cometbft +-[go-badge]: https://img.shields.io/badge/go-1.19-blue.svg +-[go-url]: https://github.com/moovweb/gvm +-[discord-badge]: https://img.shields.io/discord/669268347736686612.svg +-[discord-url]: https://discord.gg/cosmosnetwork +-[license-badge]: https://img.shields.io/github/license/cometbft/cometbft.svg +-[license-url]: https://github.com/cometbft/cometbft/blob/main/LICENSE +-[sg-badge]: https://sourcegraph.com/github.com/cometbft/cometbft/-/badge.svg +-[sg-url]: https://sourcegraph.com/github.com/cometbft/cometbft?badge +-[tests-url]: https://github.com/cometbft/cometbft/actions/workflows/tests.yml +-[tests-badge]: https://github.com/cometbft/cometbft/actions/workflows/tests.yml/badge.svg?branch=main +-[tests-badge-v037x]: https://github.com/cometbft/cometbft/actions/workflows/tests.yml/badge.svg?branch=v0.37.x +-[tests-badge-v034x]: https://github.com/cometbft/cometbft/actions/workflows/tests.yml/badge.svg?branch=v0.34.x +-[lint-badge]: https://github.com/cometbft/cometbft/actions/workflows/lint.yml/badge.svg?branch=main +-[lint-badge-v034x]: https://github.com/cometbft/cometbft/actions/workflows/lint.yml/badge.svg?branch=v0.34.x +-[lint-badge-v037x]: https://github.com/cometbft/cometbft/actions/workflows/lint.yml/badge.svg?branch=v0.37.x +-[lint-url]: https://github.com/cometbft/cometbft/actions/workflows/lint.yml +-[tm-core]: https://github.com/tendermint/tendermint ++Releases are formatted: `v-tm-v` ++For example: [`v1.4.0-tm-v0.34.20`](https://github.com/celestiaorg/celestia-core/releases/tag/v1.4.0-tm-v0.34.20) is celestia-core version `1.4.0` based on CometBFT `0.34.20`. ++`CELESTIA_CORE_VERSION` strives to adhere to [Semantic Versioning](http://semver.org/). diff --git a/patches/SECURITY.md.patch b/patches/SECURITY.md.patch new file mode 100644 index 00000000000..c1a5ff168fd --- /dev/null +++ b/patches/SECURITY.md.patch @@ -0,0 +1,39 @@ +diff --git a/SECURITY.md b/SECURITY.md +deleted file mode 100644 +index 2a5c56664..000000000 +--- a/SECURITY.md ++++ /dev/null +@@ -1,33 +0,0 @@ +-# How to Report a Security Bug +- +-If you believe you have found a security vulnerability in the Interchain Stack, +-you can report it to our primary vulnerability disclosure channel, the [Cosmos +-HackerOne Bug Bounty program][h1]. +- +-If you prefer to report an issue via email, you may send a bug report to +- with the issue details, reproduction, impact, and other +-information. Please submit only one unique email thread per vulnerability. Any +-issues reported via email are ineligible for bounty rewards. +- +-Artifacts from an email report are saved at the time the email is triaged. +-Please note: our team is not able to monitor dynamic content (e.g. a Google Docs +-link that is edited after receipt) throughout the lifecycle of a report. If you +-would like to share additional information or modify previous information, +-please include it in an additional reply as an additional attachment. +- +-Please **DO NOT** file a public issue in this repository to report a security +-vulnerability. +- +-## Coordinated Vulnerability Disclosure Policy and Safe Harbor +- +-For the most up-to-date version of the policies that govern vulnerability +-disclosure, please consult the [HackerOne program page][h1-policy]. +- +-The policy hosted on HackerOne is the official Coordinated Vulnerability +-Disclosure policy and Safe Harbor for the Interchain Stack, and the teams and +-infrastructure it supports, and it supersedes previous security policies that +-have been used in the past by individual teams and projects with targets in +-scope of the program. +- +-[h1]: https://hackerone.com/cosmos?type=team +-[h1-policy]: https://hackerone.com/cosmos?type=team&view_policy=true diff --git a/patches/STYLE_GUIDE.md.patch b/patches/STYLE_GUIDE.md.patch new file mode 100644 index 00000000000..96b57b22f11 --- /dev/null +++ b/patches/STYLE_GUIDE.md.patch @@ -0,0 +1,168 @@ +diff --git a/STYLE_GUIDE.md b/STYLE_GUIDE.md +deleted file mode 100644 +index 5eeceb6c8..000000000 +--- a/STYLE_GUIDE.md ++++ /dev/null +@@ -1,162 +0,0 @@ +-# Go Coding Style Guide +- +-In order to keep our code looking good with lots of programmers working on it, it helps to have a "style guide", so all +-the code generally looks quite similar. This doesn't mean there is only one "right way" to write code, or even that this +-standard is better than your style. But if we agree to a number of stylistic practices, it makes it much easier to read +-and modify new code. Please feel free to make suggestions if there's something you would like to add or modify. +- +-We expect all contributors to be familiar with [Effective Go](https://golang.org/doc/effective_go.html) +-(and it's recommended reading for all Go programmers anyways). Additionally, we generally agree with the suggestions +- in [Uber's style guide](https://github.com/uber-go/guide/blob/master/style.md) and use that as a starting point. +- +- +-## Code Structure +- +-Perhaps more key for code readability than good commenting is having the right structure. As a rule of thumb, try to write +-in a logical order of importance, taking a little time to think how to order and divide the code such that someone could +-scroll down and understand the functionality of it just as well as you do. A loose example of such order would be: +- +-* Constants, global and package-level variables +-* Main Struct +-* Options (only if they are seen as critical to the struct else they should be placed in another file) +-* Initialization / Start and stop of the service +-* Msgs/Events +-* Public Functions (In order of most important) +-* Private/helper functions +-* Auxiliary structs and function (can also be above private functions or in a separate file) +- +-## General +- +-* Use `gofmt` (or `goimport`) to format all code upon saving it. (If you use VIM, check out vim-go). +-* Use a linter (see below) and generally try to keep the linter happy (where it makes sense). +-* Think about documentation, and try to leave godoc comments, when it will help new developers. +-* Every package should have a high level doc.go file to describe the purpose of that package, its main functions, and any other relevant information. +-* `TODO` should not be used. If important enough should be recorded as an issue. +-* `BUG` / `FIXME` should be used sparingly to guide future developers on some of the vulnerabilities of the code. +-* `XXX` can be used in work-in-progress (prefixed with "WIP:" on github) branches but they must be removed before approving a PR. +-* Applications (e.g. clis/servers) *should* panic on unexpected unrecoverable errors and print a stack trace. +- +-## Comments +- +-* Use a space after comment deliminter (ex. `// your comment`). +-* Many comments are not sentences. These should begin with a lower case letter and end without a period. +-* Conversely, sentences in comments should be sentenced-cased and end with a period. +- +-## Linters +- +-These must be applied to all (Go) repos. +- +-* [shellcheck](https://github.com/koalaman/shellcheck) +-* [golangci-lint](https://github.com/golangci/golangci-lint) (covers all important linters) +- * See the `.golangci.yml` file in each repo for linter configuration. +- +-## Various +- +-* Reserve "Save" and "Load" for long-running persistence operations. When parsing bytes, use "Encode" or "Decode". +-* Maintain consistency across the codebase. +-* Functions that return functions should have the suffix `Fn` +-* Names should not [stutter](https://blog.golang.org/package-names). For example, a struct generally shouldn’t have +- a field named after itself; e.g., this shouldn't occur: +- +-``` golang +-type middleware struct { +- middleware Middleware +-} +-``` +- +-* In comments, use "iff" to mean, "if and only if". +-* Product names are capitalized, like "CometBFT", "Basecoin", "Protobuf", etc except in command lines: `cometbft --help` +-* Acronyms are all capitalized, like "RPC", "gRPC", "API". "MyID", rather than "MyId". +-* Prefer errors.New() instead of fmt.Errorf() unless you're actually using the format feature with arguments. +- +-## Importing Libraries +- +-Sometimes it's necessary to rename libraries to avoid naming collisions or ambiguity. +- +-* Use [goimports](https://godoc.org/golang.org/x/tools/cmd/goimports) +-* Separate imports into blocks - one for the standard lib, one for external libs and one for application libs. +-* Here are some common library labels for consistency: +- * dbm "github.com/cometbft/cometbft-db" +- * cmtcmd "github.com/cometbft/cometbft/cmd/cometbft/commands" +- * cmtcfg "github.com/cometbft/cometbft/config" +- * cmttypes "github.com/cometbft/cometbft/types" +-* Never use anonymous imports (the `.`), for example, `cmtlibs/common` or anything else. +-* When importing a pkg from the `cmt/libs` directory, prefix the pkg alias with cmt. +- * cmtbits "github.com/cometbft/cometbft/libs/bits" +-* tip: Use the `_` library import to import a library for initialization effects (side effects) +- +-## Dependencies +- +-* Dependencies should be pinned by a release tag, or specific commit, to avoid breaking `go get` when external dependencies are updated. +-* Refer to the [contributing](CONTRIBUTING.md) document for more details +- +-## Testing +- +-* The first rule of testing is: we add tests to our code +-* The second rule of testing is: we add tests to our code +-* For Golang testing: +- * Make use of table driven testing where possible and not-cumbersome +- * [Inspiration](https://dave.cheney.net/2013/06/09/writing-table-driven-tests-in-go) +- * Make use of [assert](https://godoc.org/github.com/stretchr/testify/assert) and [require](https://godoc.org/github.com/stretchr/testify/require) +-* When using mocks, it is recommended to use Testify [mock]( +- ) along with [Mockery](https://github.com/vektra/mockery) for autogeneration +- +-## Errors +- +-* Ensure that errors are concise, clear and traceable. +-* Use stdlib errors package. +-* For wrapping errors, use `fmt.Errorf()` with `%w`. +-* Panic is appropriate when an internal invariant of a system is broken, while all other cases (in particular, +- incorrect or invalid usage) should return errors. +- +-## Config +- +-* Currently the TOML filetype is being used for config files +-* A good practice is to store per-user config files under `~/.[yourAppName]/config.toml` +- +-## CLI +- +-* When implementing a CLI use [Cobra](https://github.com/spf13/cobra) and [Viper](https://github.com/spf13/viper). +-* Helper messages for commands and flags must be all lowercase. +-* Instead of using pointer flags (eg. `FlagSet().StringVar`) use Viper to retrieve flag values (eg. `viper.GetString`) +- * The flag key used when setting and getting the flag should always be stored in a +- variable taking the form `FlagXxx` or `flagXxx`. +- * Flag short variable descriptions should always start with a lower case character as to remain consistent with +- the description provided in the default `--help` flag. +- +-## Version +- +-* Every repo should have a version/version.go file that mimics the CometBFT repo +-* We read the value of the constant version in our build scripts and hence it has to be a string +- +-## Non-Go Code +- +-* All non-Go code (`*.proto`, `Makefile`, `*.sh`), where there is no common +- agreement on style, should be formatted according to +- [EditorConfig](http://editorconfig.org/) config: +- +- ```toml +- # top-most EditorConfig file +- root = true +- +- # Unix-style newlines with a newline ending every file +- [*] +- charset = utf-8 +- end_of_line = lf +- insert_final_newline = true +- trim_trailing_whitespace = true +- +- [Makefile] +- indent_style = tab +- +- [*.sh] +- indent_style = tab +- +- [*.proto] +- indent_style = space +- indent_size = 2 +- ``` +- +- Make sure the file above (`.editorconfig`) are in the root directory of your +- repo and you have a [plugin for your +- editor](http://editorconfig.org/#download) installed. diff --git a/patches/UPGRADING.md.patch b/patches/UPGRADING.md.patch new file mode 100644 index 00000000000..e84fac8076c --- /dev/null +++ b/patches/UPGRADING.md.patch @@ -0,0 +1,84 @@ +diff --git a/UPGRADING.md b/UPGRADING.md +deleted file mode 100644 +index f2cae6ead..000000000 +--- a/UPGRADING.md ++++ /dev/null +@@ -1,78 +0,0 @@ +-# Upgrading CometBFT +- +-This guide provides instructions for upgrading to specific versions of CometBFT. +- +-## v0.34.33 +- +-It is recommended that CometBFT be built with Go v1.21+ since v1.20 is no longer +-supported. +- +-## v0.34.29 +- +-It is recommended that CometBFT be built with Go v1.20+ since v1.19 is no longer +-supported. +- +-## v0.34.28 +- +-For users explicitly making use of the Go APIs provided in the `crypto/merkle` +-package, please note that, in order to fix a potential security issue, we had to +-make a breaking change here. This change should only affect a small minority of +-users. For more details, please see +-[\#557](https://github.com/cometbft/cometbft/issues/557). +- +-## v0.34.27 +- +-This is the first official release of CometBFT, forked originally from +-[Tendermint Core v0.34.24][v03424] and subsequently updated in Informal Systems' +-public fork of Tendermint Core for [v0.34.25][v03425] and [v0.34.26][v03426]. +- +-### Upgrading from Tendermint Core +- +-If you already make use of Tendermint Core (either the original Tendermint Core +-v0.34.24, or Informal Systems' public fork), you can upgrade to CometBFT +-v0.34.27 by replacing your dependency in your `go.mod` file: +- +-```bash +-go mod edit -replace github.com/tendermint/tendermint=github.com/cometbft/cometbft@v0.34.27 +-``` +- +-We make use of the original module URL in order to minimize the impact of +-switching to CometBFT. This is only possible in our v0.34 release series, and we +-will be switching our module URL to `github.com/cometbft/cometbft` in the next +-major release. +- +-### Home directory +- +-CometBFT, by default, will consider its home directory in `~/.cometbft` from now +-on instead of `~/.tendermint`. +- +-### Environment variables +- +-The environment variable prefixes have now changed from `TM` to `CMT`. For +-example, `TMHOME` or `TM_HOME` become `CMTHOME` or `CMT_HOME`. +- +-We have implemented a fallback check in case `TMHOME` is still set and `CMTHOME` +-is not, but you will start to see a warning message in the logs if the old +-`TMHOME` variable is set. This fallback check will be removed entirely in a +-subsequent major release of CometBFT. +- +-### Building CometBFT +- +-CometBFT must be compiled using Go 1.19 or higher. The use of Go 1.18 is not +-supported, since this version has reached end-of-life with the release of [Go 1.20][go120]. +- +-### Troubleshooting +- +-If you run into any trouble with this upgrade, please [contact us][discussions]. +- +---- +- +-For historical upgrading instructions for Tendermint Core v0.34.24 and earlier, +-please see the [Tendermint Core upgrading instructions][tmupgrade]. +- +-[v03424]: https://github.com/tendermint/tendermint/releases/tag/v0.34.24 +-[v03425]: https://github.com/informalsystems/tendermint/releases/tag/v0.34.25 +-[v03426]: https://github.com/informalsystems/tendermint/releases/tag/v0.34.26 +-[discussions]: https://github.com/cometbft/cometbft/discussions +-[tmupgrade]: https://github.com/tendermint/tendermint/blob/35581cf54ec436b8c37fabb43fdaa3f48339a170/UPGRADING.md +-[go120]: https://go.dev/blog/go1.20 diff --git a/patches/abci/README.md.patch b/patches/abci/README.md.patch new file mode 100644 index 00000000000..9893edf51d0 --- /dev/null +++ b/patches/abci/README.md.patch @@ -0,0 +1,13 @@ +diff --git a/abci/README.md b/abci/README.md +index b9e7268d8..1f8c37809 100644 +--- a/abci/README.md ++++ b/abci/README.md +@@ -19,7 +19,7 @@ To get up and running quickly, see the [getting started guide](../docs/app-dev/g + A detailed description of the ABCI methods and message types is contained in: + + - [The main spec](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/abci/README.md) +-- [A protobuf file](./types/types.proto) ++- [A protobuf file](../proto/abci/types.proto) + - [A Go interface](./types/application.go) + + ## Protocol Buffers diff --git a/patches/buf.work.yaml.patch b/patches/buf.work.yaml.patch new file mode 100644 index 00000000000..959f228ea4b --- /dev/null +++ b/patches/buf.work.yaml.patch @@ -0,0 +1,9 @@ +diff --git a/buf.work.yaml b/buf.work.yaml +deleted file mode 100644 +index 1878b341b..000000000 +--- a/buf.work.yaml ++++ /dev/null +@@ -1,3 +0,0 @@ +-version: v1 +-directories: +- - proto diff --git a/patches/buf.yaml.patch b/patches/buf.yaml.patch new file mode 100644 index 00000000000..dcee6fe6185 --- /dev/null +++ b/patches/buf.yaml.patch @@ -0,0 +1,19 @@ +diff --git a/buf.yaml b/buf.yaml +index d21611209..71cf9ca18 100644 +--- a/buf.yaml ++++ b/buf.yaml +@@ -1,3 +1,5 @@ ++version: v1beta1 ++ + build: + roots: + - proto +@@ -7,6 +9,8 @@ lint: + - BASIC + - FILE_LOWER_SNAKE_CASE + - UNARY_RPC ++ except: ++ - RPC_NO_SERVER_STREAMING + ignore: + - gogoproto + breaking: diff --git a/patches/crypto/merkle/README.md.patch b/patches/crypto/merkle/README.md.patch new file mode 100644 index 00000000000..897a4b1ebc5 --- /dev/null +++ b/patches/crypto/merkle/README.md.patch @@ -0,0 +1,12 @@ +diff --git a/crypto/merkle/README.md b/crypto/merkle/README.md +index 16b1abb58..299f50dc7 100644 +--- a/crypto/merkle/README.md ++++ b/crypto/merkle/README.md +@@ -1,4 +1,5 @@ + # Merkle Tree + +-For smaller static data structures that don't require immutable snapshots or mutability; +-for instance the transactions and validation signatures of a block can be hashed using this simple merkle tree logic. ++For smaller static data structures that don't require immutable snapshots or mutability. ++ ++For instance, the transactions and validation signatures of a block can be hashed using this simple merkle tree logic. diff --git a/patches/docs/DOCS_README.md.patch b/patches/docs/DOCS_README.md.patch new file mode 100644 index 00000000000..ea83d1fdf91 --- /dev/null +++ b/patches/docs/DOCS_README.md.patch @@ -0,0 +1,20 @@ +diff --git a/docs/DOCS_README.md b/docs/DOCS_README.md +deleted file mode 100644 +index af686162e..000000000 +--- a/docs/DOCS_README.md ++++ /dev/null +@@ -1,14 +0,0 @@ +-# Docs Build Workflow +- +-The documentation for CometBFT is hosted at: +- +-- +- +-built from the files in these (`/docs` and `/spec`) directories. +- +-Content modified and merged to these folders will be deployed to the `https://docs.cometbft.com` website using workflow logic from the [cometbft-docs](https://github.com/cometbft/cometbft-docs) repository +- +-### Building locally +- +-For information on how to build the documentation and view it locally, please visit the [cometbft-docs](https://github.com/cometbft/cometbft-docs) Github repository. +- diff --git a/patches/docs/README.md.patch b/patches/docs/README.md.patch new file mode 100644 index 00000000000..576ebc4df6f --- /dev/null +++ b/patches/docs/README.md.patch @@ -0,0 +1,54 @@ +diff --git a/docs/README.md b/docs/README.md +deleted file mode 100644 +index cc36e176f..000000000 +--- a/docs/README.md ++++ /dev/null +@@ -1,48 +0,0 @@ +---- +-title: CometBFT Documentation +-description: CometBFT is a blockchain application platform. +-footer: +- newsletter: false +---- +- +-# CometBFT +- +-Welcome to the CometBFT documentation! +- +-CometBFT is a blockchain application platform; it provides the equivalent +-of a web-server, database, and supporting libraries for blockchain applications +-written in any programming language. Like a web-server serving web applications, +-CometBFT serves blockchain applications. +- +-More formally, CometBFT performs Byzantine Fault Tolerant (BFT) +-State Machine Replication (SMR) for arbitrary deterministic, finite state machines. +-For more background, see [What is CometBFT?](introduction/README.md#what-is-cometbft). +- +-To get started quickly with an example application, see the [quick start guide](guides/quick-start.md). +- +-To upgrade from Tendermint Core v0.34.x to CometBFT v0.34.x, please see our +-[upgrading instructions](./guides/upgrading-from-tm.md). +- +-To learn about application development on CometBFT, see the +-[Application Blockchain Interface](https://github.com/cometbft/cometbft/tree/v0.34.x/spec/abci). +- +-For more details on using CometBFT, see the respective documentation for +-[CometBFT internals](core/), [benchmarking and monitoring](tools/), and +-[network deployments](networks/). +- +-## Contribute +- +-To recommend a change to the documentation, please submit a PR. Each major +-release's documentation is housed on the corresponding release branch, e.g. for +-the v0.34 release series, the documentation is housed on the `v0.34.x` branch. +- +-When submitting changes that affect all releases, please start by submitting a +-PR to the docs on `main` - this will be backported to the relevant release +-branches. If a change is exclusively relevant to a specific release, please +-target that release branch with your PR. +- +-Changes to the documentation will be reviewed by the team and, if accepted and +-merged, published to for the respective version(s). +- +-The build process for the documentation is housed in the +-[CometBFT documentation repository](https://github.com/cometbft/cometbft-docs). diff --git a/patches/docs/app-dev/README.md.patch b/patches/docs/app-dev/README.md.patch new file mode 100644 index 00000000000..562e71d7eb7 --- /dev/null +++ b/patches/docs/app-dev/README.md.patch @@ -0,0 +1,18 @@ +diff --git a/docs/app-dev/README.md b/docs/app-dev/README.md +deleted file mode 100644 +index aff0a570c..000000000 +--- a/docs/app-dev/README.md ++++ /dev/null +@@ -1,12 +0,0 @@ +---- +-order: false +-parent: +- order: 3 +---- +- +-# Apps +- +-- [Using ABCI-CLI](./abci-cli.md) +-- [Getting Started](./getting-started.md) +-- [Indexing transactions](./indexing-transactions.md) +-- [Application Architecture Guide](./app-architecture.md) diff --git a/patches/docs/app-dev/abci-cli.md.patch b/patches/docs/app-dev/abci-cli.md.patch new file mode 100644 index 00000000000..c8fdd4895e1 --- /dev/null +++ b/patches/docs/app-dev/abci-cli.md.patch @@ -0,0 +1,235 @@ +diff --git a/docs/app-dev/abci-cli.md b/docs/app-dev/abci-cli.md +deleted file mode 100644 +index 255b056e2..000000000 +--- a/docs/app-dev/abci-cli.md ++++ /dev/null +@@ -1,229 +0,0 @@ +---- +-order: 2 +---- +- +-# Using ABCI-CLI +- +-To facilitate testing and debugging of ABCI servers and simple apps, we +-built a CLI, the `abci-cli`, for sending ABCI messages from the command +-line. +- +-## Install +- +-Make sure you [have Go installed](https://golang.org/doc/install). +- +-Next, install the `abci-cli` tool and example applications: +- +-```sh +-git clone https://github.com/cometbft/cometbft.git +-cd cometbft +-make install_abci +-``` +- +-Now run `abci-cli` to see the list of commands: +- +-```sh +-Usage: +- abci-cli [command] +- +-Available Commands: +- batch Run a batch of abci commands against an application +- check_tx Validate a tx +- commit Commit the application state and return the Merkle root hash +- console Start an interactive abci console for multiple commands +- counter ABCI demo example +- deliver_tx Deliver a new tx to the application +- kvstore ABCI demo example +- echo Have the application echo a message +- help Help about any command +- info Get some info about the application +- query Query the application state +- set_option Set an options on the application +- +-Flags: +- --abci string socket or grpc (default "socket") +- --address string address of application socket (default "tcp://127.0.0.1:26658") +- -h, --help help for abci-cli +- -v, --verbose print the command and results as if it were a console session +- +-Use "abci-cli [command] --help" for more information about a command. +-``` +- +-## KVStore - First Example +- +-The `abci-cli` tool lets us send ABCI messages to our application, to +-help build and debug them. +- +-The most important messages are `deliver_tx`, `check_tx`, and `commit`, +-but there are others for convenience, configuration, and information +-purposes. +- +-We'll start a kvstore application, which was installed at the same time +-as `abci-cli` above. The kvstore just stores transactions in a merkle +-tree. +- +-Its code can be found +-[here](https://github.com/cometbft/cometbft/blob/v0.34.x/abci/cmd/abci-cli/abci-cli.go) +-and looks like the following: +- +-```go +-func cmdKVStore(cmd *cobra.Command, args []string) error { +- logger := log.NewTMLogger(log.NewSyncWriter(os.Stdout)) +- +- // Create the application - in memory or persisted to disk +- var app types.Application +- if flagPersist == "" { +- app = kvstore.NewKVStoreApplication() +- } else { +- app = kvstore.NewPersistentKVStoreApplication(flagPersist) +- app.(*kvstore.PersistentKVStoreApplication).SetLogger(logger.With("module", "kvstore")) +- } +- +- // Start the listener +- srv, err := server.NewServer(flagAddrD, flagAbci, app) +- if err != nil { +- return err +- } +- srv.SetLogger(logger.With("module", "abci-server")) +- if err := srv.Start(); err != nil { +- return err +- } +- +- // Stop upon receiving SIGTERM or CTRL-C. +- tmos.TrapSignal(logger, func() { +- // Cleanup +- srv.Stop() +- }) +- +- // Run forever. +- select {} +-} +-``` +- +-Start the application by running: +- +-```sh +-abci-cli kvstore +-``` +- +-And in another terminal, run +- +-```sh +-abci-cli echo hello +-abci-cli info +-``` +- +-You'll see something like: +- +-```sh +--> data: hello +--> data.hex: 68656C6C6F +-``` +- +-and: +- +-```sh +--> data: {"size":0} +--> data.hex: 7B2273697A65223A307D +-``` +- +-An ABCI application must provide two things: +- +-- a socket server +-- a handler for ABCI messages +- +-When we run the `abci-cli` tool we open a new connection to the +-application's socket server, send the given ABCI message, and wait for a +-response. +- +-The server may be generic for a particular language, and we provide a +-[reference implementation in +-Golang](https://github.com/cometbft/cometbft/tree/v0.34.x/abci/server). See the +-[list of other ABCI implementations](https://github.com/tendermint/awesome#ecosystem) for servers in +-other languages. +- +-The handler is specific to the application, and may be arbitrary, so +-long as it is deterministic and conforms to the ABCI interface +-specification. +- +-So when we run `abci-cli info`, we open a new connection to the ABCI +-server, which calls the `Info()` method on the application, which tells +-us the number of transactions in our Merkle tree. +- +-Now, since every command opens a new connection, we provide the +-`abci-cli console` and `abci-cli batch` commands, to allow multiple ABCI +-messages to be sent over a single connection. +- +-Running `abci-cli console` should drop you in an interactive console for +-speaking ABCI messages to your application. +- +-Try running these commands: +- +-```sh +-> echo hello +--> code: OK +--> data: hello +--> data.hex: 0x68656C6C6F +- +-> info +--> code: OK +--> data: {"size":0} +--> data.hex: 0x7B2273697A65223A307D +- +-> commit +--> code: OK +--> data.hex: 0x0000000000000000 +- +-> deliver_tx "abc" +--> code: OK +- +-> info +--> code: OK +--> data: {"size":1} +--> data.hex: 0x7B2273697A65223A317D +- +-> commit +--> code: OK +--> data.hex: 0x0200000000000000 +- +-> query "abc" +--> code: OK +--> log: exists +--> height: 2 +--> value: abc +--> value.hex: 616263 +- +-> deliver_tx "def=xyz" +--> code: OK +- +-> commit +--> code: OK +--> data.hex: 0x0400000000000000 +- +-> query "def" +--> code: OK +--> log: exists +--> height: 3 +--> value: xyz +--> value.hex: 78797A +-``` +- +-Note that if we do `deliver_tx "abc"` it will store `(abc, abc)`, but if +-we do `deliver_tx "abc=efg"` it will store `(abc, efg)`. +- +-You could put the commands in a file and run +-`abci-cli --verbose batch < myfile`. +- +-Note that the `abci-cli` is designed strictly for testing and debugging. In a real +-deployment, the role of sending messages is taken by CometBFT, which +-connects to the app using three separate connections, each with its own +-pattern of messages. +- +-For examples of running an ABCI app with CometBFT, see the +-[getting started guide](./getting-started.md). +- +-## Bounties +- +-Want to write an app in your favorite language?! We'd be happy +-to help you out. See [funding](https://github.com/interchainio/funding) opportunities from the +-[Interchain Foundation](https://interchain.io) for implementations in new languages and more. diff --git a/patches/docs/app-dev/app-architecture.md.patch b/patches/docs/app-dev/app-architecture.md.patch new file mode 100644 index 00000000000..c72788acf85 --- /dev/null +++ b/patches/docs/app-dev/app-architecture.md.patch @@ -0,0 +1,61 @@ +diff --git a/docs/app-dev/app-architecture.md b/docs/app-dev/app-architecture.md +deleted file mode 100644 +index be4291640..000000000 +--- a/docs/app-dev/app-architecture.md ++++ /dev/null +@@ -1,55 +0,0 @@ +---- +-order: 3 +---- +- +-# Application Architecture Guide +- +-Here we provide a brief guide on the recommended architecture of a +-CometBFT blockchain application. +- +-We distinguish here between two forms of "application". The first is the +-end-user application, like a desktop-based wallet app that a user downloads, +-which is where the user actually interacts with the system. The other is the +-ABCI application, which is the logic that actually runs on the blockchain. +-Transactions sent by an end-user application are ultimately processed by the ABCI +-application after being committed by CometBFT. +- +-The end-user application communicates with a REST API exposed by the application. +-The application runs CometBFT nodes and verifies CometBFT light-client proofs +-through the CometBFT RPC. The CometBFT process communicates with +-a local ABCI application, where the user query or transaction is actually +-processed. +- +-The ABCI application must be a deterministic result of the consensus +-engine of CometBFT - any external influence on the application state that didn't +-come through CometBFT could cause a consensus failure. Thus _nothing_ +-should communicate with the ABCI application except CometBFT via ABCI. +- +-If the ABCI application is written in Go, it can be compiled into the +-CometBFT binary. Otherwise, it should use a unix socket to communicate +-with CometBFT. If it's necessary to use TCP, extra care must be taken +-to encrypt and authenticate the connection. +- +-All reads from the ABCI application happen through the CometBFT `/abci_query` +-endpoint. All writes to the ABCI application happen through the CometBFT +-`/broadcast_tx_*` endpoints. +- +-The Light-Client Daemon is what provides light clients (end users) with +-nearly all the security of a full node. It formats and broadcasts +-transactions, and verifies proofs of queries and transaction results. +-Note that it need not be a daemon - the Light-Client logic could instead +-be implemented in the same process as the end-user application. +- +-Note for those ABCI applications with weaker security requirements, the +-functionality of the Light-Client Daemon can be moved into the ABCI +-application process itself. That said, exposing the ABCI application process +-to anything besides CometBFT over ABCI requires extreme caution, as +-all transactions, and possibly all queries, should still pass through +-CometBFT. +- +-See the following for more extensive documentation: +- +-- [Interchain Standard for the Light-Client REST API](https://github.com/cosmos/cosmos-sdk/pull/1617) (legacy/deprecated) +-- [CometBFT RPC Docs](https://docs.cometbft.com/v0.34/rpc/) +-- [CometBFT in Production](../core/running-in-production.md) +-- [ABCI spec](https://github.com/cometbft/cometbft/tree/v0.34.x/spec/abci) diff --git a/patches/docs/app-dev/getting-started.md.patch b/patches/docs/app-dev/getting-started.md.patch new file mode 100644 index 00000000000..ee53aca612f --- /dev/null +++ b/patches/docs/app-dev/getting-started.md.patch @@ -0,0 +1,203 @@ +diff --git a/docs/app-dev/getting-started.md b/docs/app-dev/getting-started.md +deleted file mode 100644 +index 5473b3663..000000000 +--- a/docs/app-dev/getting-started.md ++++ /dev/null +@@ -1,197 +0,0 @@ +---- +-order: 1 +---- +- +-# Getting Started +- +-## First CometBFT App +- +-As a general purpose blockchain engine, CometBFT is agnostic to the +-application you want to run. So, to run a complete blockchain that does +-something useful, you must start two programs: one is CometBFT, +-the other is your application, which can be written in any programming +-language. Recall from [the intro to +-ABCI](../introduction/what-is-cometbft.md#abci-overview) that CometBFT +-handles all the p2p and consensus stuff, and just forwards transactions to the +-application when they need to be validated, or when they're ready to be +-executed and committed. +- +-In this guide, we show you some examples of how to run an application +-using CometBFT. +- +-### Install +- +-The first apps we will work with are written in Go. To install them, you +-need to [install Go](https://golang.org/doc/install), put +-`$GOPATH/bin` in your `$PATH` and enable go modules. If you use `bash`, +-follow these instructions: +- +-```bash +-echo export GOPATH=\"\$HOME/go\" >> ~/.bash_profile +-echo export PATH=\"\$PATH:\$GOPATH/bin\" >> ~/.bash_profile +-``` +- +-Then run +- +-```bash +-go get github.com/cometbft/cometbft +-cd $GOPATH/src/github.com/cometbft/cometbft +-make install_abci +-``` +- +-Now you should have the `abci-cli` installed; run `abci-cli` to see the list of commands: +- +-``` +-Usage: +- abci-cli [command] +- +-Available Commands: +- batch run a batch of abci commands against an application +- check_tx validate a transaction +- commit commit the application state and return the Merkle root hash +- completion Generate the autocompletion script for the specified shell +- console start an interactive ABCI console for multiple commands +- deliver_tx deliver a new transaction to the application +- echo have the application echo a message +- help Help about any command +- info get some info about the application +- kvstore ABCI demo example +- query query the application state +- test run integration tests +- version print ABCI console version +- +-Flags: +- --abci string either socket or grpc (default "socket") +- --address string address of application socket (default "tcp://0.0.0.0:26658") +- -h, --help help for abci-cli +- --log_level string set the logger level (default "debug") +- -v, --verbose print the command and results as if it were a console session +- +-Use "abci-cli [command] --help" for more information about a command. +-``` +- +-You'll notice the `kvstore` command, an example application written in Go. +- +-Now, let's run an app! +- +-## KVStore - A First Example +- +-The kvstore app is a [Merkle +-tree](https://en.wikipedia.org/wiki/Merkle_tree) that just stores all +-transactions. If the transaction contains an `=`, e.g. `key=value`, then +-the `value` is stored under the `key` in the Merkle tree. Otherwise, the +-full transaction bytes are stored as the key and the value. +- +-Let's start a kvstore application. +- +-```sh +-abci-cli kvstore +-``` +- +-In another terminal, we can start CometBFT. You should already have the +-CometBFT binary installed. If not, follow the steps from +-[here](../introduction/install.md). If you have never run CometBFT +-before, use: +- +-```sh +-cometbft init +-cometbft node +-``` +- +-If you have used CometBFT, you may want to reset the data for a new +-blockchain by running `cometbft unsafe-reset-all`. Then you can run +-`cometbft node` to start CometBFT, and connect to the app. For more +-details, see [the guide on using CometBFT](../core/using-cometbft.md). +- +-You should see CometBFT making blocks! We can get the status of our +-CometBFT node as follows: +- +-```sh +-curl -s localhost:26657/status +-``` +- +-The `-s` just silences `curl`. For nicer output, pipe the result into a +-tool like [jq](https://stedolan.github.io/jq/) or `json_pp`. +- +-Now let's send some transactions to the kvstore. +- +-```sh +-curl -s 'localhost:26657/broadcast_tx_commit?tx="abcd"' +-``` +- +-Note the single quote (`'`) around the url, which ensures that the +-double quotes (`"`) are not escaped by bash. This command sent a +-transaction with bytes `abcd`, so `abcd` will be stored as both the key +-and the value in the Merkle tree. The response should look something +-like: +- +-```json +-{ +- "jsonrpc": "2.0", +- "id": "", +- "result": { +- "check_tx": {}, +- "deliver_tx": { +- "tags": [ +- { +- "key": "YXBwLmNyZWF0b3I=", +- "value": "amFl" +- }, +- { +- "key": "YXBwLmtleQ==", +- "value": "YWJjZA==" +- } +- ] +- }, +- "hash": "9DF66553F98DE3C26E3C3317A3E4CED54F714E39", +- "height": 14 +- } +-} +-``` +- +-We can confirm that our transaction worked and the value got stored by +-querying the app: +- +-```sh +-curl -s 'localhost:26657/abci_query?data="abcd"' +-``` +- +-The result should look like: +- +-```json +-{ +- "jsonrpc": "2.0", +- "id": "", +- "result": { +- "response": { +- "log": "exists", +- "index": "-1", +- "key": "YWJjZA==", +- "value": "YWJjZA==" +- } +- } +-} +-``` +- +-Note the `value` in the result (`YWJjZA==`); this is the base64-encoding +-of the ASCII of `abcd`. You can verify this in a python 2 shell by +-running `"YWJjZA==".decode('base64')` or in python 3 shell by running +-`import codecs; codecs.decode(b"YWJjZA==", 'base64').decode('ascii')`. +-Stay tuned for a future release that [makes this output more +-human-readable](https://github.com/tendermint/tendermint/issues/1794). +- +-Now let's try setting a different key and value: +- +-```sh +-curl -s 'localhost:26657/broadcast_tx_commit?tx="name=satoshi"' +-``` +- +-Now if we query for `name`, we should get `satoshi`, or `c2F0b3NoaQ==` +-in base64: +- +-```sh +-curl -s 'localhost:26657/abci_query?data="name"' +-``` +- +-Try some other transactions and queries to make sure everything is +-working! diff --git a/patches/docs/app-dev/indexing-transactions.md.patch b/patches/docs/app-dev/indexing-transactions.md.patch new file mode 100644 index 00000000000..05809486c7b --- /dev/null +++ b/patches/docs/app-dev/indexing-transactions.md.patch @@ -0,0 +1,286 @@ +diff --git a/docs/app-dev/indexing-transactions.md b/docs/app-dev/indexing-transactions.md +deleted file mode 100644 +index 4d64e8ae0..000000000 +--- a/docs/app-dev/indexing-transactions.md ++++ /dev/null +@@ -1,280 +0,0 @@ +---- +-order: 6 +---- +- +-# Indexing Transactions +- +-CometBFT allows you to index transactions and blocks and later query or +-subscribe to their results. Transactions are indexed by `TxResult.Events` and +-blocks are indexed by `Response(Begin|End)Block.Events`. However, transactions +-are also indexed by a primary key which includes the transaction hash and maps +-to and stores the corresponding `TxResult`. Blocks are indexed by a primary key +-which includes the block height and maps to and stores the block height, i.e. +-the block itself is never stored. +- +-Each event contains a type and a list of attributes, which are key-value pairs +-denoting something about what happened during the method's execution. For more +-details on `Events`, see the +-[ABCI](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/abci/abci.md#events) +-documentation. +- +-An `Event` has a composite key associated with it. A `compositeKey` is +-constructed by its type and key separated by a dot. +- +-For example: +- +-```json +-"jack": [ +- "account.number": 100 +-] +-``` +- +-would be equal to the composite key of `jack.account.number`. +- +-By default, CometBFT will index all transactions by their respective hashes +-and height and blocks by their height. +- +-CometBFT allows for different events within the same height to have +-equal attributes. +- +-## Configuration +- +-Operators can configure indexing via the `[tx_index]` section. The `indexer` +-field takes a series of supported indexers. If `null` is included, indexing will +-be turned off regardless of other values provided. +- +-```toml +-[tx-index] +- +-# The backend database to back the indexer. +-# If indexer is "null", no indexer service will be used. +-# +-# The application will set which txs to index. In some cases a node operator will be able +-# to decide which txs to index based on configuration set in the application. +-# +-# Options: +-# 1) "null" +-# 2) "kv" (default) - the simplest possible indexer, backed by key-value storage (defaults to levelDB; see DBBackend). +-# - When "kv" is chosen "tx.height" and "tx.hash" will always be indexed. +-# 3) "psql" - the indexer services backed by PostgreSQL. +-# indexer = "kv" +-``` +- +-### Supported Indexers +- +-#### KV +- +-The `kv` indexer type is an embedded key-value store supported by the main +-underlying CometBFT database. Using the `kv` indexer type allows you to query +-for block and transaction events directly against CometBFT's RPC. However, the +-query syntax is limited and so this indexer type might be deprecated or removed +-entirely in the future. +- +-**Implementation and data layout** +- +-The kv indexer stores each attribute of an event individually, by creating a composite key +-of the *event type*, *attribute key*, *attribute value*, *height* and *event sequence*. +- +-For example the following events: +- +-``` +-Type: "transfer", +- Attributes: []abci.EventAttribute{ +- {Key: []byte("sender"), Value: []byte("Bob"), Index: true}, +- {Key: []byte("recipient"), Value: []byte("Alice"), Index: true}, +- {Key: []byte("balance"), Value: []byte("100"), Index: true}, +- {Key: []byte("note"), Value: []byte("nothing"), Index: true}, +- }, +- +-``` +- +-``` +-Type: "transfer", +- Attributes: []abci.EventAttribute{ +- {Key: []byte("sender"), Value: []byte("Tom"), Index: true}, +- {Key: []byte("recipient"), Value: []byte("Alice"), Index: true}, +- {Key: []byte("balance"), Value: []byte("200"), Index: true}, +- {Key: []byte("note"), Value: []byte("nothing"), Index: true}, +- }, +-``` +- +-will be represented as follows in the store: +- +-``` +-Key value +-transferSenderBobEndBlock1 1 +-transferRecipientAliceEndBlock11 1 +-transferBalance100EndBlock11 1 +-transferNodeNothingEndblock11 1 +----- event2 ------ +-transferSenderTomEndBlock12 1 +-transferRecipientAliceEndBlock12 1 +-transferBalance200EndBlock12 1 +-transferNodeNothingEndblock12 1 +- +-``` +-The key is thus formed of the event type, the attribute key and value, the event the attribute belongs to (`EndBlock` or `BeginBlock`), +-the height and the event number. The event number is a local variable kept by the indexer and incremented when a new event is processed. +- +-It is an `int64` variable and has no other semantics besides being used to associate attributes belonging to the same events within a height. +-This variable is not atomically incremented as event indexing is deterministic. **Should this ever change**, the event id generation +-will be broken. +- +-#### PostgreSQL +- +-The `psql` indexer type allows an operator to enable block and transaction event +-indexing by proxying it to an external PostgreSQL instance allowing for the events +-to be stored in relational models. Since the events are stored in a RDBMS, operators +-can leverage SQL to perform a series of rich and complex queries that are not +-supported by the `kv` indexer type. Since operators can leverage SQL directly, +-searching is not enabled for the `psql` indexer type via CometBFT's RPC -- any +-such query will fail. +- +-Note, the SQL schema is stored in `state/indexer/sink/psql/schema.sql` and operators +-must explicitly create the relations prior to starting CometBFT and enabling +-the `psql` indexer type. +- +-Example: +- +-```shell +-$ psql ... -f state/indexer/sink/psql/schema.sql +-``` +- +-## Default Indexes +- +-The CometBFT tx and block event indexer indexes a few select reserved events +-by default. +- +-### Transactions +- +-The following indexes are indexed by default: +- +-- `tx.height` +-- `tx.hash` +- +-### Blocks +- +-The following indexes are indexed by default: +- +-- `block.height` +- +-## Adding Events +- +-Applications are free to define which events to index. CometBFT does not +-expose functionality to define which events to index and which to ignore. In +-your application's `DeliverTx` method, add the `Events` field with pairs of +-UTF-8 encoded strings (e.g. "transfer.sender": "Bob", "transfer.recipient": +-"Alice", "transfer.balance": "100"). +- +-Example: +- +-```go +-func (app *KVStoreApplication) DeliverTx(req types.RequestDeliverTx) types.Result { +- //... +- events := []abci.Event{ +- { +- Type: "transfer", +- Attributes: []abci.EventAttribute{ +- {Key: []byte("sender"), Value: []byte("Bob"), Index: true}, +- {Key: []byte("recipient"), Value: []byte("Alice"), Index: true}, +- {Key: []byte("balance"), Value: []byte("100"), Index: true}, +- {Key: []byte("note"), Value: []byte("nothing"), Index: true}, +- }, +- }, +- } +- return types.ResponseDeliverTx{Code: code.CodeTypeOK, Events: events} +-} +-``` +- +-If the indexer is not `null`, the transaction will be indexed. Each event is +-indexed using a composite key in the form of `{eventType}.{eventAttribute}={eventValue}`, +-e.g. `transfer.sender=bob`. +- +-## Querying Transactions Events +- +-You can query for a paginated set of transaction by their events by calling the +-`/tx_search` RPC endpoint: +- +-```bash +-curl "localhost:26657/tx_search?query=\"message.sender='cosmos1...'\"&prove=true" +-``` +-If the conditions are related to transaction events and the user wants to make sure the +-conditions are true within the same events, the `match_events` keyword should be used, +-as described [below](#querying_block_events) +- +-Check out [API docs](https://docs.cometbft.com/v0.34/rpc/#/Info/tx_search) +-for more information on query syntax and other options. +- +-## Subscribing to Transactions +- +-Clients can subscribe to transactions with the given tags via WebSocket by providing +-a query to `/subscribe` RPC endpoint. +- +-```json +-{ +- "jsonrpc": "2.0", +- "method": "subscribe", +- "id": "0", +- "params": { +- "query": "message.sender='cosmos1...'" +- } +-} +-``` +- +-Check out [API docs](https://docs.cometbft.com/v0.34/rpc/#subscribe) for more information +-on query syntax and other options. +- +-## Querying Block Events +- +-You can query for a paginated set of blocks by their events by calling the +-`/block_search` RPC endpoint: +- +-```bash +-curl "localhost:26657/block_search?query=\"block.height > 10 AND val_set.num_changed > 0\"" +-``` +- +-## `match_events` keyword +- +-The query results in the height number(s) (or transaction hashes when querying transactions) which contain events whose attributes match the query conditions. +-However, there are two options to query the indexers. To demonstrate the two modes, we reuse the two events +-where Bob and Tom send money to Alice and query the block indexer. We issue the following query: +- +-```bash +-curl "localhost:26657/block_search?query=\"sender=Bob AND balance = 200\"" +-``` +- +-The result will return height 1 even though the attributes matching the conditions in the query +-occurred in different events. +- +-If we wish to retrieve only heights where the attributes occurred within the same event, +-the query syntax is as follows: +- +-```bash +-curl "localhost:26657/block_search?query=\"sender=Bob AND balance = 200\"&match_events=true" +-``` +-Currently the default behavior is if `match_events` is set to false. +- +-Check out [API docs](https://docs.cometbft.com/v0.34/rpc/#/Info/block_search) +-for more information on query syntax and other options. +- +-**Backwards compatibility** +- +-Storing the event sequence was introduced in CometBFT 0.34.25. As there are no previous releases of CometBFT, +-all nodes running CometBFT will include the event sequence. However, mixed networks running CometBFT v0.34.25 and greater +-and Tendermint Core versions before v0.34.25 are possible. On nodes running Tendermint Core, the `match_events` keyword +-is ignored and the data is retrieved as if `match_events=false`. +- +-Additionally, if a node that was running Tendermint Core +-when the data was first indexed, and switched to CometBFT, is queried, it will retrieve this previously indexed +-data as if `match_events=false` (attributes can match the query conditions across different events on the same height). +- +- +-# Event attribute value types +- +-Users can use anything as an event value. However, if the event attribute value is a number, the following restrictions apply: +- +-- Negative numbers will not be properly retrieved when querying the indexer +-- When querying the events using `tx_search` and `block_search`, the value given as part of the condition cannot be a float. +-- Any event value retrieved from the database will be represented as a `BigInt` (from `math/big`) +-- Floating point values are not read from the database even with the introduction of `BigInt`. This was intentionally done +-to keep the same beheaviour as was historically present and not introduce breaking changes. This will be fixed in the 0.38 series. diff --git a/patches/docs/celestia-architecture/README.md.patch b/patches/docs/celestia-architecture/README.md.patch new file mode 100644 index 00000000000..a323aa42240 --- /dev/null +++ b/patches/docs/celestia-architecture/README.md.patch @@ -0,0 +1,69 @@ +diff --git a/docs/celestia-architecture/README.md b/docs/celestia-architecture/README.md +new file mode 100644 +index 000000000..f48698d1f +--- /dev/null ++++ b/docs/celestia-architecture/README.md +@@ -0,0 +1,63 @@ ++--- ++order: 1 ++parent: ++ order: false ++--- ++ ++# Tendermint and Celestia ++ ++celestia-core is not meant to be used as a general purpose framework. ++Instead, its main purpose is to provide certain components (mainly consensus but also a p2p layer for Tx gossiping) for the Celestia main chain. ++Hence, we do not provide any extensive documentation here. ++ ++Instead of keeping a copy of the Tendermint documentation, we refer to the existing extensive and maintained documentation and specification: ++ ++- ++- ++- ++ ++Reading these will give you a lot of background and context on Tendermint which will also help you understand how celestia-core and [celestia-app](https://github.com/celestiaorg/celestia-app) interact with each other. ++ ++## Celestia ++ ++As mentioned above, celestia-core aims to be more focused on the Celestia use-case than vanilla Tendermint. ++Moving forward we might provide a clear overview on the changes we incorporated. ++For now, we refer to the Celestia specific ADRs in this repository as well as to the Celestia specification: ++ ++- [celestia-specs](https://github.com/celestiaorg/celestia-specs) ++ ++## Architecture Decision Records (ADR) ++ ++This is a location to record all high-level architecture decisions in this repository. ++ ++You can read more about the ADR concept in this [blog post](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t). ++ ++An ADR should provide: ++ ++- Context on the relevant goals and the current state ++- Proposed changes to achieve the goals ++- Summary of pros and cons ++- References ++- Changelog ++ ++Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and ++justification for a change in architecture, or for the architecture of something ++new. The spec is much more compressed and streamlined summary of everything as ++it stands today. ++ ++If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match. ++ ++Note the context/background should be written in the present tense. ++ ++To start a new ADR, you can use this template: [adr-template.md](./adr-template.md) ++ ++### Table of Contents ++ ++- [ADR 001: Erasure Coding Block Propagation](./adr-001-block-propagation.md) ++- [ADR 002: Sampling erasure coded Block chunks](./adr-002-ipld-da-sampling.md) ++- [ADR 003: Retrieving Application messages](./adr-003-application-data-retrieval.md) ++- [ADR 004: Data Availability Sampling Light Client](./adr-004-mvp-light-client.md) ++- [ADR 005: Decouple BlockID and PartSetHeader](./adr-005-decouple-blockid-and-partsetheader.md) ++- [ADR 006: Row Propagation](./adr-006-row-propagation.md) ++- [ADR 007: Minimal Changes to Tendermint](./adr-007-minimal-changes-to-tendermint.md) ++- [ADR 008: Updating to Tendermint v0.35.x](./adr-008-updating-to-tendermint-v0.35.x.md) diff --git a/patches/docs/celestia-architecture/adr-001-block-propagation.md.patch b/patches/docs/celestia-architecture/adr-001-block-propagation.md.patch new file mode 100644 index 00000000000..e96336ef747 --- /dev/null +++ b/patches/docs/celestia-architecture/adr-001-block-propagation.md.patch @@ -0,0 +1,130 @@ +diff --git a/docs/celestia-architecture/adr-001-block-propagation.md b/docs/celestia-architecture/adr-001-block-propagation.md +new file mode 100644 +index 000000000..80933fd1f +--- /dev/null ++++ b/docs/celestia-architecture/adr-001-block-propagation.md +@@ -0,0 +1,124 @@ ++# ADR 001: Erasure Coding Block Propagation ++ ++## Changelog ++ ++- 16-2-2021: Created ++ ++## Context ++ ++Block propagation is currently done by splitting the block into arbitrary chunks and gossiping them to validators via a gossip routine. While this does not have downsides it does not meet the needs of the Celestia chain. The celestia chain requires blocks to be encoded in a different way and for the proposer to not propagate the chunks to peers. ++ ++Celestia wants validators to pull the block from a IPFS network. What does this mean? As I touched on earlier the proposer pushes the block to the network, this in turn means that each validator downloads and reconstructs the block each time to verify it. Instead Celestia will encode and split up the block via erasure codes, stored locally in the nodes IPFS daemon. After the proposer has sent the block to IPFS and received the CIDs it will include them into the proposal. This proposal will be gossiped to other validators, once a validator receives the proposal it will begin requesting the CIDs included in the proposal. ++ ++There are two forms of a validator, one that downloads the block and one that samples it. What does sampling mean? Sampling is the act of checking that a portion or entire block is available for download. ++ ++## Detailed Design ++ ++The proposed design is as follows. ++ ++### Types ++ ++The proposal and vote types have a BlockID, this will be replaced with a header hash. The proposal will contain add fields. ++ ++The current proposal will be updated to include required fields. The entirety of the message will be reworked at a later date. To see the extent of the needed changes you can visit the [spec repo](https://github.com/celestiaorg/celestia-specs/blob/master/src/specs/proto/consensus.proto#L19) ++ ++```proto ++message Proposal { ++ SignedMsgType type = 1; ++ int64 height = 2; ++ int32 round = 3; ++ int32 pol_round = 4; ++ ++ +++ ++ // 32-byte hash ++ bytes last_header_hash = 5; ++ // 32-byte hash ++ bytes last_commit_hash = 6; ++ // 32-byte hash ++ bytes consensus_root = 7; ++ FeeHeader fee_header = 8; ++ // 32-byte hash ++ bytes state_commitment = 9; ++ uint64 available_data_original_shares_used = 10; ++ AvailableDataHeader available_data_header = 11; ++ +++ ++ ++ google.protobuf.Timestamp timestamp = 12 ++ [(gogoproto.nullable) = false, (gogoproto.stdtime) = true]; ++ bytes signature = 12; ++} ++``` ++ ++```proto ++// Vote represents a prevote, precommit, or commit vote from validators for ++// consensus. ++message Vote { ++ SignedMsgType type = 1; ++ int64 height = 2; ++ int32 round = 3; ++ +++ ++ bytes header_hash = 4; ++ +++ ++ google.protobuf.Timestamp timestamp = 5 ++ [(gogoproto.nullable) = false, (gogoproto.stdtime) = true]; ++ bytes validator_address = 6; ++ int32 validator_index = 7; ++ bytes signature = 8; ++} ++``` ++ ++See [specs](https://github.com/celestiaorg/celestia-specs/blob/master/src/specs/data_structures.md#vote) for more details on the vote. ++ ++### Disk Storage ++ ++Currently celestia-core stores all blocks in its store. Going forward only the headers of the blocks within the unbonding period will be stored. This will drastically reduce the amount of storage required by a celestia-core node. After the unbonding period all headers will have the option of being pruned. ++ ++Proposed amendment to `BlockStore` interface ++ ++```go ++type BlockStore interface { ++ Base() int64 ++ Height() int64 ++ Size() int64 ++ ++ LoadBlockMeta(height int64) *types.BlockMeta ++ LoadHeader(height int64) *types.Header ++ LoadDAHeader(height int64) *types.DataAvailabilityHeader ++ ++ SaveHeaders(header *types.Header, daHeader *types.DataAvailabilityHeader, seenCommit *types.Commit) ++ ++ PruneHeaders(height int64) (uint64, error) ++ ++ LoadBlockCommit(height int64) *types.Commit ++ LoadSeenCommit(height int64) *types.Commit ++} ++``` ++ ++Along side these changes the rpc layer will need to change. Instead of querying the LL-core store, the node will redirect the query through IPFS. ++ ++Example: ++ ++When a user requests a block from the LL node, the request will be set to the IPLD plugin. If the IPLD does not have the requested block, it will make a request to the celestia IPFS network for the required CIDs. If the full node does not have the DAheader they will not be able to request the block data. ++ ++![user request flow](./assets/user-request.png) ++ ++The goal is to not change the public interface for RPC's. It is yet to be seen if this is possible. This means that CIDs will need to be set and loaded from the store in order to get all the related block information a user requires. ++ ++## Status ++ ++Proposed ++ ++ ++### Positive ++ ++- Minimal breakage to public interface ++- Only store the block in a single place (IPFS) ++- Reduce the public interface of the storage within Celestia. ++ ++### Negative ++ ++- User requests may take more time to process ++ ++### Neutral ++ ++## References diff --git a/patches/docs/celestia-architecture/adr-002-ipld-da-sampling.md.patch b/patches/docs/celestia-architecture/adr-002-ipld-da-sampling.md.patch new file mode 100644 index 00000000000..a8810427bf3 --- /dev/null +++ b/patches/docs/celestia-architecture/adr-002-ipld-da-sampling.md.patch @@ -0,0 +1,286 @@ +diff --git a/docs/celestia-architecture/adr-002-ipld-da-sampling.md b/docs/celestia-architecture/adr-002-ipld-da-sampling.md +new file mode 100644 +index 000000000..a2d6cf987 +--- /dev/null ++++ b/docs/celestia-architecture/adr-002-ipld-da-sampling.md +@@ -0,0 +1,280 @@ ++# ADR 002: Sampling erasure coded Block chunks ++ ++## Changelog ++ ++- 26-2-2021: Created ++ ++## Context ++ ++In Tendermint's block gossiping each peer gossips random parts of block data to peers. ++For Celestia, we need nodes (from light-clients to validators) to be able to sample row-/column-chunks of the erasure coded ++block (aka the extended data square) from the network. ++This is necessary for Data Availability proofs. ++ ++![extended_square.png](img/extended_square.png) ++ ++A high-level, implementation-independent formalization of above mentioned sampling and Data Availability proofs can be found in: ++[_Fraud and Data Availability Proofs: Detecting Invalid Blocks in Light Clients_](https://fc21.ifca.ai/papers/83.pdf). ++ ++For the time being, besides the academic paper, no other formalization or specification of the protocol exists. ++Currently, the Celestia specification itself only describes the [erasure coding](https://github.com/celestiaorg/celestia-specs/blob/master/src/specs/data_structures.md#erasure-coding) ++and how to construct the extended data square from the block data. ++ ++This ADR: ++- describes the high-level requirements ++- defines the API that and how it can be used by different components of Celestia (block gossiping, block sync, DA proofs) ++- documents decision on how to implement this. ++ ++ ++The core data structures and the erasure coding of the block are already implemented in celestia-core ([#17], [#19], [#83]). ++While there are no ADRs for these changes, we can refer to the Celestia specification in this case. ++For this aspect, the existing implementation and specification should already be on par for the most part. ++The exact arrangement of the data as described in this [rationale document](https://github.com/celestiaorg/celestia-specs/blob/master/src/rationale/message_block_layout.md) ++in the specification can happen at app-side of the ABCI boundary. ++The latter was implemented in [celestiaorg/celestia-app#21](https://github.com/celestiaorg/celestia-app/pull/21) ++leveraging a new ABCI method, added in [#110](https://github.com/celestiaorg/celestia-core/pull/110). ++This new method is a sub-set of the proposed ABCI changes aka [ABCI++](https://github.com/tendermint/spec/pull/254). ++ ++Mustafa Al-Bassam (@musalbas) implemented a [prototype](https://github.com/celestiaorg/celestia-prototype) ++whose main purpose is to realistically analyse the protocol. ++Although the prototype does not make any network requests and only operates locally, it can partly serve as a reference implementation. ++It uses the [rsmt2d] library. ++ ++The implementation will essentially use IPFS' APIs. For reading (and writing) chunks it ++will use the IPLD [`DagService`](https://github.com/ipfs/go-ipld-format/blob/d2e09424ddee0d7e696d01143318d32d0fb1ae63/merkledag.go#L54), ++more precisely the [`NodeGetter`](https://github.com/ipfs/go-ipld-format/blob/d2e09424ddee0d7e696d01143318d32d0fb1ae63/merkledag.go#L18-L27) ++and [`NodeAdder`](https://github.com/ipfs/go-ipld-format/blob/d2e09424ddee0d7e696d01143318d32d0fb1ae63/merkledag.go#L29-L39). ++As an optimization, we can also use a [`Batch`](https://github.com/ipfs/go-ipld-format/blob/d2e09424ddee0d7e696d01143318d32d0fb1ae63/batch.go#L29) ++to batch adding and removing nodes. ++This will be achieved by passing around a [CoreAPI](https://github.com/ipfs/interface-go-ipfs-core/blob/b935dfe5375eac7ea3c65b14b3f9a0242861d0b3/coreapi.go#L15) ++object, which derives from the IPFS node which is created along with a tendermint node (see [#152]). ++This code snippet does exactly that (see the [go-ipfs documentation] for more examples): ++```go ++// This constructs an IPFS node instance ++node, _ := core.NewNode(ctx, nodeOptions) ++// This attaches the Core API to the constructed node ++coreApi := coreapi.NewCoreAPI(node) ++``` ++ ++The above mentioned IPLD methods operate on so called [ipld.Nodes]. ++When computing the data root, we can pass in a [`NodeVisitor`](https://github.com/celestia/nmt/blob/b22170d6f23796a186c07e87e4ef9856282ffd1a/nmt.go#L22) ++into the Namespaced Merkle Tree library to create these (each inner- and leaf-node in the tree becomes an ipld node). ++As a peer that requests such an IPLD node, the Celestia IPLD plugin provides the [function](https://github.com/celestiaorg/celestia-core/blob/ceb881a177b6a4a7e456c7c4ab1dd0eb2b263066/p2p/ipld/plugin/nodes/nodes.go#L175) ++`NmtNodeParser` to transform the retrieved raw data back into an `ipld.Node`. ++ ++A more high-level description on the changes required to rip out the current block gossiping routine, ++including changes to block storage-, RPC-layer, and potential changes to reactors is either handled in [ADR 001](./adr-001-block-propagation.md), ++and/or in a few smaller, separate followup ADRs. ++ ++## Alternative Approaches ++ ++Instead of creating a full IPFS node object and passing it around as explained above ++ - use API (http) ++ - use ipld-light ++ - use alternative client ++ ++Also, for better performance ++ - use [graph-sync], [IPLD selectors], e.g. via [ipld-prime] ++ ++Also, there is the idea, that nodes only receive the [Header] with the data root only ++and, in an additional step/request, download the DA header using the library, too. ++While this feature is not considered here, and we assume each node that uses this library has the DA header, this assumption ++is likely to change when flesh out other parts of the system in more detail. ++Note that this also means that light clients would still need to validate that the data root and merkelizing the DA header yield the same result. ++ ++## Decision ++ ++> This section records the decision that was made. ++> It is best to record as much info as possible from the discussion that happened. This aids in not having to go back to the Pull Request to get the needed information. ++ ++> - TODO: briefly summarize github, discord, and slack discussions (?) ++> - also mention Mustafa's prototype and compare both apis briefly (RequestSamples, RespondSamples, ProcessSamplesResponse) ++> - mention [ipld experiments] ++ ++ ++ ++## Detailed Design ++ ++Add a package to the library that provides the following features: ++ 1. sample a given number of random row/col indices of extended data square given a DA header and indicate if successful or timeout/other error occurred ++ 2. store the block in the network by adding it to the peer's local Merkle-DAG whose content is discoverable via a DHT ++ 3. store the sampled chunks in the network ++ 4. reconstruct the whole block from a given DA header ++ 5. get all messages of a particular namespace ID. ++ ++We mention 5. here mostly for completeness. Its details will be described / implemented in a separate ADR / PR. ++ ++Apart from the above mentioned features, we informally collect additional requirements: ++- where randomness is needed, the randomness source should be configurable ++- all replies by the network should be verified if this is not sufficiently covered by the used libraries already (IPFS) ++- where possible, the requests to the network should happen in parallel (without DoSing the proposer for instance). ++ ++This library should be implemented as two new packages: ++ ++First, a sub-package should be added to the layzledger-core [p2p] package ++which does not know anything about the core data structures (Block, DA header etc). ++It handles the actual network requests to the IPFS network and operates on IPFS/IPLD objects ++directly and hence should live under [p2p/ipld]. ++To a some extent this part of the stack already exists. ++ ++Second, a high-level API that can "live" closer to the actual types, e.g., in a sub-package in [celestia-core/types] ++or in a new sub-package `da`. ++ ++We first describe the high-level library here and describe functions in ++more detail inline with their godoc comments below. ++ ++### API that operates on celestia-core types ++ ++As mentioned above this part of the library has knowledge of the core types (and hence depends on them). ++It does not deal with IPFS internals. ++ ++```go ++// ValidateAvailability implements the protocol described in https://fc21.ifca.ai/papers/83.pdf. ++// Specifically all steps of the protocol described in section ++// _5.2 Random Sampling and Network Block Recovery_ are carried out. ++// ++// In more detail it will first create numSamples random unique coordinates. ++// Then, it will ask the network for the leaf data corresponding to these coordinates. ++// Additionally to the number of requests, the caller can pass in a callback, ++// which will be called on for each retrieved leaf with a verified Merkle proof. ++// ++// Among other use-cases, the callback can be useful to monitoring (progress), or, ++// to process the leaf data the moment it was validated. ++// The context can be used to provide a timeout. ++// TODO: Should there be a constant = lower bound for #samples ++func ValidateAvailability( ++ ctx context.Context, ++ dah *DataAvailabilityHeader, ++ numSamples int, ++ onLeafValidity func(namespace.PrefixedData8), ++) error { /* ... */} ++ ++// RetrieveBlockData can be used to recover the block Data. ++// It will carry out a similar protocol as described for ValidateAvailability. ++// The key difference is that it will sample enough chunks until it can recover the ++// full extended data square, including original data (e.g. by using rsmt2d.RepairExtendedDataSquare). ++func RetrieveBlockData( ++ ctx context.Context, ++ dah *DataAvailabilityHeader, ++ api coreiface.CoreAPI, ++ codec rsmt2d.Codec, ++ ) (types.Data, error) {/* ... */} ++ ++// PutBlock operates directly on the Block. ++// It first computes the erasure coding, aka the extended data square. ++// Row by row ir calls a lower level library which handles adding the ++// the row to the Merkle Dag, in our case a Namespaced Merkle Tree. ++// Note, that this method could also fill the DA header. ++// The data will be pinned by default. ++func (b *Block) PutBlock(ctx context.Context, nodeAdder ipld.NodeAdder) error ++``` ++ ++We now describe the lower-level library that will be used by above methods. ++Again we provide more details inline in the godoc comments directly. ++ ++`PutBlock` is a method on `Block` as the erasure coding can then be cached, e.g. in a private field ++in the block. ++ ++### Changes to the lower level API closer to IPFS (p2p/ipld) ++ ++```go ++// GetLeafData takes in a Namespaced Merkle tree root transformed into a Cid ++// and the leaf index to retrieve. ++// Callers also need to pass in the total number of leaves of that tree. ++// Internally, this will be translated to a IPLD path and corresponds to ++// an ipfs dag get request, e.g. namespacedCID/0/1/0/0/1. ++// The retrieved data should be pinned by default. ++func GetLeafData( ++ ctx context.Context, ++ rootCid cid.Cid, ++ leafIndex uint32, ++ totalLeafs uint32, // this corresponds to the extended square width ++ api coreiface.CoreAPI, ++) ([]byte, error) ++``` ++ ++`GetLeafData` can be used by above `ValidateAvailability` and `RetrieveBlock` and ++`PutLeaves` by `PutBlock`. ++ ++### A Note on IPFS/IPLD ++ ++In IPFS all data is _content addressed_ which basically means the data is identified by its hash. ++Particularly, in the Celestia case, the root CID identifies the Namespaced Merkle tree including all its contents (inner and leaf nodes). ++This means that if a `GetLeafData` request succeeds, the retrieved leaf data is in fact the leaf data in the tree. ++We do not need to additionally verify Merkle proofs per leaf as this will essentially be done via IPFS on each layer while ++resolving and getting to the leaf data. ++ ++> TODO: validate this assumption and link to code that shows how this is done internally ++ ++### Implementation plan ++ ++As fully integrating Data Available proofs into tendermint, is a rather larger change we break up the work into the ++following packages (not mentioning the implementation work that was already done): ++ ++1. Flesh out the changes in the consensus messages ([celestia-specs#126], [celestia-specs#127]) ++2. Flesh out the changes that would be necessary to replace the current block gossiping ([ADR 001](./adr-001-block-propagation.md)) ++3. Add the possibility of storing and retrieving block data (samples or whole block) to celestia-core (this ADR and related PRs). ++4. Integrate above API (3.) as an addition into celestia-core without directly replacing the tendermint counterparts (block gossip etc). ++5. Rip out each component that will be redundant with above integration in one or even several smaller PRs: ++ - block gossiping (see ADR 001) ++ - modify block store (see ADR 001) ++ - make downloading full Blocks optional (flag/config) ++ - route some RPC requests to IPFS (see ADR 001) ++ ++ ++## Status ++ ++Proposed ++ ++## Consequences ++ ++### Positive ++ ++- simplicity & ease of implementation ++- can re-use an existing networking and p2p stack (go-ipfs) ++- potential support of large, cool, and helpful community ++- high-level API definitions independent of the used stack ++ ++### Negative ++ ++- latency ++- being connected to the public IPFS network might be overkill if peers should in fact only care about a subset that participates in the Celestia protocol ++- dependency on a large code-base with lots of features and options of which we only need a small subset of ++ ++### Neutral ++- two different p2p layers exist in celestia-core ++ ++## References ++ ++- https://github.com/celestiaorg/celestia-core/issues/85 ++- https://github.com/celestiaorg/celestia-core/issues/167 ++ ++- https://docs.ipld.io/#nodes ++- https://arxiv.org/abs/1809.09044 ++- https://fc21.ifca.ai/papers/83.pdf ++- https://github.com/tendermint/spec/pull/254 ++ ++ ++[#17]: https://github.com/celestiaorg/celestia-core/pull/17 ++[#19]: https://github.com/celestiaorg/celestia-core/pull/19 ++[#83]: https://github.com/celestiaorg/celestia-core/pull/83 ++ ++[#152]: https://github.com/celestiaorg/celestia-core/pull/152 ++ ++[celestia-specs#126]: https://github.com/celestiaorg/celestia-specs/issues/126 ++[celestia-specs#127]: https://github.com/celestiaorg/celestia-specs/pulls/127 ++[Header]: https://github.com/celestiaorg/celestia-specs/blob/master/src/specs/data_structures.md#header ++ ++[go-ipfs documentation]: https://github.com/ipfs/go-ipfs/tree/master/docs/examples/go-ipfs-as-a-library#use-go-ipfs-as-a-library-to-spawn-a-node-and-add-a-file ++[ipld experiments]: https://github.com/celestia/ipld-plugin-experiments ++[ipld.Nodes]: https://github.com/ipfs/go-ipld-format/blob/d2e09424ddee0d7e696d01143318d32d0fb1ae63/format.go#L22-L45 ++[graph-sync]: https://github.com/ipld/specs/blob/master/block-layer/graphsync/graphsync.md ++[IPLD selectors]: https://github.com/ipld/specs/blob/master/selectors/selectors.md ++[ipld-prime]: https://github.com/ipld/go-ipld-prime ++ ++[rsmt2d]: https://github.com/celestiaorg/rsmt2d ++ ++ ++[p2p]: https://github.com/celestiaorg/celestia-core/tree/0eccfb24e2aa1bb9c4428e20dd7828c93f300e60/p2p ++[p2p/ipld]: https://github.com/celestiaorg/celestia-core/tree/0eccfb24e2aa1bb9c4428e20dd7828c93f300e60/p2p/ipld ++[celestia-core/types]: https://github.com/celestiaorg/celestia-core/tree/0eccfb24e2aa1bb9c4428e20dd7828c93f300e60/types diff --git a/patches/docs/celestia-architecture/adr-003-application-data-retrieval.md.patch b/patches/docs/celestia-architecture/adr-003-application-data-retrieval.md.patch new file mode 100644 index 00000000000..b4b4c0bec39 --- /dev/null +++ b/patches/docs/celestia-architecture/adr-003-application-data-retrieval.md.patch @@ -0,0 +1,147 @@ +diff --git a/docs/celestia-architecture/adr-003-application-data-retrieval.md b/docs/celestia-architecture/adr-003-application-data-retrieval.md +new file mode 100644 +index 000000000..689fdfdab +--- /dev/null ++++ b/docs/celestia-architecture/adr-003-application-data-retrieval.md +@@ -0,0 +1,141 @@ ++# ADR 003: Retrieving Application messages ++ ++## Changelog ++ ++- 2021-04-25: initial draft ++ ++## Context ++ ++This ADR builds on top of [ADR 002](adr-002-ipld-da-sampling.md) and will use the implemented APIs described there. ++The reader should familiarize themselves at least with the high-level concepts as well as in the [specs](https://github.com/celestiaorg/celestia-specs/blob/master/src/specs/data_structures.md#2d-reed-solomon-encoding-scheme). ++ ++The academic [paper](https://arxiv.org/abs/1905.09274) describes the motivation and context for this API. ++The main motivation can be quoted from section 3.3 of that paper: ++ ++> (Property1) **Application message retrieval partitioning.** Client nodes must be able to download all of the messages relevant to the applications they use [...], without needing to downloading any messages for other applications. ++ ++> (Property2) **Application message retrieval completeness.** When client nodes download messages relevant to the applications they use [...], they must be able to verify that the messages they received are the complete set of messages relevant to their applications, for specific ++blocks, and that there are no omitted messages. ++ ++ ++ ++The main data structure that enables above properties is called a Namespaced Merkle Tree (NMT), an ordered binary Merkle tree where: ++1. each node in the tree includes the range of namespaces of the messages in all descendants of each node ++2. leaves in the tree are ordered by the namespace identifiers of the leaf messages ++ ++A more formal description can be found the [specification](https://github.com/celestiaorg/celestia-specs/blob/de5f4f74f56922e9fa735ef79d9e6e6492a2bad1/specs/data_structures.md#namespace-merkle-tree). ++An implementation can be found in [this repository](https://github.com/celestiaorg/nmt). ++ ++This ADR basically describes version of the [`GetWithProof`](https://github.com/celestiaorg/nmt/blob/ddcc72040149c115f83b2199eafabf3127ae12ac/nmt.go#L193-L196) of the NMT that leverages the fact that IPFS uses content addressing and that we have implemented an [IPLD plugin](https://github.com/celestiaorg/celestia-core/tree/37502aac69d755c189df37642b87327772f4ac2a/p2p/ipld) for an NMT. ++ ++**Note**: The APIs defined here will be particularly relevant for Optimistic Rollup (full) nodes that want to download their Rollup's data (see [celestiaorg/optimint#48](https://github.com/celestiaorg/optimint/issues/48)). ++Another potential use-case of this API could be for so-called [light validator nodes](https://github.com/celestiaorg/celestia-specs/blob/master/src/specs/node_types.md#node-type-definitions) that want to download and replay the state-relevant portion of the block data, i.e. transactions with [reserved namespace IDs](https://github.com/celestiaorg/celestia-specs/blob/master/src/specs/consensus.md#reserved-namespace-ids). ++ ++## Alternative Approaches ++ ++The approach described below will rely on IPFS' block exchange protocol (bitswap) and DHT; IPFS's implementation will be used as a black box to find peers that can serve the requested data. ++This will likely be much slower than it potentially could be and for a first implementation we intentionally do not incorporate the optimizations that we could. ++ ++We briefly mention potential optimizations for the future here: ++- Use of [graphsync](https://github.com/ipld/specs/blob/5d3a3485c5fe2863d613cd9d6e18f96e5e568d16/block-layer/graphsync/graphsync.md) instead of [bitswap](https://docs.ipfs.io/concepts/bitswap/) and use of [IPLD selectors](https://github.com/ipld/specs/blob/5d3a3485c5fe2863d613cd9d6e18f96e5e568d16/design/history/exploration-reports/2018.10-selectors-design-goals.md) ++- expose an API to be able to download application specific data by namespace (including proofs) with the minimal number of round-trips (e.g. finding nodes that expose an RPC endpoint like [`GetWithProof`](https://github.com/celestiaorg/nmt/blob/ddcc72040149c115f83b2199eafabf3127ae12ac/nmt.go#L193-L196)) ++ ++## Decision ++ ++Most discussions on this particular API happened either on calls or on other non-documented way. ++We only describe the decision in this section. ++ ++We decide to implement the simplest approach first. ++We first describe the protocol informally here and explain why this fulfils (Property1) and (Property2) in the [Context](#context) section above. ++ ++In the case that leaves with the requested namespace exist, this basically boils down to the following: traverse the tree starting from the root until finding first leaf (start) with the namespace in question, then directly request and download all leaves coming after the start until the namespace changes to a greater than the requested one again. ++In the case that no leaves with the requested namespace exist in the tree, we traverse the tree to find the leaf in the position in the tree where the namespace would have been and download the neighbouring leaves. ++ ++This is pretty much what the [`ProveNamespace`](https://github.com/celestiaorg/nmt/blob/ddcc72040149c115f83b2199eafabf3127ae12ac/nmt.go#L132-L146) method does but using IPFS we can simply locate and then request the leaves, and the corresponding inner proof nodes will automatically be downloaded on the way, too. ++ ++## Detailed Design ++ ++We define one function that returns all shares of a block belonging to a requested namespace and block (via the block's data availability header). ++See [`ComputeShares`](https://github.com/celestiaorg/celestia-core/blob/1a08b430a8885654b6e020ac588b1080e999170c/types/block.go#L1371) for reference how encode the block data into namespace shares. ++ ++```go ++// RetrieveShares returns all raw data (raw shares) of the passed-in ++// namespace ID nID and included in the block with the DataAvailabilityHeader dah. ++func RetrieveShares( ++ ctx context.Context, ++ nID namespace.ID, ++ dah *types.DataAvailabilityHeader, ++ api coreiface.CoreAPI, ++) ([][]byte, error) { ++ // 1. Find the row root(s) that contains the namespace ID nID ++ // 2. Traverse the corresponding tree(s) according to the ++ // above informally described algorithm and get the corresponding ++ // leaves (if any) ++ // 3. Return all (raw) shares corresponding to the nID ++} ++ ++``` ++ ++Additionally, we define two functions that use the first one above to: ++1. return all the parsed (non-padding) data with [reserved namespace IDs](https://github.com/celestiaorg/celestia-specs/blob/de5f4f74f56922e9fa735ef79d9e6e6492a2bad1/specs/consensus.md#reserved-namespace-ids): transactions, intermediate state roots, evidence. ++2. return all application specific blobs (shares) belonging to one namespace ID parsed as a slice of Messages ([specification](https://github.com/celestiaorg/celestia-specs/blob/de5f4f74f56922e9fa735ef79d9e6e6492a2bad1/specs/data_structures.md#message) and [code](https://github.com/celestiaorg/celestia-core/blob/1a08b430a8885654b6e020ac588b1080e999170c/types/block.go#L1336)). ++ ++The latter two methods might require moving or exporting a few currently unexported functions that (currently) live in [share_merging.go](https://github.com/celestiaorg/celestia-core/blob/1a08b430a8885654b6e020ac588b1080e999170c/types/share_merging.go#L57-L76) and could be implemented in a separate pull request. ++ ++```go ++// RetrieveStateRelevantMessages returns all state-relevant transactions ++// (transactions, intermediate state roots, and evidence) included in a block ++// with the DataAvailabilityHeader dah. ++func RetrieveStateRelevantMessages( ++ ctx context.Context, ++ nID namespace.ID, ++ dah *types.DataAvailabilityHeader, ++ api coreiface.CoreAPI, ++) (Txs, IntermediateStateRoots, EvidenceData, error) { ++ // like RetrieveShares but for all reserved namespaces ++ // additionally the shares are parsed (merged) into the ++ // corresponding types in the return arguments ++} ++``` ++ ++```go ++// RetrieveMessages returns all Messages of the passed-in ++// namespace ID and included in the block with the DataAvailabilityHeader dah. ++func RetrieveMessages( ++ ctx context.Context, ++ nID namespace.ID, ++ dah *types.DataAvailabilityHeader, ++ api coreiface.CoreAPI, ++) (Messages, error) { ++ // like RetrieveShares but this additionally parsed the shares ++ // into the Messages type ++} ++``` ++ ++## Status ++ ++Proposed ++ ++## Consequences ++ ++This API will most likely be used by Rollups too. ++We should document it properly and move it together with relevant parts from ADR 002 into a separate go-package. ++ ++### Positive ++ ++- easy to implement with the existing code (see [ADR 002](https://github.com/celestiaorg/celestia-core/blob/47d6c965704e102ae877b2f4e10aeab782d9c648/docs/adr/adr-002-ipld-da-sampling.md#detailed-design)) ++- resilient data retrieval via a p2p network ++- dependence on a mature and well-tested code-base with a large and welcoming community ++ ++### Negative ++ ++- with IPFS, we inherit the fact that potentially a lot of round-trips are done until the data is fully downloaded; in other words: this could end up way slower than potentially possible ++- anyone interacting with that API needs to run an IPFS node ++ ++### Neutral ++ ++- optimizations can happen incrementally once we have an initial working version ++ ++## References ++ ++We've linked to all references throughout the ADR. diff --git a/patches/docs/celestia-architecture/adr-004-mvp-light-client.md.patch b/patches/docs/celestia-architecture/adr-004-mvp-light-client.md.patch new file mode 100644 index 00000000000..14fca867ddf --- /dev/null +++ b/patches/docs/celestia-architecture/adr-004-mvp-light-client.md.patch @@ -0,0 +1,298 @@ +diff --git a/docs/celestia-architecture/adr-004-mvp-light-client.md b/docs/celestia-architecture/adr-004-mvp-light-client.md +new file mode 100644 +index 000000000..cbba0921b +--- /dev/null ++++ b/docs/celestia-architecture/adr-004-mvp-light-client.md +@@ -0,0 +1,292 @@ ++# ADR 004: Data Availability Sampling Light Client ++ ++## Changelog ++ ++- 2021-05-03: Initial Draft ++ ++## Context ++ ++We decided to augment the existing [RPC-based Tendermint light client](https://github.com/tendermint/tendermint/blob/bc643b19c48495077e0394d3e21e1d2a52c99548/light/doc.go#L2-L126) by adding the possibility to additionally validate blocks by doing Data Availability Sampling (DAS). ++In general, DAS gives light clients assurance that the data behind the block header they validated is actually available in the network and hence, that state fraud proofs could be generated. ++See [ADR 002](adr-002-ipld-da-sampling.md) for more context on DAS. ++ ++A great introduction on the Tendermint light client (and light clients in general) can be found in this series of [blog posts](https://medium.com/tendermint/everything-you-need-to-know-about-the-tendermint-light-client-f80d03856f98) as well as this [paper](https://arxiv.org/abs/2010.07031). ++ ++This ADR describes the changes necessary to augment the existing Tendermint light client implementation with DAS from a UX as well as from a protocol perspective. ++ ++## Alternative Approaches ++ ++Ideally, the light client should not just request [signed headers](https://github.com/tendermint/tendermint/blob/bc643b19c48495077e0394d3e21e1d2a52c99548/light/doc.go#L35-L52) from [a few pre-configured peers](https://github.com/tendermint/tendermint/blob/bc643b19c48495077e0394d3e21e1d2a52c99548/light/setup.go#L51-L52) but instead also discover peers from a p2p network. ++We will eventually implement this. For more context, we refer to this [issue](https://github.com/celestiaorg/celestia-core/issues/86). ++This would require that the (signed) headers are provided via other means than the RPC. ++See this [abandoned pull request](https://github.com/tendermint/tendermint/pull/4508) and [issue](https://github.com/tendermint/tendermint/issues/4456) in the Tendermint repository and also this [suggestion](https://github.com/celestiaorg/celestia-core/issues/86#issuecomment-831182564) by [@Wondertan](https://github.com/Wondertan) in this repository. ++ ++For some use-cases—like DAS light validator nodes, or the light clients of a Data Availability Layer that are run by full nodes of an Optimistic Rollup—it would even make sense that the light client (passively) participates in the consensus protocol to some extent; i.e. runs a subset of the consensus reactor to Consensus messages ([Votes](https://github.com/tendermint/tendermint/blob/bc643b19c48495077e0394d3e21e1d2a52c99548/types/vote.go#L48-L59) etc.) come in as early as possible. ++Then light clients would not need to wait for the canonical commit to be included in the next [block](https://github.com/tendermint/tendermint/blob/bc643b19c48495077e0394d3e21e1d2a52c99548/types/block.go#L48). ++ ++For the RPC-based light client it could also make sense to add a new RPC endpoint to tendermint for clients to retrieve the [`DataAvailabilityHeader`](https://github.com/celestiaorg/celestia-core/blob/50f722a510dd2ba8e3d31931c9d83132d6318d4b/types/block.go#L52-L69) (DAHeader), or embed the DAHeader. ++The [Commit](https://github.com/celestiaorg/celestia-core/blob/cbf1f1a4a0472373289a9834b0d33e0918237b7f/rpc/core/routes.go#L25) only contains the [SignedHeader](https://github.com/celestiaorg/celestia-core/blob/cbf1f1a4a0472373289a9834b0d33e0918237b7f/rpc/core/types/responses.go#L32-L36) (Header and Commit signatures). ++Not all light clients will need the full DAHeader though (e.g. super-light-clients do not). ++ ++ ++## Decision ++ ++For our MVP, we [decide](https://github.com/celestiaorg/celestia-core/issues/307) to only modify the existing RPC-endpoint based light client. ++This is mostly because we want to ship our MVP as quickly as possible but independently of this it makes sense to provide a familiar experience for engineers coming from the Cosmos ecosystem. ++ ++We will later implement the above mentioned variants. ++How exactly will be described in separate ADRs though. ++ ++## Detailed Design ++ ++From a user perspective very little changes: ++the existing light client command gets an additional flag that indicates whether to run DAS or not. ++Additionally, the light client operator can decide the number of successful samples to make to deem the block available (and hence valid). ++ ++In case DAS is enabled, the light client will need to: ++1. retrieve the DAHeader corresponding to the data root in the Header ++2. request a parameterizable number of random samples. ++ ++If the all sampling requests succeed, the whole block is available ([with some high enough probability](https://arxiv.org/abs/1809.09044)). ++ ++### UX ++ ++The main change to the light client [command](https://github.com/celestiaorg/celestia-core/blob/master/cmd/tendermint/commands/light.go#L32-L104) is to add in a new flag to indicate if it should run DAS or not. ++Additionally, the user can choose the number of succeeding samples required for a block to be considered available. ++ ++```diff ++=================================================================== ++diff --git a/cmd/tendermint/commands/light.go b/cmd/tendermint/commands/light.go ++--- a/cmd/tendermint/commands/light.go (revision 48b043014f0243edd1e8ebad8cd0564ab9100407) +++++ b/cmd/tendermint/commands/light.go (date 1620546761822) ++@@ -64,6 +64,8 @@ ++ dir string ++ maxOpenConnections int ++ +++ daSampling bool +++ numSamples uint32 ++ sequential bool ++ trustingPeriod time.Duration ++ trustedHeight int64 ++@@ -101,6 +103,10 @@ ++ LightCmd.Flags().BoolVar(&sequential, "sequential", false, ++ "sequential verification. Verify all headers sequentially as opposed to using skipping verification", ++ ) +++ LightCmd.Flags().BoolVar(&daSampling, "da-sampling", false, +++ "data availability sampling. Verify each header (sequential verification), additionally verify data availability via data availability sampling", +++ ) +++ LightCmd.Flags().Uint32Var(&numSamples, "num-samples", 15, "Number of data availability samples until block data deemed available.") ++ } ++``` ++ ++For the Data Availability sampling, the light client will have to run an IPFS node. ++It makes sense to make this mostly opaque to the user as everything around IPFS can be [configured](https://github.com/ipfs/go-ipfs/blob/d6322f485af222e319c893eeac51c44a9859e901/docs/config.md) in the `$IPFS_PATH`. ++This IPFS path should simply be a sub-directory inside the light client's [directory](https://github.com/celestiaorg/celestia-core/blob/cbf1f1a4a0472373289a9834b0d33e0918237b7f/cmd/tendermint/commands/light.go#L86-L87). ++We can later add the ability to let users configure the IPFS setup more granular. ++ ++**Note:** DAS should only be compatible to sequential verification. ++In case a light client is parametrized to run DAS and skipping verification, the CLI should return an easy-to-understand warning or even an error explaining why this does not make sense. ++ ++### Light Client Protocol with DAS ++ ++#### Light Store ++ ++The light client stores data in its own [badgerdb instance](https://github.com/celestiaorg/celestia-core/blob/50f722a510dd2ba8e3d31931c9d83132d6318d4b/cmd/tendermint/commands/light.go#L125) in the given directory: ++ ++```go ++db, err := badgerdb.NewDB("light-client-db", dir) ++``` ++ ++While it is not critical for this feature, we should at least try to re-use that same DB instance for the local ipld store. ++Otherwise, we introduce yet another DB instance; something we want to avoid, especially on the long run (see [#283](https://github.com/celestiaorg/celestia-core/issues/283)). ++For the first implementation, it might still be simpler to create a separate DB instance and tackle cleaning this up in a separate pull request, e.g. together with other [instances]([#283](https://github.com/celestiaorg/celestia-core/issues/283)). ++ ++#### RPC ++ ++No changes to the RPC endpoints are absolutely required. ++Although, for convenience and ease of use, we should either add the `DAHeader` to the existing [Commit](https://github.com/celestiaorg/celestia-core/blob/cbf1f1a4a0472373289a9834b0d33e0918237b7f/rpc/core/routes.go#L25) endpoint, or, introduce a new endpoint to retrieve the `DAHeader` on demand and for a certain height or block hash. ++ ++The first has the downside that not every light client needs the DAHeader. ++The second explicitly reveals to full-nodes which clients are doing DAS and which not. ++ ++**Implementation Note:** The additional (or modified) RPC endpoint could work as a simple first step until we implement downloading the DAHeader from a given data root in the header. ++Also, the light client uses a so called [`Provider`](https://github.com/tendermint/tendermint/blob/7f30bc96f014b27fbe74a546ea912740eabdda74/light/provider/provider.go#L9-L26) to retrieve [LightBlocks](https://github.com/tendermint/tendermint/blob/7f30bc96f014b27fbe74a546ea912740eabdda74/types/light.go#L11-L16), i.e. signed headers and validator sets. ++Currently, only the [`http` provider](https://github.com/tendermint/tendermint/blob/7f30bc96f014b27fbe74a546ea912740eabdda74/light/provider/http/http.go#L1) is implemented. ++Hence, as _a first implementation step_, we should augment the `Provider` and the `LightBlock` to optionally include the DAHeader (details below). ++In parallel but in a separate pull request, we add a separate RPC endpoint to download the DAHeader for a certain height. ++ ++#### Store DataAvailabilityHeader ++ ++For full nodes to be able to serve the `DataAvailabilityHeader` without having to recompute it each time, it needs to be stored somewhere. ++While this is independent of the concrete serving mechanism, it is more so relevant for the RPC endpoint. ++There is ongoing work to make the Tendermint Store only store Headers and the DataAvailabilityHeader in [#218](https://github.com/celestiaorg/celestia-core/pull/218/) / [#182](https://github.com/celestiaorg/celestia-core/issues/182). ++ ++At the time writing this ADR, another pull request ([#312](https://github.com/celestiaorg/celestia-core/pull/312)) is in the works with a more isolated change that adds the `DataAvailabilityHeader` to the `BlockID`. ++Hence, the DAHeader is [stored](https://github.com/celestiaorg/celestia-core/blob/50f722a510dd2ba8e3d31931c9d83132d6318d4b/store/store.go#L355-L367) along the [`BlockMeta`](https://github.com/celestiaorg/celestia-core/blob/50f722a510dd2ba8e3d31931c9d83132d6318d4b/types/block_meta.go#L11-L17) there. ++ ++For a first implementation, we could first build on top of #312 and adapt to the changed storage API where only headers and the DAHeader are stored inside tendermint's store (as drafted in #218). ++A major downside of storing block data inside of tendermint's store as well as in the IPFS' block store is that is not only redundantly stored data but also IO intense work that will slow down full nodes. ++ ++ ++#### DAS ++ ++The changes for DAS are very simple from a high-level perspective assuming that the light client has the ability to download the DAHeader along with the required data (signed header + validator set) of a given height: ++ ++Every time the light client validates a retrieved light-block, it additionally starts DAS in the background (once). ++For a DAS light client it is important to use [sequential](https://github.com/tendermint/tendermint/blob/f366ae3c875a4f4f61f37f4b39383558ac5a58cc/light/client.go#L46-L53) verification and not [skipping](https://github.com/tendermint/tendermint/blob/f366ae3c875a4f4f61f37f4b39383558ac5a58cc/light/client.go#L55-L69) verification. ++Skipping verification only works under the assumption that 2/3+1 of voting power is honest. ++The whole point of doing DAS (and state fraud proofs) is to remove that assumption. ++See also this related issue in the LL specification: [#159](https://github.com/celestiaorg/celestia-specs/issues/159). ++ ++Independent of the existing implementation, there are three ways this could be implemented: ++1. the DAS light client only accepts a header as valid and trusts it after DAS succeeds (additionally to the tendermint verification), and it waits until DAS succeeds (or there was an error or timeout on the way) ++2. (aka 1.5) the DAS light client stages headers where the tendermint verification passes as valid and spins up DAS sampling routines in the background; the staged headers are committed as valid iff all routines successfully return in time ++3. the DAS light client optimistically accepts a header as valid and trusts it if the regular tendermint verification succeeds; the DAS is run in the background (with potentially much longer timeouts as in 1.) and after the background routine returns (or errs or times out), the already trusted headers are marked as unavailable; this might require rolling back the already trusted headers ++ ++We note that from an implementation point of view 1. is not only the simplest approach, but it would also work best with the currently implemented light client design. ++It is the approach that should be implemented first. ++ ++The 2. approach can be seen as an optimization where the higher latency DAS can be conducted in parallel for various heights. ++This could speed up catching-up (sequentially) if the light client went offline (shorter than the weak subjectivity time window). ++ ++The 3. approach is the most general of all, but it moves the responsibility to wait or to rollback headers to the caller and hence is undesirable as it offers too much flexibility. ++ ++ ++#### Data Structures ++ ++##### LightBlock ++ ++As mentioned above the LightBlock should optionally contain the DataAvailabilityHeader. ++```diff ++Index: types/light.go ++=================================================================== ++diff --git a/types/light.go b/types/light.go ++--- a/types/light.go (revision 64044aa2f2f2266d1476013595aa33bb274ba161) +++++ b/types/light.go (date 1620481205049) ++@@ -13,6 +13,9 @@ ++ type LightBlock struct { ++ *SignedHeader `json:"signed_header"` ++ ValidatorSet *ValidatorSet `json:"validator_set"` +++ +++ // DataAvailabilityHeader is only populated for DAS light clients for others it can be nil. +++ DataAvailabilityHeader *DataAvailabilityHeader `json:"data_availability_header"` ++ } ++``` ++ ++Alternatively, we could introduce a `DASLightBlock` that embeds a `LightBlock` and has the `DataAvailabilityHeader` as the only (non-optional) field. ++This would be more explicit as it is a new type. ++Instead, adding a field to the existing `LightBlock`is backwards compatible and does not require any further code changes; the new type requires `To`- and `FromProto` functions at least. ++ ++##### Provider ++ ++The [`Provider`](https://github.com/tendermint/tendermint/blob/7f30bc96f014b27fbe74a546ea912740eabdda74/light/provider/provider.go#L9-L26) should be changed to additionally provide the `DataAvailabilityHeader` to enable DAS light clients. ++Implementations of the interface need to additionally retrieve the `DataAvailabilityHeader` for the [modified LightBlock](#lightblock). ++Users of the provider need to indicate this to the provider. ++ ++We could either augment the `LightBlock` method with a flag, add a new method solely for providing the `DataAvailabilityHeader`, or, we could introduce a new method for DAS light clients. ++ ++The latter is preferable because it is the most explicit and clear, and it still keeps places where DAS is not used without any code changes. ++ ++Hence: ++ ++```diff ++Index: light/provider/provider.go ++=================================================================== ++diff --git a/light/provider/provider.go b/light/provider/provider.go ++--- a/light/provider/provider.go (revision 7d06ae28196e8765c9747aca9db7d2732f56cfc3) +++++ b/light/provider/provider.go (date 1620298115962) ++@@ -21,6 +21,14 @@ ++ // error is returned. ++ LightBlock(ctx context.Context, height int64) (*types.LightBlock, error) ++ +++ // DASLightBlock returns the LightBlock containing the DataAvailabilityHeader. +++ // Other than including the DataAvailabilityHeader it behaves exactly the same +++ // as LightBlock. +++ // +++ // It can be used by DAS light clients. +++ DASLightBlock(ctx context.Context, height int64) (*types.LightBlock, error) +++ +++ ++ // ReportEvidence reports an evidence of misbehavior. ++ ReportEvidence(context.Context, types.Evidence) error ++ } ++``` ++Alternatively, with the exact same result, we could embed the existing `Provider` into a new interface: e.g. `DASProvider` that adds this method. ++This is completely equivalent as above and which approach is better will become more clear when we spent more time on the implementation. ++ ++Regular light clients will call `LightBlock` and DAS light clients will call `DASLightBlock`. ++In the first case the result will be the same as for vanilla Tendermint and in the second case the returned `LightBlock` will additionally contain the `DataAvailabilityHeader` of the requested height. ++ ++#### Running an IPFS node ++ ++We already have methods to [initialize](https://github.com/celestiaorg/celestia-core/blob/cbf1f1a4a0472373289a9834b0d33e0918237b7f/cmd/tendermint/commands/init.go#L116-L157) and [run](https://github.com/celestiaorg/celestia-core/blob/cbf1f1a4a0472373289a9834b0d33e0918237b7f/node/node.go#L1449-L1488) an IPFS node in place. ++These need to be refactored such that they can effectively be for the light client as well. ++This means: ++1. these methods need to be exported and available in a place that does not introduce interdependence of go packages ++2. users should be able to run a light client with a single command and hence most of the initialization logic should be coupled with creating the actual IPFS node and [made independent](https://github.com/celestiaorg/celestia-core/blob/cbf1f1a4a0472373289a9834b0d33e0918237b7f/cmd/tendermint/commands/init.go#L119-L120) of the `tendermint init` command ++ ++An example for 2. can be found in the IPFS [code](https://github.com/ipfs/go-ipfs/blob/cd72589cfd41a5397bb8fc9765392bca904b596a/cmd/ipfs/daemon.go#L239) itself. ++We might want to provide a slightly different default initialization though (see how this is [overridable](https://github.com/ipfs/go-ipfs/blob/cd72589cfd41a5397bb8fc9765392bca904b596a/cmd/ipfs/daemon.go#L164-L165) in the ipfs daemon cmd). ++ ++We note that for operating a fully functional light client the IPFS node could be running in client mode [`dht.ModeClient`](https://github.com/libp2p/go-libp2p-kad-dht/blob/09d923fcf68218181b5cd329bf5199e767bd33c3/dht_options.go#L29-L30) but be actually want light clients to also respond to incoming queries, e.g. from other light clients. ++Hence, they should by default run in [`dht.ModeServer`](https://github.com/libp2p/go-libp2p-kad-dht/blob/09d923fcf68218181b5cd329bf5199e767bd33c3/dht_options.go#L31-L32). ++In an environment were any bandwidth must be saved, or, were the network conditions do not allow the server mode, we make it easy to change the default behavior. ++ ++##### Client ++ ++We add another [`Option`](https://github.com/tendermint/tendermint/blob/a91680efee3653e3de620f24eb8ddca1c95ce8f9/light/client.go#L43-L117) to the [`Client`](https://github.com/tendermint/tendermint/blob/a91680efee3653e3de620f24eb8ddca1c95ce8f9/light/client.go#L173) that indicates that this client does DAS. ++ ++This option indicates: ++1. to do sequential verification and ++2. to request [`DASLightBlocks`](#lightblock) from the [provider](#provider). ++ ++All other changes should only affect unexported methods only. ++ ++##### ValidateAvailability ++ ++In order for the light clients to perform DAS to validate availability, they do not need to be aware of the fact that an IPFS node is run. ++Instead, we can use the existing [`ValidateAvailability`](https://github.com/celestiaorg/celestia-core/blame/master/p2p/ipld/validate.go#L23-L28) function (as defined in [ADR 002](adr-002-ipld-da-sampling.md) and implemented in [#270](https://github.com/celestiaorg/celestia-core/pull/270)). ++Note that this expects an ipfs core API object `CoreAPI` to be passed in. ++Using that interface has the major benefit that we could even change the requirement that the light client itself runs the IPFS node without changing most of the validation logic. ++E.g., the IPFS node (with our custom IPLD plugin) could run in different process (or machine), and we could still just pass in that same `CoreAPI` interface. ++ ++Orthogonal to this ADR, we also note that we could change all IPFS readonly methods to accept the minimal interface they actually use, namely something that implements `ResolveNode` (and maybe additionally a `NodeGetter`). ++ ++`ValidateAvailability` needs to be called each time a header is validated. ++A DAS light client will have to request the `DASLightBlock` for this as per above to be able to pass in a `DataAvailabilityHeader`. ++ ++#### Testing ++ ++Ideally, we add the DAS light client to the existing e2e tests. ++It might be worth to catch up with some relevant changes from tendermint upstream. ++In particular, [tendermint/tendermint#6196](https://github.com/tendermint/tendermint/pull/6196) and previous changes that it depends on. ++ ++Additionally, we should provide a simple example in the documentation that walks through the DAS light client. ++It would be good if the light client logs some (info) output related to DAS to provide feedback to the user. ++ ++## Status ++ ++Proposed ++ ++## Consequences ++ ++### Positive ++ ++- simple to implement and understand ++- familiar to tendermint / Cosmos devs ++- allows trying out the MVP without relying on the [celestia-app](https://github.com/celestiaorg/celestia-app) (instead a simple abci app like a modified [KVStore](https://github.com/celestiaorg/celestia-core/blob/42e4e8b58ebc58ebd663c114d2bcd7ab045b1c55/abci/example/kvstore/README.md) app could be used to demo the DAS light client) ++ ++### Negative ++ ++- light client does not discover peers ++- requires the light client that currently runs simple RPC requests only to run an IPFS node ++- rpc makes it extremely easy to infer which light clients are doing DAS and which not ++- the initial light client implementation might still be confusing to devs familiar to tendermint/Cosmos for the reason that it does DAS (and state fraud proofs) to get rid of the underlying honest majority assumption, but it will still do all checks related to that same honest majority assumption (e.g. download validator sets, Commits and validate that > 2/3 of them signed the header) ++ ++### Neutral ++ ++DAS light clients need to additionally obtain the DAHeader from the data root in the header to be able to actually do DAS. ++ ++## References ++ ++We have linked all references above inside the text already. diff --git a/patches/docs/celestia-architecture/adr-005-decouple-blockid-and-partsetheader.md.patch b/patches/docs/celestia-architecture/adr-005-decouple-blockid-and-partsetheader.md.patch new file mode 100644 index 00000000000..1b2c968ecdc --- /dev/null +++ b/patches/docs/celestia-architecture/adr-005-decouple-blockid-and-partsetheader.md.patch @@ -0,0 +1,54 @@ +diff --git a/docs/celestia-architecture/adr-005-decouple-blockid-and-partsetheader.md b/docs/celestia-architecture/adr-005-decouple-blockid-and-partsetheader.md +new file mode 100644 +index 000000000..1bf8fa741 +--- /dev/null ++++ b/docs/celestia-architecture/adr-005-decouple-blockid-and-partsetheader.md +@@ -0,0 +1,47 @@ ++# ADR 005: Decouple the PartSetHeader from the BlockID ++ ++## Changelog ++ ++- 2021-08-01: Initial Draft ++ ++## Context ++ ++Celestia has multiple commits to the block data via the `DataHash` and the `PartSetHeader` in the `BlockID`. As stated in the [#184](https://github.com/celestiaorg/lazyledger-core/issues/184), we no longer need the `PartSetHeader` for this additional commitment to the block's data. However, we are still planning to use the `PartSetHeader` for block propagation during consensus in the short-medium term. This means that we will remove the `PartSetHeader` from as many places as possible, but keep it in the `Proposal` struct. ++ ++## Alternative Approaches ++ ++It’s worth noting that there are proposed changes to remove the `PartSetHeader` entirely, and instead use the already existing commitment to block data, the `DataAvailabilityHeader`, to propagate blocks in parallel during consensus. Discussions regarding the detailed differences entailed in each approach are documented in that ADR's PR. The current direction that is described in this ADR is significantly more conservative in its approach, but it is not strictly an alternative to other designs. This is because other designs would also require removal of the `PartSethHeader`, which is a project in and of itself due to the `BlockID` widespread usage throughout tendermint and the bugs that pop up when attempting to remove it. ++ ++## Decision ++ ++While we build other better designs to experiment with, we will continue to implement the design specified here as it is not orthogonal. https://github.com/celestiaorg/lazyledger-core/pull/434#issuecomment-869158788 ++ ++## Detailed Design ++ ++- [X] Decouple the BlockID and the PartSetHeader [#441](https://github.com/celestiaorg/lazyledger-core/pull/441) ++- [ ] Remove the BlockID from every possible struct other than the `Proposal` ++ - [X] Stop signing over the `PartSetHeader` while voting [#457](https://github.com/celestiaorg/lazyledger-core/pull/457) ++ - [X] Remove the `PartSetHeader` from the Header [#457](https://github.com/celestiaorg/lazyledger-core/pull/457) ++ - [X] Remove the `PartSetHeader` from `VoteSetBits`, `VoteSetMaj23`, and `state.State` [#479](https://github.com/celestiaorg/lazyledger-core/pull/479) ++ - [ ] Remove the `PartSetHeader` from other structs ++ ++ ++## Status ++ ++Proposed ++ ++### Positive ++ ++- Conservative and easy to implement ++- Acts as a stepping stone for other better designs ++- Allows us to use 64kb sized chunks, which are well tested ++ ++### Negative ++ ++- Not an ideal design as we still have to include an extra commitment to the block's data in the proposal ++ ++## References ++ ++Alternative ADR [#434](https://github.com/celestiaorg/lazyledger-core/pull/434) ++Alternative implementation [#427](https://github.com/celestiaorg/lazyledger-core/pull/427) and [#443](https://github.com/celestiaorg/lazyledger-core/pull/443) ++[Comment](https://github.com/celestiaorg/lazyledger-core/pull/434#issuecomment-869158788) that summarizes decision +\ No newline at end of file diff --git a/patches/docs/celestia-architecture/adr-006-row-propagation.md.patch b/patches/docs/celestia-architecture/adr-006-row-propagation.md.patch new file mode 100644 index 00000000000..935cc65fcb5 --- /dev/null +++ b/patches/docs/celestia-architecture/adr-006-row-propagation.md.patch @@ -0,0 +1,208 @@ +diff --git a/docs/celestia-architecture/adr-006-row-propagation.md b/docs/celestia-architecture/adr-006-row-propagation.md +new file mode 100644 +index 000000000..a31686dd3 +--- /dev/null ++++ b/docs/celestia-architecture/adr-006-row-propagation.md +@@ -0,0 +1,202 @@ ++# ADR 006: Consensus Block Gossiping with Rows ++ ++## Changelog ++* 24.06.2021 - Initial description ++* 07.07.2021 - More important details were added ++* 18.08.2021 - Mention alternative approaches briefly ++ ++## Context ++It's a long story of relations between Celestia, Tendermint, and consensus block gossiping. Celestia's team discussed ++multiple ideas, several ADRs were made, and nothing yet was finalized. This ADR is another attempt to bring valuable ++changes into block gossiping and hopefully successful. ++ ++Currently, we inherit the following from Tendermint. Our codebase relies on the blocks Parts notion. Each Part is a ++piece of an entire serialized block. Those Parts are gossiped between nodes in consensus and committed with ++`PartSetHeader` containing a Merkle Root of the Parts. However, Parts gossiping wasn't designed for Celestia blocks. ++ ++Celestia comes with a different block representation from Tendermint. It lays out Blocks as a table of data shares, ++where Rows or Columns can be and should be gossiped instead of Parts, keeping only one system-wide commitment to data. ++ ++## Alternative Approaches ++### ["nah it works just don't touch it"](https://ahseeit.com//king-include/uploads/2020/11/121269295_375504380484919_2997236194077828589_n-6586327691.jpg) approach ++ ++It turns out that we could fully treat the Tendermint consensus as a black box, keeping two data commitments: one for ++consensus with `PartSetHeader` and another for the world outside the consensus with `DAHeader`. ++ ++#### Pros ++* Less work ++ ++### Others ++* get rid of the PartsHeader from BlockID without changing block propagation at all (see [ADR 005](https://github.com/celestiaorg/celestia-core/blob/58a3901827afbf97852d807de34a2b66f93e0eb6/docs/lazy-adr/adr-005-decouple-blockid-and-partsetheader.md#adr-005-decouple-the-partsetheader-from-the-blockid)) ++* change block propagation to fixed-sized chunks but based on the ODS instead of how Parts are built currently (for this we have empirical evidence of how it performs in practice) ++* send the block as a whole (only works with smaller blocks) ++* block propagation-based on sending the header and Tx-IDs and then requesting the Tx/Messages that are missing from the local mempool of a node on demand ++ ++#### Cons ++* Pulls two data commitments to Celestia's specs ++* Brings ambiguity to data integrity verification ++* Controversial from software design perspective ++* Brings DOSing vector for big Blocks. Every Block would need to be represented in two formats in RAM ++* Wastes more resources on building and verifying additional ++ ++## Decision ++The decision is to still treat Tendermint's consensus as a black box, but with few amendments to gossiping mechanism: ++* Introduce `RowSet` that mimics `PartSet`. ++ ++ `RowSet` is a helper structure that wraps DAHeader and tracks received Rows with their integrity against DAHeader and ++ tells its user when the block is complete and/or can be recovered. Mostly it is a helper and is not a high-level ++ concept. ++* Replace `PartSet` with `RowSet` within consensus. ++* Keep `DAHeader` in `Proposal` ++* Remove `PartSetHeader` from `Proposal` ++ ++The changes above are required to implement the decision. At later point, other changes listed below are ++likely to be implemented as a clean-up: ++* Entirely removing `PartSetHeader`, as redundant data commitment ++* Removing `PartSet` ++* Relying on `DAHeader` instead of `PartSetHeader` ++ ++## Detailed Design ++The detailed design section demonstrates the design and supporting changes package by package. Fortunately, the ++design does not affect any public API and changes are solely internal. ++ ++### `types` ++#### RowSet and Row ++First and essential part is to implement `RowSet` and `Row`, fully mimicking semantics of `PartSet` and `Part` to ++decrease the number of required changes. Below, implementation semantics are presented: ++ ++```go ++// Row represents a blob of multiple ExtendedDataSquare shares. ++// Practically, it is half of an extended row, as other half can be recomputed. ++type Row struct { ++// Index is a top-to-bottom index of a Row in ExtendedDataSquare. ++// NOTE: Row Index is unnecessary, as we can determine it's Index by hash from DAHeader. However, Index removal ++// would bring more changes to Consensus Reactor with arguable pros of less bandwidth usage. ++Index int ++// The actual share blob. ++Data []byte ++} ++ ++// NewRow creates new Row from flattened shares and index. ++func NewRow(idx int, row [][]byte) *Row ++ ++// RowSet wraps DAHeader and tracks added Rows with their integrity against DAHeader. ++// It allows user to check whenever rsmt2d.ExtendedDataSquare can be recovered. ++// ++// RowSet tracks the whole ExtendedDataSquare, Where Q0 is the original block data: ++// ---- ---- ++// | Q0 || Q1 | ++// ---- ---- ++// | Q2 || Q3 | ++// ---- ---- ++// ++// But its AddRow and GetRow methods accepts and returns only half of the Rows - Q0 and Q2. Q1 and Q3 are recomputed. ++// ---- ++// | Q0 | ++// ---- ++// | Q2 | ++// ---- ++// ++type RowSet interface { ++// NOTE: The RowSet is defined as an interface for simplicity. In practice it should be a struct with one and only ++// implementation. ++ ++// AddRow adds a Row to the set. It returns true with nil error in case Row was successfully added. ++// The logic for Row is: ++// * Check if it was already added ++// * Verify its size corresponds to DAHeader ++// * Extend it with erasure coding and compute a NMT Root over it ++// * Verify that the NMT Root corresponds to DAHeader Root under its Index ++// * Finally add it to set and mark as added. ++// ++AddRow(*Row) (bool, error) ++ ++// GetRow return of a Row by its index, if exist. ++GetRow(i int) *Row ++ ++// Square checks if enough rows were added and returns recomputed ExtendedDataSquare if enough ++Square() (*rsmt2d.ExtendedDataSquare, error) ++ ++// other helper methods are omitted ++} ++ ++// NewRowSet creates full RowSet from rsmt2d.ExtendedDataSquare to gossip it to others through GetRow. ++func NewRowSet(eds *rsmt2d.ExtendedDataSquare) *RowSet ++ ++// NewRowSetFromHeader creates empty RowSet from a DAHeader to receive and verify gossiped Rows against the DAHeader ++// with AddRow. ++func NewRowSetFromHeader(dah *ipld.DataAvailabilityHeader) *RowSet ++``` ++ ++#### Vote ++`Vote` should include a commitment to data. Previously, it relied on `PartSetHeader` in `BlockId`, instead it relies on ++added `DAHeader`. Protobuf schema is updated accordingly. ++ ++#### Proposal ++`Proposal` is extended with `NumOriginalDataShares`. This is an optimization that ++helps Validators to populate Header without counting original data shares themselves from a block received from a ++Proposer. Potentially, that introduce a vulnerability by which a Proposer can send wrong value, leaving the populated ++Header of Validators wrong. This part of the decision is optional. ++ ++### `consenSUS` ++#### Reactor ++##### Messages ++The decision affects two messages on consensus reactor: ++* `BlockPartMessage` -> `BlockRowMessage` ++ * Instead of `Part` it carries `Row` defined above. ++* `NewValidBlockMessage` ++ * Instead of `PartSetHeader` it carries `DAHeader` ++ * `BitArray` of `RowSet` instead of `PartSet` ++ Protobuf schema for both is updated accordingly. ++ ++##### PeerRoundState ++`PeerRoundState` tracks state of each known peer in a round, specifically what commitment it has for a Block and what ++chunks peer holds. The decision changes it to track `DAHeader` instead of `PartSetHeader`, along with `BitArray` of ++`RowSet` instead of `PartSet`. ++ ++##### BlockCatchup ++The Reactor helps its peers to catchup if they go out of sync. Instead of sending random `Part` it now sends random ++`Row` by `BlockRowMessage`. Unfortunately, that requires the Reactor to load whole Block from store. As an optimization, ++an ability to load Row only from the store could be introduced at later point. ++ ++#### State ++##### RoundState ++The RoundState keeps Proposal, Valid and Lock Block's data. Along with an entire Block and its Parts, the RoundState ++also keeps Rows using `RowSet`. At later point, `PartSet` that tracks part can be removed. ++ ++##### Proposal Stage ++Previously, the State in proposal stage waited for all Parts to assemble the entire Block. Instead, the State waits for ++the half of all Rows from a proposer and/or peers to recompute the Block's data and notifies them back that no more ++needs to be sent. Also, through Rows, only minimally required amount of information is gossiped. Everything else to ++assemble the full Block is collected from own chain State and Proposal. ++ ++## Status ++Proposed ++ ++## Consequences ++### Positive ++* Hardening of consensus gossiping with erasure coding ++* Blocks exceeding the size limit are immediately rejected on Proposal, without the need to download an entire Block. ++* More control over Row message size during consensus, comparing to Part message, as last part of the block always has ++ unpredictable size. `DAHeader`, on the other hand, allows knowing precisely the size of Row messages. ++* Less bandwidth usage ++ * Only required Block's data is gossiped. ++ * Merkle proofs of Parts are not sent on the wire ++* Only one system-wide block data commitment schema ++* We don't abandon the work we were doing for months and taking profits out of it ++ * PR [#287](https://github.com/celestiaorg/lazyledger-core/pull/287) ++ * PR [#312](https://github.com/celestiaorg/lazyledger-core/pull/312) ++ * PR [#427](https://github.com/celestiaorg/lazyledger-core/pull/427) ++ * and merged others ++ ++### Negative ++* We invest some more time(~1.5 weeks). ++ * Most of the work is done. Only few changes left in the implementation along with peer reviews. ++ ++### Neutral ++* Rows vs Parts on the wire ++ * Previously, parts were propagated with max size of 64KiB. Let's now take a Row of the largest 128x128 block in ++ comparison. The actual data size in such a case for the Row would be 128x256(shares_per_row*share_size)=32KiB, which ++ is exactly two times smaller than a Part. ++* Gossiped chunks are no longer constant size. Instead, their size is proportional to the size of Block's data. ++* Another step back from original Tendermint's codebases diff --git a/patches/docs/celestia-architecture/adr-007-minimal-changes-to-tendermint.md.patch b/patches/docs/celestia-architecture/adr-007-minimal-changes-to-tendermint.md.patch new file mode 100644 index 00000000000..713bf67966f --- /dev/null +++ b/patches/docs/celestia-architecture/adr-007-minimal-changes-to-tendermint.md.patch @@ -0,0 +1,243 @@ +diff --git a/docs/celestia-architecture/adr-007-minimal-changes-to-tendermint.md b/docs/celestia-architecture/adr-007-minimal-changes-to-tendermint.md +new file mode 100644 +index 000000000..67f07d8a4 +--- /dev/null ++++ b/docs/celestia-architecture/adr-007-minimal-changes-to-tendermint.md +@@ -0,0 +1,237 @@ ++# ADR 007: From Ukraine, with Love ++ ++## Changelog ++ ++- 2021-08-20: Initial Description ++- 2022-05-03: Update pointing to ADR 008 ++ ++## Context ++ ++Currently, our fork of tendermint includes changes to how to erasure block data, minor changes to the header to commit ++to that data, additions to serve data availability sampling, along with some miscellaneous modification to adhere to the ++spec. Instead of incorporating all of these changes into our fork of tendermint, we will only make the strictly ++necessary changes and the other services and their code to the new celestia-node repo. Notably, we will also refactor ++some of the remaining necessary changes to be more isolated from the rest of the tendermint codebase. Both of these ++strategies should significantly streamline pulling updates from upstream, and allow us to iterate faster since most ++changes will be isolated to celestia-node. ++ ++Update: many of the changes described below have since been minimized or removed. Please see ADR 008 for a summarized list of changes. Notably, we removed intermediate state roots, adopted two new methods from ABCI++ instead of PreprocessTxs, and are still signing over the PartSetHeader. ++ ++## Decision ++ ++Treat tendermint more as a "black box". ++ ++## Detailed Design ++ ++### Overview ++ ++We keep the bare-minimum changes to tendermint in our fork, celestia-core. Where necessary and possible we augment the ++tendermint node in a separate process, via celestia-node, which communicates with the tendermint node via RPC. All data ++availability sampling logic, including all Celestia-specific networking logic not already provided by tendermint, is ++moved into celestia node: ++ ++![core node relation](./img/core-node-relation.jpg) ++ ++The detailed design of celestia-node will be defined in the repository itself. ++ ++### Necessary changes to tendermint ++ ++#### Changing the repo import names to celestiaorg ++ ++- Rebrand (https://github.com/celestiaorg/celestia-core/pull/476) ++ ++#### Changes to the README.md other basic things ++ ++- update github templates (https://github.com/celestiaorg/celestia-core/pull/405) ++- update README.md (https://github.com/celestiaorg/celestia-core/pull/10) ++ ++#### Adding the extra types of block data ++ ++- Update core data types (https://github.com/celestiaorg/celestia-core/pull/17) ++ - Create the Message/Messages types ++ - Proto and the tendermint version ++ - Create the IntermediateStateRoots type ++ - Proto and the tendermint version ++- Data availability for evidence (https://github.com/celestiaorg/celestia-core/pull/19) ++ - Add both types to `types.Data` ++ - Modify proto ++ - Add `EvidenceData` to `types.Data` ++ ++#### Add the HeaderHash to the Commit ++ ++- Add header hash to commit(https://github.com/celestiaorg/celestia-core/pull/198) ++ ++#### Adding the consts package in types ++ ++#### Remove iavl as a dependency ++ ++- remove iavl as a dependency (https://github.com/celestiaorg/celestia-core/pull/129) ++ ++#### Using the `DataAvailabilityHeader` to calculate the DataHash ++ ++The `DataAvailabilityHeader` struct will be used by celestia-core as well as by the celestia-node. It might make sense ++to (eventually) move the struct together with all the DA-related code into a separate repository and go-module. ++@Wondertan explored this as part of [#427](https://github.com/celestiaorg/celestia-core/pull/427#issue-674512464). This ++way all client implementations can depend on that module without running into circular dependencies. Hence, we only ++describe how to hash the block data here: ++ ++- Update core types (https://github.com/celestiaorg/celestia-core/pull/17) ++ - Replace the `Data.Hash()` with `DAH.Hash()` ++ - Use DAH to fill DataHash when filling the header ++ - Fill the DAH when making a block to generate the data hash ++ ++#### Add availableDataOriginalSharesUsed to the header ++ ++- Add availableDataOriginalSharesUsed to the header (https://github.com/celestiaorg/celestia-core/pull/262) ++ ++#### Reap some number of transactions probably using the app or some other mech ++ ++- Enforce a minimum square size (https://github.com/celestiaorg/celestia-core/pull/282) ++- Use squares with a width that is a power of two(https://github.com/celestiaorg/celestia-core/pull/331) ++- Adopt reaping from the mempool to max square size (https://github.com/celestiaorg/celestia-core/issues/77) ++- Proposal: Decide on a mech to pick square size and communicate that to the ++ app (https://github.com/celestiaorg/celestia-core/issues/454) ++- Also see ABCI++ for a less hacky solution ++ ++#### Filling the DAH using share merging and splitting ++ ++- Compute Shares (not merged) (https://github.com/celestiaorg/celestia-core/pull/60) ++ - part II (not merged) (https://github.com/celestiaorg/celestia-core/pull/63) ++ - while this was not merged, we will need some function to compute the shares that make up the block data ++- Share Splitting (https://github.com/celestiaorg/celestia-core/pull/246) ++ - Serialize each constituent of block data ++ - Split into shares ++ - Txs (contiguous) ++ - Messages (not contiguous) ++ - Evidence (contiguous) ++ - IntermediateStateRoots (contiguous) ++- Combine shares into original square ++- ExtendBlockData ++- Generate nmt root of each row and col ++- Use those roots to generate the DataHash ++- Share Merging (https://github.com/celestiaorg/celestia-core/pull/261) ++ - Sort by namespace ++ - Parse each reserved type ++ - Parse remaining messages ++ ++#### Add the wrapper around nmt to erasure namespaces ++ ++- Implement rsmt tree wrapper for nmt (https://github.com/celestiaorg/celestia-core/pull/238) ++ ++#### Add PreprocessTxs to ABCI ++ ++- Add PreprocessTxs method to ABCI (https://github.com/celestiaorg/celestia-core/pull/110) ++- Add method to ABCI interface ++- Create sync and async versions ++- Add sync version to the CreateProposalBlock method of BlockExecutor ++ ++#### Fill the DAH while making the block ++ ++- Basic DA functionality (https://github.com/celestiaorg/celestia-core/pull/83) ++ ++#### Only produce blocks on some interval ++ ++- Control block times (https://github.com/tendermint/tendermint/issues/5911) ++ ++#### Stop signing over the PartSetHeader ++ ++- Replace canonical blockID with just a hash in the CononicalVote ++- Replace the LastBlockID in the header with just a hash ++ ++#### Optionally remove some unused code ++ ++- Removing misc unsued code (https://github.com/celestiaorg/celestia-core/pull/208) ++- Remove docs deployment (https://github.com/celestiaorg/celestia-core/pull/134) ++- Start deleting docs (https://github.com/celestiaorg/celestia-core/pull/209) ++- Remove tendermint-db in favor of badgerdb (https://github.com/celestiaorg/celestia-core/pull/241) ++- Delete blockchain 2 until further notice (https://github.com/celestiaorg/celestia-core/pull/309) ++- We don’t need to support using out of process apps ++ ++#### Nice to Haves ++ ++- More efficient hashing (https://github.com/celestiaorg/celestia-core/pull/351) ++ ++We should also take this opportunity to refactor as many additions to tendermint into their own package as possible. ++This will hopefully make updating to future versions of tendermint easier. For example, when we fill the data ++availability header, instead of using a method on `Block`, it could be handled by a function that takes `types.Data` as ++input and returns the DAH, the number of shares used in the square, along with the obligatory error. ++ ++```go ++func FillDataAvailabilityHeader(data types.Data) (types.DataAvailabilityHeader, numOrigDataShares, error) ++``` ++ ++We could perform a similar treatment to the `splitIntoShares` methods and their helper method `ComputeShares`. Instead ++of performing the share splitting logic in those methods, we could keep it in a different package and instead call the ++equivalent function to compute the shares. ++ ++Beyond refactoring and some minor additions, we will also have to remove and revert quite a few changes to get to the ++minimum desired changes specified above. ++ ++### Changes that will need to be reverted ++ ++#### IPLD Plugin ++ ++- Introduction (https://github.com/celestiaorg/celestia-core/pull/144) ++- Initial integration (https://github.com/celestiaorg/celestia-core/pull/152) ++- Custom Multihash (https://github.com/celestiaorg/celestia-core/pull/155) ++- Puting data during proposal (https://github.com/celestiaorg/celestia-core/pull/178) ++- Module name (https://github.com/celestiaorg/celestia-core/pull/151) ++- Update rsmt2d (https://github.com/celestiaorg/celestia-core/pull/290) ++- Make plugin a package (https://github.com/celestiaorg/celestia-core/pull/294) ++ ++#### Adding DAH to Stuff ++ ++- Adding DAH to Proposal (https://github.com/celestiaorg/celestia-core/pull/248/files) ++- Blockmeta (https://github.com/celestiaorg/celestia-core/pull/372) ++ ++#### Embedding DAS ++ ++- GetLeafData (https://github.com/celestiaorg/celestia-core/pull/212) ++- RetrieveBlockData (https://github.com/celestiaorg/celestia-core/pull/232) ++- ValidateAvailability (https://github.com/celestiaorg/celestia-core/pull/270) ++- Prevent double writes to IPFS (https://github.com/celestiaorg/celestia-core/pull/271) ++- Stop Pinning (https://github.com/celestiaorg/celestia-core/pull/276) ++- Rework IPFS Node (https://github.com/celestiaorg/celestia-core/pull/334) ++- Refactor for putting the block (https://github.com/celestiaorg/celestia-core/pull/338) ++- Config for IPFS node (https://github.com/celestiaorg/celestia-core/pull/340) ++- IPLD Dag instead of CoreAPI (https://github.com/celestiaorg/celestia-core/pull/352) ++- Adding the DAG to the blockstore (https://github.com/celestiaorg/celestia-core/pull/356) ++- Saving and Loading using IPFS (https://github.com/celestiaorg/celestia-core/pull/374) ++- Manual Providing (https://github.com/celestiaorg/celestia-core/pull/375) ++- Refactor node provider (https://github.com/celestiaorg/celestia-core/pull/400) ++- DAS in light client workaround (https://github.com/celestiaorg/celestia-core/pull/413) ++ ++#### BlockID and PartSetHeader ++ ++- Decouple ParSetHeader from BlockID (https://github.com/celestiaorg/celestia-core/pull/441) ++- Stop Signing over the PartSetHeader (https://github.com/celestiaorg/celestia-core/pull/457) ++- We still don’t want to sign over the PartSetHeader, but we will not be able to use the same mechanism used in the ++ linked PR, as that way requires decoupling of the PSH from the BlockID ++- Remove PSH from some consensus messages (https://github.com/celestiaorg/celestia-core/pull/479) ++ ++Note: This ADR overrides ADR 005 Decouple BlockID and the PartSetHeader. The PartSetHeader and the BlockID will mostly ++remain the same. This will make pulling changes from upstream much easier ++ ++## Status ++ ++Accepted ++ ++## Consequences ++ ++### Positive ++ ++- Pulling changes from upstream is streamlined ++- Separation of functionality will help us iterate faster ++- Creates a great opportunity for reconsidering past design choices without fully starting from scratch ++- Prepare for future designs ++- Don’t have to have two p2p stacks in a single repo ++ ++### Negative ++ ++- Perform some computation multiple times ++- Running multiple nodes instead of a single node is less convenient for node operators (but only in the case the full ++ celestia-node wants to participate in the consensus protocol) ++ ++## References ++ ++Tracking Issue #491 diff --git a/patches/docs/celestia-architecture/adr-008-updating-to-tendermint-v0.35.x.md.patch b/patches/docs/celestia-architecture/adr-008-updating-to-tendermint-v0.35.x.md.patch new file mode 100644 index 00000000000..1a3ba7b0c7b --- /dev/null +++ b/patches/docs/celestia-architecture/adr-008-updating-to-tendermint-v0.35.x.md.patch @@ -0,0 +1,60 @@ +diff --git a/docs/celestia-architecture/adr-008-updating-to-tendermint-v0.35.x.md b/docs/celestia-architecture/adr-008-updating-to-tendermint-v0.35.x.md +new file mode 100644 +index 000000000..276358c41 +--- /dev/null ++++ b/docs/celestia-architecture/adr-008-updating-to-tendermint-v0.35.x.md +@@ -0,0 +1,53 @@ ++# ADR 008: Updating to tendermint v0.35.x ++ ++## Changelog ++ ++- 2022-05-03: Initial document describing changes to tendermint v0.35.x ++ ++## Context ++ ++Building off of ADR 007, we have further distilled the necessary changes to tendermint and continued to move added logic to other repos. Specifically, we have moved generation of the data hash, efficient construction of the data square, and a message inclusion check to celestia-app via adopting two new methods from ABCI++. This document is to serve as a guide for the remaining changes made on top of tendermint v0.35.4. ++ ++### Changes to tendermint ++ ++#### Misc ++ ++- [update github templates](https://github.com/celestiaorg/celestia-core/pull/405) ++- [update README.md](https://github.com/celestiaorg/celestia-core/pull/737/commits/be9039d4e0f5d876ec3d8d4521be3374172d7992) ++- [updating to go 1.17](https://github.com/celestiaorg/celestia-core/pull/737/commits/6094b7338082d106f81da987dffa56eb540a675e) ++- [adding the consts package](https://github.com/celestiaorg/celestia-core/pull/737/commits/fea8528b0177230b7e75396ae05f7a9b5da23741) ++ ++#### Changing the way the data hash is calculated ++ ++To enable data availability sampling, Celestia uses a proprietary data square format to encode its block data. The data hash is generated from this data square by calculating namespace merkle tree root over each row and column. In the following changes, we implement encoding and decoding of block data to the data square format and tooling to generate the data hash. More details over this design can be found in our (archived but still very useful) [specs repo](https://github.com/celestiaorg/celestia-specs) ++ ++- [Adding the Data Availability Header](https://github.com/celestiaorg/celestia-core/pull/737/commits/116b7af4000920030a373363487ef9a9f084e066) ++- [Adding a wrapper for namespaced merkle trees](https://github.com/celestiaorg/celestia-core/pull/737/commits/eee8f352cb6a1687a9f6b470abe28bbd4eb66413) ++- [Adding Messages and Evidence to the block data](https://github.com/celestiaorg/celestia-core/pull/737/commits/86df6529a7c0cc1112c34b6bf1b5364aa0518dec) ++- [Adding share splitting and merging for block encoding](https://github.com/celestiaorg/celestia-core/pull/737/commits/bf2d8b46c1caf1fed52e7db9bf8aa6a9847d84ab) ++- [Modifying MakeBlock to also accept Messages](https://github.com/celestiaorg/celestia-core/pull/737/commits/bb970a417356ab030c934ccd2bd39c9641af45f8) ++ ++#### Adding PrepareProposal and ProcessProposal ABCI methods from ABCI++ ++ ++- [PrepareProposal](https://github.com/celestiaorg/celestia-core/pull/737/commits/07f9a05444db763c44ff81f564e7350ddf57e5a4) ++- [ProcessProposal](https://github.com/celestiaorg/celestia-core/pull/737/commits/2c9552db09841f2bbebc1ec34653b2441def9f13) ++ ++more details on how we use these new methods in the app can be found in the [ABCI++ Adoption ADR](https://github.com/celestiaorg/celestia-app/blob/master/docs/architecture/ADR-001-ABCI%2B%2B.md). ++ ++#### Wrapping Malleated Transactions ++ ++Tendermint and the cosmos-sdk were not built to handle malleated transactions (txs that are submitted by the user, but modified by the block producer before being included in a block). While not a final solution, we have resorted to adding the hash of the original transaction (the one that is not modified by the block producer) to the modified one. This allows us to track the transaction in the event system and mempool. ++ ++- [Index malleated Txs](https://github.com/celestiaorg/celestia-core/pull/737/commits/a54e3599a5ef6b2ba8b63f586aed8185a3f59e4d) ++ ++#### Create NMT Inclusion Proofs for Transactions ++ ++Since the block data that is committed over is encoded as a data square and we use namespaced merkle trees to generate the row and column roots of that square, we have to create transaction inclusion proofs also using nmts and a data square. The problem is that the block data isn't stored as a square, so in order to generate the inclusion proofs, we have to regenerate a portion of the square. We do that here. ++ ++- [Create namespace merkle tree inclusion proofs for transactions included in the block](https://github.com/celestiaorg/celestia-core/pull/737/commits/01051aa5fef0693bf3bda801e39c80e5746b9c33) ++ ++#### Adding the DataCommitment RPC endpoint ++ ++This RPC endpoint is used by quantum gravity bridge orchestrators to create a commitment over the block data of a range of blocks. ++ ++- [Adding the DataCommitment RPC endpoint](https://github.com/celestiaorg/celestia-core/pull/737/commits/134eeefb7af41afe760d4adc5b22a9d55e36bc3e) +\ No newline at end of file diff --git a/patches/docs/celestia-architecture/adr-009-cat-pool.md.patch b/patches/docs/celestia-architecture/adr-009-cat-pool.md.patch new file mode 100644 index 00000000000..d78e2dc0c4f --- /dev/null +++ b/patches/docs/celestia-architecture/adr-009-cat-pool.md.patch @@ -0,0 +1,102 @@ +diff --git a/docs/celestia-architecture/adr-009-cat-pool.md b/docs/celestia-architecture/adr-009-cat-pool.md +new file mode 100644 +index 000000000..44772e152 +--- /dev/null ++++ b/docs/celestia-architecture/adr-009-cat-pool.md +@@ -0,0 +1,96 @@ ++# ADR 009: Content addressable transaction pool ++ ++## Changelog ++ ++- 2023-01-11: Initial Draft (@cmwaters) ++ ++## Context ++ ++One of the criteria of success for Celestia as a reliable data availability layer is the ability to handle large transactional throughput. A component that plays a significant role in this is the mempool. It's purpose is to receive transactions from clients and broadcast them to all other nodes, eventually reaching the next block proposer who includes it in their block. Given Celestia's aggregator-like role whereby larger transactions, i.e. blobs, are expected to dominate network traffic, a content-addressable algorithm, common in many other [peer-to-peer file sharing protocols](https://en.wikipedia.org/wiki/InterPlanetary_File_System), could be far more beneficial than the current transaction-flooding protocol that Tendermint currently uses. ++ ++This ADR describes the content addressable transaction protocol and through a comparative analysis with the existing gossip protocol, presents the case for it's adoption in Celestia. ++ ++## Decision ++ ++Use a content addressable transaction pool for disseminating transaction to nodes within the Celestia Network ++ ++## Detailed Design ++ ++The core idea is that each transaction can be referenced by a key, generated through a cryptographic hash function that reflects the content of the transaction. Nodes signal to one another which transactions they have via this key, and can request transactions they are missing through the key. This reduces the amount of duplicated transmission compared to a system which blindly sends received transactions to all other connected peers (as we will see in the consequences section). ++ ++Full details on the exact protocol can be found in the [spec](../../mempool/cat/spec.md). Here, the document focuses on the main deciding points around the architecture: ++ ++- It is assumed clients submit transactions to a single node in the network. Thus a node that receives a transaction through RPC will immediately broadcast it to all connected peers. ++- The new messages: `SeenTx` and `WantTx`, are broadcast over a new mempool channel `byte(0x31)` for backwards compatibility and to distinguish priorities. Nodes running the other mempools will not receive these messages and will be able to operate normally. Similarly, the interfaces used by Tendermint are not modified in any way, thus a node operator can easily switch between mempool versions. ++- Transaction gossiping takes priority over these "state" messages as to avoid situations where we receive a `SeenTx` and respond with a `WantTx` while the transaction is still queued in the nodes p2p buffer. ++- The node only sends `SeenTx` to nodes that haven't yet seen the transaction, using jitter (with an upper bound of 100ms) to stagger when `SeenTx`s are broadcast to avoid messages being sent at once. ++- `WantTx`s are sent to one peer at a time. A timeout is used to deem when a peer is unresponsive and the `WantTx` should be sent to another peer. This is currently set to 200ms (an estimation of network round trip time). It is not yet configurable but we may want to change that in the future. ++- A channel has been added to allow the `TxPool` to feed validated txs to the `Reactor` to be sent to all other peers. ++ ++A series of new metrics have been added to monitor effectiveness: ++ ++- SuccessfulTxs: number of transactions committed in a block (to be used as a baseline) ++- AlreadySeenTxs: transactions that are received more than once ++- RequestedTxs: the number of initial requests for a transaction ++- RerequestedTxs: the number of follow up requests for a transaction. If this is high, it may indicate that the request timeout is too short. ++ ++The CAT pool has had numerous unit tests added. It has been tested in the local e2e networks and put under strain in large, geographically dispersed 100 node networks. ++ ++## Alternative Approaches ++ ++A few variations on the design were prototyped and tested. An early implementation experimented with just `SeenTx`s. All nodes would gossip `SeenTx` upon receiving a valid tx. Nodes would not relay received transactions to peers that had sent them a `SeenTx`. However, in many cases this would lead to a node sending a tx to a peer before it was able to receive the `SeenTx` that the node had just sent. Even with a higher priority, a large amount of duplication still occurred. ++ ++Another trick was tested which involved adding a `From` field to the `SeenTx`. Nodes receiving the `SeenTx` would use the `NodeID` in `From` to check if they were already connected to that peer and thus could expect a transaction from them soon instead of immediately issuing a `WantTx`. In large scale tests, this proved to be surprisingly less efficient. This might be because a `SeenTx` rarely arrives from another node before the initial sender has broadcast to everyone. It may also be because in the testnets, each node was only connected to 10 other nodes, decreasing the chance that the node was actually connected to the original sender. The `From` field also added an extra 40 bytes to the `SeenTx` message. In the chart below, this experiment is shown as CAT2. ++ ++## Status ++ ++Implemented ++ ++## Consequences ++ ++To validate its effectiveness, the protocol was benchmarked against existing mempool implementations. This was done under close-to-real network environments which used [testground](https://github.com/testground/testground) and the celestia-app binary (@ v0.11.0) to create 100 validator networks. The network would then be subjected to PFBs from 1100 light nodes at 4kb per transaction. The network followed 15 second blocktimes with a maximum block size of roughly 8MB (these were being filled). This was run for 10 minutes before being torn down. The collected data was aggregated across the 100 nodes and is as follows: ++ ++| Version | Average Bandwidth | Standard Deviation | Finalized Bandwidth | ++|-----|-----|------|------| ++| v0 | 982.66MB/s | 113.91MB/s | 11MB/s | ++| v1 | 999.89MB/s | 133.24MB/s | 11MB/s | ++| v2 (CAT) | 98.90MB/s | 18.95MB/s | 11MB/s | ++| v2 (CAT2) | 110.28MB/s | 33.49MB/s | 11MB/s | ++ ++> Finalized bandwidth is the amount of bytes finalized by consensus per second whereas the other measurements are per node. ++ ++Rather than just expressing the difference in bytes, this can also be viewed by the factor of duplication (i.e. the amount of times a transaction is received by a node) ++ ++| Version | v0 | v1 | v2 (CAT) | v2 (CAT2) | ++| --------|----|----|----------|-----------| ++| Duplication | 17.61x | 17.21x | 1.75x | 1.85x | ++ ++ ++This, of course, comes at the cost of additional message overhead and there comes a point where the transactions are small enough that the reduction in duplication doesn't outweigh the extra state messages. ++ ++ ++### Positive ++ ++- Reduction in network bandwidth. ++- Cross compatible and therefore easily reversible. ++ ++### Negative ++ ++- Extra network round trip when not directly receiving a transaction. ++- Greater complexity than a simple flooding mechanism. ++ ++### Neutral ++ ++- Allows for compact blocks to be implemented as it depends on the push pull functionality. ++ ++## Ongoing work ++ ++This section describes further work that may be subsequently undertaken in this area. The first is transaction bundling. If a node is subject to a lot of transactions from clients, instead of sending them off immediately one-by-one, it may wait for a fixed period (~100ms) and bundle them all together. The set of transactions can now be represented as a single key. This increases the content to key ratio and thus improves the performance of the protocol. ++ ++An area of further exploration is the concept of neighborhoods. Variations of this idea are present in both [GossipSub](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md#gossipsub-the-gossiping-mesh-router) and Solana's Turbine. The concept entails shaping the network typology into many neighborhoods or sections where a node can be seen as strongly connected to nodes in their neighbourhood and weakly connected to peers in other neighborhoods. The idea behind a more structured topology is to make the broadcasting more directed. ++ ++Outside of protocol development, work can be done to more accurately measure the performance. Both protocols managed to sustain 15 second block times with mostly full blocks i.e. same output throughput. This indicates that the network was being artificially constrained. Either of these constraints need to be lifted (ideally max square size) so we are able to measure the underlying network speed. ++ ++## References ++ ++- [Content-addressable transaction pool spec](../../mempool/cat/spec.md) diff --git a/patches/docs/celestia-architecture/adr-template.md.patch b/patches/docs/celestia-architecture/adr-template.md.patch new file mode 100644 index 00000000000..ac4fc56404e --- /dev/null +++ b/patches/docs/celestia-architecture/adr-template.md.patch @@ -0,0 +1,78 @@ +diff --git a/docs/celestia-architecture/adr-template.md b/docs/celestia-architecture/adr-template.md +new file mode 100644 +index 000000000..adbac8f4d +--- /dev/null ++++ b/docs/celestia-architecture/adr-template.md +@@ -0,0 +1,72 @@ ++# ADR {ADR-NUMBER}: {TITLE} ++ ++## Changelog ++ ++- {date}: {changelog} ++ ++## Context ++ ++> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution. ++ ++## Alternative Approaches ++ ++> This section contains information around alternative options that are considered before making a decision. It should contain an explanation on why the alternative approach(es) were not chosen. ++ ++## Decision ++ ++> This section records the decision that was made. ++> It is best to record as much info as possible from the discussion that happened. This aids in not having to go back to the Pull Request to get the needed information. ++ ++## Detailed Design ++ ++> This section does not need to be filled in at the start of the ADR, but must be completed prior to the merging of the implementation. ++> ++> Here are some common questions that get answered as part of the detailed design: ++> ++> - What are the user requirements? ++> ++> - What systems will be affected? ++> ++> - What new data structures are needed, what data structures will be changed? ++> ++> - What new APIs will be needed, what APIs will be changed? ++> ++> - What are the efficiency considerations (time/space)? ++> ++> - What are the expected access patterns (load/throughput)? ++> ++> - Are there any logging, monitoring or observability needs? ++> ++> - Are there any security considerations? ++> ++> - Are there any privacy considerations? ++> ++> - How will the changes be tested? ++> ++> - If the change is large, how will the changes be broken up for ease of review? ++> ++> - Will these changes require a breaking (major) release? ++> ++> - Does this change require coordination with the Celestia fork of the SDK or celestia-app? ++ ++## Status ++ ++> A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. Once the ADR has been implemented mark the ADR as "implemented". If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement. ++ ++{Deprecated|Proposed|Accepted|Declined} ++ ++## Consequences ++ ++> This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones. ++ ++### Positive ++ ++### Negative ++ ++### Neutral ++ ++## References ++ ++> Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here! ++ ++- {reference link} diff --git a/patches/docs/celestia-architecture/img/core-node-relation.jpg.patch b/patches/docs/celestia-architecture/img/core-node-relation.jpg.patch new file mode 100644 index 00000000000..0755f665475 --- /dev/null +++ b/patches/docs/celestia-architecture/img/core-node-relation.jpg.patch @@ -0,0 +1,4 @@ +diff --git a/docs/celestia-architecture/img/core-node-relation.jpg b/docs/celestia-architecture/img/core-node-relation.jpg +new file mode 100644 +index 000000000..8c9364063 +Binary files /dev/null and b/docs/celestia-architecture/img/core-node-relation.jpg differ diff --git a/patches/docs/celestia-architecture/img/extended_square.png.patch b/patches/docs/celestia-architecture/img/extended_square.png.patch new file mode 100644 index 00000000000..7c53d357025 --- /dev/null +++ b/patches/docs/celestia-architecture/img/extended_square.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/celestia-architecture/img/extended_square.png b/docs/celestia-architecture/img/extended_square.png +new file mode 100644 +index 000000000..8bbf46950 +Binary files /dev/null and b/docs/celestia-architecture/img/extended_square.png differ diff --git a/patches/docs/core/README.md.patch b/patches/docs/core/README.md.patch new file mode 100644 index 00000000000..2baf33b676d --- /dev/null +++ b/patches/docs/core/README.md.patch @@ -0,0 +1,29 @@ +diff --git a/docs/core/README.md b/docs/core/README.md +deleted file mode 100644 +index cc7d4b6fd..000000000 +--- a/docs/core/README.md ++++ /dev/null +@@ -1,23 +0,0 @@ +---- +-order: 1 +-parent: +- title: Core +- order: 4 +---- +- +-# Overview +- +-This section dives into the internals of the CometBFT's implementation. +- +-- [Using CometBFT](./using-cometbft.md) +-- [Configuration](./configuration.md) +-- [Running in Production](./running-in-production.md) +-- [Metrics](./metrics.md) +-- [Validators](./validators.md) +-- [Subscribing to events](./subscription.md) +-- [Block Structure](./block-structure.md) +-- [RPC](./rpc.md) +-- [Fast Sync](./fast-sync.md) +-- [State Sync](./state-sync.md) +-- [Mempool](./mempool.md) +-- [Light Client](./light-client.md) diff --git a/patches/docs/core/block-structure.md.patch b/patches/docs/core/block-structure.md.patch new file mode 100644 index 00000000000..f98a47dfbae --- /dev/null +++ b/patches/docs/core/block-structure.md.patch @@ -0,0 +1,22 @@ +diff --git a/docs/core/block-structure.md b/docs/core/block-structure.md +deleted file mode 100644 +index dc73e5027..000000000 +--- a/docs/core/block-structure.md ++++ /dev/null +@@ -1,16 +0,0 @@ +---- +-order: 8 +---- +- +-# Block Structure +- +-The CometBFT consensus engine records all agreements by a +-supermajority of nodes into a blockchain, which is replicated among all +-nodes. This blockchain is accessible via various RPC endpoints, mainly +-`/block?height=` to get the full block, as well as +-`/blockchain?minHeight=_&maxHeight=_` to get a list of headers. But what +-exactly is stored in these blocks? +- +-The [specification](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/core/data_structures.md) contains a detailed description of each component - that's the best place to get started. +- +-To dig deeper, check out the [types package documentation](https://godoc.org/github.com/cometbft/cometbft/types). diff --git a/patches/docs/core/configuration.md.patch b/patches/docs/core/configuration.md.patch new file mode 100644 index 00000000000..b821ed31639 --- /dev/null +++ b/patches/docs/core/configuration.md.patch @@ -0,0 +1,546 @@ +diff --git a/docs/core/configuration.md b/docs/core/configuration.md +deleted file mode 100644 +index 917f28fdd..000000000 +--- a/docs/core/configuration.md ++++ /dev/null +@@ -1,540 +0,0 @@ +---- +-order: 3 +---- +- +-# Configuration +- +-CometBFT can be configured via a TOML file in +-`$CMTHOME/config/config.toml`. Some of these parameters can be overridden by +-command-line flags. For most users, the options in the `##### main base configuration options #####` are intended to be modified while config options +-further below are intended for advance power users. +- +-## Options +- +-The default configuration file create by `cometbft init` has all +-the parameters set with their default values. It will look something +-like the file below, however, double check by inspecting the +-`config.toml` created with your version of `cometbft` installed: +- +-```toml +- +-# This is a TOML config file. +-# For more information, see https://github.com/toml-lang/toml +- +-# NOTE: Any path below can be absolute (e.g. "/var/myawesomeapp/data") or +-# relative to the home directory (e.g. "data"). The home directory is +-# "$HOME/.cometbft" by default, but could be changed via $CMTHOME env variable +-# or --home cmd flag. +- +-####################################################################### +-### Main Base Config Options ### +-####################################################################### +- +-# TCP or UNIX socket address of the ABCI application, +-# or the name of an ABCI application compiled in with the CometBFT binary +-proxy_app = "tcp://127.0.0.1:26658" +- +-# A custom human readable name for this node +-moniker = "anonymous" +- +-# If this node is many blocks behind the tip of the chain, FastSync +-# allows them to catchup quickly by downloading blocks in parallel +-# and verifying their commits +-fast_sync = true +- +-# Database backend: goleveldb | cleveldb | boltdb | rocksdb | badgerdb +-# * goleveldb (github.com/syndtr/goleveldb - most popular implementation) +-# - pure go +-# - stable +-# * cleveldb (uses levigo wrapper) +-# - fast +-# - requires gcc +-# - use cleveldb build tag (go build -tags cleveldb) +-# * boltdb (uses etcd's fork of bolt - github.com/etcd-io/bbolt) +-# - EXPERIMENTAL +-# - may be faster is some use-cases (random reads - indexer) +-# - use boltdb build tag (go build -tags boltdb) +-# * rocksdb (uses github.com/tecbot/gorocksdb) +-# - EXPERIMENTAL +-# - requires gcc +-# - use rocksdb build tag (go build -tags rocksdb) +-# * badgerdb (uses github.com/dgraph-io/badger) +-# - EXPERIMENTAL +-# - use badgerdb build tag (go build -tags badgerdb) +-db_backend = "goleveldb" +- +-# Database directory +-db_dir = "data" +- +-# Output level for logging, including package level options +-log_level = "info" +- +-# Output format: 'plain' (colored text) or 'json' +-log_format = "plain" +- +-##### additional base config options ##### +- +-# Path to the JSON file containing the initial validator set and other meta data +-genesis_file = "config/genesis.json" +- +-# Path to the JSON file containing the private key to use as a validator in the consensus protocol +-priv_validator_key_file = "config/priv_validator_key.json" +- +-# Path to the JSON file containing the last sign state of a validator +-priv_validator_state_file = "data/priv_validator_state.json" +- +-# TCP or UNIX socket address for CometBFT to listen on for +-# connections from an external PrivValidator process +-priv_validator_laddr = "" +- +-# Path to the JSON file containing the private key to use for node authentication in the p2p protocol +-node_key_file = "config/node_key.json" +- +-# Mechanism to connect to the ABCI application: socket | grpc +-abci = "socket" +- +-# If true, query the ABCI app on connecting to a new peer +-# so the app can decide if we should keep the connection or not +-filter_peers = false +- +- +-####################################################################### +-### Advanced Configuration Options ### +-####################################################################### +- +-####################################################### +-### RPC Server Configuration Options ### +-####################################################### +-[rpc] +- +-# TCP or UNIX socket address for the RPC server to listen on +-laddr = "tcp://127.0.0.1:26657" +- +-# A list of origins a cross-domain request can be executed from +-# Default value '[]' disables cors support +-# Use '["*"]' to allow any origin +-cors_allowed_origins = [] +- +-# A list of methods the client is allowed to use with cross-domain requests +-cors_allowed_methods = ["HEAD", "GET", "POST", ] +- +-# A list of non simple headers the client is allowed to use with cross-domain requests +-cors_allowed_headers = ["Origin", "Accept", "Content-Type", "X-Requested-With", "X-Server-Time", ] +- +-# TCP or UNIX socket address for the gRPC server to listen on +-# NOTE: This server only supports /broadcast_tx_commit +-grpc_laddr = "" +- +-# Maximum number of simultaneous connections. +-# Does not include RPC (HTTP&WebSocket) connections. See max_open_connections +-# If you want to accept a larger number than the default, make sure +-# you increase your OS limits. +-# 0 - unlimited. +-# Should be < {ulimit -Sn} - {MaxNumInboundPeers} - {MaxNumOutboundPeers} - {N of wal, db and other open files} +-# 1024 - 40 - 10 - 50 = 924 = ~900 +-grpc_max_open_connections = 900 +- +-# Activate unsafe RPC commands like /dial_seeds and /unsafe_flush_mempool +-unsafe = false +- +-# Maximum number of simultaneous connections (including WebSocket). +-# Does not include gRPC connections. See grpc_max_open_connections +-# If you want to accept a larger number than the default, make sure +-# you increase your OS limits. +-# 0 - unlimited. +-# Should be < {ulimit -Sn} - {MaxNumInboundPeers} - {MaxNumOutboundPeers} - {N of wal, db and other open files} +-# 1024 - 40 - 10 - 50 = 924 = ~900 +-max_open_connections = 900 +- +-# Maximum number of unique clientIDs that can /subscribe +-# If you're using /broadcast_tx_commit, set to the estimated maximum number +-# of broadcast_tx_commit calls per block. +-max_subscription_clients = 100 +- +-# Maximum number of unique queries a given client can /subscribe to +-# If you're using GRPC (or Local RPC client) and /broadcast_tx_commit, set to +-# the estimated # maximum number of broadcast_tx_commit calls per block. +-max_subscriptions_per_client = 5 +- +-# Experimental parameter to specify the maximum number of events a node will +-# buffer, per subscription, before returning an error and closing the +-# subscription. Must be set to at least 100, but higher values will accommodate +-# higher event throughput rates (and will use more memory). +-experimental_subscription_buffer_size = 200 +- +-# Experimental parameter to specify the maximum number of RPC responses that +-# can be buffered per WebSocket client. If clients cannot read from the +-# WebSocket endpoint fast enough, they will be disconnected, so increasing this +-# parameter may reduce the chances of them being disconnected (but will cause +-# the node to use more memory). +-# +-# Must be at least the same as "experimental_subscription_buffer_size", +-# otherwise connections could be dropped unnecessarily. This value should +-# ideally be somewhat higher than "experimental_subscription_buffer_size" to +-# accommodate non-subscription-related RPC responses. +-experimental_websocket_write_buffer_size = 200 +- +-# If a WebSocket client cannot read fast enough, at present we may +-# silently drop events instead of generating an error or disconnecting the +-# client. +-# +-# Enabling this experimental parameter will cause the WebSocket connection to +-# be closed instead if it cannot read fast enough, allowing for greater +-# predictability in subscription behaviour. +-experimental_close_on_slow_client = false +- +-# How long to wait for a tx to be committed during /broadcast_tx_commit. +-# WARNING: Using a value larger than 10s will result in increasing the +-# global HTTP write timeout, which applies to all connections and endpoints. +-# See https://github.com/tendermint/tendermint/issues/3435 +-timeout_broadcast_tx_commit = "10s" +- +-# Maximum size of request body, in bytes +-max_body_bytes = 1000000 +- +-# Maximum size of request header, in bytes +-max_header_bytes = 1048576 +- +-# The path to a file containing certificate that is used to create the HTTPS server. +-# Might be either absolute path or path related to CometBFT's config directory. +-# If the certificate is signed by a certificate authority, +-# the certFile should be the concatenation of the server's certificate, any intermediates, +-# and the CA's certificate. +-# NOTE: both tls_cert_file and tls_key_file must be present for CometBFT to create HTTPS server. +-# Otherwise, HTTP server is run. +-tls_cert_file = "" +- +-# The path to a file containing matching private key that is used to create the HTTPS server. +-# Might be either absolute path or path related to CometBFT's config directory. +-# NOTE: both tls-cert-file and tls-key-file must be present for CometBFT to create HTTPS server. +-# Otherwise, HTTP server is run. +-tls_key_file = "" +- +-# pprof listen address (https://golang.org/pkg/net/http/pprof) +-pprof_laddr = "" +- +-####################################################### +-### P2P Configuration Options ### +-####################################################### +-[p2p] +- +-# Address to listen for incoming connections +-laddr = "tcp://0.0.0.0:26656" +- +-# Address to advertise to peers for them to dial +-# If empty, will use the same port as the laddr, +-# and will introspect on the listener or use UPnP +-# to figure out the address. ip and port are required +-# example: 159.89.10.97:26656 +-external_address = "" +- +-# Comma separated list of seed nodes to connect to +-seeds = "" +- +-# Comma separated list of nodes to keep persistent connections to +-persistent_peers = "" +- +-# UPNP port forwarding +-upnp = false +- +-# Path to address book +-addr_book_file = "config/addrbook.json" +- +-# Set true for strict address routability rules +-# Set false for private or local networks +-addr_book_strict = true +- +-# Maximum number of inbound peers +-max_num_inbound_peers = 40 +- +-# Maximum number of outbound peers to connect to, excluding persistent peers +-max_num_outbound_peers = 10 +- +-# List of node IDs, to which a connection will be (re)established ignoring any existing limits +-unconditional_peer_ids = "" +- +-# Maximum pause when redialing a persistent peer (if zero, exponential backoff is used) +-persistent_peers_max_dial_period = "0s" +- +-# Time to wait before flushing messages out on the connection +-flush_throttle_timeout = "100ms" +- +-# Maximum size of a message packet payload, in bytes +-max_packet_msg_payload_size = 1024 +- +-# Rate at which packets can be sent, in bytes/second +-send_rate = 5120000 +- +-# Rate at which packets can be received, in bytes/second +-recv_rate = 5120000 +- +-# Set true to enable the peer-exchange reactor +-pex = true +- +-# Seed mode, in which node constantly crawls the network and looks for +-# peers. If another node asks it for addresses, it responds and disconnects. +-# +-# Does not work if the peer-exchange reactor is disabled. +-seed_mode = false +- +-# Comma separated list of peer IDs to keep private (will not be gossiped to other peers) +-private_peer_ids = "" +- +-# Toggle to disable guard against peers connecting from the same ip. +-allow_duplicate_ip = false +- +-# Peer connection configuration. +-handshake_timeout = "20s" +-dial_timeout = "3s" +- +-####################################################### +-### Mempool Configuration Option ### +-####################################################### +-[mempool] +- +-# Mempool version to use: +-# 1) "v0" - (default) FIFO mempool. +-# 2) "v1" - prioritized mempool. +-version = "v0" +- +-# Recheck (default: true) defines whether CometBFT should recheck the +-# validity for all remaining transaction in the mempool after a block. +-# Since a block affects the application state, some transactions in the +-# mempool may become invalid. If this does not apply to your application, +-# you can disable rechecking. +-recheck = true +-broadcast = true +-wal_dir = "" +- +-# Maximum number of transactions in the mempool +-size = 5000 +- +-# Limit the total size of all txs in the mempool. +-# This only accounts for raw transactions (e.g. given 1MB transactions and +-# max_txs_bytes=5MB, mempool will only accept 5 transactions). +-max_txs_bytes = 1073741824 +- +-# Size of the cache (used to filter transactions we saw earlier) in transactions +-cache_size = 10000 +- +-# Do not remove invalid transactions from the cache (default: false) +-# Set to true if it's not possible for any invalid transaction to become valid +-# again in the future. +-keep-invalid-txs-in-cache = false +- +-# Maximum size of a single transaction. +-# NOTE: the max size of a tx transmitted over the network is {max_tx_bytes}. +-max_tx_bytes = 1048576 +- +-# Maximum size of a batch of transactions to send to a peer +-# Including space needed by encoding (one varint per transaction). +-# XXX: Unused due to https://github.com/tendermint/tendermint/issues/5796 +-max_batch_bytes = 0 +- +-# ttl-duration, if non-zero, defines the maximum amount of time a transaction +-# can exist for in the mempool. +-# +-# Note, if ttl-num-blocks is also defined, a transaction will be removed if it +-# has existed in the mempool at least ttl-num-blocks number of blocks or if it's +-# insertion time into the mempool is beyond ttl-duration. +-ttl-duration = "0s" +- +-# ttl-num-blocks, if non-zero, defines the maximum number of blocks a transaction +-# can exist for in the mempool. +-# +-# Note, if ttl-duration is also defined, a transaction will be removed if it +-# has existed in the mempool at least ttl-num-blocks number of blocks or if +-# it's insertion time into the mempool is beyond ttl-duration. +-ttl-num-blocks = 0 +- +-####################################################### +-### State Sync Configuration Options ### +-####################################################### +-[statesync] +-# State sync rapidly bootstraps a new node by discovering, fetching, and restoring a state machine +-# snapshot from peers instead of fetching and replaying historical blocks. Requires some peers in +-# the network to take and serve state machine snapshots. State sync is not attempted if the node +-# has any local state (LastBlockHeight > 0). The node will have a truncated block history, +-# starting from the height of the snapshot. +-enable = false +- +-# RPC servers (comma-separated) for light client verification of the synced state machine and +-# retrieval of state data for node bootstrapping. Also needs a trusted height and corresponding +-# header hash obtained from a trusted source, and a period during which validators can be trusted. +-# +-# For Cosmos SDK-based chains, trust_period should usually be about 2/3 of the unbonding time (~2 +-# weeks) during which they can be financially punished (slashed) for misbehavior. +-rpc_servers = "" +-trust_height = 0 +-trust_hash = "" +-trust_period = "168h0m0s" +- +-# Time to spend discovering snapshots before initiating a restore. +-discovery_time = "15s" +- +-# Temporary directory for state sync snapshot chunks, defaults to the OS tempdir (typically /tmp). +-# Will create a new, randomly named directory within, and remove it when done. +-temp_dir = "" +- +-# The timeout duration before re-requesting a chunk, possibly from a different +-# peer (default: 1 minute). +-chunk_request_timeout = "10s" +- +-# The number of concurrent chunk fetchers to run (default: 1). +-chunk_fetchers = "4" +- +-####################################################### +-### Fast Sync Configuration Connections ### +-####################################################### +-[fastsync] +- +-# Fast Sync version to use: +-# 1) "v0" (default) - the legacy fast sync implementation +-# 2) "v1" - refactor of v0 version for better testability +-# 2) "v2" - complete redesign of v0, optimized for testability & readability +-version = "v0" +- +-####################################################### +-### Consensus Configuration Options ### +-####################################################### +-[consensus] +- +-wal_file = "data/cs.wal/wal" +- +-# How long we wait for a proposal block before prevoting nil +-timeout_propose = "3s" +-# How much timeout_propose increases with each round +-timeout_propose_delta = "500ms" +-# How long we wait after receiving +2/3 prevotes for “anything” (ie. not a single block or nil) +-timeout_prevote = "1s" +-# How much the timeout_prevote increases with each round +-timeout_prevote_delta = "500ms" +-# How long we wait after receiving +2/3 precommits for “anything” (ie. not a single block or nil) +-timeout_precommit = "1s" +-# How much the timeout_precommit increases with each round +-timeout_precommit_delta = "500ms" +-# How long we wait after committing a block, before starting on the new +-# height (this gives us a chance to receive some more precommits, even +-# though we already have +2/3). +-timeout_commit = "1s" +- +-# How many blocks to look back to check existence of the node's consensus votes before joining consensus +-# When non-zero, the node will panic upon restart +-# if the same consensus key was used to sign {double_sign_check_height} last blocks. +-# So, validators should stop the state machine, wait for some blocks, and then restart the state machine to avoid panic. +-double_sign_check_height = 0 +- +-# Make progress as soon as we have all the precommits (as if TimeoutCommit = 0) +-skip_timeout_commit = false +- +-# EmptyBlocks mode and possible interval between empty blocks +-create_empty_blocks = true +-create_empty_blocks_interval = "0s" +- +-# Reactor sleep duration parameters +-peer_gossip_sleep_duration = "100ms" +-peer_query_maj23_sleep_duration = "2s" +- +-####################################################### +-### Storage Configuration Options ### +-####################################################### +-[storage] +- +-# Set to true to discard ABCI responses from the state store, which can save a +-# considerable amount of disk space. Set to false to ensure ABCI responses are +-# persisted. ABCI responses are required for /block_results RPC queries, and to +-# reindex events in the command-line tool. +-discard_abci_responses = false +- +-####################################################### +-### Transaction Indexer Configuration Options ### +-####################################################### +-[tx_index] +- +-# What indexer to use for transactions +-# +-# The application will set which txs to index. In some cases a node operator will be able +-# to decide which txs to index based on configuration set in the application. +-# +-# Options: +-# 1) "null" +-# 2) "kv" (default) - the simplest possible indexer, backed by key-value storage (defaults to levelDB; see DBBackend). +-# - When "kv" is chosen "tx.height" and "tx.hash" will always be indexed. +-# 3) "psql" - the indexer services backed by PostgreSQL. +-# When "kv" or "psql" is chosen "tx.height" and "tx.hash" will always be indexed. +-indexer = "kv" +- +-# The PostgreSQL connection configuration, the connection format: +-# postgresql://:@:/? +-psql-conn = "" +- +-####################################################### +-### Instrumentation Configuration Options ### +-####################################################### +-[instrumentation] +- +-# When true, Prometheus metrics are served under /metrics on +-# PrometheusListenAddr. +-# Check out the documentation for the list of available metrics. +-prometheus = false +- +-# Address to listen for Prometheus collector(s) connections +-prometheus_listen_addr = ":26660" +- +-# Maximum number of simultaneous connections. +-# If you want to accept a larger number than the default, make sure +-# you increase your OS limits. +-# 0 - unlimited. +-max_open_connections = 3 +- +-# Instrumentation namespace +-namespace = "cometbft" +- ``` +- +-## Empty blocks VS no empty blocks +-### create_empty_blocks = true +- +-If `create_empty_blocks` is set to `true` in your config, blocks will be created ~ every second (with default consensus parameters). You can regulate the delay between blocks by changing the `timeout_commit`. E.g. `timeout_commit = "10s"` should result in ~ 10 second blocks. +- +-### create_empty_blocks = false +- +-In this setting, blocks are created when transactions received. +- +-Note after the block H, CometBFT creates something we call a "proof block" (only if the application hash changed) H+1. The reason for this is to support proofs. If you have a transaction in block H that changes the state to X, the new application hash will only be included in block H+1. If after your transaction is committed, you want to get a light-client proof for the new state (X), you need the new block to be committed in order to do that because the new block has the new application hash for the state X. That's why we make a new (empty) block if the application hash changes. Otherwise, you won't be able to make a proof for the new state. +- +-Plus, if you set `create_empty_blocks_interval` to something other than the default (`0`), CometBFT will be creating empty blocks even in the absence of transactions every `create_empty_blocks_interval.` For instance, with `create_empty_blocks = false` and `create_empty_blocks_interval = "30s"`, CometBFT will only create blocks if there are transactions, or after waiting 30 seconds without receiving any transactions. +- +-## Consensus timeouts explained +-There's a variety of information about timeouts in [Running in +-production](./running-in-production.md#configuration-parameters). +-You can also find more detailed explanation in the paper describing +-the Tendermint consensus algorithm, adopted by CometBFT: [The latest +-gossip on BFT consensus](https://arxiv.org/abs/1807.04938). +- +-```toml +-[consensus] +-... +- +-timeout_propose = "3s" +-timeout_propose_delta = "500ms" +-timeout_prevote = "1s" +-timeout_prevote_delta = "500ms" +-timeout_precommit = "1s" +-timeout_precommit_delta = "500ms" +-timeout_commit = "1s" +-``` +-Note that in a successful round, the only timeout that we absolutely wait no +-matter what is `timeout_commit`. +-Here's a brief summary of the timeouts: +-- `timeout_propose` = how long a validator should wait for a proposal block before prevoting nil +-- `timeout_propose_delta` = how much `timeout_propose` increases with each round +-- `timeout_prevote` = how long a validator should wait after receiving +2/3 prevotes for +- anything (ie. not a single block or nil) +-- `timeout_prevote_delta` = how much the `timeout_prevote` increases with each round +-- `timeout_precommit` = how long a validator should wait after receiving +2/3 precommits for +- anything (ie. not a single block or nil) +-- `timeout_precommit_delta` = how much the `timeout_precommit` increases with each round +-- `timeout_commit` = how long a validator should wait after committing a block, before starting +- on the new height (this gives us a chance to receive some more precommits, +- even though we already have +2/3) +- diff --git a/patches/docs/core/fast-sync.md.patch b/patches/docs/core/fast-sync.md.patch new file mode 100644 index 00000000000..739e153df2a --- /dev/null +++ b/patches/docs/core/fast-sync.md.patch @@ -0,0 +1,54 @@ +diff --git a/docs/core/fast-sync.md b/docs/core/fast-sync.md +deleted file mode 100644 +index b3a13a34f..000000000 +--- a/docs/core/fast-sync.md ++++ /dev/null +@@ -1,48 +0,0 @@ +---- +-order: 10 +---- +- +-# Fast Sync +- +-In a proof of work blockchain, syncing with the chain is the same +-process as staying up-to-date with the consensus: download blocks, and +-look for the one with the most total work. In proof-of-stake, the +-consensus process is more complex, as it involves rounds of +-communication between the nodes to determine what block should be +-committed next. Using this process to sync up with the blockchain from +-scratch can take a very long time. It's much faster to just download +-blocks and check the merkle tree of validators than to run the real-time +-consensus gossip protocol. +- +-## Using Fast Sync +- +-To support faster syncing, CometBFT offers a `fast-sync` mode, which +-is enabled by default, and can be toggled in the `config.toml` or via +-`--fast_sync=false`. +- +-In this mode, the CometBFT daemon will sync hundreds of times faster +-than if it used the real-time consensus process. Once caught up, the +-daemon will switch out of fast sync and into the normal consensus mode. +-After running for some time, the node is considered `caught up` if it +-has at least one peer and its height is at least as high as the max +-reported peer height. +-See [the IsCaughtUp method](https://github.com/cometbft/cometbft/blob/v0.34.x/blockchain/v0/pool.go#L168). +- +-Note: There are three versions of fast sync. We recommend using v0 as v1 and v2 are still in beta. +- If you would like to use a different version you can do so by changing the version in the `config.toml`: +- +-```toml +-####################################################### +-### Fast Sync Configuration Connections ### +-####################################################### +-[fastsync] +- +-# Fast Sync version to use: +-# 1) "v0" (default) - the legacy fast sync implementation +-# 2) "v1" - refactor of v0 version for better testability +-# 2) "v2" - complete redesign of v0, optimized for testability & readability +-version = "v0" +-``` +- +-If we're lagging sufficiently, we should go back to fast syncing, but +-this is an [open issue](https://github.com/tendermint/tendermint/issues/129). diff --git a/patches/docs/core/how-to-read-logs.md.patch b/patches/docs/core/how-to-read-logs.md.patch new file mode 100644 index 00000000000..853951e0a4b --- /dev/null +++ b/patches/docs/core/how-to-read-logs.md.patch @@ -0,0 +1,150 @@ +diff --git a/docs/core/how-to-read-logs.md b/docs/core/how-to-read-logs.md +deleted file mode 100644 +index e94a7570f..000000000 +--- a/docs/core/how-to-read-logs.md ++++ /dev/null +@@ -1,144 +0,0 @@ +---- +-order: 7 +---- +- +-# How to read logs +- +-## Walkabout example +- +-We first create three connections (mempool, consensus and query) to the +-application (running `kvstore` locally in this case). +- +-```sh +-I[10-04|13:54:27.364] Starting multiAppConn module=proxy impl=multiAppConn +-I[10-04|13:54:27.366] Starting localClient module=abci-client connection=query impl=localClient +-I[10-04|13:54:27.366] Starting localClient module=abci-client connection=mempool impl=localClient +-I[10-04|13:54:27.367] Starting localClient module=abci-client connection=consensus impl=localClient +-``` +- +-Then CometBFT and the application perform a handshake. +- +-```sh +-I[10-04|13:54:27.367] ABCI Handshake module=consensus appHeight=90 appHash=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD +-I[10-04|13:54:27.368] ABCI Replay Blocks module=consensus appHeight=90 storeHeight=90 stateHeight=90 +-I[10-04|13:54:27.368] Completed ABCI Handshake - CometBFT and App are synced module=consensus appHeight=90 appHash=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD +-``` +- +-After that, we start a few more things like the event switch, reactors, +-and perform UPNP discover in order to detect the IP address. +- +-```sh +-I[10-04|13:54:27.374] Starting EventSwitch module=types impl=EventSwitch +-I[10-04|13:54:27.375] This node is a validator module=consensus +-I[10-04|13:54:27.379] Starting Node module=main impl=Node +-I[10-04|13:54:27.381] Local listener module=p2p ip=:: port=26656 +-I[10-04|13:54:27.382] Getting UPNP external address module=p2p +-I[10-04|13:54:30.386] Could not perform UPNP discover module=p2p err="write udp4 0.0.0.0:38238->239.255.255.250:1900: i/o timeout" +-I[10-04|13:54:30.386] Starting DefaultListener module=p2p impl=Listener(@10.0.2.15:26656) +-I[10-04|13:54:30.387] Starting P2P Switch module=p2p impl="P2P Switch" +-I[10-04|13:54:30.387] Starting MempoolReactor module=mempool impl=MempoolReactor +-I[10-04|13:54:30.387] Starting BlockchainReactor module=blockchain impl=BlockchainReactor +-I[10-04|13:54:30.387] Starting ConsensusReactor module=consensus impl=ConsensusReactor +-I[10-04|13:54:30.387] ConsensusReactor module=consensus fastSync=false +-I[10-04|13:54:30.387] Starting ConsensusState module=consensus impl=ConsensusState +-I[10-04|13:54:30.387] Starting WAL module=consensus wal=/home/vagrant/.cometbft/data/cs.wal/wal impl=WAL +-I[10-04|13:54:30.388] Starting TimeoutTicker module=consensus impl=TimeoutTicker +-``` +- +-Notice the second row where CometBFT reports that "This node is a +-validator". It also could be just an observer (regular node). +- +-Next we replay all the messages from the WAL. +- +-```sh +-I[10-04|13:54:30.390] Catchup by replaying consensus messages module=consensus height=91 +-I[10-04|13:54:30.390] Replay: New Step module=consensus height=91 round=0 step=RoundStepNewHeight +-I[10-04|13:54:30.390] Replay: Done module=consensus +-``` +- +-"Started node" message signals that everything is ready for work. +- +-```sh +-I[10-04|13:54:30.391] Starting RPC HTTP server on tcp socket 0.0.0.0:26657 module=rpc-server +-I[10-04|13:54:30.392] Started node module=main nodeInfo="NodeInfo{id: DF22D7C92C91082324A1312F092AA1DA197FA598DBBFB6526E, moniker: anonymous, network: test-chain-3MNw2N [remote , listen 10.0.2.15:26656], version: 0.11.0-10f361fc ([wire_version=0.6.2 p2p_version=0.5.0 consensus_version=v1/0.2.2 rpc_version=0.7.0/3 tx_index=on rpc_addr=tcp://0.0.0.0:26657])}" +-``` +- +-Next follows a standard block creation cycle, where we enter a new +-round, propose a block, receive more than 2/3 of prevotes, then +-precommits and finally have a chance to commit a block. For details, +-please refer to [Byzantine Consensus Algorithm](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/consensus/consensus.md). +- +-```sh +-I[10-04|13:54:30.393] enterNewRound(91/0). Current: 91/0/RoundStepNewHeight module=consensus +-I[10-04|13:54:30.393] enterPropose(91/0). Current: 91/0/RoundStepNewRound module=consensus +-I[10-04|13:54:30.393] enterPropose: Our turn to propose module=consensus proposer=125B0E3C5512F5C2B0E1109E31885C4511570C42 privValidator="PrivValidator{125B0E3C5512F5C2B0E1109E31885C4511570C42 LH:90, LR:0, LS:3}" +-I[10-04|13:54:30.394] Signed proposal module=consensus height=91 round=0 proposal="Proposal{91/0 1:21B79872514F (-1,:0:000000000000) {/10EDEDD7C84E.../}}" +-I[10-04|13:54:30.397] Received complete proposal block module=consensus height=91 hash=F671D562C7B9242900A286E1882EE64E5556FE9E +-I[10-04|13:54:30.397] enterPrevote(91/0). Current: 91/0/RoundStepPropose module=consensus +-I[10-04|13:54:30.397] enterPrevote: ProposalBlock is valid module=consensus height=91 round=0 +-I[10-04|13:54:30.398] Signed and pushed vote module=consensus height=91 round=0 vote="Vote{0:125B0E3C5512 91/00/1(Prevote) F671D562C7B9 {/89047FFC21D8.../}}" err=null +-I[10-04|13:54:30.401] Added to prevote module=consensus vote="Vote{0:125B0E3C5512 91/00/1(Prevote) F671D562C7B9 {/89047FFC21D8.../}}" prevotes="VoteSet{H:91 R:0 T:1 +2/3:F671D562C7B9242900A286E1882EE64E5556FE9E:1:21B79872514F BA{1:X} map[]}" +-I[10-04|13:54:30.401] enterPrecommit(91/0). Current: 91/0/RoundStepPrevote module=consensus +-I[10-04|13:54:30.401] enterPrecommit: +2/3 prevoted proposal block. Locking module=consensus hash=F671D562C7B9242900A286E1882EE64E5556FE9E +-I[10-04|13:54:30.402] Signed and pushed vote module=consensus height=91 round=0 vote="Vote{0:125B0E3C5512 91/00/2(Precommit) F671D562C7B9 {/80533478E41A.../}}" err=null +-I[10-04|13:54:30.404] Added to precommit module=consensus vote="Vote{0:125B0E3C5512 91/00/2(Precommit) F671D562C7B9 {/80533478E41A.../}}" precommits="VoteSet{H:91 R:0 T:2 +2/3:F671D562C7B9242900A286E1882EE64E5556FE9E:1:21B79872514F BA{1:X} map[]}" +-I[10-04|13:54:30.404] enterCommit(91/0). Current: 91/0/RoundStepPrecommit module=consensus +-I[10-04|13:54:30.405] Finalizing commit of block with 0 txs module=consensus height=91 hash=F671D562C7B9242900A286E1882EE64E5556FE9E root=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD +-I[10-04|13:54:30.405] Block{ +- Header{ +- ChainID: test-chain-3MNw2N +- Height: 91 +- Time: 2017-10-04 13:54:30.393 +0000 UTC +- NumTxs: 0 +- LastBlockID: F15AB8BEF9A6AAB07E457A6E16BC410546AA4DC6:1:D505DA273544 +- LastCommit: 56FEF2EFDB8B37E9C6E6D635749DF3169D5F005D +- Data: +- Validators: CE25FBFF2E10C0D51AA1A07C064A96931BC8B297 +- App: E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD +- }#F671D562C7B9242900A286E1882EE64E5556FE9E +- Data{ +- +- }# +- Commit{ +- BlockID: F15AB8BEF9A6AAB07E457A6E16BC410546AA4DC6:1:D505DA273544 +- Precommits: Vote{0:125B0E3C5512 90/00/2(Precommit) F15AB8BEF9A6 {/FE98E2B956F0.../}} +- }#56FEF2EFDB8B37E9C6E6D635749DF3169D5F005D +-}#F671D562C7B9242900A286E1882EE64E5556FE9E module=consensus +-I[10-04|13:54:30.408] Executed block module=state height=91 validTxs=0 invalidTxs=0 +-I[10-04|13:54:30.410] Committed state module=state height=91 txs=0 hash=E0FBAFBF6FCED8B9786DDFEB1A0D4FA2501BADAD +-I[10-04|13:54:30.410] Recheck txs module=mempool numtxs=0 height=91 +-``` +- +-## List of modules +- +-Here is the list of modules you may encounter in CometBFT's log and a +-little overview what they do. +- +-- `abci-client` As mentioned in [Application Development Guide](../app-dev/abci-cli.md), CometBFT acts as an ABCI +- client with respect to the application and maintains 3 connections: +- mempool, consensus and query. The code used by CometBFT can +- be found [here](https://github.com/cometbft/cometbft/blob/v0.34.x/abci/client). +-- `blockchain` Provides storage, pool (a group of peers), and reactor +- for both storing and exchanging blocks between peers. +-- `consensus` The heart of CometBFT, which is the +- implementation of the consensus algorithm. Includes two +- "submodules": `wal` (write-ahead logging) for ensuring data +- integrity and `replay` to replay blocks and messages on recovery +- from a crash. +-- `events` Simple event notification system. The list of events can be +- found +- [here](https://github.com/cometbft/cometbft/blob/v0.34.x/types/events.go). +- You can subscribe to them by calling `subscribe` RPC method. Refer +- to [RPC docs](./rpc.md) for additional information. +-- `mempool` Mempool module handles all incoming transactions, whenever +- they are coming from peers or the application. +-- `p2p` Provides an abstraction around peer-to-peer communication. For +- more details, please check out the +- [README](https://github.com/cometbft/cometbft/blob/v0.34.x/p2p/README.md). +-- `rpc` [CometBFT's RPC](./rpc.md). +-- `rpc-server` RPC server. For implementation details, please read the +- [doc.go](https://github.com/cometbft/cometbft/blob/v0.34.x/rpc/jsonrpc/doc.go). +-- `state` Represents the latest state and execution submodule, which +- executes blocks against the application. +-- `types` A collection of the publicly exposed types and methods to +- work with them. diff --git a/patches/docs/core/light-client.md.patch b/patches/docs/core/light-client.md.patch new file mode 100644 index 00000000000..ba7ca5ee930 --- /dev/null +++ b/patches/docs/core/light-client.md.patch @@ -0,0 +1,75 @@ +diff --git a/docs/core/light-client.md b/docs/core/light-client.md +deleted file mode 100644 +index 4a08a5129..000000000 +--- a/docs/core/light-client.md ++++ /dev/null +@@ -1,69 +0,0 @@ +---- +-order: 13 +---- +- +-# Light Client +- +-Light clients are an important part of the complete blockchain system for most +-applications. CometBFT provides unique speed and security properties for +-light client applications. +- +-See our [light +-package](https://pkg.go.dev/github.com/cometbft/cometbft/light?tab=doc). +- +-## Overview +- +-The objective of the light client protocol is to get a commit for a recent +-block hash where the commit includes a majority of signatures from the last +-known validator set. From there, all the application state is verifiable with +-[merkle proofs](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/core/encoding.md#iavl-tree). +- +-## Properties +- +-- You get the full collateralized security benefits of CometBFT; no +- need to wait for confirmations. +-- You get the full speed benefits of CometBFT; transactions +- commit instantly. +-- You can get the most recent version of the application state +- non-interactively (without committing anything to the blockchain). For +- example, this means that you can get the most recent value of a name from the +- name-registry without worrying about fork censorship attacks, without posting +- a commit and waiting for confirmations. It's fast, secure, and free! +- +-## Where to obtain trusted height & hash +- +-[Trust Options](https://pkg.go.dev/github.com/cometbft/cometbft/light?tab=doc#TrustOptions) +- +-One way to obtain semi-trusted hash & height is to query multiple full nodes +-and compare their hashes: +- +-```bash +-$ curl -s https://233.123.0.140:26657:26657/commit | jq "{height: .result.signed_header.header.height, hash: .result.signed_header.commit.block_id.hash}" +-{ +- "height": "273", +- "hash": "188F4F36CBCD2C91B57509BBF231C777E79B52EE3E0D90D06B1A25EB16E6E23D" +-} +-``` +- +-## Running a light client as an HTTP proxy server +- +-CometBFT comes with a built-in `cometbft light` command, which can be used +-to run a light client proxy server, verifying CometBFT RPC. All calls that +-can be tracked back to a block header by a proof will be verified before +-passing them back to the caller. Other than that, it will present the same +-interface as a full CometBFT node. +- +-You can start the light client proxy server by running `cometbft light `, +-with a variety of flags to specify the primary node, the witness nodes (which cross-check +-the information provided by the primary), the hash and height of the trusted header, +-and more. +- +-For example: +- +-```bash +-$ cometbft light supernova -p tcp://233.123.0.140:26657 \ +- -w tcp://179.63.29.15:26657,tcp://144.165.223.135:26657 \ +- --height=10 --hash=37E9A6DD3FA25E83B22C18835401E8E56088D0D7ABC6FD99FCDC920DD76C1C57 +-``` +- +-For additional options, run `cometbft light --help`. diff --git a/patches/docs/core/mempool.md.patch b/patches/docs/core/mempool.md.patch new file mode 100644 index 00000000000..6a8f663bacc --- /dev/null +++ b/patches/docs/core/mempool.md.patch @@ -0,0 +1,54 @@ +diff --git a/docs/core/mempool.md b/docs/core/mempool.md +deleted file mode 100644 +index 8dd968781..000000000 +--- a/docs/core/mempool.md ++++ /dev/null +@@ -1,48 +0,0 @@ +---- +-order: 12 +---- +- +-# Mempool +- +-## Transaction ordering +- +-Currently, there's no ordering of transactions other than the order they've +-arrived (via RPC or from other nodes). +- +-So the only way to specify the order is to send them to a single node. +- +-valA: +- +-- `tx1` +-- `tx2` +-- `tx3` +- +-If the transactions are split up across different nodes, there's no way to +-ensure they are processed in the expected order. +- +-valA: +- +-- `tx1` +-- `tx2` +- +-valB: +- +-- `tx3` +- +-If valB is the proposer, the order might be: +- +-- `tx3` +-- `tx1` +-- `tx2` +- +-If valA is the proposer, the order might be: +- +-- `tx1` +-- `tx2` +-- `tx3` +- +-That said, if the transactions contain some internal value, like an +-order/nonce/sequence number, the application can reject transactions that are +-out of order. So if a node receives `tx3`, then `tx1`, it can reject `tx3` and then +-accept `tx1`. The sender can then retry sending `tx3`, which should probably be +-rejected until the node has seen `tx2`. diff --git a/patches/docs/core/metrics.md.patch b/patches/docs/core/metrics.md.patch new file mode 100644 index 00000000000..e7c47b75b08 --- /dev/null +++ b/patches/docs/core/metrics.md.patch @@ -0,0 +1,71 @@ +diff --git a/docs/core/metrics.md b/docs/core/metrics.md +deleted file mode 100644 +index 749c2a7b6..000000000 +--- a/docs/core/metrics.md ++++ /dev/null +@@ -1,65 +0,0 @@ +---- +-order: 5 +---- +- +-# Metrics +- +-CometBFT can report and serve the Prometheus metrics, which in their turn can +-be consumed by Prometheus collector(s). +- +-This functionality is disabled by default. +- +-To enable the Prometheus metrics, set `instrumentation.prometheus=true` in your +-config file. Metrics will be served under `/metrics` on 26660 port by default. +-Listen address can be changed in the config file (see +-`instrumentation.prometheus\_listen\_addr`). +- +-## List of available metrics +- +-The following metrics are available: +- +-| **Name** | **Type** | **Tags** | **Description** | +-|--------------------------------------------|-----------|------------------|------------------------------------------------------------------------| +-| consensus\_height | Gauge | | Height of the chain | +-| consensus\_validators | Gauge | | Number of validators | +-| consensus\_validators\_power | Gauge | | Total voting power of all validators | +-| consensus\_validator\_power | Gauge | | Voting power of the node if in the validator set | +-| consensus\_validator\_last\_signed\_height | Gauge | | Last height the node signed a block, if the node is a validator | +-| consensus\_validator\_missed\_blocks | Gauge | | Total amount of blocks missed for the node, if the node is a validator | +-| consensus\_missing\_validators | Gauge | | Number of validators who did not sign | +-| consensus\_missing\_validators\_power | Gauge | | Total voting power of the missing validators | +-| consensus\_byzantine\_validators | Gauge | | Number of validators who tried to double sign | +-| consensus\_byzantine\_validators\_power | Gauge | | Total voting power of the byzantine validators | +-| consensus\_block\_interval\_seconds | Histogram | | Time between this and last block (Block.Header.Time) in seconds | +-| consensus\_rounds | Gauge | | Number of rounds | +-| consensus\_num\_txs | Gauge | | Number of transactions | +-| consensus\_total\_txs | Gauge | | Total number of transactions committed | +-| consensus\_block\_parts | Counter | peer\_id | Number of blockparts transmitted by peer | +-| consensus\_latest\_block\_height | Gauge | | /status sync\_info number | +-| consensus\_fast\_syncing | Gauge | | Either 0 (not fast syncing) or 1 (syncing) | +-| consensus\_state\_syncing | Gauge | | Either 0 (not state syncing) or 1 (syncing) | +-| consensus\_block\_size\_bytes | Gauge | | Block size in bytes | +-| consensus\_step\_duration | Histogram | step | Histogram of durations for each step in the consensus protocol | +-| consensus\_block\_gossip\_parts\_received | Counter | matches\_current | Number of block parts received by the node | +-| p2p\_message\_send\_bytes\_total | Counter | message\_type | Number of bytes sent to all peers per message type | +-| p2p\_message\_receive\_bytes\_total | Counter | message\_type | Number of bytes received from all peers per message type | +-| p2p\_peers | Gauge | | Number of peers node's connected to | +-| p2p\_peer\_receive\_bytes\_total | Counter | peer\_id, chID | Number of bytes per channel received from a given peer | +-| p2p\_peer\_send\_bytes\_total | Counter | peer\_id, chID | Number of bytes per channel sent to a given peer | +-| p2p\_peer\_pending\_send\_bytes | Gauge | peer\_id | Number of pending bytes to be sent to a given peer | +-| p2p\_num\_txs | Gauge | peer\_id | Number of transactions submitted by each peer\_id | +-| p2p\_pending\_send\_bytes | Gauge | peer\_id | Amount of data pending to be sent to peer | +-| mempool\_size | Gauge | | Number of uncommitted transactions | +-| mempool\_tx\_size\_bytes | Histogram | | Transaction sizes in bytes | +-| mempool\_failed\_txs | Counter | | Number of failed transactions | +-| mempool\_recheck\_times | Counter | | Number of transactions rechecked in the mempool | +-| state\_block\_processing\_time | Histogram | | Time between BeginBlock and EndBlock in ms | +- +- +-## Useful queries +- +-Percentage of missing + byzantine validators: +- +-```md +-((consensus\_byzantine\_validators\_power + consensus\_missing\_validators\_power) / consensus\_validators\_power) * 100 +-``` diff --git a/patches/docs/core/rpc.md.patch b/patches/docs/core/rpc.md.patch new file mode 100644 index 00000000000..275891263cb --- /dev/null +++ b/patches/docs/core/rpc.md.patch @@ -0,0 +1,15 @@ +diff --git a/docs/core/rpc.md b/docs/core/rpc.md +deleted file mode 100644 +index e118d5a3a..000000000 +--- a/docs/core/rpc.md ++++ /dev/null +@@ -1,9 +0,0 @@ +---- +-order: 9 +---- +- +-# RPC +- +-The RPC documentation is hosted here: +- +-- [OpenAPI reference](../rpc) diff --git a/patches/docs/core/running-in-production.md.patch b/patches/docs/core/running-in-production.md.patch new file mode 100644 index 00000000000..e166e146e0a --- /dev/null +++ b/patches/docs/core/running-in-production.md.patch @@ -0,0 +1,418 @@ +diff --git a/docs/core/running-in-production.md b/docs/core/running-in-production.md +deleted file mode 100644 +index 88ef6686c..000000000 +--- a/docs/core/running-in-production.md ++++ /dev/null +@@ -1,412 +0,0 @@ +---- +-order: 4 +---- +- +-# Running in production +- +-## Database +- +-By default, CometBFT uses the `syndtr/goleveldb` package for its in-process +-key-value database. If you want maximal performance, it may be best to install +-the real C-implementation of LevelDB and compile CometBFT to use that using +-`make build COMETBFT_BUILD_OPTIONS=cleveldb`. See the [install +-instructions](../introduction/install.md) for details. +- +-CometBFT keeps multiple distinct databases in the `$CMTHOME/data`: +- +-- `blockstore.db`: Keeps the entire blockchain - stores blocks, +- block commits, and block meta data, each indexed by height. Used to sync new +- peers. +-- `evidence.db`: Stores all verified evidence of misbehaviour. +-- `state.db`: Stores the current blockchain state (ie. height, validators, +- consensus params). Only grows if consensus params or validators change. Also +- used to temporarily store intermediate results during block processing. +-- `tx_index.db`: Indexes txs (and their results) by tx hash and by DeliverTx result events. +- +-By default, CometBFT will only index txs by their hash and height, not by their DeliverTx +-result events. See [indexing transactions](../app-dev/indexing-transactions.md) for +-details. +- +-Applications can expose block pruning strategies to the node operator. +-Please read the documentation of your application to find out more details. +- +-Applications can use [state sync](./state-sync.md) to help nodes bootstrap quickly. +- +-## Logging +- +-Default logging level (`log_level = "main:info,state:info,statesync:info,*:error"`) should suffice for +-normal operation mode. Read [this +-post](https://blog.cosmos.network/one-of-the-exciting-new-features-in-0-10-0-release-is-smart-log-level-flag-e2506b4ab756) +-for details on how to configure `log_level` config variable. Some of the +-modules can be found [here](./how-to-read-logs.md#list-of-modules). If +-you're trying to debug CometBFT or asked to provide logs with debug +-logging level, you can do so by running CometBFT with +-`--log_level="*:debug"`. +- +-## Write Ahead Logs (WAL) +- +-CometBFT uses write ahead logs for the consensus (`cs.wal`) and the mempool +-(`mempool.wal`). Both WALs have a max size of 1GB and are automatically rotated. +- +-### Consensus WAL +- +-The `consensus.wal` is used to ensure we can recover from a crash at any point +-in the consensus state machine. +-It writes all consensus messages (timeouts, proposals, block part, or vote) +-to a single file, flushing to disk before processing messages from its own +-validator. Since CometBFT validators are expected to never sign a conflicting vote, the +-WAL ensures we can always recover deterministically to the latest state of the consensus without +-using the network or re-signing any consensus messages. +- +-If your `consensus.wal` is corrupted, see [below](#wal-corruption). +- +-### Mempool WAL +- +-The `mempool.wal` logs all incoming txs before running CheckTx, but is +-otherwise not used in any programmatic way. It's just a kind of manual +-safe guard. Note the mempool provides no durability guarantees - a tx sent to one or many nodes +-may never make it into the blockchain if those nodes crash before being able to +-propose it. Clients must monitor their txs by subscribing over websockets, +-polling for them, or using `/broadcast_tx_commit`. In the worst case, txs can be +-resent from the mempool WAL manually. +- +-For the above reasons, the `mempool.wal` is disabled by default. To enable, set +-`mempool.wal_dir` to where you want the WAL to be located (e.g. +-`data/mempool.wal`). +- +-## DoS Exposure and Mitigation +- +-Validators are supposed to setup [Sentry Node Architecture](./validators.md) +-to prevent Denial-of-Service attacks. +- +-### P2P +- +-The core of the CometBFT peer-to-peer system is `MConnection`. Each +-connection has `MaxPacketMsgPayloadSize`, which is the maximum packet +-size and bounded send & receive queues. One can impose restrictions on +-send & receive rate per connection (`SendRate`, `RecvRate`). +- +-The number of open P2P connections can become quite large, and hit the operating system's open +-file limit (since TCP connections are considered files on UNIX-based systems). Nodes should be +-given a sizable open file limit, e.g. 8192, via `ulimit -n 8192` or other deployment-specific +-mechanisms. +- +-### RPC +- +-#### Attack Exposure and Mitigation +- +-**It is generally not recommended for RPC endpoints to be exposed publicly, and +-especially so if the node in question is a validator**, as the CometBFT RPC does +-not currently provide advanced security features. Public exposure of RPC +-endpoints without appropriate protection can make the associated node vulnerable +-to a variety of attacks. +- +-It is entirely up to operators to ensure, if nodes' RPC endpoints have to be +-exposed publicly, that appropriate measures have been taken to mitigate against +-attacks. Some examples of mitigation measures include, but are not limited to: +- +-- Never publicly exposing the RPC endpoints of validators (i.e. if the RPC +- endpoints absolutely have to be exposed, ensure you do so only on full nodes +- and with appropriate protection) +-- Correct usage of rate-limiting, authentication and caching (e.g. as provided +- by reverse proxies like [nginx](https://nginx.org/) and/or DDoS protection +- services like [Cloudflare](https://www.cloudflare.com)) +-- Only exposing the specific endpoints absolutely necessary for the relevant use +- cases (configurable via nginx/Cloudflare/etc.) +- +-If no expertise is available to the operator to assist with securing nodes' RPC +-endpoints, it is strongly recommended to never expose those endpoints publicly. +- +-**Under no condition should any of the [unsafe RPC endpoints](../rpc/#/Unsafe) +-ever be exposed publicly.** +- +-#### Endpoints Returning Multiple Entries +- +-Endpoints returning multiple entries are limited by default to return 30 +-elements (100 max). See the [RPC Documentation](../rpc/) for more information. +- +-## Debugging CometBFT +- +-If you ever have to debug CometBFT, the first thing you should probably do is +-check out the logs. See [How to read logs](./how-to-read-logs.md), where we +-explain what certain log statements mean. +- +-If, after skimming through the logs, things are not clear still, the next thing +-to try is querying the `/status` RPC endpoint. It provides the necessary info: +-whenever the node is syncing or not, what height it is on, etc. +- +-```bash +-curl http(s)://{ip}:{rpcPort}/status +-``` +- +-`/dump_consensus_state` will give you a detailed overview of the consensus +-state (proposer, latest validators, peers states). From it, you should be able +-to figure out why, for example, the network had halted. +- +-```bash +-curl http(s)://{ip}:{rpcPort}/dump_consensus_state +-``` +- +-There is a reduced version of this endpoint - `/consensus_state`, which returns +-just the votes seen at the current height. +- +-If, after consulting with the logs and above endpoints, you still have no idea +-what's happening, consider using `cometbft debug kill` sub-command. This +-command will scrap all the available info and kill the process. See +-[Debugging](../tools/debugging.md) for the exact format. +- +-You can inspect the resulting archive yourself or create an issue on +-[Github](https://github.com/cometbft/cometbft). Before opening an issue +-however, be sure to check if there's [no existing +-issue](https://github.com/cometbft/cometbft/issues) already. +- +-## Monitoring CometBFT +- +-Each CometBFT instance has a standard `/health` RPC endpoint, which responds +-with 200 (OK) if everything is fine and 500 (or no response) - if something is +-wrong. +- +-Other useful endpoints include mentioned earlier `/status`, `/net_info` and +-`/validators`. +- +-CometBFT also can report and serve Prometheus metrics. See +-[Metrics](./metrics.md). +- +-`cometbft debug dump` sub-command can be used to periodically dump useful +-information into an archive. See [Debugging](../tools/debugging.md) for more +-information. +- +-## What happens when my app dies +- +-You are supposed to run CometBFT under a [process +-supervisor](https://en.wikipedia.org/wiki/Process_supervision) (like +-systemd or runit). It will ensure CometBFT is always running (despite +-possible errors). +- +-Getting back to the original question, if your application dies, +-CometBFT will panic. After a process supervisor restarts your +-application, CometBFT should be able to reconnect successfully. The +-order of restart does not matter for it. +- +-## Signal handling +- +-We catch SIGINT and SIGTERM and try to clean up nicely. For other +-signals we use the default behavior in Go: +-[Default behavior of signals in Go programs](https://golang.org/pkg/os/signal/#hdr-Default_behavior_of_signals_in_Go_programs). +- +-## Corruption +- +-**NOTE:** Make sure you have a backup of the CometBFT data directory. +- +-### Possible causes +- +-Remember that most corruption is caused by hardware issues: +- +-- RAID controllers with faulty / worn out battery backup, and an unexpected power loss +-- Hard disk drives with write-back cache enabled, and an unexpected power loss +-- Cheap SSDs with insufficient power-loss protection, and an unexpected power-loss +-- Defective RAM +-- Defective or overheating CPU(s) +- +-Other causes can be: +- +-- Database systems configured with fsync=off and an OS crash or power loss +-- Filesystems configured to use write barriers plus a storage layer that ignores write barriers. LVM is a particular culprit. +-- CometBFT bugs +-- Operating system bugs +-- Admin error (e.g., directly modifying CometBFT data-directory contents) +- +-(Source: ) +- +-### WAL Corruption +- +-If consensus WAL is corrupted at the latest height and you are trying to start +-CometBFT, replay will fail with panic. +- +-Recovering from data corruption can be hard and time-consuming. Here are two approaches you can take: +- +-1. Delete the WAL file and restart CometBFT. It will attempt to sync with other peers. +-2. Try to repair the WAL file manually: +- +-1) Create a backup of the corrupted WAL file: +- +- ```sh +- cp "$CMTHOME/data/cs.wal/wal" > /tmp/corrupted_wal_backup +- ``` +- +-2) Use `./scripts/wal2json` to create a human-readable version: +- +- ```sh +- ./scripts/wal2json/wal2json "$CMTHOME/data/cs.wal/wal" > /tmp/corrupted_wal +- ``` +- +-3) Search for a "CORRUPTED MESSAGE" line. +-4) By looking at the previous message and the message after the corrupted one +- and looking at the logs, try to rebuild the message. If the consequent +- messages are marked as corrupted too (this may happen if length header +- got corrupted or some writes did not make it to the WAL ~ truncation), +- then remove all the lines starting from the corrupted one and restart +- CometBFT. +- +- ```sh +- $EDITOR /tmp/corrupted_wal +- ``` +- +-5) After editing, convert this file back into binary form by running: +- +- ```sh +- ./scripts/json2wal/json2wal /tmp/corrupted_wal $CMTHOME/data/cs.wal/wal +- ``` +- +-## Hardware +- +-### Processor and Memory +- +-While actual specs vary depending on the load and validators count, minimal +-requirements are: +- +-- 1GB RAM +-- 25GB of disk space +-- 1.4 GHz CPU +- +-SSD disks are preferable for applications with high transaction throughput. +- +-Recommended: +- +-- 2GB RAM +-- 100GB SSD +-- x64 2.0 GHz 2v CPU +- +-While for now, CometBFT stores all the history and it may require significant +-disk space over time, we are planning to implement state syncing (See [this +-issue](https://github.com/tendermint/tendermint/issues/828)). So, storing all +-the past blocks will not be necessary. +- +-### Validator signing on 32 bit architectures (or ARM) +- +-Both our `ed25519` and `secp256k1` implementations require constant time +-`uint64` multiplication. Non-constant time crypto can (and has) leaked +-private keys on both `ed25519` and `secp256k1`. This doesn't exist in hardware +-on 32 bit x86 platforms ([source](https://bearssl.org/ctmul.html)), and it +-depends on the compiler to enforce that it is constant time. It's unclear at +-this point whenever the Golang compiler does this correctly for all +-implementations. +- +-**We do not support nor recommend running a validator on 32 bit architectures OR +-the "VIA Nano 2000 Series", and the architectures in the ARM section rated +-"S-".** +- +-### Operating Systems +- +-CometBFT can be compiled for a wide range of operating systems thanks to Go +-language (the list of \$OS/\$ARCH pairs can be found +-[here](https://golang.org/doc/install/source#environment)). +- +-While we do not favor any operation system, more secure and stable Linux server +-distributions (like CentOS) should be preferred over desktop operation systems +-(like Mac OS). +- +-### Miscellaneous +- +-NOTE: if you are going to use CometBFT in a public domain, make sure +-you read [hardware recommendations](https://cosmos.network/validators) for a validator in the +-Cosmos network. +- +-## Configuration parameters +- +-- `p2p.flush_throttle_timeout` +-- `p2p.max_packet_msg_payload_size` +-- `p2p.send_rate` +-- `p2p.recv_rate` +- +-If you are going to use CometBFT in a private domain and you have a +-private high-speed network among your peers, it makes sense to lower +-flush throttle timeout and increase other params. +- +-```toml +-[p2p] +- +-send_rate=20000000 # 2MB/s +-recv_rate=20000000 # 2MB/s +-flush_throttle_timeout=10 +-max_packet_msg_payload_size=10240 # 10KB +-``` +- +-- `mempool.recheck` +- +-After every block, CometBFT rechecks every transaction left in the +-mempool to see if transactions committed in that block affected the +-application state, so some of the transactions left may become invalid. +-If that does not apply to your application, you can disable it by +-setting `mempool.recheck=false`. +- +-- `mempool.broadcast` +- +-Setting this to false will stop the mempool from relaying transactions +-to other peers until they are included in a block. It means only the +-peer you send the tx to will see it until it is included in a block. +- +-- `consensus.skip_timeout_commit` +- +-We want `skip_timeout_commit=false` when there is economics on the line +-because proposers should wait to hear for more votes. But if you don't +-care about that and want the fastest consensus, you can skip it. It will +-be kept false by default for public deployments (e.g. [Cosmos +-Hub](https://cosmos.network/intro/hub)) while for enterprise +-applications, setting it to true is not a problem. +- +-- `consensus.peer_gossip_sleep_duration` +- +-You can try to reduce the time your node sleeps before checking if +-theres something to send its peers. +- +-- `consensus.timeout_commit` +- +-You can also try lowering `timeout_commit` (time we sleep before +-proposing the next block). +- +-- `p2p.addr_book_strict` +- +-By default, CometBFT checks whenever a peer's address is routable before +-saving it to the address book. The address is considered as routable if the IP +-is [valid and within allowed ranges](https://github.com/cometbft/cometbft/blob/v0.34.x/p2p/netaddress.go#L258). +- +-This may not be the case for private or local networks, where your IP range is usually +-strictly limited and private. If that case, you need to set `addr_book_strict` +-to `false` (turn it off). +- +-- `rpc.max_open_connections` +- +-By default, the number of simultaneous connections is limited because most OS +-give you limited number of file descriptors. +- +-If you want to accept greater number of connections, you will need to increase +-these limits. +- +-[Sysctls to tune the system to be able to open more connections](https://github.com/satori-com/tcpkali/blob/master/doc/tcpkali.man.md#sysctls-to-tune-the-system-to-be-able-to-open-more-connections) +- +-The process file limits must also be increased, e.g. via `ulimit -n 8192`. +- +-...for N connections, such as 50k: +- +-```md +-kern.maxfiles=10000+2*N # BSD +-kern.maxfilesperproc=100+2*N # BSD +-kern.ipc.maxsockets=10000+2*N # BSD +-fs.file-max=10000+2*N # Linux +-net.ipv4.tcp_max_orphans=N # Linux +- +-# For load-generating clients. +-net.ipv4.ip_local_port_range="10000 65535" # Linux. +-net.inet.ip.portrange.first=10000 # BSD/Mac. +-net.inet.ip.portrange.last=65535 # (Enough for N < 55535) +-net.ipv4.tcp_tw_reuse=1 # Linux +-net.inet.tcp.maxtcptw=2*N # BSD +- +-# If using netfilter on Linux: +-net.netfilter.nf_conntrack_max=N +-echo $((N/8)) > /sys/module/nf_conntrack/parameters/hashsize +-``` +- +-The similar option exists for limiting the number of gRPC connections - +-`rpc.grpc_max_open_connections`. diff --git a/patches/docs/core/state-sync.md.patch b/patches/docs/core/state-sync.md.patch new file mode 100644 index 00000000000..6f6e36a26fe --- /dev/null +++ b/patches/docs/core/state-sync.md.patch @@ -0,0 +1,54 @@ +diff --git a/docs/core/state-sync.md b/docs/core/state-sync.md +deleted file mode 100644 +index a6e314fe5..000000000 +--- a/docs/core/state-sync.md ++++ /dev/null +@@ -1,48 +0,0 @@ +---- +-order: 11 +---- +- +-# State Sync +- +-With fast sync a node is downloading all of the data of an application from genesis and verifying it. +-With state sync your node will download data related to the head or near the head of the chain and verify the data. +-This leads to drastically shorter times for joining a network. +- +-## Using State Sync +- +-State sync will continuously work in the background to supply nodes with chunked data when bootstrapping. +- +-> NOTE: Before trying to use state sync, see if the application you are operating a node for supports it. +- +-Under the state sync section in `config.toml` you will find multiple settings that need to be configured in order for your node to use state sync. +- +-Lets breakdown the settings: +- +-- `enable`: Enable is to inform the node that you will be using state sync to bootstrap your node. +-- `rpc_servers`: RPC servers are needed because state sync utilizes the light client for verification. +- - 2 servers are required, more is always helpful. +-- `temp_dir`: Temporary directory is store the chunks in the machines local storage, If nothing is set it will create a directory in `/tmp` +- +-The next information you will need to acquire it through publicly exposed RPC's or a block explorer which you trust. +- +-- `trust_height`: Trusted height defines at which height your node should trust the chain. +-- `trust_hash`: Trusted hash is the hash in the `BlockID` corresponding to the trusted height. +-- `trust_period`: Trust period is the period in which headers can be verified. +- > :warning: This value should be significantly smaller than the unbonding period. +- +-If you are relying on publicly exposed RPC's to get the need information, you can use `curl`. +- +-Example: +- +-```bash +-curl -s https://233.123.0.140:26657/commit | jq "{height: .result.signed_header.header.height, hash: .result.signed_header.commit.block_id.hash}" +-``` +- +-The response will be: +- +-```json +-{ +- "height": "273", +- "hash": "188F4F36CBCD2C91B57509BBF231C777E79B52EE3E0D90D06B1A25EB16E6E23D" +-} +-``` diff --git a/patches/docs/core/subscription.md.patch b/patches/docs/core/subscription.md.patch new file mode 100644 index 00000000000..4f3a47f7e34 --- /dev/null +++ b/patches/docs/core/subscription.md.patch @@ -0,0 +1,97 @@ +diff --git a/docs/core/subscription.md b/docs/core/subscription.md +deleted file mode 100644 +index 796a415ff..000000000 +--- a/docs/core/subscription.md ++++ /dev/null +@@ -1,91 +0,0 @@ +---- +-order: 7 +---- +- +-# Subscribing to events via Websocket +- +-CometBFT emits different events, which you can subscribe to via +-[Websocket](https://en.wikipedia.org/wiki/WebSocket). This can be useful +-for third-party applications (for analysis) or for inspecting state. +- +-[List of events](https://godoc.org/github.com/cometbft/cometbft/types#pkg-constants) +- +-To connect to a node via websocket from the CLI, you can use a tool such as +-[wscat](https://github.com/websockets/wscat) and run: +- +-```sh +-wscat -c ws://127.0.0.1:26657/websocket +-``` +- +-NOTE: If your node's RPC endpoint is TLS-enabled, utilize the scheme `wss` instead of `ws`. +- +-You can subscribe to any of the events above by calling the `subscribe` RPC +-method via Websocket along with a valid query. +- +-```json +-{ +- "jsonrpc": "2.0", +- "method": "subscribe", +- "id": 0, +- "params": { +- "query": "tm.event='NewBlock'" +- } +-} +-``` +- +-Check out [API docs](https://docs.cometbft.com/v0.34/rpc/) for +-more information on query syntax and other options. +- +-You can also use tags, given you had included them into DeliverTx +-response, to query transaction results. See [Indexing +-transactions](./indexing-transactions.md) for details. +- +- +-## Query parameter and event type restrictions +- +-While CometBFT imposes no restrictions on the application with regards to the type of +-the event output, there are several restrictions when it comes to querying +-events whose attribute values are numeric. +- +-- Queries cannot include negative numbers +-- If floating points are compared to integers, they are converted to an integer +-- Floating point to floating point comparison leads to a loss of precision for very big floating point numbers +-(e.g., `10000000000000000000.0` is treated the same as `10000000000000000000.6`) +-- When floating points do get converted to integers, they are always rounded down. +-This has been done to preserve the behaviour present before introducing the support for BigInts in the query parameters. +- +-## ValidatorSetUpdates +- +-When validator set changes, ValidatorSetUpdates event is published. The +-event carries a list of pubkey/power pairs. The list is the same +-CometBFT receives from ABCI application (see [EndBlock +-section](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/abci/abci++_methods.md#endblock) in +-the ABCI spec). +- +-Response: +- +-```json +-{ +- "jsonrpc": "2.0", +- "id": 0, +- "result": { +- "query": "tm.event='ValidatorSetUpdates'", +- "data": { +- "type": "tendermint/event/ValidatorSetUpdates", +- "value": { +- "validator_updates": [ +- { +- "address": "09EAD022FD25DE3A02E64B0FE9610B1417183EE4", +- "pub_key": { +- "type": "tendermint/PubKeyEd25519", +- "value": "ww0z4WaZ0Xg+YI10w43wTWbBmM3dpVza4mmSQYsd0ck=" +- }, +- "voting_power": "10", +- "proposer_priority": "0" +- } +- ] +- } +- } +- } +-} +-``` diff --git a/patches/docs/core/using-cometbft.md.patch b/patches/docs/core/using-cometbft.md.patch new file mode 100644 index 00000000000..cfa465c182e --- /dev/null +++ b/patches/docs/core/using-cometbft.md.patch @@ -0,0 +1,580 @@ +diff --git a/docs/core/using-cometbft.md b/docs/core/using-cometbft.md +deleted file mode 100644 +index b50173b5f..000000000 +--- a/docs/core/using-cometbft.md ++++ /dev/null +@@ -1,574 +0,0 @@ +---- +-order: 2 +---- +- +-# Using CometBFT +- +-This is a guide to using the `cometbft` program from the command line. +-It assumes only that you have the `cometbft` binary installed and have +-some rudimentary idea of what CometBFT and ABCI are. +- +-You can see the help menu with `cometbft --help`, and the version +-number with `cometbft version`. +- +-## Directory Root +- +-The default directory for blockchain data is `~/.cometbft`. Override +-this by setting the `CMTHOME` environment variable. +- +-## Initialize +- +-Initialize the root directory by running: +- +-```sh +-cometbft init +-``` +- +-This will create a new private key (`priv_validator_key.json`), and a +-genesis file (`genesis.json`) containing the associated public key, in +-`$CMTHOME/config`. This is all that's necessary to run a local testnet +-with one validator. +- +-For more elaborate initialization, see the testnet command: +- +-```sh +-cometbft testnet --help +-``` +- +-### Genesis +- +-The `genesis.json` file in `$CMTHOME/config/` defines the initial +-CometBFT state upon genesis of the blockchain ([see +-definition](https://github.com/cometbft/cometbft/blob/v0.34.x/types/genesis.go)). +- +-#### Fields +- +-- `genesis_time`: Official time of blockchain start. +-- `chain_id`: ID of the blockchain. **This must be unique for +- every blockchain.** If your testnet blockchains do not have unique +- chain IDs, you will have a bad time. The ChainID must be less than 50 symbols. +-- `initial_height`: Height at which CometBFT should begin at. If a blockchain is conducting a network upgrade, +- starting from the stopped height brings uniqueness to previous heights. +-- `consensus_params` ([see spec](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/core/data_structures.md#consensusparams)) +- - `block` +- - `max_bytes`: Max block size, in bytes. +- - `max_gas`: Max gas per block. +- - `time_iota_ms`: Minimum time increment between consecutive blocks (in +- milliseconds). If the block header timestamp is ahead of the system clock, +- decrease this value. +- - `evidence` +- - `max_age_num_blocks`: Max age of evidence, in blocks. The basic formula +- for calculating this is: MaxAgeDuration / {average block time}. +- - `max_age_duration`: Max age of evidence, in time. It should correspond +- with an app's "unbonding period" or other similar mechanism for handling +- [Nothing-At-Stake +- attacks](https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed). +- - `max_bytes`: This sets the maximum size in bytes of evidence that can be committed +- in a single block and should fall comfortably under the max block bytes. +- - `validator` +- - `pub_key_types`: Public key types validators can use. +- - `version` +- - `app_version`: ABCI application version. +-- `validators`: List of initial validators. Note this may be overridden entirely by the +- application, and may be left empty to make explicit that the +- application will initialize the validator set upon `InitChain`. +- - `pub_key`: The first element specifies the key type, +- using the declared `PubKeyName` for the adopted +- [key type](https://github.com/cometbft/cometbft/blob/v0.34.x/crypto/ed25519/ed25519.go#L36). +- The second element are the pubkey bytes. +- - `power`: The validator's voting power. +- - `name`: Name of the validator (optional). +-- `app_hash`: The expected application hash (as returned by the +- `ResponseInfo` ABCI message) upon genesis. If the app's hash does +- not match, CometBFT will panic. +-- `app_state`: The application state (e.g. initial distribution +- of tokens). +- +-> :warning: **ChainID must be unique to every blockchain. Reusing old chainID can cause issues** +- +-#### Sample genesis.json +- +-```json +-{ +- "genesis_time": "2023-01-21T11:17:42.341227868Z", +- "chain_id": "test-chain-ROp9KF", +- "initial_height": "0", +- "consensus_params": { +- "block": { +- "max_bytes": "22020096", +- "max_gas": "-1", +- }, +- "evidence": { +- "max_age_num_blocks": "100000", +- "max_age_duration": "172800000000000", +- "max_bytes": 51200, +- }, +- "validator": { +- "pub_key_types": [ +- "ed25519" +- ] +- } +- }, +- "validators": [ +- { +- "address": "B547AB87E79F75A4A3198C57A8C2FDAF8628CB47", +- "pub_key": { +- "type": "tendermint/PubKeyEd25519", +- "value": "P/V6GHuZrb8rs/k1oBorxc6vyXMlnzhJmv7LmjELDys=" +- }, +- "power": "10", +- "name": "" +- } +- ], +- "app_hash": "" +-} +-``` +- +-## Run +- +-To run a CometBFT node, use: +- +-```bash +-cometbft node +-``` +- +-By default, CometBFT will try to connect to an ABCI application on +-`127.0.0.1:26658`. If you have the `kvstore` ABCI app installed, run it in +-another window. If you don't, kill CometBFT and run an in-process version of +-the `kvstore` app: +- +-```bash +-cometbft node --proxy_app=kvstore +-``` +- +-After a few seconds, you should see blocks start streaming in. Note that blocks +-are produced regularly, even if there are no transactions. See _No Empty +-Blocks_, below, to modify this setting. +- +-CometBFT supports in-process versions of the `counter`, `kvstore`, and `noop` +-apps that ship as examples with `abci-cli`. It's easy to compile your app +-in-process with CometBFT if it's written in Go. If your app is not written in +-Go, run it in another process, and use the `--proxy_app` flag to specify the +-address of the socket it is listening on, for instance: +- +-```bash +-cometbft node --proxy_app=/var/run/abci.sock +-``` +- +-You can find out what flags are supported by running `cometbft node --help`. +- +-## Transactions +- +-To send a transaction, use `curl` to make requests to the CometBFT RPC +-server, for example: +- +-```sh +-curl http://localhost:26657/broadcast_tx_commit?tx=\"abcd\" +-``` +- +-We can see the chain's status at the `/status` end-point: +- +-```sh +-curl http://localhost:26657/status | json_pp +-``` +- +-and the `latest_app_hash` in particular: +- +-```sh +-curl http://localhost:26657/status | json_pp | grep latest_app_hash +-``` +- +-Visit `http://localhost:26657` in your browser to see the list of other +-endpoints. Some take no arguments (like `/status`), while others specify +-the argument name and use `_` as a placeholder. +- +- +-> TIP: Find the RPC Documentation [here](https://docs.cometbft.com/v0.34/rpc/) +- +-### Formatting +- +-The following nuances when sending/formatting transactions should be +-taken into account: +- +-With `GET`: +- +-To send a UTF8 string byte array, quote the value of the tx parameter: +- +-```sh +-curl 'http://localhost:26657/broadcast_tx_commit?tx="hello"' +-``` +- +-which sends a 5 byte transaction: "h e l l o" \[68 65 6c 6c 6f\]. +- +-Note the URL must be wrapped with single quotes, else bash will ignore +-the double quotes. To avoid the single quotes, escape the double quotes: +- +-```sh +-curl http://localhost:26657/broadcast_tx_commit?tx=\"hello\" +-``` +- +-Using a special character: +- +-```sh +-curl 'http://localhost:26657/broadcast_tx_commit?tx="€5"' +-``` +- +-sends a 4 byte transaction: "€5" (UTF8) \[e2 82 ac 35\]. +- +-To send as raw hex, omit quotes AND prefix the hex string with `0x`: +- +-```sh +-curl http://localhost:26657/broadcast_tx_commit?tx=0x01020304 +-``` +- +-which sends a 4 byte transaction: \[01 02 03 04\]. +- +-With `POST` (using `json`), the raw hex must be `base64` encoded: +- +-```sh +-curl --data-binary '{"jsonrpc":"2.0","id":"anything","method":"broadcast_tx_commit","params": {"tx": "AQIDBA=="}}' -H 'content-type:text/plain;' http://localhost:26657 +-``` +- +-which sends the same 4 byte transaction: \[01 02 03 04\]. +- +-Note that raw hex cannot be used in `POST` transactions. +- +-## Reset +- +-> :warning: **UNSAFE** Only do this in development and only if you can +-afford to lose all blockchain data! +- +- +-To reset a blockchain, stop the node and run: +- +-```sh +-cometbft unsafe_reset_all +-``` +- +-This command will remove the data directory and reset private validator and +-address book files. +- +-## Configuration +- +-CometBFT uses a `config.toml` for configuration. For details, see [the +-config specification](./configuration.md). +- +-Notable options include the socket address of the application +-(`proxy_app`), the listening address of the CometBFT peer +-(`p2p.laddr`), and the listening address of the RPC server +-(`rpc.laddr`). +- +-Some fields from the config file can be overwritten with flags. +- +-## No Empty Blocks +- +-While the default behavior of `cometbft` is still to create blocks +-approximately once per second, it is possible to disable empty blocks or +-set a block creation interval. In the former case, blocks will be +-created when there are new transactions or when the AppHash changes. +- +-To configure CometBFT to not produce empty blocks unless there are +-transactions or the app hash changes, run CometBFT with this +-additional flag: +- +-```sh +-cometbft node --consensus.create_empty_blocks=false +-``` +- +-or set the configuration via the `config.toml` file: +- +-```toml +-[consensus] +-create_empty_blocks = false +-``` +- +-Remember: because the default is to _create empty blocks_, avoiding +-empty blocks requires the config option to be set to `false`. +- +-The block interval setting allows for a delay (in time.Duration format [ParseDuration](https://golang.org/pkg/time/#ParseDuration)) between the +-creation of each new empty block. It can be set with this additional flag: +- +-```sh +---consensus.create_empty_blocks_interval="5s" +-``` +- +-or set the configuration via the `config.toml` file: +- +-```toml +-[consensus] +-create_empty_blocks_interval = "5s" +-``` +- +-With this setting, empty blocks will be produced every 5s if no block +-has been produced otherwise, regardless of the value of +-`create_empty_blocks`. +- +-## Broadcast API +- +-Earlier, we used the `broadcast_tx_commit` endpoint to send a +-transaction. When a transaction is sent to a CometBFT node, it will +-run via `CheckTx` against the application. If it passes `CheckTx`, it +-will be included in the mempool, broadcasted to other peers, and +-eventually included in a block. +- +-Since there are multiple phases to processing a transaction, we offer +-multiple endpoints to broadcast a transaction: +- +-```md +-/broadcast_tx_async +-/broadcast_tx_sync +-/broadcast_tx_commit +-``` +- +-These correspond to no-processing, processing through the mempool, and +-processing through a block, respectively. That is, `broadcast_tx_async`, +-will return right away without waiting to hear if the transaction is +-even valid, while `broadcast_tx_sync` will return with the result of +-running the transaction through `CheckTx`. Using `broadcast_tx_commit` +-will wait until the transaction is committed in a block or until some +-timeout is reached, but will return right away if the transaction does +-not pass `CheckTx`. The return value for `broadcast_tx_commit` includes +-two fields, `check_tx` and `deliver_tx`, pertaining to the result of +-running the transaction through those ABCI messages. +- +-The benefit of using `broadcast_tx_commit` is that the request returns +-after the transaction is committed (i.e. included in a block), but that +-can take on the order of a second. For a quick result, use +-`broadcast_tx_sync`, but the transaction will not be committed until +-later, and by that point its effect on the state may change. +- +-Note the mempool does not provide strong guarantees - just because a tx passed +-CheckTx (ie. was accepted into the mempool), doesn't mean it will be committed, +-as nodes with the tx in their mempool may crash before they get to propose. +-For more information, see the [mempool +-write-ahead-log](./running-in-production.md#mempool-wal) +- +-## CometBFT Networks +- +-When `cometbft init` is run, both a `genesis.json` and +-`priv_validator_key.json` are created in `~/.cometbft/config`. The +-`genesis.json` might look like: +- +-```json +-{ +- "validators" : [ +- { +- "pub_key" : { +- "value" : "h3hk+QE8c6QLTySp8TcfzclJw/BG79ziGB/pIA+DfPE=", +- "type" : "tendermint/PubKeyEd25519" +- }, +- "power" : 10, +- "name" : "" +- } +- ], +- "app_hash" : "", +- "chain_id" : "test-chain-rDlYSN", +- "genesis_time" : "0001-01-01T00:00:00Z" +-} +-``` +- +-And the `priv_validator_key.json`: +- +-```json +-{ +- "last_step" : 0, +- "last_round" : "0", +- "address" : "B788DEDE4F50AD8BC9462DE76741CCAFF87D51E2", +- "pub_key" : { +- "value" : "h3hk+QE8c6QLTySp8TcfzclJw/BG79ziGB/pIA+DfPE=", +- "type" : "tendermint/PubKeyEd25519" +- }, +- "last_height" : "0", +- "priv_key" : { +- "value" : "JPivl82x+LfVkp8i3ztoTjY6c6GJ4pBxQexErOCyhwqHeGT5ATxzpAtPJKnxNx/NyUnD8Ebv3OIYH+kgD4N88Q==", +- "type" : "tendermint/PrivKeyEd25519" +- } +-} +-``` +- +-The `priv_validator_key.json` actually contains a private key, and should +-thus be kept absolutely secret; for now we work with the plain text. +-Note the `last_` fields, which are used to prevent us from signing +-conflicting messages. +- +-Note also that the `pub_key` (the public key) in the +-`priv_validator_key.json` is also present in the `genesis.json`. +- +-The genesis file contains the list of public keys which may participate +-in the consensus, and their corresponding voting power. Greater than 2/3 +-of the voting power must be active (i.e. the corresponding private keys +-must be producing signatures) for the consensus to make progress. In our +-case, the genesis file contains the public key of our +-`priv_validator_key.json`, so a CometBFT node started with the default +-root directory will be able to make progress. Voting power uses an int64 +-but must be positive, thus the range is: 0 through 9223372036854775807. +-Because of how the current proposer selection algorithm works, we do not +-recommend having voting powers greater than 10\^12 (ie. 1 trillion). +- +-If we want to add more nodes to the network, we have two choices: we can +-add a new validator node, who will also participate in the consensus by +-proposing blocks and voting on them, or we can add a new non-validator +-node, who will not participate directly, but will verify and keep up +-with the consensus protocol. +- +-### Peers +- +-#### Seed +- +-A seed node is a node who relays the addresses of other peers which they know +-of. These nodes constantly crawl the network to try to get more peers. The +-addresses which the seed node relays get saved into a local address book. Once +-these are in the address book, you will connect to those addresses directly. +-Basically the seed nodes job is just to relay everyones addresses. You won't +-connect to seed nodes once you have received enough addresses, so typically you +-only need them on the first start. The seed node will immediately disconnect +-from you after sending you some addresses. +- +-#### Persistent Peer +- +-Persistent peers are people you want to be constantly connected with. If you +-disconnect you will try to connect directly back to them as opposed to using +-another address from the address book. On restarts you will always try to +-connect to these peers regardless of the size of your address book. +- +-All peers relay peers they know of by default. This is called the peer exchange +-protocol (PEX). With PEX, peers will be gossiping about known peers and forming +-a network, storing peer addresses in the addrbook. Because of this, you don't +-have to use a seed node if you have a live persistent peer. +- +-#### Connecting to Peers +- +-To connect to peers on start-up, specify them in the +-`$CMTHOME/config/config.toml` or on the command line. Use `seeds` to +-specify seed nodes, and +-`persistent_peers` to specify peers that your node will maintain +-persistent connections with. +- +-For example, +- +-```sh +-cometbft node --p2p.seeds "f9baeaa15fedf5e1ef7448dd60f46c01f1a9e9c4@1.2.3.4:26656,0491d373a8e0fcf1023aaf18c51d6a1d0d4f31bd@5.6.7.8:26656" +-``` +- +-Alternatively, you can use the `/dial_seeds` endpoint of the RPC to +-specify seeds for a running node to connect to: +- +-```sh +-curl 'localhost:26657/dial_seeds?seeds=\["f9baeaa15fedf5e1ef7448dd60f46c01f1a9e9c4@1.2.3.4:26656","0491d373a8e0fcf1023aaf18c51d6a1d0d4f31bd@5.6.7.8:26656"\]' +-``` +- +-Note, with PEX enabled, you +-should not need seeds after the first start. +- +-If you want CometBFT to connect to specific set of addresses and +-maintain a persistent connection with each, you can use the +-`--p2p.persistent_peers` flag or the corresponding setting in the +-`config.toml` or the `/dial_peers` RPC endpoint to do it without +-stopping CometBFT instance. +- +-```sh +-cometbft node --p2p.persistent_peers "429fcf25974313b95673f58d77eacdd434402665@10.11.12.13:26656,96663a3dd0d7b9d17d4c8211b191af259621c693@10.11.12.14:26656" +- +-curl 'localhost:26657/dial_peers?persistent=true&peers=\["429fcf25974313b95673f58d77eacdd434402665@10.11.12.13:26656","96663a3dd0d7b9d17d4c8211b191af259621c693@10.11.12.14:26656"\]' +-``` +- +-### Adding a Non-Validator +- +-Adding a non-validator is simple. Just copy the original `genesis.json` +-to `~/.cometbft/config` on the new machine and start the node, +-specifying seeds or persistent peers as necessary. If no seeds or +-persistent peers are specified, the node won't make any blocks, because +-it's not a validator, and it won't hear about any blocks, because it's +-not connected to the other peer. +- +-### Adding a Validator +- +-The easiest way to add new validators is to do it in the `genesis.json`, +-before starting the network. For instance, we could make a new +-`priv_validator_key.json`, and copy it's `pub_key` into the above genesis. +- +-We can generate a new `priv_validator_key.json` with the command: +- +-```sh +-cometbft gen_validator +-``` +- +-Now we can update our genesis file. For instance, if the new +-`priv_validator_key.json` looks like: +- +-```json +-{ +- "address" : "5AF49D2A2D4F5AD4C7C8C4CC2FB020131E9C4902", +- "pub_key" : { +- "value" : "l9X9+fjkeBzDfPGbUM7AMIRE6uJN78zN5+lk5OYotek=", +- "type" : "tendermint/PubKeyEd25519" +- }, +- "priv_key" : { +- "value" : "EDJY9W6zlAw+su6ITgTKg2nTZcHAH1NMTW5iwlgmNDuX1f35+OR4HMN88ZtQzsAwhETq4k3vzM3n6WTk5ii16Q==", +- "type" : "tendermint/PrivKeyEd25519" +- }, +- "last_step" : 0, +- "last_round" : "0", +- "last_height" : "0" +-} +-``` +- +-then the new `genesis.json` will be: +- +-```json +-{ +- "validators" : [ +- { +- "pub_key" : { +- "value" : "h3hk+QE8c6QLTySp8TcfzclJw/BG79ziGB/pIA+DfPE=", +- "type" : "tendermint/PubKeyEd25519" +- }, +- "power" : 10, +- "name" : "" +- }, +- { +- "pub_key" : { +- "value" : "l9X9+fjkeBzDfPGbUM7AMIRE6uJN78zN5+lk5OYotek=", +- "type" : "tendermint/PubKeyEd25519" +- }, +- "power" : 10, +- "name" : "" +- } +- ], +- "app_hash" : "", +- "chain_id" : "test-chain-rDlYSN", +- "genesis_time" : "0001-01-01T00:00:00Z" +-} +-``` +- +-Update the `genesis.json` in `~/.cometbft/config`. Copy the genesis +-file and the new `priv_validator_key.json` to the `~/.cometbft/config` on +-a new machine. +- +-Now run `cometbft node` on both machines, and use either +-`--p2p.persistent_peers` or the `/dial_peers` to get them to peer up. +-They should start making blocks, and will only continue to do so as long +-as both of them are online. +- +-To make a CometBFT network that can tolerate one of the validators +-failing, you need at least four validator nodes (e.g., 2/3). +- +-Updating validators in a live network is supported but must be +-explicitly programmed by the application developer. See the [application +-developers guide](../app-dev/abci-cli.md) for more details. +- +-### Local Network +- +-To run a network locally, say on a single machine, you must change the `_laddr` +-fields in the `config.toml` (or using the flags) so that the listening +-addresses of the various sockets don't conflict. Additionally, you must set +-`addr_book_strict=false` in the `config.toml`, otherwise CometBFT's p2p +-library will deny making connections to peers with the same IP address. +- +-### Upgrading +- +-See the +-[UPGRADING.md](https://github.com/cometbft/cometbft/blob/v0.34.x/UPGRADING.md) +-guide. You may need to reset your chain between major breaking releases. +-Although, we expect CometBFT to have fewer breaking releases in the future +-(especially after 1.0 release). diff --git a/patches/docs/core/validators.md.patch b/patches/docs/core/validators.md.patch new file mode 100644 index 00000000000..5cdf95abd17 --- /dev/null +++ b/patches/docs/core/validators.md.patch @@ -0,0 +1,121 @@ +diff --git a/docs/core/validators.md b/docs/core/validators.md +deleted file mode 100644 +index b28cb7ff0..000000000 +--- a/docs/core/validators.md ++++ /dev/null +@@ -1,115 +0,0 @@ +---- +-order: 6 +---- +- +-# Validators +- +-Validators are responsible for committing new blocks in the blockchain. +-These validators participate in the consensus protocol by broadcasting +-_votes_ which contain cryptographic signatures signed by each +-validator's private key. +- +-Some Proof-of-Stake consensus algorithms aim to create a "completely" +-decentralized system where all stakeholders (even those who are not +-always available online) participate in the committing of blocks. +-CometBFT has a different approach to block creation. Validators are +-expected to be online, and the set of validators is permissioned/curated +-by some external process. Proof-of-stake is not required, but can be +-implemented on top of CometBFT consensus. That is, validators may be +-required to post collateral on-chain, off-chain, or may not be required +-to post any collateral at all. +- +-Validators have a cryptographic key-pair and an associated amount of +-"voting power". Voting power need not be the same. +- +-## Becoming a Validator +- +-There are two ways to become validator. +- +-1. They can be pre-established in the [genesis state](./using-cometbft.md#genesis) +-2. The ABCI app responds to the EndBlock message with changes to the +- existing validator set. +- +-## Setting up a Validator +- +-When setting up a validator there are countless ways to configure your setup. This guide is aimed at showing one of them, the sentry node design. This design is mainly for DDoS prevention. +- +-### Network Layout +- +-![ALT Network Layout](../imgs/sentry_layout.png) +- +-The diagram is based on AWS, other cloud providers will have similar solutions to design a solution. Running nodes is not limited to cloud providers, you can run nodes on bare metal systems as well. The architecture will be the same no matter which setup you decide to go with. +- +-The proposed network diagram is similar to the classical backend/frontend separation of services in a corporate environment. The “backend” in this case is the private network of the validator in the data center. The data center network might involve multiple subnets, firewalls and redundancy devices, which is not detailed on this diagram. The important point is that the data center allows direct connectivity to the chosen cloud environment. Amazon AWS has “Direct Connect”, while Google Cloud has “Partner Interconnect”. This is a dedicated connection to the cloud provider (usually directly to your virtual private cloud instance in one of the regions). +- +-All sentry nodes (the “frontend”) connect to the validator using this private connection. The validator does not have a public IP address to provide its services. +- +-Amazon has multiple availability zones within a region. One can install sentry nodes in other regions too. In this case the second, third and further regions need to have a private connection to the validator node. This can be achieved by VPC Peering (“VPC Network Peering” in Google Cloud). In this case, the second, third and further region sentry nodes will be directed to the first region and through the direct connect to the data center, arriving to the validator. +- +-A more persistent solution (not detailed on the diagram) is to have multiple direct connections to different regions from the data center. This way VPC Peering is not mandatory, although still beneficial for the sentry nodes. This overcomes the risk of depending on one region. It is more costly. +- +-### Local Configuration +- +-![ALT Local Configuration](../imgs/sentry_local_config.png) +- +-The validator will only talk to the sentry that are provided, the sentry nodes will communicate to the validator via a secret connection and the rest of the network through a normal connection. The sentry nodes do have the option of communicating with each other as well. +- +-When initializing nodes there are five parameters in the `config.toml` that may need to be altered. +- +-- `pex:` boolean. This turns the peer exchange reactor on or off for a node. When `pex=false`, only the `persistent_peers` list is available for connection. +-- `persistent_peers:` a comma separated list of `nodeID@ip:port` values that define a list of peers that are expected to be online at all times. This is necessary at first startup because by setting `pex=false` the node will not be able to join the network. +-- `unconditional_peer_ids:` comma separated list of nodeID's. These nodes will be connected to no matter the limits of inbound and outbound peers. This is useful for when sentry nodes have full address books. +-- `private_peer_ids:` comma separated list of nodeID's. These nodes will not be gossiped to the network. This is an important field as you do not want your validator IP gossiped to the network. +-- `addr_book_strict:` boolean. By default nodes with a routable address will be considered for connection. If this setting is turned off (false), non-routable IP addresses, like addresses in a private network can be added to the address book. +-- `double_sign_check_height` int64 height. How many blocks to look back to check existence of the node's consensus votes before joining consensus When non-zero, the node will panic upon restart if the same consensus key was used to sign `double_sign_check_height` last blocks. So, validators should stop the state machine, wait for some blocks, and then restart the state machine to avoid panic. +- +-#### Validator Node Configuration +- +-| Config Option | Setting | +-| ------------------------ | -------------------------- | +-| pex | false | +-| persistent_peers | list of sentry nodes | +-| private_peer_ids | none | +-| unconditional_peer_ids | optionally sentry node IDs | +-| addr_book_strict | false | +-| double_sign_check_height | 10 | +- +-The validator node should have `pex=false` so it does not gossip to the entire network. The persistent peers will be your sentry nodes. Private peers can be left empty as the validator is not trying to hide who it is communicating with. Setting unconditional peers is optional for a validator because they will not have a full address books. +- +-#### Sentry Node Configuration +- +-| Config Option | Setting | +-| ---------------------- | --------------------------------------------- | +-| pex | true | +-| persistent_peers | validator node, optionally other sentry nodes | +-| private_peer_ids | validator node ID | +-| unconditional_peer_ids | validator node ID, optionally sentry node IDs | +-| addr_book_strict | false | +- +-The sentry nodes should be able to talk to the entire network hence why `pex=true`. The persistent peers of a sentry node will be the validator, and optionally other sentry nodes. The sentry nodes should make sure that they do not gossip the validator's ip, to do this you must put the validators nodeID as a private peer. The unconditional peer IDs will be the validator ID and optionally other sentry nodes. +- +-> Note: Do not forget to secure your node's firewalls when setting them up. +- +-More Information can be found at these links: +- +-- +-- +- +-### Validator keys +- +-Protecting a validator's consensus key is the most important factor to take in when designing your setup. The key that a validator is given upon creation of the node is called a consensus key, it has to be online at all times in order to vote on blocks. It is **not recommended** to merely hold your private key in the default json file (`priv_validator_key.json`). Fortunately, the [Interchain Foundation](https://interchain.io/) has worked with a team to build a key management server for validators. You can find documentation on how to use it [here](https://github.com/iqlusioninc/tmkms), it is used extensively in production. You are not limited to using this tool, there are also [HSMs](https://safenet.gemalto.com/data-encryption/hardware-security-modules-hsms/), there is not a recommended HSM. +- +-Currently CometBFT uses [Ed25519](https://ed25519.cr.yp.to/) keys which are widely supported across the security sector and HSMs. +- +-## Committing a Block +- +-> **+2/3 is short for "more than 2/3"** +- +-A block is committed when +2/3 of the validator set sign +-[precommit votes](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/core/data_structures.md#vote) +-for that block at the same `round`. +-The +2/3 set of precommit votes is called a +-[commit](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/core/data_structures.md#commit). +-While any +2/3 set of precommits for the same block at the same height&round can serve as +-validation, the canonical commit is included in the next block (see +-[LastCommit](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/core/data_structures.md#block)). diff --git a/patches/docs/guides/README.md.patch b/patches/docs/guides/README.md.patch new file mode 100644 index 00000000000..12949b7d398 --- /dev/null +++ b/patches/docs/guides/README.md.patch @@ -0,0 +1,21 @@ +diff --git a/docs/guides/README.md b/docs/guides/README.md +deleted file mode 100644 +index 7c8b0a9e5..000000000 +--- a/docs/guides/README.md ++++ /dev/null +@@ -1,15 +0,0 @@ +---- +-order: false +-parent: +- order: 2 +---- +- +-# Guides +- +-- [Installing CometBFT](./install.md) +-- [Quick-start using CometBFT](./quick-start.md) +-- [Upgrading from Tendermint to CometBFT](./upgrading-from-tm.md) +-- [Creating a built-in application in Go](./go-built-in.md) +-- [Creating an external application in Go](./go.md) +-- [Creating an external application in Java](./java.md) +-- [Creating an external application in Kotlin](./kotlin.md) diff --git a/patches/docs/guides/go-built-in.md.patch b/patches/docs/guides/go-built-in.md.patch new file mode 100644 index 00000000000..f920357b8e5 --- /dev/null +++ b/patches/docs/guides/go-built-in.md.patch @@ -0,0 +1,766 @@ +diff --git a/docs/guides/go-built-in.md b/docs/guides/go-built-in.md +deleted file mode 100644 +index 2f1611a90..000000000 +--- a/docs/guides/go-built-in.md ++++ /dev/null +@@ -1,760 +0,0 @@ +---- +-order: 3 +---- +- +-# Creating a built-in application in Go +- +-## Guide Assumptions +- +-This guide is designed for beginners who want to get started with a CometBFT +-application from scratch. It does not assume that you have any prior +-experience with CometBFT. +- +-CometBFT is a service that provides a Byzantine Fault Tolerant consensus engine +-for state-machine replication. The replicated state-machine, or "application", can be written +-in any language that can send and receive protocol buffer messages in a client-server model. +-Applications written in Go can also use CometBFT as a library and run the service in the same +-process as the application. +- +-By following along this tutorial you will create a CometBFT application called kvstore, +-a (very) simple distributed BFT key-value store. +-The application will be written in Go and +-some understanding of the Go programming language is expected. +-If you have never written Go, you may want to go through [Learn X in Y minutes +-Where X=Go](https://learnxinyminutes.com/docs/go/) first, to familiarize +-yourself with the syntax. +- +-Note: Please use the latest released version of this guide and of CometBFT. +-We strongly advise against using unreleased commits for your development. +- +-### Built-in app vs external app +- +-On the one hand, to get maximum performance you can run your application in +-the same process as the CometBFT, as long as your application is written in Go. +-[Cosmos SDK](https://github.com/cosmos/cosmos-sdk) is written +-this way. +-This is the approach followed in this tutorial. +- +-On the other hand, having a separate application might give you better security +-guarantees as two processes would be communicating via established binary protocol. +-CometBFT will not have access to application's state. +-If that is the way you wish to proceed, use the [Creating an application in Go](./go.md) guide instead of this one. +- +- +-## 1.1 Installing Go +- +-Verify that you have the latest version of Go installed (refer to the [official guide for installing Go](https://golang.org/doc/install)): +- +-```bash +-$ go version +-go version go1.21.9 darwin/amd64 +-``` +- +-## 1.2 Creating a new Go project +- +-We'll start by creating a new Go project. +- +-```bash +-mkdir kvstore +-``` +- +-Inside the example directory, create a `main.go` file with the following content: +- +-```go +-package main +- +-import ( +- "fmt" +-) +- +-func main() { +- fmt.Println("Hello, CometBFT") +-} +-``` +- +-When run, this should print "Hello, CometBFT" to the standard output. +- +-```bash +-cd kvstore +-$ go run main.go +-Hello, CometBFT +-``` +- +-We are going to use [Go modules](https://github.com/golang/go/wiki/Modules) for +-dependency management, so let's start by including a dependency on this version of +-CometBFT. +- +-```bash +-go mod init kvstore +-go get github.com/tendermint/tendermint +-go mod edit -replace github.com/tendermint/tendermint=github.com/cometbft/cometbft@v0.34.27 +-``` +- +-After running the above commands you will see two generated files, `go.mod` and `go.sum`. +-The go.mod file should look similar to: +- +-```go +-module github.com/me/example +- +-go 1.19 +- +-require ( +- github.com/cometbft/cometbft v0.34.27 +-) +-``` +- +-As you write the kvstore application, you can rebuild the binary by +-pulling any new dependencies and recompiling it. +- +-```sh +-go get +-go build +-``` +- +-## 1.3 Writing a CometBFT application +- +-CometBFT communicates with the application through the Application +-BlockChain Interface (ABCI). The messages exchanged through the interface are +-defined in the ABCI [protobuf +-file](https://github.com/cometbft/cometbft/blob/v0.34.x/proto/tendermint/abci/types.proto). +- +-We begin by creating the basic scaffolding for an ABCI application by +-creating a new type, `KVStoreApplication`, which implements the +-methods defined by the `abcitypes.Application` interface. +- +-Create a file called `app.go` with the following contents: +- +-```go +-package main +- +-import ( +- abcitypes "github.com/cometbft/cometbft/abci/types" +-) +- +-type KVStoreApplication struct{} +- +-var _ abcitypes.Application = (*KVStoreApplication)(nil) +- +-func NewKVStoreApplication() *KVStoreApplication { +- return &KVStoreApplication{} +-} +- +-func (app *KVStoreApplication) Info(info abcitypes.RequestInfo) abcitypes.ResponseInfo { +- return abcitypes.ResponseInfo{} +-} +- +-func (app *KVStoreApplication) Query(query abcitypes.RequestQuery) abcitypes.ResponseQuery { +- return abcitypes.ResponseQuery{} +-} +- +-func (app *KVStoreApplication) CheckTx(tx abcitypes.RequestCheckTx) abcitypes.ResponseCheckTx { +- return abcitypes.ResponseCheckTx{} +-} +- +-func (app *KVStoreApplication) InitChain(chain abcitypes.RequestInitChain) abcitypes.ResponseInitChain { +- return abcitypes.ResponseInitChain{} +-} +- +- +-func (app *KVStoreApplication) BeginBlock(block abcitypes.RequestBeginBlock) abcitypes.ResponseBeginBlock { +- return abcitypes.ResponseBeginBlock{} +-} +- +-func (app *KVStoreApplication) DeliverTx(tx abcitypes.RequestDeliverTx) abcitypes.ResponseDeliverTx { +- return abcitypes.ResponseDeliverTx{} +-} +- +-func (app *KVStoreApplication) EndBlock(block abcitypes.RequestEndBlock) abcitypes.ResponseEndBlock { +- return abcitypes.ResponseEndBlock{} +-} +- +-func (app *KVStoreApplication) Commit() abcitypes.ResponseCommit { +- return abcitypes.ResponseCommit{} +-} +- +-func (app *KVStoreApplication) ListSnapshots(snapshots abcitypes.RequestListSnapshots) abcitypes.ResponseListSnapshots { +- return abcitypes.ResponseListSnapshots{} +-} +- +-func (app *KVStoreApplication) OfferSnapshot(snapshot abcitypes.RequestOfferSnapshot) abcitypes.ResponseOfferSnapshot { +- return abcitypes.ResponseOfferSnapshot{} +-} +- +-func (app *KVStoreApplication) LoadSnapshotChunk(chunk abcitypes.RequestLoadSnapshotChunk) abcitypes.ResponseLoadSnapshotChunk { +- return abcitypes.ResponseLoadSnapshotChunk{} +-} +- +-func (app *KVStoreApplication) ApplySnapshotChunk(chunk abcitypes.RequestApplySnapshotChunk) abcitypes.ResponseApplySnapshotChunk { +- return abcitypes.ResponseApplySnapshotChunk{} +-} +-``` +- +-The types used here are defined in the CometBFT library and were added as a dependency +-to the project when you ran `go get`. If your IDE is not recognizing the types, go ahead and run the command again. +- +-```bash +-go get github.com/cometbft/cometbft@v0.34.27 +-``` +- +-Now go back to the `main.go` and modify the `main` function so it matches the following, +-where an instance of the `KVStoreApplication` type is created. +- +-```go +-func main() { +- fmt.Println("Hello, CometBFT") +- +- _ = NewKVStoreApplication() +-} +-``` +- +-You can recompile and run the application now by running `go get` and `go build`, but it does +-not do anything. +-So let's revisit the code adding the logic needed to implement our minimal key/value store +-and to start it along with the CometBFT Service. +- +- +-### 1.3.1 Add a persistent data store +- +-Our application will need to write its state out to persistent storage so that it +-can stop and start without losing all of its data. +- +-For this tutorial, we will use [BadgerDB](https://github.com/dgraph-io/badger), a +-fast embedded key-value store. +- +-First, add Badger as a dependency of your go module using the `go get` command: +- +-`go get github.com/dgraph-io/badger/v3` +- +-Next, let's update the application and its constructor to receive a handle to the database, as follows: +- +-```go +-type KVStoreApplication struct { +- db *badger.DB +- onGoingBlock *badger.Txn +-} +- +-var _ abcitypes.Application = (*KVStoreApplication)(nil) +- +-func NewKVStoreApplication(db *badger.DB) *KVStoreApplication { +- return &KVStoreApplication{db: db} +-} +-``` +- +-The `onGoingBlock` keeps track of the Badger transaction that will update the application's state when a block +-is completed. Don't worry about it for now, we'll get to that later. +- +-Next, update the `import` stanza at the top to include the Badger library: +- +-```go +-import( +- "github.com/dgraph-io/badger/v3" +- abcitypes "github.com/cometbft/cometbft/abci/types" +-) +-``` +- +-Finally, update the `main.go` file to invoke the updated constructor: +- +-```go +- _ = NewKVStoreApplication(nil) +-``` +- +-### 1.3.2 CheckTx +- +-When CometBFT receives a new transaction from a client, or from another full node, +-CometBFT asks the application if the transaction is acceptable, using the `CheckTx` method. +-Invalid transactions will not be shared with other nodes and will not become part of any blocks and, therefore, will not be executed by the application. +- +-In our application, a transaction is a string with the form `key=value`, indicating a key and value to write to the store. +- +-The most basic validation check we can perform is to check if the transaction conforms to the `key=value` pattern. +-For that, let's add the following helper method to app.go: +- +-```go +-func (app *KVStoreApplication) isValid(tx []byte) uint32 { +- // check format +- parts := bytes.Split(tx, []byte("=")) +- if len(parts) != 2 { +- return 1 +- } +- +- return 0 +-} +-``` +- +-Now you can rewrite the `CheckTx` method to use the helper function: +- +-```go +-func (app *KVStoreApplication) CheckTx(req abcitypes.RequestCheckTx) abcitypes.ResponseCheckTx { +- code := app.isValid(req.Tx) +- return abcitypes.ResponseCheckTx{Code: code} +-} +-``` +- +-While this `CheckTx` is simple and only validates that the transaction is well-formed, +-it is very common for `CheckTx` to make more complex use of the state of an application. +-For example, you may refuse to overwrite an existing value, or you can associate +-versions to the key/value pairs and allow the caller to specify a version to +-perform a conditional update. +- +-Depending on the checks and on the conditions violated, the function may return +-different values, but any response with a non-zero code will be considered invalid +-by CometBFT. Our `CheckTx` logic returns 0 to CometBFT when a transaction passes +-its validation checks. The specific value of the code is meaningless to CometBFT. +-Non-zero codes are logged by CometBFT so applications can provide more specific +-information on why the transaction was rejected. +- +-Note that `CheckTx` does not execute the transaction, it only verifies that the transaction could be executed. We do not know yet if the rest of the network has agreed to accept this transaction into a block. +- +- +-Finally, make sure to add the bytes package to the `import` stanza at the top of `app.go`: +- +-```go +-import( +- "bytes" +- +- "github.com/dgraph-io/badger/v3" +- abcitypes "github.com/cometbft/cometbft/abci/types" +-) +-``` +- +- +-### 1.3.3 BeginBlock -> DeliverTx -> EndBlock -> Commit +- +-When the CometBFT consensus engine has decided on the block, the block is transferred to the +-application over three ABCI method calls: `BeginBlock`, `DeliverTx`, and `EndBlock`. +- +-- `BeginBlock` is called once to indicate to the application that it is about to +-receive a block. +-- `DeliverTx` is called repeatedly, once for each application transaction that was included in the block. +-- `EndBlock` is called once to indicate to the application that no more transactions +-will be delivered to the application within this block. +- +-Note that, to implement these calls in our application we're going to make use of Badger's +-transaction mechanism. We will always refer to these as Badger transactions, not to +-confuse them with the transactions included in the blocks delivered by CometBFT, +-the _application transactions_. +- +-First, let's create a new Badger transaction during `BeginBlock`. All application transactions in the +-current block will be executed within this Badger transaction. +-Then, return informing CometBFT that the application is ready to receive application transactions: +- +-```go +-func (app *KVStoreApplication) BeginBlock(req abcitypes.RequestBeginBlock) abcitypes.ResponseBeginBlock { +- app.onGoingBlock = app.db.NewTransaction(true) +- return abcitypes.ResponseBeginBlock{} +-} +-``` +- +-Next, let's modify `DeliverTx` to add the `key` and `value` to the database transaction every time our application +-receives a new application transaction through `RequestDeliverTx`. +- +-```go +-func (app *KVStoreApplication) DeliverTx(req abcitypes.RequestDeliverTx) abcitypes.ResponseDeliverTx { +- if code := app.isValid(req.Tx); code != 0 { +- return abcitypes.ResponseDeliverTx{Code: code} +- } +- +- parts := bytes.SplitN(req.Tx, []byte("="), 2) +- key, value := parts[0], parts[1] +- +- if err := app.onGoingBlock.Set(key, value); err != nil { +- log.Panicf("Error writing to database, unable to execute tx: %v", err) +- } +- +- return abcitypes.ResponseDeliverTx{Code: 0} +-} +-``` +- +-Note that we check the validity of the transaction _again_ during `DeliverTx`. +-Transactions are not guaranteed to be valid when they are delivered to an +-application, even if they were valid when they were proposed. +-This can happen if the application state is used to determine transaction +-validity. Application state may have changed between the initial execution of `CheckTx` +-and the transaction delivery in `DeliverTx` in a way that rendered the transaction +-no longer valid. +- +-`EndBlock` is called to inform the application that the full block has been delivered +-and give the application a chance to perform any other computation needed, before the +-effects of the transactions become permanent. +- +-Note that `EndBlock` **cannot** yet commit the Badger transaction we were building +-in during `DeliverTx`. +-Since other methods, such as `Query`, rely on a consistent view of the application's +-state, the application should only update its state by committing the Badger transactions +-when the full block has been delivered and the `Commit` method is invoked. +- +-The `Commit` method tells the application to make permanent the effects of +-the application transactions. +-Let's update the method to terminate the pending Badger transaction and +-persist the resulting state: +- +-```go +-func (app *KVStoreApplication) Commit() abcitypes.ResponseCommit { +- if err := app.onGoingBlock.Commit(); err != nil { +- log.Panicf("Error writing to database, unable to commit block: %v", err) +- } +- return abcitypes.ResponseCommit{Data: []byte{}} +-} +-``` +- +-Finally, make sure to add the log library to the `import` stanza as well: +- +-```go +-import ( +- "bytes" +- "log" +- +- "github.com/dgraph-io/badger/v3" +- abcitypes "github.com/cometbft/cometbft/abci/types" +-) +-``` +- +-You may have noticed that the application we are writing will crash if it receives +-an unexpected error from the Badger database during the `DeliverTx` or `Commit` methods. +-This is not an accident. If the application received an error from the database, there +-is no deterministic way for it to make progress so the only safe option is to terminate. +- +-### 1.3.4 Query +- +-When a client tries to read some information from the `kvstore`, the request will be +-handled in the `Query` method. To do this, let's rewrite the `Query` method in `app.go`: +- +-```go +-func (app *KVStoreApplication) Query(req abcitypes.RequestQuery) abcitypes.ResponseQuery { +- resp := abcitypes.ResponseQuery{Key: req.Data} +- +- dbErr := app.db.View(func(txn *badger.Txn) error { +- item, err := txn.Get(req.Data) +- if err != nil { +- if err != badger.ErrKeyNotFound { +- return err +- } +- resp.Log = "key does not exist" +- return nil +- } +- +- return item.Value(func(val []byte) error { +- resp.Log = "exists" +- resp.Value = val +- return nil +- }) +- }) +- if dbErr != nil { +- log.Panicf("Error reading database, unable to execute query: %v", dbErr) +- } +- return resp +-} +-``` +- +-Since it reads only committed data from the store, transactions that are part of a block +-that is being processed are not reflected in the query result. +- +- +-## 1.4 Starting an application and a CometBFT instance in the same process +- +-Now that we have the basic functionality of our application in place, let's put it all together inside of our main.go file. +- +-Change the contents of your `main.go` file to the following. +- +-```go +-package main +- +-import ( +- "flag" +- "fmt" +- "github.com/cometbft/cometbft/p2p" +- "github.com/cometbft/cometbft/privval" +- "github.com/cometbft/cometbft/proxy" +- "log" +- "os" +- "os/signal" +- "path/filepath" +- "syscall" +- +- "github.com/dgraph-io/badger/v3" +- "github.com/spf13/viper" +- cfg "github.com/cometbft/cometbft/config" +- cmtflags "github.com/cometbft/cometbft/libs/cli/flags" +- cmtlog "github.com/cometbft/cometbft/libs/log" +- nm "github.com/cometbft/cometbft/node" +-) +- +-var homeDir string +- +-func init() { +- flag.StringVar(&homeDir, "cmt-home", "", "Path to the CometBFT config directory (if empty, uses $HOME/.cometbft)") +-} +- +-func main() { +- flag.Parse() +- if homeDir == "" { +- homeDir = os.ExpandEnv("$HOME/.cometbft") +- } +- config := cfg.DefaultConfig() +- +- config.SetRoot(homeDir) +- +- viper.SetConfigFile(fmt.Sprintf("%s/%s", homeDir, "config/config.toml")) +- if err := viper.ReadInConfig(); err != nil { +- log.Fatalf("Reading config: %v", err) +- } +- if err := viper.Unmarshal(config); err != nil { +- log.Fatalf("Decoding config: %v", err) +- } +- if err := config.ValidateBasic(); err != nil { +- log.Fatalf("Invalid configuration data: %v", err) +- } +- +- dbPath := filepath.Join(homeDir, "badger") +- db, err := badger.Open(badger.DefaultOptions(dbPath)) +- if err != nil { +- log.Fatalf("Opening database: %v", err) +- } +- defer func() { +- if err := db.Close(); err != nil { +- log.Printf("Closing database: %v", err) +- } +- }() +- +- app := NewKVStoreApplication(db) +- +- pv := privval.LoadFilePV( +- config.PrivValidatorKeyFile(), +- config.PrivValidatorStateFile(), +- ) +- +- nodeKey, err := p2p.LoadNodeKey(config.NodeKeyFile()) +- if err != nil { +- log.Fatalf("failed to load node's key: %v", err) +- } +- +- logger := cmtlog.NewTMLogger(cmtlog.NewSyncWriter(os.Stdout)) +- logger, err = cmtflags.ParseLogLevel(config.LogLevel, logger, cfg.DefaultLogLevel) +- if err != nil { +- log.Fatalf("failed to parse log level: %v", err) +- } +- +- node, err := nm.NewNode( +- config, +- pv, +- nodeKey, +- proxy.NewLocalClientCreator(app), +- nm.DefaultGenesisDocProviderFunc(config), +- nm.DefaultDBProvider, +- nm.DefaultMetricsProvider(config.Instrumentation), +- logger) +- +- if err != nil { +- log.Fatalf("Creating node: %v", err) +- } +- +- node.Start() +- defer func() { +- node.Stop() +- node.Wait() +- }() +- +- c := make(chan os.Signal, 1) +- signal.Notify(c, os.Interrupt, syscall.SIGTERM) +- <-c +-} +-``` +- +-This is a huge blob of code, so let's break it down into pieces. +- +-First, we use [viper](https://github.com/spf13/viper) to load the CometBFT configuration files, which we will generate later: +- +- +-```go +- config := cfg.DefaultValidatorConfig() +- +- config.SetRoot(homeDir) +- +- viper.SetConfigFile(fmt.Sprintf("%s/%s", homeDir, "config/config.toml")) +- if err := viper.ReadInConfig(); err != nil { +- log.Fatalf("Reading config: %v", err) +- } +- if err := viper.Unmarshal(config); err != nil { +- log.Fatalf("Decoding config: %v", err) +- } +- if err := config.ValidateBasic(); err != nil { +- log.Fatalf("Invalid configuration data: %v", err) +- } +-``` +- +-Next, we initialize the Badger database and create an app instance. +- +-```go +- dbPath := filepath.Join(homeDir, "badger") +- db, err := badger.Open(badger.DefaultOptions(dbPath)) +- if err != nil { +- log.Fatalf("Opening database: %v", err) +- } +- defer func() { +- if err := db.Close(); err != nil { +- log.Fatalf("Closing database: %v", err) +- } +- }() +- +- app := NewKVStoreApplication(db) +-``` +- +-We use `FilePV`, which is a private validator (i.e. thing which signs consensus +-messages). Normally, you would use `SignerRemote` to connect to an external +-[HSM](https://kb.certus.one/hsm.html). +- +-```go +- pv := privval.LoadFilePV( +- config.PrivValidatorKeyFile(), +- config.PrivValidatorStateFile(), +- ) +-``` +- +-`nodeKey` is needed to identify the node in a p2p network. +- +-```go +- nodeKey, err := p2p.LoadNodeKey(config.NodeKeyFile()) +- if err != nil { +- return nil, fmt.Errorf("failed to load node's key: %w", err) +- } +-``` +- +-Now we have everything set up to run the CometBFT node. We construct +-a node by passing it the configuration, the logger, a handle to our application and +-the genesis information: +- +-```go +- node, err := nm.NewNode( +- config, +- pv, +- nodeKey, +- proxy.NewLocalClientCreator(app), +- nm.DefaultGenesisDocProviderFunc(config), +- nm.DefaultDBProvider, +- nm.DefaultMetricsProvider(config.Instrumentation), +- logger) +- +- if err != nil { +- log.Fatalf("Creating node: %v", err) +- } +-``` +- +-Finally, we start the node, i.e., the CometBFT service inside our application: +- +-```go +- node.Start() +- defer func() { +- node.Stop() +- node.Wait() +- }() +-``` +- +-The additional logic at the end of the file allows the program to catch SIGTERM. This means that the node can shut down gracefully when an operator tries to kill the program: +- +-```go +- c := make(chan os.Signal, 1) +- signal.Notify(c, os.Interrupt, syscall.SIGTERM) +- <-c +-``` +- +-## 1.5 Initializing and Running +- +-Our application is almost ready to run, but first we'll need to populate the CometBFT configuration files. +-The following command will create a `cometbft-home` directory in your project and add a basic set of configuration files in `cometbft-home/config/`. +-For more information on what these files contain see [the configuration documentation](https://github.com/cometbft/cometbft/blob/v0.34.x/docs/core/configuration.md). +- +-From the root of your project, run: +- +-```bash +-go run github.com/cometbft/cometbft/cmd/cometbft@v0.34.27 init --home /tmp/cometbft-home +-``` +- +-You should see an output similar to the following: +- +-```bash +-I[2022-11-09|09:06:34.444] Generated private validator module=main keyFile=/tmp/cometbft-home/config/priv_validator_key.json stateFile=/tmp/cometbft-home/data/priv_validator_state.json +-I[2022-11-09|09:06:34.444] Generated node key module=main path=/tmp/cometbft-home/config/node_key.json +-I[2022-11-09|09:06:34.444] Generated genesis file module=main path=/tmp/cometbft-home/config/genesis.json +-``` +- +-Now rebuild the app: +- +-```bash +-go build -mod=mod # use -mod=mod to automatically refresh the dependencies +-``` +- +-Everything is now in place to run your application. Run: +- +-```bash +-./kvstore -cmt-home /tmp/cometbft-home +-``` +- +-The application will start and you should see a continuous output starting with: +- +-```bash +-badger 2022/11/09 09:08:50 INFO: All 0 tables opened in 0s +-badger 2022/11/09 09:08:50 INFO: Discard stats nextEmptySlot: 0 +-badger 2022/11/09 09:08:50 INFO: Set nextTxnTs to 0 +-I[2022-11-09|09:08:50.085] service start module=proxy msg="Starting multiAppConn service" impl=multiAppConn +-I[2022-11-09|09:08:50.085] service start module=abci-client connection=query msg="Starting localClient service" impl=localClient +-I[2022-11-09|09:08:50.085] service start module=abci-client connection=snapshot msg="Starting localClient service" impl=localClient +-... +-``` +- +-More importantly, the application using CometBFT is producing blocks 🎉🎉 and you can see this reflected in the log output in lines like this: +- +-```bash +-I[2022-11-09|09:08:52.147] received proposal module=consensus proposal="Proposal{2/0 (F518444C0E348270436A73FD0F0B9DFEA758286BEB29482F1E3BEA75330E825C:1:C73D3D1273F2, -1) AD19AE292A45 @ 2022-11-09T12:08:52.143393Z}" +-I[2022-11-09|09:08:52.152] received complete proposal block module=consensus height=2 hash=F518444C0E348270436A73FD0F0B9DFEA758286BEB29482F1E3BEA75330E825C +-I[2022-11-09|09:08:52.160] finalizing commit of block module=consensus height=2 hash=F518444C0E348270436A73FD0F0B9DFEA758286BEB29482F1E3BEA75330E825C root= num_txs=0 +-I[2022-11-09|09:08:52.167] executed block module=state height=2 num_valid_txs=0 num_invalid_txs=0 +-I[2022-11-09|09:08:52.171] committed state module=state height=2 num_txs=0 app_hash= +-``` +- +-The blocks, as you can see from the `num_valid_txs=0` part, are empty, but let's remedy that next. +- +-## 1.6 Using the application +- +-Let's try submitting a transaction to our new application. +-Open another terminal window and run the following curl command: +- +- +-```bash +-curl -s 'localhost:26657/broadcast_tx_commit?tx="cometbft=rocks"' +-``` +- +-If everything went well, you should see a response indicating which height the +-transaction was included in the blockchain. +- +-Finally, let's make sure that transaction really was persisted by the application. +-Run the following command: +- +-```bash +-curl -s 'localhost:26657/abci_query?data="cometbft"' +-``` +- +-Let's examine the response object that this request returns. +-The request returns a `json` object with a `key` and `value` field set. +- +-```json +-... +- "key": "dGVuZGVybWludA==", +- "value": "cm9ja3M=", +-... +-``` +- +-Those values don't look like the `key` and `value` we sent to CometBFT. +-What's going on here? +- +-The response contains a `base64` encoded representation of the data we submitted. +-To get the original value out of this data, we can use the `base64` command line utility: +- +-```bash +-echo "cm9ja3M=" | base64 -d +-``` +- +-## Outro +- +-I hope everything went smoothly and your first, but hopefully not the last, +-CometBFT application is up and running. If not, please [open an issue on +-Github](https://github.com/cometbft/cometbft/issues/new/choose). diff --git a/patches/docs/guides/go.md.patch b/patches/docs/guides/go.md.patch new file mode 100644 index 00000000000..ae36a037037 --- /dev/null +++ b/patches/docs/guides/go.md.patch @@ -0,0 +1,689 @@ +diff --git a/docs/guides/go.md b/docs/guides/go.md +deleted file mode 100644 +index 9711f570f..000000000 +--- a/docs/guides/go.md ++++ /dev/null +@@ -1,683 +0,0 @@ +---- +-order: 4 +---- +- +-# Creating an application in Go +- +-## Guide Assumptions +- +-This guide is designed for beginners who want to get started with a CometBFT +-application from scratch. It does not assume that you have any prior +-experience with CometBFT. +- +-CometBFT is a service that provides a Byzantine Fault Tolerant consensus engine +-for state-machine replication. The replicated state-machine, or "application", can be written +-in any language that can send and receive protocol buffer messages in a client-server model. +-Applications written in Go can also use CometBFT as a library and run the service in the same +-process as the application. +- +-By following along this tutorial you will create a CometBFT application called kvstore, +-a (very) simple distributed BFT key-value store. +-The application will be written in Go and +-some understanding of the Go programming language is expected. +-If you have never written Go, you may want to go through [Learn X in Y minutes +-Where X=Go](https://learnxinyminutes.com/docs/go/) first, to familiarize +-yourself with the syntax. +- +-Note: Please use the latest released version of this guide and of CometBFT. +-We strongly advise against using unreleased commits for your development. +- +-### Built-in app vs external app +- +-On the one hand, to get maximum performance you can run your application in +-the same process as the CometBFT, as long as your application is written in Go. +-[Cosmos SDK](https://github.com/cosmos/cosmos-sdk) is written +-this way. +-If that is the way you wish to proceed, use the [Creating a built-in application in Go](./go-built-in.md) guide instead of this one. +- +-On the other hand, having a separate application might give you better security +-guarantees as two processes would be communicating via established binary protocol. +-CometBFT will not have access to application's state. +-This is the approach followed in this tutorial. +- +-## 1.1 Installing Go +- +-Verify that you have the latest version of Go installed (refer to the [official guide for installing Go](https://golang.org/doc/install)): +- +-```bash +-$ go version +-go version go1.21.9 darwin/amd64 +-``` +- +-## 1.2 Creating a new Go project +- +-We'll start by creating a new Go project. +- +-```bash +-mkdir kvstore +-``` +- +-Inside the example directory, create a `main.go` file with the following content: +- +-```go +-package main +- +-import ( +- "fmt" +-) +- +-func main() { +- fmt.Println("Hello, CometBFT") +-} +-``` +- +-When run, this should print "Hello, CometBFT" to the standard output. +- +-```bash +-cd kvstore +-$ go run main.go +-Hello, CometBFT +-``` +- +-We are going to use [Go modules](https://github.com/golang/go/wiki/Modules) for +-dependency management, so let's start by including a dependency on this version of +-CometBFT. +- +-```bash +-go mod init kvstore +-go get github.com/cometbft/cometbft@v0.34.27 +-``` +- +-After running the above commands you will see two generated files, `go.mod` and `go.sum`. +-The go.mod file should look similar to: +- +-```go +-module github.com/me/example +- +-go 1.19 +- +-require ( +- github.com/cometbft/cometbft v0.34.27 +-) +-``` +- +-As you write the kvstore application, you can rebuild the binary by +-pulling any new dependencies and recompiling it. +- +-```sh +-go get +-go build +-``` +- +- +-## 1.3 Writing a CometBFT application +- +-CometBFT communicates with the application through the Application +-BlockChain Interface (ABCI). The messages exchanged through the interface are +-defined in the ABCI [protobuf +-file](https://github.com/cometbft/cometbft/blob/v0.34.x/proto/tendermint/abci/types.proto). +- +-We begin by creating the basic scaffolding for an ABCI application by +-creating a new type, `KVStoreApplication`, which implements the +-methods defined by the `abcitypes.Application` interface. +- +-Create a file called `app.go` with the following contents: +- +-```go +-package main +- +-import ( +- abcitypes "github.com/cometbft/cometbft/abci/types" +-) +- +-type KVStoreApplication struct{} +- +-var _ abcitypes.Application = (*KVStoreApplication)(nil) +- +-func NewKVStoreApplication() *KVStoreApplication { +- return &KVStoreApplication{} +-} +- +-func (app *KVStoreApplication) Info(info abcitypes.RequestInfo) abcitypes.ResponseInfo { +- return abcitypes.ResponseInfo{} +-} +- +-func (app *KVStoreApplication) Query(query abcitypes.RequestQuery) abcitypes.ResponseQuery { +- return abcitypes.ResponseQuery{} +-} +- +-func (app *KVStoreApplication) CheckTx(tx abcitypes.RequestCheckTx) abcitypes.ResponseCheckTx { +- return abcitypes.ResponseCheckTx{} +-} +- +-func (app *KVStoreApplication) InitChain(chain abcitypes.RequestInitChain) abcitypes.ResponseInitChain { +- return abcitypes.ResponseInitChain{} +-} +- +-func (app *KVStoreApplication) BeginBlock(block abcitypes.RequestBeginBlock) abcitypes.ResponseBeginBlock { +- return abcitypes.ResponseBeginBlock{} +-} +- +-func (app *KVStoreApplication) DeliverTx(tx abcitypes.RequestDeliverTx) abcitypes.ResponseDeliverTx { +- return abcitypes.ResponseDeliverTx{} +-} +- +-func (app *KVStoreApplication) EndBlock(block abcitypes.RequestEndBlock) abcitypes.ResponseEndBlock { +- return abcitypes.ResponseEndBlock{} +-} +- +-func (app *KVStoreApplication) Commit() abcitypes.ResponseCommit { +- return abcitypes.ResponseCommit{} +-} +- +-func (app *KVStoreApplication) ListSnapshots(snapshots abcitypes.RequestListSnapshots) abcitypes.ResponseListSnapshots { +- return abcitypes.ResponseListSnapshots{} +-} +- +-func (app *KVStoreApplication) OfferSnapshot(snapshot abcitypes.RequestOfferSnapshot) abcitypes.ResponseOfferSnapshot { +- return abcitypes.ResponseOfferSnapshot{} +-} +- +-func (app *KVStoreApplication) LoadSnapshotChunk(chunk abcitypes.RequestLoadSnapshotChunk) abcitypes.ResponseLoadSnapshotChunk { +- return abcitypes.ResponseLoadSnapshotChunk{} +-} +- +-func (app *KVStoreApplication) ApplySnapshotChunk(chunk abcitypes.RequestApplySnapshotChunk) abcitypes.ResponseApplySnapshotChunk { +- return abcitypes.ResponseApplySnapshotChunk{} +-} +-``` +- +-The types used here are defined in the CometBFT library and were added as a dependency +-to the project when you ran `go get`. If your IDE is not recognizing the types, go ahead and run the command again. +- +-```bash +-go get github.com/cometbft/cometbft@v0.34.27 +-``` +- +-Now go back to the `main.go` and modify the `main` function so it matches the following, +-where an instance of the `KVStoreApplication` type is created. +- +-```go +-func main() { +- fmt.Println("Hello, CometBFT") +- +- _ = NewKVStoreApplication() +-} +-``` +- +-You can recompile and run the application now by running `go get` and `go build`, but it does +-not do anything. +-So let's revisit the code adding the logic needed to implement our minimal key/value store +-and to start it along with the CometBFT Service. +- +- +-### 1.3.1 Add a persistent data store +- +-Our application will need to write its state out to persistent storage so that it +-can stop and start without losing all of its data. +- +-For this tutorial, we will use [BadgerDB](https://github.com/dgraph-io/badger), a +-a fast embedded key-value store. +- +-First, add Badger as a dependency of your go module using the `go get` command: +- +-`go get github.com/dgraph-io/badger/v3` +- +-Next, let's update the application and its constructor to receive a handle to the database, as follows: +- +-```go +-type KVStoreApplication struct { +- db *badger.DB +- onGoingBlock *badger.Txn +-} +- +-var _ abcitypes.Application = (*KVStoreApplication)(nil) +- +-func NewKVStoreApplication(db *badger.DB) *KVStoreApplication { +- return &KVStoreApplication{db: db} +-} +-``` +- +-The `onGoingBlock` keeps track of the Badger transaction that will update the application's state when a block +-is completed. Don't worry about it for now, we'll get to that later. +- +-Next, update the `import` stanza at the top to include the Badger library: +- +-```go +-import( +- "github.com/dgraph-io/badger/v3" +- abcitypes "github.com/cometbft/cometbft/abci/types" +-) +-``` +- +-Finally, update the `main.go` file to invoke the updated constructor: +- +-```go +- _ = NewKVStoreApplication(nil) +-``` +- +-### 1.3.2 CheckTx +- +-When CometBFT receives a new transaction from a client, or from another full node, +-CometBFT asks the application if the transaction is acceptable, using the `CheckTx` method. +-Invalid transactions will not be shared with other nodes and will not become part of any blocks and, therefore, will not be executed by the application. +- +-In our application, a transaction is a string with the form `key=value`, indicating a key and value to write to the store. +- +-The most basic validation check we can perform is to check if the transaction conforms to the `key=value` pattern. +-For that, let's add the following helper method to app.go: +- +-```go +-func (app *KVStoreApplication) isValid(tx []byte) uint32 { +- // check format +- parts := bytes.Split(tx, []byte("=")) +- if len(parts) != 2 { +- return 1 +- } +- +- return 0 +-} +-``` +- +-Now you can rewrite the `CheckTx` method to use the helper function: +- +-```go +-func (app *KVStoreApplication) CheckTx(req abcitypes.RequestCheckTx) abcitypes.ResponseCheckTx { +- code := app.isValid(req.Tx) +- return abcitypes.ResponseCheckTx{Code: code} +-} +-``` +- +-While this `CheckTx` is simple and only validates that the transaction is well-formed, +-it is very common for `CheckTx` to make more complex use of the state of an application. +-For example, you may refuse to overwrite an existing value, or you can associate +-versions to the key/value pairs and allow the caller to specify a version to +-perform a conditional update. +- +-Depending on the checks and on the conditions violated, the function may return +-different values, but any response with a non-zero code will be considered invalid +-by CometBFT. Our `CheckTx` logic returns 0 to CometBFT when a transaction passes +-its validation checks. The specific value of the code is meaningless to CometBFT. +-Non-zero codes are logged by CometBFT so applications can provide more specific +-information on why the transaction was rejected. +- +-Note that `CheckTx` does not execute the transaction, it only verifies that that the transaction could be executed. We do not know yet if the rest of the network has agreed to accept this transaction into a block. +- +- +-Finally, make sure to add the bytes package to the `import` stanza at the top of `app.go`: +- +-```go +-import( +- "bytes" +- +- "github.com/dgraph-io/badger/v3" +- abcitypes "github.com/cometbft/cometbft/abci/types" +-) +-``` +- +- +-### 1.3.3 BeginBlock -> DeliverTx -> EndBlock -> Commit +- +-When the CometBFT consensus engine has decided on the block, the block is transferred to the +-application over three ABCI method calls: `BeginBlock`, `DeliverTx`, and `EndBlock`. +- +-- `BeginBlock` is called once to indicate to the application that it is about to +-receive a block. +-- `DeliverTx` is called repeatedly, once for each application transaction that was included in the block. +-- `EndBlock` is called once to indicate to the application that no more transactions +-will be delivered to the application in within this block. +- +-Note that, to implement these calls in our application we're going to make use of Badger's +-transaction mechanism. We will always refer to these as Badger transactions, not to +-confuse them with the transactions included in the blocks delivered by CometBFT, +-the _application transactions_. +- +-First, let's create a new Badger transaction during `BeginBlock`. All application transactions in the +-current block will be executed within this Badger transaction. +-Then, return informing CometBFT that the application is ready to receive application transactions: +- +-```go +-func (app *KVStoreApplication) BeginBlock(req abcitypes.RequestBeginBlock) abcitypes.ResponseBeginBlock { +- app.onGoingBlock = app.db.NewTransaction(true) +- return abcitypes.ResponseBeginBlock{} +-} +-``` +- +-Next, let's modify `DeliverTx` to add the `key` and `value` to the database transaction every time our application +-receives a new application transaction through `RequestDeliverTx`. +- +-```go +-func (app *KVStoreApplication) DeliverTx(req abcitypes.RequestDeliverTx) abcitypes.ResponseDeliverTx { +- if code := app.isValid(req.Tx); code != 0 { +- return abcitypes.ResponseDeliverTx{Code: code} +- } +- +- parts := bytes.SplitN(req.Tx, []byte("="), 2) +- key, value := parts[0], parts[1] +- +- if err := app.onGoingBlock.Set(key, value); err != nil { +- log.Panicf("Error writing to database, unable to execute tx: %v", err) +- } +- +- return abcitypes.ResponseDeliverTx{Code: 0} +-} +-``` +- +-Note that we check the validity of the transaction _again_ during `DeliverTx`. +-Transactions are not guaranteed to be valid when they are delivered to an +-application, even if they were valid when they were proposed. +-This can happen if the application state is used to determine transaction +-validity. Application state may have changed between the initial execution of `CheckTx` +-and the transaction delivery in `DeliverTx` in a way that rendered the transaction +-no longer valid. +- +-`EndBlock` is called to inform the application that the full block has been delivered +-and give the application a chance to perform any other computation needed, before the +-effects of the transactions become permanent. +- +-Note that `EndBlock` **cannot** yet commit the Badger transaction we were building +-in during `DeliverTx`. +-Since other methods, such as `Query`, rely on a consistent view of the application's +-state, the application should only update its state by committing the Badger transactions +-when the full block has been delivered and the `Commit` method is invoked. +- +-The `Commit` method tells the application to make permanent the effects of +-the application transactions. +-Let's update the method to terminate the pending Badger transaction and +-persist the resulting state: +- +-```go +-func (app *KVStoreApplication) Commit() abcitypes.ResponseCommit { +- if err := app.onGoingBlock.Commit(); err != nil { +- log.Panicf("Error writing to database, unable to commit block: %v", err) +- } +- return abcitypes.ResponseCommit{Data: []byte{}} +-} +-``` +- +-Finally, make sure to add the log library to the `import` stanza as well: +- +-```go +-import ( +- "bytes" +- "log" +- +- "github.com/dgraph-io/badger/v3" +- abcitypes "github.com/cometbft/cometbft/abci/types" +-) +-``` +- +-You may have noticed that the application we are writing will crash if it receives +-an unexpected error from the Badger database during the `DeliverTx` or `Commit` methods. +-This is not an accident. If the application received an error from the database, there +-is no deterministic way for it to make progress so the only safe option is to terminate. +- +-### 1.3.4 Query +- +-When a client tries to read some information from the `kvstore`, the request will be +-handled in the `Query` method. To do this, let's rewrite the `Query` method in `app.go`: +- +-```go +-func (app *KVStoreApplication) Query(req abcitypes.RequestQuery) abcitypes.ResponseQuery { +- resp := abcitypes.ResponseQuery{Key: req.Data} +- +- dbErr := app.db.View(func(txn *badger.Txn) error { +- item, err := txn.Get(req.Data) +- if err != nil { +- if err != badger.ErrKeyNotFound { +- return err +- } +- resp.Log = "key does not exist" +- return nil +- } +- +- return item.Value(func(val []byte) error { +- resp.Log = "exists" +- resp.Value = val +- return nil +- }) +- }) +- if dbErr != nil { +- log.Panicf("Error reading database, unable to execute query: %v", dbErr) +- } +- return resp +-} +-``` +- +-Since it reads only committed data from the store, transactions that are part of a block +-that is being processed are not reflected in the query result. +- +- +- +- +-## 1.4 Starting an application and a CometBFT instance +- +-Now that we have the basic functionality of our application in place, let's put it all together inside of our `main.go` file. +- +-Change the contents of your `main.go` file to the following. +- +-```go +-package main +- +-import ( +- "flag" +- "fmt" +- abciserver "github.com/cometbft/cometbft/abci/server" +- "log" +- "os" +- "os/signal" +- "path/filepath" +- "syscall" +- +- "github.com/dgraph-io/badger/v3" +- cmtlog "github.com/cometbft/cometbft/libs/log" +-) +- +-var homeDir string +-var socketAddr string +- +-func init() { +- flag.StringVar(&homeDir, "kv-home", "", "Path to the kvstore directory (if empty, uses $HOME/.kvstore)") +- flag.StringVar(&socketAddr, "socket-addr", "unix://example.sock", "Unix domain socket address (if empty, uses \"unix://example.sock\"") +-} +- +-func main() { +- flag.Parse() +- if homeDir == "" { +- homeDir = os.ExpandEnv("$HOME/.kvstore") +- } +- +- dbPath := filepath.Join(homeDir, "badger") +- db, err := badger.Open(badger.DefaultOptions(dbPath)) +- if err != nil { +- log.Fatalf("Opening database: %v", err) +- } +- defer func() { +- if err := db.Close(); err != nil { +- log.Fatalf("Closing database: %v", err) +- } +- }() +- +- app := NewKVStoreApplication(db) +- +- logger := cmtlog.NewTMLogger(cmtlog.NewSyncWriter(os.Stdout)) +- +- server := abciserver.NewSocketServer(socketAddr, app) +- server.SetLogger(logger) +- +- if err := server.Start(); err != nil { +- fmt.Fprintf(os.Stderr, "error starting socket server: %v", err) +- os.Exit(1) +- } +- defer server.Stop() +- +- c := make(chan os.Signal, 1) +- signal.Notify(c, os.Interrupt, syscall.SIGTERM) +- <-c +-} +-``` +- +-This is a huge blob of code, so let's break it down into pieces. +- +-First, we initialize the Badger database and create an app instance: +- +-```go +- dbPath := filepath.Join(homeDir, "badger") +- db, err := badger.Open(badger.DefaultOptions(dbPath)) +- if err != nil { +- log.Fatalf("Opening database: %v", err) +- } +- defer func() { +- if err := db.Close(); err != nil { +- log.Fatalf("Closing database: %v", err) +- } +- }() +- +- app := NewKVStoreApplication(db) +-``` +- +-For **Windows** users, restarting this app will make badger throw an error as it requires value log to be truncated. For more information on this, visit [here](https://github.com/dgraph-io/badger/issues/744). +-This can be avoided by setting the truncate option to true, like this: +- +-```go +- db, err := badger.Open(badger.DefaultOptions("/tmp/badger").WithTruncate(true)) +-``` +- +-Then we start the ABCI server and add some signal handling to gracefully stop +-it upon receiving SIGTERM or Ctrl-C. CometBFT will act as a client, +-which connects to our server and send us transactions and other messages. +- +-```go +- server := abciserver.NewSocketServer(socketAddr, app) +- server.SetLogger(logger) +- +- if err := server.Start(); err != nil { +- fmt.Fprintf(os.Stderr, "error starting socket server: %v", err) +- os.Exit(1) +- } +- defer server.Stop() +- +- c := make(chan os.Signal, 1) +- signal.Notify(c, os.Interrupt, syscall.SIGTERM) +- <-c +-``` +- +-## 1.5 Initializing and Running +- +-Our application is almost ready to run, but first we'll need to populate the CometBFT configuration files. +-The following command will create a `cometbft-home` directory in your project and add a basic set of configuration files in `cometbft-home/config/`. +-For more information on what these files contain see [the configuration documentation](https://github.com/cometbft/cometbft/blob/v0.34.x/docs/core/configuration.md). +- +-From the root of your project, run: +- +-```bash +-go run github.com/cometbft/cometbft/cmd/cometbft@v0.34.27 init --home /tmp/cometbft-home +-``` +- +-You should see an output similar to the following: +- +-```bash +-I[2022-11-09|09:06:34.444] Generated private validator module=main keyFile=/tmp/cometbft-home/config/priv_validator_key.json stateFile=/tmp/cometbft-home/data/priv_validator_state.json +-I[2022-11-09|09:06:34.444] Generated node key module=main path=/tmp/cometbft-home/config/node_key.json +-I[2022-11-09|09:06:34.444] Generated genesis file module=main path=/tmp/cometbft-home/config/genesis.json +-``` +- +-Now rebuild the app: +- +-```bash +-go build -mod=mod # use -mod=mod to automatically refresh the dependencies +-``` +- +-Everything is now in place to run your application. Run: +- +-```bash +-./kvstore -kv-home /tmp/badger-home +-``` +- +-The application will start and you should see an output similar to the following: +- +-```bash +-badger 2022/11/09 17:01:28 INFO: All 0 tables opened in 0s +-badger 2022/11/09 17:01:28 INFO: Discard stats nextEmptySlot: 0 +-badger 2022/11/09 17:01:28 INFO: Set nextTxnTs to 0 +-I[2022-11-09|17:01:28.726] service start msg="Starting ABCIServer service" impl=ABCIServer +-I[2022-11-09|17:01:28.726] Waiting for new connection... +-``` +- +-Then we need to start CometBFT service and point it to our application. +-Open a new terminal window and cd to the same folder where the app is running. +-Then execute the following command: +- +-```bash +-go run github.com/cometbft/cometbft/cmd/cometbft@v0.34.27 node --home /tmp/cometbft-home --proxy_app=unix://example.sock +-``` +- +-This should start the full node and connect to our ABCI application, which will be +-reflected in the application output. +- +-```sh +-I[2022-11-09|17:07:08.124] service start msg="Starting ABCIServer service" impl=ABCIServer +-I[2022-11-09|17:07:08.124] Waiting for new connection... +-I[2022-11-09|17:08:12.702] Accepted a new connection +-I[2022-11-09|17:08:12.703] Waiting for new connection... +-I[2022-11-09|17:08:12.703] Accepted a new connection +-I[2022-11-09|17:08:12.703] Waiting for new connection... +-``` +- +-Also, the application using CometBFT Core is producing blocks 🎉🎉 and you can see this reflected in the log output of the service in lines like this: +- +-```bash +-I[2022-11-09|09:08:52.147] received proposal module=consensus proposal="Proposal{2/0 (F518444C0E348270436A73FD0F0B9DFEA758286BEB29482F1E3BEA75330E825C:1:C73D3D1273F2, -1) AD19AE292A45 @ 2022-11-09T12:08:52.143393Z}" +-I[2022-11-09|09:08:52.152] received complete proposal block module=consensus height=2 hash=F518444C0E348270436A73FD0F0B9DFEA758286BEB29482F1E3BEA75330E825C +-I[2022-11-09|09:08:52.160] finalizing commit of block module=consensus height=2 hash=F518444C0E348270436A73FD0F0B9DFEA758286BEB29482F1E3BEA75330E825C root= num_txs=0 +-I[2022-11-09|09:08:52.167] executed block module=state height=2 num_valid_txs=0 num_invalid_txs=0 +-I[2022-11-09|09:08:52.171] committed state module=state height=2 num_txs=0 app_hash= +-``` +- +-The blocks, as you can see from the `num_valid_txs=0` part, are empty, but let's remedy that next. +- +-## 1.6 Using the application +- +-Let's try submitting a transaction to our new application. +-Open another terminal window and run the following curl command: +- +- +-```bash +-curl -s 'localhost:26657/broadcast_tx_commit?tx="cometbft=rocks"' +-``` +- +-If everything went well, you should see a response indicating which height the +-transaction was included in the blockchain. +- +-Finally, let's make sure that transaction really was persisted by the application. +-Run the following command: +- +-```bash +-curl -s 'localhost:26657/abci_query?data="cometbft"' +-``` +- +-Let's examine the response object that this request returns. +-The request returns a `json` object with a `key` and `value` field set. +- +-```json +-... +- "key": "dGVuZGVybWludA==", +- "value": "cm9ja3M=", +-... +-``` +- +-Those values don't look like the `key` and `value` we sent to CometBFT. +-What's going on here? +- +-The response contains a `base64` encoded representation of the data we submitted. +-To get the original value out of this data, we can use the `base64` command line utility: +- +-```bash +-echo "cm9ja3M=" | base64 -d +-``` +- +-## Outro +- +-I hope everything went smoothly and your first, but hopefully not the last, +-CometBFT application is up and running. If not, please [open an issue on +-Github](https://github.com/cometbft/cometbft/issues/new/choose). diff --git a/patches/docs/guides/install.md.patch b/patches/docs/guides/install.md.patch new file mode 100644 index 00000000000..c42b9e1d5f0 --- /dev/null +++ b/patches/docs/guides/install.md.patch @@ -0,0 +1,126 @@ +diff --git a/docs/guides/install.md b/docs/guides/install.md +deleted file mode 100644 +index 4b2d3166e..000000000 +--- a/docs/guides/install.md ++++ /dev/null +@@ -1,120 +0,0 @@ +---- +-order: 1 +---- +- +-# Install CometBFT +- +-## From Binary +- +-To download pre-built binaries, see the [releases page](https://github.com/cometbft/cometbft/releases). +- +-## From Source +- +-You'll need `go` [installed](https://golang.org/doc/install) and the required +-environment variables set, which can be done with the following commands: +- +-```sh +-echo export GOPATH=\"\$HOME/go\" >> ~/.bash_profile +-echo export PATH=\"\$PATH:\$GOPATH/bin\" >> ~/.bash_profile +-``` +- +-### Get Source Code +- +-```sh +-git clone https://github.com/cometbft/cometbft.git +-cd cometbft +-``` +- +-### Compile +- +-```sh +-make install +-``` +- +-to put the binary in `$GOPATH/bin` or use: +- +-```sh +-make build +-``` +- +-to put the binary in `./build`. +- +-_DISCLAIMER_ The binary of CometBFT is build/installed without the DWARF +-symbol table. If you would like to build/install CometBFT with the DWARF +-symbol and debug information, remove `-s -w` from `BUILD_FLAGS` in the make +-file. +- +-The latest CometBFT is now installed. You can verify the installation by +-running: +- +-```sh +-cometbft version +-``` +- +-## Run +- +-To start a one-node blockchain with a simple in-process application: +- +-```sh +-cometbft init +-cometbft node --proxy_app=kvstore +-``` +- +-## Reinstall +- +-If you already have CometBFT installed, and you make updates, simply +- +-```sh +-make install +-``` +- +-To upgrade, run +- +-```sh +-git pull origin main +-make install +-``` +- +-## Compile with CLevelDB support +- +-Install [LevelDB](https://github.com/google/leveldb) (minimum version is 1.7). +- +-Install LevelDB with snappy (optionally). Below are commands for Ubuntu: +- +-```sh +-sudo apt-get update +-sudo apt install build-essential +- +-sudo apt-get install libsnappy-dev +- +-wget https://github.com/google/leveldb/archive/v1.20.tar.gz && \ +- tar -zxvf v1.20.tar.gz && \ +- cd leveldb-1.20/ && \ +- make && \ +- sudo cp -r out-static/lib* out-shared/lib* /usr/local/lib/ && \ +- cd include/ && \ +- sudo cp -r leveldb /usr/local/include/ && \ +- sudo ldconfig && \ +- rm -f v1.20.tar.gz +-``` +- +-Set a database backend to `cleveldb`: +- +-```toml +-# config/config.toml +-db_backend = "cleveldb" +-``` +- +-To install CometBFT, run: +- +-```sh +-CGO_LDFLAGS="-lsnappy" make install COMETBFT_BUILD_OPTIONS=cleveldb +-``` +- +-or run: +- +-```sh +-CGO_LDFLAGS="-lsnappy" make build COMETBFT_BUILD_OPTIONS=cleveldb +-``` +- +-which puts the binary in `./build`. diff --git a/patches/docs/guides/quick-start.md.patch b/patches/docs/guides/quick-start.md.patch new file mode 100644 index 00000000000..33808d786f8 --- /dev/null +++ b/patches/docs/guides/quick-start.md.patch @@ -0,0 +1,130 @@ +diff --git a/docs/guides/quick-start.md b/docs/guides/quick-start.md +deleted file mode 100644 +index 21dcdc91d..000000000 +--- a/docs/guides/quick-start.md ++++ /dev/null +@@ -1,124 +0,0 @@ +---- +-order: 2 +---- +- +-# Quick Start +- +-## Overview +- +-This is a quick start guide. If you have a vague idea about how CometBFT +-works and want to get started right away, continue. +- +-## Install +- +-See the [install guide](./install.md). +- +-## Initialization +- +-Running: +- +-```sh +-cometbft init +-``` +- +-will create the required files for a single, local node. +- +-These files are found in `$HOME/.cometbft`: +- +-```sh +-$ ls $HOME/.cometbft +- +-config data +- +-$ ls $HOME/.cometbft/config/ +- +-config.toml genesis.json node_key.json priv_validator.json +-``` +- +-For a single, local node, no further configuration is required. +-Configuring a cluster is covered further below. +- +-## Local Node +- +-Start CometBFT with a simple in-process application: +- +-```sh +-cometbft node --proxy_app=kvstore +-``` +- +-> Note: `kvstore` is a non persistent app, if you would like to run an application with persistence run `--proxy_app=persistent_kvstore` +- +-and blocks will start to stream in: +- +-```sh +-I[01-06|01:45:15.592] Executed block module=state height=1 validTxs=0 invalidTxs=0 +-I[01-06|01:45:15.624] Committed state module=state height=1 txs=0 appHash= +-``` +- +-Check the status with: +- +-```sh +-curl -s localhost:26657/status +-``` +- +-### Sending Transactions +- +-With the KVstore app running, we can send transactions: +- +-```sh +-curl -s 'localhost:26657/broadcast_tx_commit?tx="abcd"' +-``` +- +-and check that it worked with: +- +-```sh +-curl -s 'localhost:26657/abci_query?data="abcd"' +-``` +- +-We can send transactions with a key and value too: +- +-```sh +-curl -s 'localhost:26657/broadcast_tx_commit?tx="name=satoshi"' +-``` +- +-and query the key: +- +-```sh +-curl -s 'localhost:26657/abci_query?data="name"' +-``` +- +-where the value is returned in hex. +- +-## Cluster of Nodes +- +-First create four Ubuntu cloud machines. The following was tested on Digital +-Ocean Ubuntu 16.04 x64 (3GB/1CPU, 20GB SSD). We'll refer to their respective IP +-addresses below as IP1, IP2, IP3, IP4. +- +-Then, `ssh` into each machine and install CometBFT following the [guide](./install.md). +- +-Next, use the `cometbft testnet` command to create four directories of config files (found in `./mytestnet`) and copy each directory to the relevant machine in the cloud, so that each machine has `$HOME/mytestnet/node[0-3]` directory. +- +-Before you can start the network, you'll need peers identifiers (IPs are not enough and can change). We'll refer to them as ID1, ID2, ID3, ID4. +- +-```sh +-cometbft show_node_id --home ./mytestnet/node0 +-cometbft show_node_id --home ./mytestnet/node1 +-cometbft show_node_id --home ./mytestnet/node2 +-cometbft show_node_id --home ./mytestnet/node3 +-``` +- +-Finally, from each machine, run: +- +-```sh +-cometbft node --home ./mytestnet/node0 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656" +-cometbft node --home ./mytestnet/node1 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656" +-cometbft node --home ./mytestnet/node2 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656" +-cometbft node --home ./mytestnet/node3 --proxy_app=kvstore --p2p.persistent_peers="ID1@IP1:26656,ID2@IP2:26656,ID3@IP3:26656,ID4@IP4:26656" +-``` +- +-Note that after the third node is started, blocks will start to stream in +-because >2/3 of validators (defined in the `genesis.json`) have come online. +-Persistent peers can also be specified in the `config.toml`. See [here](../core/configuration.md) for more information about configuration options. +- +-Transactions can then be sent as covered in the single, local node example above. diff --git a/patches/docs/guides/upgrading-from-tm.md.patch b/patches/docs/guides/upgrading-from-tm.md.patch new file mode 100644 index 00000000000..a7f10e11d34 --- /dev/null +++ b/patches/docs/guides/upgrading-from-tm.md.patch @@ -0,0 +1,52 @@ +diff --git a/docs/guides/upgrading-from-tm.md b/docs/guides/upgrading-from-tm.md +deleted file mode 100644 +index 5f83d342e..000000000 +--- a/docs/guides/upgrading-from-tm.md ++++ /dev/null +@@ -1,46 +0,0 @@ +---- +-order: 3 +---- +- +-# Upgrading from Tendermint Core +- +-CometBFT was originally forked from [Tendermint Core v0.34.24][v03424] and +-subsequently updated in Informal Systems' public fork of Tendermint Core for +-[v0.34.25][v03425] and [v0.34.26][v03426]. +- +-If you already make use of Tendermint Core (either the original Tendermint Core +-v0.34.24, or Informal Systems' public fork), you can upgrade to CometBFT +-v0.34.27 by replacing your dependency in your `go.mod` file: +- +-```bash +-go mod edit -replace github.com/tendermint/tendermint=github.com/cometbft/cometbft@v0.34.27 +-``` +- +-We make use of the original module URL in order to minimize the impact of +-switching to CometBFT. This is only possible in our v0.34 release series, and we +-will be switching our module URL to `github.com/cometbft/cometbft` in the next +-major release. +- +-## Home directory +- +-CometBFT, by default, will consider its home directory in `~/.cometbft` from now +-on instead of `~/.tendermint`. +- +-## Environment variables +- +-The environment variable prefixes have now changed from `TM` to `CMT`. For +-example, `TMHOME` or `TM_HOME` become `CMTHOME` or `CMT_HOME`. +- +-We have implemented a fallback check in case `TMHOME` is still set and `CMTHOME` +-is not, but you will start to see a warning message in the logs if the old +-`TMHOME` variable is set. This fallback check will be removed entirely in a +-subsequent major release of CometBFT. +- +-## Building CometBFT +- +-If you are building CometBFT from scratch, please note that it must be compiled +-using Go 1.21 or higher. +- +-[v03424]: https://github.com/tendermint/tendermint/releases/tag/v0.34.24 +-[v03425]: https://github.com/informalsystems/tendermint/releases/tag/v0.34.25 +-[v03426]: https://github.com/informalsystems/tendermint/releases/tag/v0.34.26 diff --git a/patches/docs/imgs/abci.png.patch b/patches/docs/imgs/abci.png.patch new file mode 100644 index 00000000000..85b59f024fa --- /dev/null +++ b/patches/docs/imgs/abci.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/imgs/abci.png b/docs/imgs/abci.png +deleted file mode 100644 +index 73111cafd..000000000 +Binary files a/docs/imgs/abci.png and /dev/null differ diff --git a/patches/docs/imgs/consensus_logic.png.patch b/patches/docs/imgs/consensus_logic.png.patch new file mode 100644 index 00000000000..9b326561d52 --- /dev/null +++ b/patches/docs/imgs/consensus_logic.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/imgs/consensus_logic.png b/docs/imgs/consensus_logic.png +deleted file mode 100644 +index 22b70b265..000000000 +Binary files a/docs/imgs/consensus_logic.png and /dev/null differ diff --git a/patches/docs/imgs/light_client_bisection_alg.png.patch b/patches/docs/imgs/light_client_bisection_alg.png.patch new file mode 100644 index 00000000000..20c3dbd426e --- /dev/null +++ b/patches/docs/imgs/light_client_bisection_alg.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/imgs/light_client_bisection_alg.png b/docs/imgs/light_client_bisection_alg.png +deleted file mode 100644 +index a960ee69f..000000000 +Binary files a/docs/imgs/light_client_bisection_alg.png and /dev/null differ diff --git a/patches/docs/imgs/sentry_layout.png.patch b/patches/docs/imgs/sentry_layout.png.patch new file mode 100644 index 00000000000..6d2dbe33dd0 --- /dev/null +++ b/patches/docs/imgs/sentry_layout.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/imgs/sentry_layout.png b/docs/imgs/sentry_layout.png +deleted file mode 100644 +index 7d7dff44d..000000000 +Binary files a/docs/imgs/sentry_layout.png and /dev/null differ diff --git a/patches/docs/imgs/sentry_local_config.png.patch b/patches/docs/imgs/sentry_local_config.png.patch new file mode 100644 index 00000000000..99605a90d19 --- /dev/null +++ b/patches/docs/imgs/sentry_local_config.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/imgs/sentry_local_config.png b/docs/imgs/sentry_local_config.png +deleted file mode 100644 +index 4fdb2fe58..000000000 +Binary files a/docs/imgs/sentry_local_config.png and /dev/null differ diff --git a/patches/docs/introduction/README.md.patch b/patches/docs/introduction/README.md.patch new file mode 100644 index 00000000000..7b01ea2878b --- /dev/null +++ b/patches/docs/introduction/README.md.patch @@ -0,0 +1,337 @@ +diff --git a/docs/introduction/README.md b/docs/introduction/README.md +deleted file mode 100644 +index acafe992f..000000000 +--- a/docs/introduction/README.md ++++ /dev/null +@@ -1,331 +0,0 @@ +---- +-order: false +-parent: +- title: Introduction +- order: 1 +---- +- +-# What is CometBFT +- +-CometBFT is software for securely and consistently replicating an +-application on many machines. By securely, we mean that CometBFT works +-as long as less than 1/3 of machines fail in arbitrary ways. By consistently, +-we mean that every non-faulty machine sees the same transaction log and +-computes the same state. Secure and consistent replication is a +-fundamental problem in distributed systems; it plays a critical role in +-the fault tolerance of a broad range of applications, from currencies, +-to elections, to infrastructure orchestration, and beyond. +- +-The ability to tolerate machines failing in arbitrary ways, including +-becoming malicious, is known as Byzantine fault tolerance (BFT). The +-theory of BFT is decades old, but software implementations have only +-became popular recently, due largely to the success of "blockchain +-technology" like Bitcoin and Ethereum. Blockchain technology is just a +-reformalization of BFT in a more modern setting, with emphasis on +-peer-to-peer networking and cryptographic authentication. The name +-derives from the way transactions are batched in blocks, where each +-block contains a cryptographic hash of the previous one, forming a +-chain. +- +-CometBFT consists of two chief technical components: a blockchain +-consensus engine and a generic application interface. +-The consensus engine, +-which is based on [Tendermint consensus algorithm][tendermint-paper], +-ensures that the same transactions are +-recorded on every machine in the same order. The application interface, +-called the Application BlockChain Interface (ABCI), delivers the transactions +-to applications for processing. Unlike other +-blockchain and consensus solutions, which come pre-packaged with built +-in state machines (like a fancy key-value store, or a quirky scripting +-language), developers can use CometBFT for BFT state machine +-replication of applications written in whatever programming language and +-development environment is right for them. +- +-CometBFT is designed to be easy-to-use, simple-to-understand, highly +-performant, and useful for a wide variety of distributed applications. +- +-## CometBFT vs. X +- +-CometBFT is broadly similar to two classes of software. The first +-class consists of distributed key-value stores, like Zookeeper, etcd, +-and consul, which use non-BFT consensus. The second class is known as +-"blockchain technology", and consists of both cryptocurrencies like +-Bitcoin and Ethereum, and alternative distributed ledger designs like +-Hyperledger's Burrow. +- +-### Zookeeper, etcd, consul +- +-Zookeeper, etcd, and consul are all implementations of key-value stores +-atop a classical, non-BFT consensus algorithm. Zookeeper uses an +-algorithm called Zookeeper Atomic Broadcast, while etcd and consul use +-the Raft log replication algorithm. A +-typical cluster contains 3-5 machines, and can tolerate crash failures +-in less than 1/2 of the machines (e.g., 1 out of 3 or 2 out of 5), +-but even a single Byzantine fault can jeopardize the whole system. +- +-Each offering provides a slightly different implementation of a +-featureful key-value store, but all are generally focused around +-providing basic services to distributed systems, such as dynamic +-configuration, service discovery, locking, leader-election, and so on. +- +-CometBFT is in essence similar software, but with two key differences: +- +-- It is Byzantine Fault Tolerant, meaning it can only tolerate less than 1/3 +- of machines failing, but those failures can include arbitrary behavior - +- including hacking and malicious attacks. +-- It does not specify a +- particular application, like a fancy key-value store. Instead, it +- focuses on arbitrary state machine replication, so developers can build +- the application logic that's right for them, from key-value store to +- cryptocurrency to e-voting platform and beyond. +- +-### Bitcoin, Ethereum, etc +- +-[Tendermint consensus algorithm][tendermint-paper], adopted by CometBFT, +-emerged in the tradition of cryptocurrencies like Bitcoin, +-Ethereum, etc. with the goal of providing a more efficient and secure +-consensus algorithm than Bitcoin's Proof of Work. In the early days, +-Tendermint consensus-based blockchains had a simple currency built in, and to participate in +-consensus, users had to "bond" units of the currency into a security +-deposit which could be revoked if they misbehaved -this is what made +-Tendermint consensus a Proof-of-Stake algorithm. +- +-Since then, CometBFT has evolved to be a general purpose blockchain +-consensus engine that can host arbitrary application states. That means +-it can be used as a plug-and-play replacement for the consensus engines +-of other blockchain software. So one can take the current Ethereum code +-base, whether in Rust, or Go, or Haskell, and run it as an ABCI +-application using CometBFT. Indeed, [we did that with +-Ethereum](https://github.com/cosmos/ethermint). And we plan to do +-the same for Bitcoin, ZCash, and various other deterministic +-applications as well. +- +-Another example of a cryptocurrency application built on CometBFT is +-[the Cosmos network](http://cosmos.network). +- +-### Other Blockchain Projects +- +-[Fabric](https://github.com/hyperledger/fabric) takes a similar approach +-to CometBFT, but is more opinionated about how the state is managed, +-and requires that all application behavior runs in potentially many +-docker containers, modules it calls "chaincode". It uses an +-implementation of [PBFT](http://pmg.csail.mit.edu/papers/osdi99.pdf). +-from a team at IBM that is [augmented to handle potentially +-non-deterministic +-chaincode](https://drops.dagstuhl.de/opus/volltexte/2017/7093/pdf/LIPIcs-OPODIS-2016-24.pdf). +-It is possible to implement this docker-based behavior as an ABCI app in +-CometBFT, though extending CometBFT to handle non-determinism +-remains for future work. +- +-[Burrow](https://github.com/hyperledger/burrow) is an implementation of +-the Ethereum Virtual Machine and Ethereum transaction mechanics, with +-additional features for a name-registry, permissions, and native +-contracts, and an alternative blockchain API. It uses CometBFT as its +-consensus engine, and provides a particular application state. +- +-## ABCI Overview +- +-The [Application BlockChain Interface +-(ABCI)](https://github.com/cometbft/cometbft/tree/main/abci) +-allows for Byzantine Fault Tolerant replication of applications +-written in any programming language. +- +-### Motivation +- +-Thus far, all blockchains "stacks" (such as +-[Bitcoin](https://github.com/bitcoin/bitcoin)) have had a monolithic +-design. That is, each blockchain stack is a single program that handles +-all the concerns of a decentralized ledger; this includes P2P +-connectivity, the "mempool" broadcasting of transactions, consensus on +-the most recent block, account balances, Turing-complete contracts, +-user-level permissions, etc. +- +-Using a monolithic architecture is typically bad practice in computer +-science. It makes it difficult to reuse components of the code, and +-attempts to do so result in complex maintenance procedures for forks of +-the codebase. This is especially true when the codebase is not modular +-in design and suffers from "spaghetti code". +- +-Another problem with monolithic design is that it limits you to the +-language of the blockchain stack (or vice versa). In the case of +-Ethereum which supports a Turing-complete bytecode virtual-machine, it +-limits you to languages that compile down to that bytecode; while the +-[list](https://github.com/pirapira/awesome-ethereum-virtual-machine#programming-languages-that-compile-into-evm) +-is growing, it is still very limited. +- +-In contrast, our approach is to decouple the consensus engine and P2P +-layers from the details of the state of the particular +-blockchain application. We do this by abstracting away the details of +-the application to an interface, which is implemented as a socket +-protocol. +- +-### Intro to ABCI +- +-[CometBFT](https://github.com/cometbft/cometbft), the +-"consensus engine", communicates with the application via a socket +-protocol that satisfies the ABCI, the CometBFT Socket Protocol. +- +-To draw an analogy, let's talk about a well-known cryptocurrency, +-Bitcoin. Bitcoin is a cryptocurrency blockchain where each node +-maintains a fully audited Unspent Transaction Output (UTXO) database. If +-one wanted to create a Bitcoin-like system on top of ABCI, CometBFT +-would be responsible for +- +-- Sharing blocks and transactions between nodes +-- Establishing a canonical/immutable order of transactions +- (the blockchain) +- +-The application will be responsible for +- +-- Maintaining the UTXO database +-- Validating cryptographic signatures of transactions +-- Preventing transactions from spending non-existent transactions +-- Allowing clients to query the UTXO database. +- +-CometBFT is able to decompose the blockchain design by offering a very +-simple API (i.e. the ABCI) between the application process and consensus +-process. +- +-The ABCI consists of 3 primary message types that get delivered from the +-core to the application. The application replies with corresponding +-response messages. +- +-The messages are specified here: [ABCI Message +-Types](https://github.com/cometbft/cometbft/blob/main/proto/tendermint/abci/types.proto). +- +-The **DeliverTx** message is the work horse of the application. Each +-transaction in the blockchain is delivered with this message. The +-application needs to validate each transaction received with the +-**DeliverTx** message against the current state, application protocol, +-and the cryptographic credentials of the transaction. A validated +-transaction then needs to update the application state — by binding a +-value into a key values store, or by updating the UTXO database, for +-instance. +- +-The **CheckTx** message is similar to **DeliverTx**, but it's only for +-validating transactions. CometBFT's mempool first checks the +-validity of a transaction with **CheckTx**, and only relays valid +-transactions to its peers. For instance, an application may check an +-incrementing sequence number in the transaction and return an error upon +-**CheckTx** if the sequence number is old. Alternatively, they might use +-a capabilities based system that requires capabilities to be renewed +-with every transaction. +- +-The **Commit** message is used to compute a cryptographic commitment to +-the current application state, to be placed into the next block header. +-This has some handy properties. Inconsistencies in updating that state +-will now appear as blockchain forks which catches a whole class of +-programming errors. This also simplifies the development of secure +-lightweight clients, as Merkle-hash proofs can be verified by checking +-against the block hash, and that the block hash is signed by a quorum. +- +-There can be multiple ABCI socket connections to an application. +-CometBFT creates three ABCI connections to the application; one +-for the validation of transactions when broadcasting in the mempool, one +-for the consensus engine to run block proposals, and one more for +-querying the application state. +- +-It's probably evident that applications designers need to very carefully +-design their message handlers to create a blockchain that does anything +-useful but this architecture provides a place to start. The diagram +-below illustrates the flow of messages via ABCI. +- +-![abci](../imgs/abci.png) +- +-## A Note on Determinism +- +-The logic for blockchain transaction processing must be deterministic. +-If the application logic weren't deterministic, consensus would not be +-reached among the CometBFT replica nodes. +- +-Solidity on Ethereum is a great language of choice for blockchain +-applications because, among other reasons, it is a completely +-deterministic programming language. However, it's also possible to +-create deterministic applications using existing popular languages like +-Java, C++, Python, or Go, by avoiding +-sources of non-determinism such as: +- +-- random number generators (without deterministic seeding) +-- race conditions on threads (or avoiding threads altogether) +-- the system clock +-- uninitialized memory (in unsafe programming languages like C +- or C++) +-- [floating point +- arithmetic](http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/) +-- language features that are random (e.g. map iteration in Go) +- +-While programmers can avoid non-determinism by being careful, it is also +-possible to create a special linter or static analyzer for each language +-to check for determinism. In the future we may work with partners to +-create such tools. +- +-## Consensus Overview +- +-CometBFT adopts [Tendermint consensus][tendermint-paper], +-an easy-to-understand, mostly asynchronous, BFT consensus algorithm. +-The algorithm follows a simple state machine that looks like this: +- +-![consensus-logic](../imgs/consensus_logic.png) +- +-Participants in the algorithm are called **validators**; they take turns +-proposing blocks of transactions and voting on them. Blocks are +-committed in a chain, with one block at each **height**. A block may +-fail to be committed, in which case the algorithm moves to the next +-**round**, and a new validator gets to propose a block for that height. +-Two stages of voting are required to successfully commit a block; we +-call them **pre-vote** and **pre-commit**. +- +-There is a picture of a couple doing the polka because validators are +-doing something like a polka dance. When more than two-thirds of the +-validators pre-vote for the same block, we call that a **polka**. Every +-pre-commit must be justified by a polka in the same round. +-A block is committed when +-more than 2/3 of validators pre-commit for the same block in the same +-round. +- +-Validators may fail to commit a block for a number of reasons; the +-current proposer may be offline, or the network may be slow. Tendermint consensus +-allows them to establish that a validator should be skipped. Validators +-wait a small amount of time to receive a complete proposal block from +-the proposer before voting to move to the next round. This reliance on a +-timeout is what makes Tendermint consensus a weakly synchronous algorithm, rather +-than an asynchronous one. However, the rest of the algorithm is +-asynchronous, and validators only make progress after hearing from more +-than two-thirds of the validator set. A simplifying element of +-Tendermint consensus is that it uses the same mechanism to commit a block as it +-does to skip to the next round. +- +-Assuming less than one-third of the validators are Byzantine, Tendermint consensus algorithm +-guarantees that safety will never be violated - that is, validators will +-never commit conflicting blocks at the same height. To do this it +-introduces a few **locking** rules which modulate which paths can be +-followed in the flow diagram. Once a validator precommits a block, it is +-locked on that block. Then, +- +-1. it must prevote for the block it is locked on +-2. it can only unlock, and precommit for a new block, if there is a +- polka for that block in a later round +- +-## Stake +- +-In many systems, not all validators will have the same "weight" in the +-consensus protocol. Thus, we are not so much interested in one-third or +-two-thirds of the validators, but in those proportions of the total +-voting power, which may not be uniformly distributed across individual +-validators. +- +-Since CometBFT can replicate arbitrary applications, it is possible to +-define a currency, and denominate the voting power in that currency. +-When voting power is denominated in a native currency, the system is +-often referred to as Proof-of-Stake. Validators can be forced, by logic +-in the application, to "bond" their currency holdings in a security +-deposit that can be destroyed if they're found to misbehave in the +-consensus protocol. This adds an economic element to the security of the +-protocol, allowing one to quantify the cost of violating the assumption +-that less than one-third of voting power is Byzantine. +- +-The [Cosmos Network](https://cosmos.network) is designed to use this +-Proof-of-Stake mechanism across an array of cryptocurrencies implemented +-as ABCI applications. +- +-[tendermint-paper]: https://arxiv.org/abs/1807.04938 diff --git a/patches/docs/introduction/what-is-cometbft.md.patch b/patches/docs/introduction/what-is-cometbft.md.patch new file mode 100644 index 00000000000..082faa03e36 --- /dev/null +++ b/patches/docs/introduction/what-is-cometbft.md.patch @@ -0,0 +1,338 @@ +diff --git a/docs/introduction/what-is-cometbft.md b/docs/introduction/what-is-cometbft.md +deleted file mode 100644 +index a694b9ad5..000000000 +--- a/docs/introduction/what-is-cometbft.md ++++ /dev/null +@@ -1,332 +0,0 @@ +---- +-order: 5 +---- +- +-# What is CometBFT +- +-CometBFT is software for securely and consistently replicating an +-application on many machines. By securely, we mean that CometBFT works +-as long as less than 1/3 of machines fail in arbitrary ways. By consistently, +-we mean that every non-faulty machine sees the same transaction log and +-computes the same state. Secure and consistent replication is a +-fundamental problem in distributed systems; it plays a critical role in +-the fault tolerance of a broad range of applications, from currencies, +-to elections, to infrastructure orchestration, and beyond. +- +-The ability to tolerate machines failing in arbitrary ways, including +-becoming malicious, is known as Byzantine fault tolerance (BFT). The +-theory of BFT is decades old, but software implementations have only +-became popular recently, due largely to the success of "blockchain +-technology" like Bitcoin and Ethereum. Blockchain technology is just a +-reformalization of BFT in a more modern setting, with emphasis on +-peer-to-peer networking and cryptographic authentication. The name +-derives from the way transactions are batched in blocks, where each +-block contains a cryptographic hash of the previous one, forming a +-chain. In practice, the blockchain data structure actually optimizes BFT +-design. +- +-CometBFT consists of two chief technical components: a blockchain +-consensus engine and a generic application interface. +-The consensus engine, +-which is based on [Tendermint consensus algorithm][tendermint-paper], +-ensures that the same transactions are +-recorded on every machine in the same order. The application interface, +-called the Application BlockChain Interface (ABCI), enables the +-transactions to be processed in any programming language. Unlike other +-blockchain and consensus solutions, which come pre-packaged with built +-in state machines (like a fancy key-value store, or a quirky scripting +-language), developers can use CometBFT for BFT state machine +-replication of applications written in whatever programming language and +-development environment is right for them. +- +-CometBFT is designed to be easy-to-use, simple-to-understand, highly +-performant, and useful for a wide variety of distributed applications. +- +-## CometBFT vs. X +- +-CometBFT is broadly similar to two classes of software. The first +-class consists of distributed key-value stores, like Zookeeper, etcd, +-and consul, which use non-BFT consensus. The second class is known as +-"blockchain technology", and consists of both cryptocurrencies like +-Bitcoin and Ethereum, and alternative distributed ledger designs like +-Hyperledger's Burrow. +- +-### Zookeeper, etcd, consul +- +-Zookeeper, etcd, and consul are all implementations of a key-value store +-atop a classical, non-BFT consensus algorithm. Zookeeper uses a version +-of Paxos called Zookeeper Atomic Broadcast, while etcd and consul use +-the Raft consensus algorithm, which is much younger and simpler. A +-typical cluster contains 3-5 machines, and can tolerate crash failures +-in up to 1/2 of the machines, but even a single Byzantine fault can +-destroy the system. +- +-Each offering provides a slightly different implementation of a +-featureful key-value store, but all are generally focused around +-providing basic services to distributed systems, such as dynamic +-configuration, service discovery, locking, leader-election, and so on. +- +-CometBFT is in essence similar software, but with two key differences: +- +-- It is Byzantine Fault Tolerant, meaning it can only tolerate less than 1/3 +- of machines failing, but those failures can include arbitrary behavior - +- including hacking and malicious attacks. +-- It does not specify a +- particular application, like a fancy key-value store. Instead, it +- focuses on arbitrary state machine replication, so developers can build +- the application logic that's right for them, from key-value store to +- cryptocurrency to e-voting platform and beyond. +- +-### Bitcoin, Ethereum, etc +- +-[Tendermint consensus algorithm][tendermint-paper], adopted by CometBFT, +-emerged in the tradition of cryptocurrencies like Bitcoin, +-Ethereum, etc. with the goal of providing a more efficient and secure +-consensus algorithm than Bitcoin's Proof of Work. In the early days, +-Tendermint consensus-based blockchains had a simple currency built in, and to participate in +-consensus, users had to "bond" units of the currency into a security +-deposit which could be revoked if they misbehaved -this is what made +-Tendermint consensus a Proof-of-Stake algorithm. +- +-Since then, CometBFT has evolved to be a general purpose blockchain +-consensus engine that can host arbitrary application states. That means +-it can be used as a plug-and-play replacement for the consensus engines +-of other blockchain software. So one can take the current Ethereum code +-base, whether in Rust, or Go, or Haskell, and run it as an ABCI +-application using CometBFT. Indeed, [we did that with +-Ethereum](https://github.com/cosmos/ethermint). And we plan to do +-the same for Bitcoin, ZCash, and various other deterministic +-applications as well. +- +-Another example of a cryptocurrency application built on CometBFT is +-[the Cosmos network](http://cosmos.network). +- +-### Other Blockchain Projects +- +-[Fabric](https://github.com/hyperledger/fabric) takes a similar approach +-to CometBFT, but is more opinionated about how the state is managed, +-and requires that all application behavior runs in potentially many +-docker containers, modules it calls "chaincode". It uses an +-implementation of [PBFT](http://pmg.csail.mit.edu/papers/osdi99.pdf). +-from a team at IBM that is [augmented to handle potentially +-non-deterministic +-chaincode](https://drops.dagstuhl.de/opus/volltexte/2017/7093/pdf/LIPIcs-OPODIS-2016-24.pdf). +-It is possible to implement this docker-based behavior as an ABCI app in +-CometBFT, though extending CometBFT to handle non-determinism +-remains for future work. +- +-[Burrow](https://github.com/hyperledger/burrow) is an implementation of +-the Ethereum Virtual Machine and Ethereum transaction mechanics, with +-additional features for a name-registry, permissions, and native +-contracts, and an alternative blockchain API. It uses CometBFT as its +-consensus engine, and provides a particular application state. +- +-## ABCI Overview +- +-The [Application BlockChain Interface +-(ABCI)](https://github.com/cometbft/cometbft/tree/v0.34.x/abci) +-allows for Byzantine Fault Tolerant replication of applications +-written in any programming language. +- +-### Motivation +- +-Thus far, all blockchains "stacks" (such as +-[Bitcoin](https://github.com/bitcoin/bitcoin)) have had a monolithic +-design. That is, each blockchain stack is a single program that handles +-all the concerns of a decentralized ledger; this includes P2P +-connectivity, the "mempool" broadcasting of transactions, consensus on +-the most recent block, account balances, Turing-complete contracts, +-user-level permissions, etc. +- +-Using a monolithic architecture is typically bad practice in computer +-science. It makes it difficult to reuse components of the code, and +-attempts to do so result in complex maintenance procedures for forks of +-the codebase. This is especially true when the codebase is not modular +-in design and suffers from "spaghetti code". +- +-Another problem with monolithic design is that it limits you to the +-language of the blockchain stack (or vice versa). In the case of +-Ethereum which supports a Turing-complete bytecode virtual-machine, it +-limits you to languages that compile down to that bytecode; today, those +-are Serpent and Solidity. +- +-In contrast, our approach is to decouple the consensus engine and P2P +-layers from the details of the application state of the particular +-blockchain application. We do this by abstracting away the details of +-the application to an interface, which is implemented as a socket +-protocol. +- +-Thus we have an interface, the Application BlockChain Interface (ABCI), +-and its primary implementation, the Tendermint Socket Protocol (TSP, or +-Teaspoon). +- +-### Intro to ABCI +- +-[CometBFT](https://github.com/cometbft/cometbft), the +-"consensus engine", communicates with the application via a socket +-protocol that satisfies the ABCI, the CometBFT Socket Protocol. +- +-To draw an analogy, let's talk about a well-known cryptocurrency, +-Bitcoin. Bitcoin is a cryptocurrency blockchain where each node +-maintains a fully audited Unspent Transaction Output (UTXO) database. If +-one wanted to create a Bitcoin-like system on top of ABCI, CometBFT +-would be responsible for +- +-- Sharing blocks and transactions between nodes +-- Establishing a canonical/immutable order of transactions +- (the blockchain) +- +-The application will be responsible for +- +-- Maintaining the UTXO database +-- Validating cryptographic signatures of transactions +-- Preventing transactions from spending non-existent transactions +-- Allowing clients to query the UTXO database. +- +-CometBFT is able to decompose the blockchain design by offering a very +-simple API (i.e. the ABCI) between the application process and consensus +-process. +- +-The ABCI consists of 3 primary message types that get delivered from the +-core to the application. The application replies with corresponding +-response messages. +- +-The messages are specified here: [ABCI Message +-Types](https://github.com/cometbft/cometbft/blob/v0.34.x/proto/tendermint/abci/types.proto). +- +-The **DeliverTx** message is the work horse of the application. Each +-transaction in the blockchain is delivered with this message. The +-application needs to validate each transaction received with the +-**DeliverTx** message against the current state, application protocol, +-and the cryptographic credentials of the transaction. A validated +-transaction then needs to update the application state — by binding a +-value into a key values store, or by updating the UTXO database, for +-instance. +- +-The **CheckTx** message is similar to **DeliverTx**, but it's only for +-validating transactions. CometBFT's mempool first checks the +-validity of a transaction with **CheckTx**, and only relays valid +-transactions to its peers. For instance, an application may check an +-incrementing sequence number in the transaction and return an error upon +-**CheckTx** if the sequence number is old. Alternatively, they might use +-a capabilities based system that requires capabilities to be renewed +-with every transaction. +- +-The **Commit** message is used to compute a cryptographic commitment to +-the current application state, to be placed into the next block header. +-This has some handy properties. Inconsistencies in updating that state +-will now appear as blockchain forks which catches a whole class of +-programming errors. This also simplifies the development of secure +-lightweight clients, as Merkle-hash proofs can be verified by checking +-against the block hash, and that the block hash is signed by a quorum. +- +-There can be multiple ABCI socket connections to an application. +-CometBFT creates three ABCI connections to the application; one +-for the validation of transactions when broadcasting in the mempool, one +-for the consensus engine to run block proposals, and one more for +-querying the application state. +- +-It's probably evident that applications designers need to very carefully +-design their message handlers to create a blockchain that does anything +-useful but this architecture provides a place to start. The diagram +-below illustrates the flow of messages via ABCI. +- +-![abci](../imgs/abci.png) +- +-## A Note on Determinism +- +-The logic for blockchain transaction processing must be deterministic. +-If the application logic weren't deterministic, consensus would not be +-reached among the CometBFT replica nodes. +- +-Solidity on Ethereum is a great language of choice for blockchain +-applications because, among other reasons, it is a completely +-deterministic programming language. However, it's also possible to +-create deterministic applications using existing popular languages like +-Java, C++, Python, or Go. Game programmers and blockchain developers are +-already familiar with creating deterministic programs by avoiding +-sources of non-determinism such as: +- +-- random number generators (without deterministic seeding) +-- race conditions on threads (or avoiding threads altogether) +-- the system clock +-- uninitialized memory (in unsafe programming languages like C +- or C++) +-- [floating point +- arithmetic](http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/) +-- language features that are random (e.g. map iteration in Go) +- +-While programmers can avoid non-determinism by being careful, it is also +-possible to create a special linter or static analyzer for each language +-to check for determinism. In the future we may work with partners to +-create such tools. +- +-## Consensus Overview +- +-CometBFT adopts [Tendermint consensus][tendermint-paper], +-an easy-to-understand, mostly asynchronous, BFT consensus algorithm. +-The algorithm follows a simple state machine that looks like this: +- +-![consensus-logic](../imgs/consensus_logic.png) +- +-Participants in the algorithm are called **validators**; they take turns +-proposing blocks of transactions and voting on them. Blocks are +-committed in a chain, with one block at each **height**. A block may +-fail to be committed, in which case the algorithm moves to the next +-**round**, and a new validator gets to propose a block for that height. +-Two stages of voting are required to successfully commit a block; we +-call them **pre-vote** and **pre-commit**. A block is committed when +-more than 2/3 of validators pre-commit for the same block in the same +-round. +- +-There is a picture of a couple doing the polka because validators are +-doing something like a polka dance. When more than two-thirds of the +-validators pre-vote for the same block, we call that a **polka**. Every +-pre-commit must be justified by a polka in the same round. +- +-Validators may fail to commit a block for a number of reasons; the +-current proposer may be offline, or the network may be slow. Tendermint consensus +-allows them to establish that a validator should be skipped. Validators +-wait a small amount of time to receive a complete proposal block from +-the proposer before voting to move to the next round. This reliance on a +-timeout is what makes Tendermint consensus a weakly synchronous algorithm, rather +-than an asynchronous one. However, the rest of the algorithm is +-asynchronous, and validators only make progress after hearing from more +-than two-thirds of the validator set. A simplifying element of +-Tendermint consensus is that it uses the same mechanism to commit a block as it +-does to skip to the next round. +- +-Assuming less than one-third of the validators are Byzantine, Tendermint consensus algorithm +-guarantees that safety will never be violated - that is, validators will +-never commit conflicting blocks at the same height. To do this it +-introduces a few **locking** rules which modulate which paths can be +-followed in the flow diagram. Once a validator precommits a block, it is +-locked on that block. Then, +- +-1. it must prevote for the block it is locked on +-2. it can only unlock, and precommit for a new block, if there is a +- polka for that block in a later round +- +-## Stake +- +-In many systems, not all validators will have the same "weight" in the +-consensus protocol. Thus, we are not so much interested in one-third or +-two-thirds of the validators, but in those proportions of the total +-voting power, which may not be uniformly distributed across individual +-validators. +- +-Since CometBFT can replicate arbitrary applications, it is possible to +-define a currency, and denominate the voting power in that currency. +-When voting power is denominated in a native currency, the system is +-often referred to as Proof-of-Stake. Validators can be forced, by logic +-in the application, to "bond" their currency holdings in a security +-deposit that can be destroyed if they're found to misbehave in the +-consensus protocol. This adds an economic element to the security of the +-protocol, allowing one to quantify the cost of violating the assumption +-that less than one-third of voting power is Byzantine. +- +-The [Cosmos Network](https://cosmos.network) is designed to use this +-Proof-of-Stake mechanism across an array of cryptocurrencies implemented +-as ABCI applications. +- +-[tendermint-paper]: https://arxiv.org/abs/1807.04938 diff --git a/patches/docs/networks/README.md.patch b/patches/docs/networks/README.md.patch new file mode 100644 index 00000000000..248c8cb45af --- /dev/null +++ b/patches/docs/networks/README.md.patch @@ -0,0 +1,19 @@ +diff --git a/docs/networks/README.md b/docs/networks/README.md +deleted file mode 100644 +index ceea23598..000000000 +--- a/docs/networks/README.md ++++ /dev/null +@@ -1,13 +0,0 @@ +---- +-order: 1 +-parent: +- title: Networks +- order: 5 +---- +- +-# Overview +- +-Use [Docker Compose](./docker-compose.md) to spin up CometBFT testnets on your +-local machine. +- +-See the `cometbft testnet --help` command for more help initializing testnets. diff --git a/patches/docs/networks/docker-compose.md.patch b/patches/docs/networks/docker-compose.md.patch new file mode 100644 index 00000000000..53c3f2847ec --- /dev/null +++ b/patches/docs/networks/docker-compose.md.patch @@ -0,0 +1,185 @@ +diff --git a/docs/networks/docker-compose.md b/docs/networks/docker-compose.md +deleted file mode 100644 +index e8991beed..000000000 +--- a/docs/networks/docker-compose.md ++++ /dev/null +@@ -1,179 +0,0 @@ +---- +-order: 2 +---- +- +-# Docker Compose +- +-With Docker Compose, you can spin up local testnets with a single command. +- +-## Requirements +- +-1. [Install CometBFT](../introduction/install.md) +-2. [Install docker](https://docs.docker.com/engine/installation/) +-3. [Install docker-compose](https://docs.docker.com/compose/install/) +- +-## Build +- +-Build the `cometbft` binary and, optionally, the `cometbft/localnode` +-docker image. +- +-Note the binary will be mounted into the container so it can be updated without +-rebuilding the image. +- +-```sh +-# Build the linux binary in ./build +-make build-linux +- +-# (optionally) Build cometbft/localnode image +-make build-docker-localnode +-``` +- +-## Run a testnet +- +-To start a 4 node testnet run: +- +-```sh +-make localnet-start +-``` +- +-The nodes bind their RPC servers to ports 26657, 26660, 26662, and 26664 on the +-host. +- +-This file creates a 4-node network using the localnode image. +- +-The nodes of the network expose their P2P and RPC endpoints to the host machine +-on ports 26656-26657, 26659-26660, 26661-26662, and 26663-26664 respectively. +- +-To update the binary, just rebuild it and restart the nodes: +- +-```sh +-make build-linux +-make localnet-start +-``` +- +-## Configuration +- +-The `make localnet-start` creates files for a 4-node testnet in `./build` by +-calling the `cometbft testnet` command. +- +-The `./build` directory is mounted to the `/cometbft` mount point to attach +-the binary and config files to the container. +- +-To change the number of validators / non-validators change the `localnet-start` Makefile target [here](../../Makefile): +- +-```makefile +-localnet-start: localnet-stop +- @if ! [ -f build/node0/config/genesis.json ]; then docker run --rm -v $(CURDIR)/build:/cometbft:Z cometbft/localnode testnet --v 5 --n 3 --o . --populate-persistent-peers --starting-ip-address 192.167.10.2 ; fi +- docker-compose up +-``` +- +-The command now will generate config files for 5 validators and 3 +-non-validators. Along with generating new config files the docker-compose file needs to be edited. +-Adding 4 more nodes is required in order to fully utilize the config files that were generated. +- +-```yml +- node3: # bump by 1 for every node +- container_name: node3 # bump by 1 for every node +- image: "cometbft/localnode" +- environment: +- - ID=3 +- - LOG=${LOG:-cometbft.log} +- ports: +- - "26663-26664:26656-26657" # Bump 26663-26664 by one for every node +- volumes: +- - ./build:/cometbft:Z +- networks: +- localnet: +- ipv4_address: 192.167.10.5 # bump the final digit by 1 for every node +-``` +- +-Before running it, don't forget to cleanup the old files: +- +-```sh +-# Clear the build folder +-rm -rf ./build/node* +-``` +- +-## Configuring ABCI containers +- +-To use your own ABCI applications with 4-node setup edit the [docker-compose.yaml](https://github.com/cometbft/cometbft/blob/v0.34.x/docker-compose.yml) file and add images to your ABCI application. +- +-```yml +- abci0: +- container_name: abci0 +- image: "abci-image" +- build: +- context: . +- dockerfile: abci.Dockerfile +- command: +- networks: +- localnet: +- ipv4_address: 192.167.10.6 +- +- abci1: +- container_name: abci1 +- image: "abci-image" +- build: +- context: . +- dockerfile: abci.Dockerfile +- command: +- networks: +- localnet: +- ipv4_address: 192.167.10.7 +- +- abci2: +- container_name: abci2 +- image: "abci-image" +- build: +- context: . +- dockerfile: abci.Dockerfile +- command: +- networks: +- localnet: +- ipv4_address: 192.167.10.8 +- +- abci3: +- container_name: abci3 +- image: "abci-image" +- build: +- context: . +- dockerfile: abci.Dockerfile +- command: +- networks: +- localnet: +- ipv4_address: 192.167.10.9 +- +-``` +- +-Override the [command](https://github.com/cometbft/cometbft/blob/v0.34.x/networks/local/localnode/Dockerfile#L11) in each node to connect to it's ABCI. +- +-```yml +- node0: +- container_name: node0 +- image: "cometbft/localnode" +- ports: +- - "26656-26657:26656-26657" +- environment: +- - ID=0 +- - LOG=$${LOG:-cometbft.log} +- volumes: +- - ./build:/cometbft:Z +- command: node --proxy_app=tcp://abci0:26658 +- networks: +- localnet: +- ipv4_address: 192.167.10.2 +-``` +- +-Similarly do for node1, node2 and node3 then [run testnet](#run-a-testnet). +- +-## Logging +- +-Log is saved under the attached volume, in the `cometbft.log` file. If the +-`LOG` environment variable is set to `stdout` at start, the log is not saved, +-but printed on the screen. +- +-## Special binaries +- +-If you have multiple binaries with different names, you can specify which one +-to run with the `BINARY` environment variable. The path of the binary is relative +-to the attached volume. diff --git a/patches/docs/qa/CometBFT-QA-34.md.patch b/patches/docs/qa/CometBFT-QA-34.md.patch new file mode 100644 index 00000000000..f95e48f0833 --- /dev/null +++ b/patches/docs/qa/CometBFT-QA-34.md.patch @@ -0,0 +1,376 @@ +diff --git a/docs/qa/CometBFT-QA-34.md b/docs/qa/CometBFT-QA-34.md +deleted file mode 100644 +index d63342640..000000000 +--- a/docs/qa/CometBFT-QA-34.md ++++ /dev/null +@@ -1,370 +0,0 @@ +---- +-order: 1 +-parent: +- title: CometBFT QA Results v0.34.x +- description: This is a report on the results obtained when running v0.34.x on testnets +- order: 3 +---- +- +-# CometBFT QA Results v0.34.x +- +-## v0.34.x - From Tendermint Core to CometBFT +- +-This section reports on the QA process we followed before releasing the first `v0.34.x` version +-from our CometBFT repository. +- +-The changes with respect to the last version of `v0.34.x` +-(namely `v0.34.26`, released from the Informal Systems' Tendermint Core fork) +-are minimal, and focus on rebranding our fork of Tendermint Core to CometBFT at places +-where there is no substantial risk of breaking compatibility +-with earlier Tendermint Core versions of `v0.34.x`. +- +-Indeed, CometBFT versions of `v0.34.x` (`v0.34.27` and subsequent) should fulfill +-the following compatibility-related requirements. +- +-* Operators can easily upgrade a `v0.34.x` version of Tendermint Core to CometBFT. +-* Upgrades from Tendermint Core to CometBFT can be uncoordinated for versions of the `v0.34.x` branch. +-* Nodes running CometBFT must be interoperable with those running Tendermint Core in the same chain, +- as long as all are running a `v0.34.x` version. +- +-These QA tests focus on the third bullet, whereas the first two bullets are tested using our _e2e tests_. +- +-It would be prohibitively time consuming to test mixed networks of all combinations of existing `v0.34.x` +-versions, combined with the CometBFT release candidate under test. +-Therefore our testing focuses on the last Tendermint Core version (`v0.34.26`) and the CometBFT release +-candidate under test. +- +-We run the _200 node test_, but not the _rotating node test_. The effort of running the latter +-is not justified given the amount and nature of the changes we are testing with respect to the +-full QA cycle run previously on `v0.34.x`. +-Since the changes to the system's logic are minimal, we are interested in these performance requirements: +- +-* The CometBFT release candidate under test performs similarly to Tendermint Core (i.e., the baseline) +- * when used at scale (i.e., in a large network of CometBFT nodes) +- * when used at scale in a mixed network (i.e., some nodes are running CometBFT +- and others are running an older Tendermint Core version) +- +-Therefore we carry out a complete run of the _200-node test_ on the following networks: +- +-* A homogeneous 200-node testnet, where all nodes are running the CometBFT release candidate under test. +-* A mixed network where 1/2 (99 out of 200) of the nodes are running the CometBFT release candidate under test, +- and the rest (101 out of 200) are running Tendermint Core `v0.34.26`. +-* A mixed network where 1/3 (66 out of 200) of the nodes are running the CometBFT release candidate under test, +- and the rest (134 out of 200) are running Tendermint Core `v0.34.26`. +-* A mixed network where 2/3 (133 out of 200) of the nodes are running the CometBFT release candidate under test, +- and the rest (67 out of 200) are running Tendermint Core `v0.34.26`. +- +-## Configuration and Results +-In the following sections we provide the results of the _200 node test_. +-Each section reports the baseline results (for reference), the homogeneous network scenario (all CometBFT nodes), +-and the mixed networks with 1/2, 1/3 and 2/3 of Tendermint Core nodes. +- +-### Saturation Point +- +-As the CometBFT release candidate under test has minimal changes +-with respect to Tendermint Core `v0.34.26`, other than the rebranding changes, +-we can confidently reuse the results from the `v0.34.x` baseline test regarding +-the [saturation point](TMCore-QA-34.md#finding-the-saturation-point). +- +-Therefore, we will simply use a load of (`r=200,c=2`) +-(see the explanation [here](TMCore-QA-34.md#finding-the-saturation-point)) on all experiments. +- +-We also include the baseline results for quick reference and comparison. +- +-### Experiments +- +-On each of the three networks, the test consists of 4 experiments, with the goal of +-ensuring the data obtained is consistent across experiments. +- +-On each of the networks, we pick only one representative run to present and discuss the +-results. +- +- +-## Examining latencies +-For each network the figures plot the four experiments carried out with the network. +-We can see that the latencies follow comparable patterns across all experiments. +- +-Unique identifiers, UUID, for each execution are presented on top of each graph. +-We refer to these UUID to indicate to the representative runs. +- +-### CometBFT Homogeneous network +- +-![latencies](img34/homogeneous/all_experiments.png) +- +-### 1/2 Tendermint Core - 1/2 CometBFT +- +-![latencies](img34/cmt1tm1/all_experiments.png) +- +-### 1/3 Tendermint Core - 2/3 CometBFT +- +-![latencies](img34/cmt2tm1/all_experiments.png) +- +-### 2/3 Tendermint Core - 1/3 CometBFT +- +-![latencies_all_tm2_3_cmt1_3](img34/v034_200node_tm2cmt1/all_experiments.png) +- +- +-## Prometheus Metrics +- +-This section reports on the key Prometheus metrics extracted from the following experiments. +- +-* Baseline results: `v0.34.x`, obtained in October 2022 and reported [here](TMCore-QA-34.md). +-* CometBFT homogeneous network: experiment with UUID starting with `be8c`. +-* Mixed network, 1/2 Tendermint Core `v0.34.26` and 1/2 running CometBFT: experiment with UUID starting with `04ee`. +-* Mixed network, 1/3 Tendermint Core `v0.34.26` and 2/3 running CometBFT: experiment with UUID starting with `fc5e`. +-* Mixed network, 2/3 Tendermint Core `v0.34.26` and 1/3 running CometBFT: experiment with UUID starting with `4759`. +- +-We make explicit comparisons between the baseline and the homogenous setups, but refrain from +-commenting on the mixed network experiment unless they show some exceptional results. +- +-### Mempool Size +- +-For each reported experiment we show two graphs. +-The first shows the evolution over time of the cumulative number of transactions +-inside all full nodes' mempools at a given time. +- +-The second one shows the evolution of the average over all full nodes. +- +-#### Baseline +- +-![mempool-cumulative](img34/baseline/mempool_size.png) +- +-![mempool-avg](img34/baseline/avg_mempool_size.png) +- +-#### CometBFT Homogeneous network +- +-The results for the homogeneous network and the baseline are similar in terms of outstanding transactions. +- +-![mempool-cumulative-homogeneous](img34/homogeneous/mempool_size.png) +- +-![mempool-avg-homogeneous](img34/homogeneous/avg_mempool_size.png) +- +-#### 1/2 Tendermint Core - 1/2 CometBFT +- +-![mempool size](img34/cmt1tm1/mempool_size.png) +- +-![average mempool size](img34/cmt1tm1/avg_mempool_size.png) +- +-#### 1/3 Tendermint Core - 2/3 CometBFT +- +-![mempool size](img34/cmt2tm1/mempool_size.png) +- +-![average mempool size](img34/cmt2tm1/avg_mempool_size.png) +- +-#### 2/3 Tendermint Core - 1/3 CometBFT +- +-![mempool_tm2_3_cmt_1_3](img34/v034_200node_tm2cmt1/mempool_size.png) +- +-![mempool-avg_tm2_3_cmt_1_3](img34/v034_200node_tm2cmt1/avg_mempool_size.png) +- +-### Consensus Rounds per Height +- +-The following graphs show the rounds needed to complete each height and agree on a block. +- +-A value of `0` shows that only one round was required (with id `0`), and a value of `1` shows that two rounds were required. +- +-#### Baseline +-We can see that round 1 is reached with a certain frequency. +- +-![rounds](img34/baseline/rounds.png) +- +-#### CometBFT Homogeneous network +- +-Most heights finished in round 0, some nodes needed to advance to round 1 at various moments, +-and a few nodes even needed to advance to round 2 at one point. +-This coincides with the time at which we observed the biggest peak in mempool size +-on the corresponding plot, shown above. +- +-![rounds-homogeneous](img34/homogeneous/rounds.png) +- +-#### 1/2 Tendermint Core - 1/2 CometBFT +- +-![peers](img34/cmt1tm1/rounds.png) +- +-#### 1/3 Tendermint Core - 2/3 CometBFT +- +-![peers](img34/cmt2tm1/rounds.png) +- +-#### 2/3 Tendermint Core - 1/3 CometBFT +- +-![rounds-tm2_3_cmt1_3](img34/v034_200node_tm2cmt1/rounds.png) +- +-### Peers +- +-The following plots show how many peers a node had throughtout the experiment. +- +-The thick red dashed line represents the moving average over a sliding window of 20 seconds. +- +-#### Baseline +- +-The following graph shows the that the number of peers was stable throughout the experiment. +-Seed nodes typically have a higher number of peers. +-The fact that non-seed nodes reach more than 50 peers is due to +-[#9548](https://github.com/tendermint/tendermint/issues/9548). +- +-![peers](img34/baseline/peers.png) +- +-#### CometBFT Homogeneous network +- +-The results for the homogeneous network are very similar to the baseline. +-The only difference being that the seed nodes seem to loose peers in the middle of the experiment. +-However this cannot be attributed to the differences in the code, which are mainly rebranding. +- +-![peers-homogeneous](img34/homogeneous/peers.png) +- +-#### 1/2 Tendermint Core - 1/2 CometBFT +- +-![peers](img34/cmt1tm1/peers.png) +- +-#### 1/3 Tendermint Core - 2/3 CometBFT +- +-![peers](img34/cmt2tm1/peers.png) +- +-#### 2/3 Tendermint Core - 1/3 CometBFT +- +-As in the homogeneous case, there is some variation in the number of peers for some nodes. +-These, however, do not affect the average. +- +-![peers-tm2_3_cmt1_3](img34/v034_200node_tm2cmt1/peers.png) +- +-### Blocks Produced per Minute, Transactions Processed per Minute +- +-The following plot show the rate of block production and the rate of transactions delivered, throughout the experiments. +- +-In both graphs, rates are calculated over a sliding window of 20 seconds. +-The thick red dashed line show the rates' moving averages. +- +-#### Baseline +- +-The average number of blocks/minute oscilate between 10 and 40. +- +-![heights](img34/baseline/block_rate_regular.png) +- +-The number of transactions/minute tops around 30k. +- +-![total-txs](img34/baseline/total_txs_rate_regular.png) +- +- +-#### CometBFT Homogeneous network +- +-The plot showing the block production rate shows that the rate oscillates around 20 blocks/minute, +-mostly within the same range as the baseline. +- +-![heights-homogeneous-rate](img34/homogeneous/block_rate_regular.png) +- +-The plot showing the transaction rate shows the rate stays around 20000 transactions per minute, +-also topping around 30k. +- +-![txs-homogeneous-rate](img34/homogeneous/total_txs_rate_regular.png) +- +-#### 1/2 Tendermint Core - 1/2 CometBFT +- +-![height rate](img34/cmt1tm1/block_rate_regular.png) +- +-![transaction rate](img34/cmt1tm1/total_txs_rate_regular.png) +- +-#### 1/3 Tendermint Core - 2/3 CometBFT +- +-![height rate](img34/cmt2tm1/block_rate_regular.png) +- +-![transaction rate](img34/cmt2tm1/total_txs_rate_regular.png) +- +-#### 2/3 Tendermint Core - 1/3 CometBFT +- +-![height rate](img34/v034_200node_tm2cmt1/block_rate_regular.png) +- +-![transaction rate](img34/v034_200node_tm2cmt1/total_txs_rate_regular.png) +- +-### Memory Resident Set Size +- +-The following graphs show the Resident Set Size (RSS) of all monitored processes and the average value. +- +-#### Baseline +- +-![rss](img34/baseline/memory.png) +- +-![rss-avg](img34/baseline/avg_memory.png) +- +-#### CometBFT Homogeneous network +- +-This is the plot for the homogeneous network, which is slightly more stable than the baseline over +-the time of the experiment. +- +-![rss-homogeneous](img34/homogeneous/memory.png) +- +-And this is the average plot. It oscillates around 560 MiB, which is noticeably lower than the baseline. +- +-![rss-avg-homogeneous](img34/homogeneous/avg_memory.png) +- +-#### 1/2 Tendermint Core - 1/2 CometBFT +- +-![rss](img34/cmt1tm1/memory.png) +- +-![rss average](img34/cmt1tm1/avg_memory.png) +- +-#### 1/3 Tendermint Core - 2/3 CometBFT +- +-![rss](img34/cmt2tm1/memory.png) +- +-![rss average](img34/cmt2tm1/avg_memory.png) +- +-#### 2/3 Tendermint Core - 1/3 CometBFT +- +-![rss](img34/v034_200node_tm2cmt1/memory.png) +- +-![rss average](img34/v034_200node_tm2cmt1/avg_memory.png) +- +-### CPU utilization +- +-The following graphs show the `load1` of nodes, as typically shown in the first line of the Unix `top` +-command, and their average value. +- +-#### Baseline +- +-![load1](img34/baseline/cpu.png) +- +-![load1-avg](img34/baseline/avg_cpu.png) +- +-#### CometBFT Homogeneous network +- +-The load in the homogenous network is, similarly to the baseline case, below 5 and, therefore, normal. +- +-![load1-homogeneous](img34/homogeneous/cpu.png) +- +-As expected, the average plot also looks similar. +- +-![load1-homogeneous-avg](img34/homogeneous/avg_cpu.png) +- +-#### 1/2 Tendermint Core - 1/2 CometBFT +- +-![load1](img34/cmt1tm1/cpu.png) +- +-![average load1](img34/cmt1tm1/avg_cpu.png) +- +-#### 1/3 Tendermint Core - 2/3 CometBFT +- +-![load1](img34/cmt2tm1/cpu.png) +- +-![average load1](img34/cmt2tm1/avg_cpu.png) +- +-#### 2/3 Tendermint Core - 1/3 CometBFT +- +-![load1](img34/v034_200node_tm2cmt1/cpu.png) +- +-![average load1](img34/v034_200node_tm2cmt1/avg_cpu.png) +- +-## Test Results +- +-The comparison of the baseline results and the homogeneous case show that both scenarios had similar numbers and are therefore equivalent. +- +-The mixed nodes cases show that networks operate normally with a mix of compatible Tendermint Core and CometBFT versions. +-Although not the main goal, a comparison of metric numbers with the homogenous case and the baseline scenarios show similar results and therefore we can conclude that mixing compatible Tendermint Core and CometBFT introduces not performance degradation. +- +-A conclusion of these tests is shown in the following table, along with the commit versions used in the experiments. +- +-| Scenario | Date | Version | Result | +-|--|--|--|--| +-|CometBFT Homogeneous network | 2023-02-08 | 3b783434f26b0e87994e6a77c5411927aad9ce3f | Pass +-|1/2 Tendermint Core
1/2 CometBFT | 2023-02-14 | CometBFT: 3b783434f26b0e87994e6a77c5411927aad9ce3f
Tendermint Core: 66c2cb63416e66bff08e11f9088e21a0ed142790 | Pass| +-|1/3 Tendermint Core
2/3 CometBFT | 2023-02-08 | CometBFT: 3b783434f26b0e87994e6a77c5411927aad9ce3f
Tendermint Core: 66c2cb63416e66bff08e11f9088e21a0ed142790 | Pass| +-|2/3 Tendermint Core
1/3 CometBFT | 2023-02-08 | CometBFT: 3b783434f26b0e87994e6a77c5411927aad9ce3f
Tendermint Core: 66c2cb63416e66bff08e11f9088e21a0ed142790 | Pass | diff --git a/patches/docs/qa/README.md.patch b/patches/docs/qa/README.md.patch new file mode 100644 index 00000000000..9a093614690 --- /dev/null +++ b/patches/docs/qa/README.md.patch @@ -0,0 +1,29 @@ +diff --git a/docs/qa/README.md b/docs/qa/README.md +deleted file mode 100644 +index e4068920d..000000000 +--- a/docs/qa/README.md ++++ /dev/null +@@ -1,23 +0,0 @@ +---- +-order: 1 +-parent: +- title: CometBFT Quality Assurance +- description: This is a report on the process followed and results obtained when running v0.34.x on testnets +- order: 2 +---- +- +-# CometBFT Quality Assurance +- +-This directory keeps track of the process followed by the CometBFT team +-for Quality Assurance before cutting a release. +-This directory is to live in multiple branches. On each release branch, +-the contents of this directory reflect the status of the process +-at the time the Quality Assurance process was applied for that release. +- +-File [method](./method.md) keeps track of the process followed to obtain the results +-used to decide if a release is passing the Quality Assurance process. +-The results obtained in each release are stored in their own directory. +-The following releases have undergone the Quality Assurance process, and the corresponding reports include detailed information on tests and comparison with the baseline. +- +-* [TM v0.34.x](TMCore-QA-34.md) - Tested prior to releasing Tendermint Core v0.34.22. +-* [v0.34.x](CometBFT-QA-34.md) - Tested prior to releasing v0.34.27, using TM v0.34.x results as baseline. diff --git a/patches/docs/qa/TMCore-QA-34.md.patch b/patches/docs/qa/TMCore-QA-34.md.patch new file mode 100644 index 00000000000..5186e262df2 --- /dev/null +++ b/patches/docs/qa/TMCore-QA-34.md.patch @@ -0,0 +1,283 @@ +diff --git a/docs/qa/TMCore-QA-34.md b/docs/qa/TMCore-QA-34.md +deleted file mode 100644 +index e5764611c..000000000 +--- a/docs/qa/TMCore-QA-34.md ++++ /dev/null +@@ -1,277 +0,0 @@ +---- +-order: 1 +-parent: +- title: Tendermint Core QA Results v0.34.x +- description: This is a report on the results obtained when running v0.34.x on testnets +- order: 2 +---- +- +-# Tendermint Core QA Results v0.34.x +- +-## 200 Node Testnet +- +-### Finding the Saturation Point +- +-The first goal when examining the results of the tests is identifying the saturation point. +-The saturation point is a setup with a transaction load big enough to prevent the testnet +-from being stable: the load runner tries to produce slightly more transactions than can +-be processed by the testnet. +- +-The following table summarizes the results for v0.34.x, for the different experiments +-(extracted from file [`v034_report_tabbed.txt`](img34/v034_report_tabbed.txt)). +- +-The X axis of this table is `c`, the number of connections created by the load runner process to the target node. +-The Y axis of this table is `r`, the rate or number of transactions issued per second. +- +-| | c=1 | c=2 | c=4 | +-| :--- | ----: | ----: | ----: | +-| r=25 | 2225 | 4450 | 8900 | +-| r=50 | 4450 | 8900 | 17800 | +-| r=100 | 8900 | 17800 | 35600 | +-| r=200 | 17800 | 35600 | 38660 | +- +-The table shows the number of 1024-byte-long transactions that were produced by the load runner, +-and processed by Tendermint Core, during the 90 seconds of the experiment's duration. +-Each cell in the table refers to an experiment with a particular number of websocket connections (`c`) +-to a chosen validator, and the number of transactions per second that the load runner +-tries to produce (`r`). Note that the overall load that the tool attempts to generate is $c \cdot r$. +- +-We can see that the saturation point is beyond the diagonal that spans cells +- +-* `r=200,c=2` +-* `r=100,c=4` +- +-given that the total number of transactions should be close to the product rate X the number of connections x experiment time. +- +-All experiments below the saturation diagonal (`r=200,c=4`) have in common that the total +-number of transactions processed is noticeably less than the product $c \cdot r \cdot 89$ (89 seconds, since the last batch never gets sent), +-which is the expected number of transactions when the system is able to deal well with the +-load. +-With (`r=200,c=4`), we obtained 38660 whereas the theoretical number of transactions should +-have been $200 \cdot 4 \cdot 89 = 71200$. +- +-At this point, we chose an experiment at the limit of the saturation diagonal, +-in order to further study the performance of this release. +-**The chosen experiment is (`r=200,c=2`)**. +- +-This is a plot of the CPU load (average over 1 minute, as output by `top`) of the load runner for (`r=200,c=2`), +-where we can see that the load stays close to 0 most of the time. +- +-![load-load-runner](img34/v034_r200c2_load-runner.png) +- +-### Examining latencies +- +-The method described [here](method.md) allows us to plot the latencies of transactions +-for all experiments. +- +-![all-latencies](img34/v034_200node_latencies.png) +- +-As we can see, even the experiments beyond the saturation diagonal managed to keep +-transaction latency stable (i.e. not constantly increasing). +-Our interpretation for this is that contention within Tendermint Core was propagated, +-via the websockets, to the load runner, +-hence the load runner could not produce the target load, but a fraction of it. +- +-Further examination of the Prometheus data (see below), showed that the mempool contained many transactions +-at steady state, but did not grow much without quickly returning to this steady state. This demonstrates +-that Tendermint Core network was able to process transactions at least as quickly as they +-were submitted to the mempool. Finally, the test script made sure that, at the end of an experiment, the +-mempool was empty so that all transactions submitted to the chain were processed. +- +-Finally, the number of points present in the plot appears to be much less than expected given the +-number of transactions in each experiment, particularly close to or above the saturation diagonal. +-This is a visual effect of the plot; what appear to be points in the plot are actually potentially huge +-clusters of points. To corroborate this, we have zoomed in the plot above by setting (carefully chosen) +-tiny axis intervals. The cluster shown below looks like a single point in the plot above. +- +-![all-latencies-zoomed](img34/v034_200node_latencies_zoomed.png) +- +-The plot of latencies can we used as a baseline to compare with other releases. +- +-The following plot summarizes average latencies versus overall throughput +-across different numbers of WebSocket connections to the node into which +-transactions are being loaded. +- +-![latency-vs-throughput](img34/v034_latency_throughput.png) +- +-### Prometheus Metrics on the Chosen Experiment +- +-As mentioned [above](#finding-the-saturation-point), the chosen experiment is `r=200,c=2`. +-This section further examines key metrics for this experiment extracted from Prometheus data. +- +-#### Mempool Size +- +-The mempool size, a count of the number of transactions in the mempool, was shown to be stable and homogeneous +-at all full nodes. It did not exhibit any unconstrained growth. +-The plot below shows the evolution over time of the cumulative number of transactions inside all full nodes' mempools +-at a given time. +-The two spikes that can be observed correspond to a period where consensus instances proceeded beyond the initial round +-at some nodes. +- +-![mempool-cumulative](img34/v034_r200c2_mempool_size.png) +- +-The plot below shows evolution of the average over all full nodes, which oscillates between 1500 and 2000 +-outstanding transactions. +- +-![mempool-avg](img34/v034_r200c2_mempool_size_avg.png) +- +-The peaks observed coincide with the moments when some nodes proceeded beyond the initial round of consensus (see below). +- +-#### Peers +- +-The number of peers was stable at all nodes. +-It was higher for the seed nodes (around 140) than for the rest (between 21 and 74). +-The fact that non-seed nodes reach more than 50 peers is due to #9548. +- +-![peers](img34/v034_r200c2_peers.png) +- +-#### Consensus Rounds per Height +- +-Most nodes used only round 0 for most heights, but some nodes needed to advance to round 1 for some heights. +- +-![rounds](img34/v034_r200c2_rounds.png) +- +-#### Blocks Produced per Minute, Transactions Processed per Minute +- +-The blocks produced per minute are the slope of this plot. +- +-![heights](img34/v034_r200c2_heights.png) +- +-Over a period of 2 minutes, the height goes from 530 to 569. +-This results in an average of 19.5 blocks produced per minute. +- +-The transactions processed per minute are the slope of this plot. +- +-![total-txs](img34/v034_r200c2_total-txs.png) +- +-Over a period of 2 minutes, the total goes from 64525 to 100125 transactions, +-resulting in 17800 transactions per minute. However, we can see in the plot that +-all transactions in the load are processed long before the two minutes. +-If we adjust the time window when transactions are processed (approx. 105 seconds), +-we obtain 20343 transactions per minute. +- +-#### Memory Resident Set Size +- +-Resident Set Size of all monitored processes is plotted below. +- +-![rss](img34/v034_r200c2_rss.png) +- +-The average over all processes oscillates around 1.2 GiB and does not demonstrate unconstrained growth. +- +-![rss-avg](img34/v034_r200c2_rss_avg.png) +- +-#### CPU utilization +- +-The best metric from Prometheus to gauge CPU utilization in a Unix machine is `load1`, +-as it usually appears in the +-[output of `top`](https://www.digitalocean.com/community/tutorials/load-average-in-linux). +- +-![load1](img34/v034_r200c2_load1.png) +- +-It is contained in most cases below 5, which is generally considered acceptable load. +- +-### Test Result +- +-**Result: N/A** (v0.34.x is the baseline) +- +-Date: 2022-10-14 +- +-Version: 3ec6e424d6ae4c96867c2dcf8310572156068bb6 +- +-## Rotating Node Testnet +- +-For this testnet, we will use a load that can safely be considered below the saturation +-point for the size of this testnet (between 13 and 38 full nodes): `c=4,r=800`. +- +-N.B.: The version of CometBFT used for these tests is affected by #9539. +-However, the reduced load that reaches the mempools is orthogonal to functionality +-we are focusing on here. +- +-### Latencies +- +-The plot of all latencies can be seen in the following plot. +- +-![rotating-all-latencies](img34/v034_rotating_latencies.png) +- +-We can observe there are some very high latencies, towards the end of the test. +-Upon suspicion that they are duplicate transactions, we examined the latencies +-raw file and discovered there are more than 100K duplicate transactions. +- +-The following plot shows the latencies file where all duplicate transactions have +-been removed, i.e., only the first occurrence of a duplicate transaction is kept. +- +-![rotating-all-latencies-uniq](img34/v034_rotating_latencies_uniq.png) +- +-This problem, existing in `v0.34.x`, will need to be addressed, perhaps in the same way +-we addressed it when running the 200 node test with high loads: increasing the `cache_size` +-configuration parameter. +- +-### Prometheus Metrics +- +-The set of metrics shown here are less than for the 200 node experiment. +-We are only interested in those for which the catch-up process (blocksync) may have an impact. +- +-#### Blocks and Transactions per minute +- +-Just as shown for the 200 node test, the blocks produced per minute are the gradient of this plot. +- +-![rotating-heights](img34/v034_rotating_heights.png) +- +-Over a period of 5229 seconds, the height goes from 2 to 3638. +-This results in an average of 41 blocks produced per minute. +- +-The following plot shows only the heights reported by ephemeral nodes +-(which are also included in the plot above). Note that the _height_ metric +-is only showed _once the node has switched to consensus_, hence the gaps +-when nodes are killed, wiped out, started from scratch, and catching up. +- +-![rotating-heights-ephe](img34/v034_rotating_heights_ephe.png) +- +-The transactions processed per minute are the gradient of this plot. +- +-![rotating-total-txs](img34/v034_rotating_total-txs.png) +- +-The small lines we see periodically close to `y=0` are the transactions that +-ephemeral nodes start processing when they are caught up. +- +-Over a period of 5229 minutes, the total goes from 0 to 387697 transactions, +-resulting in 4449 transactions per minute. We can see some abrupt changes in +-the plot's gradient. This will need to be investigated. +- +-#### Peers +- +-The plot below shows the evolution in peers throughout the experiment. +-The periodic changes observed are due to the ephemeral nodes being stopped, +-wiped out, and recreated. +- +-![rotating-peers](img34/v034_rotating_peers.png) +- +-The validators' plots are concentrated at the higher part of the graph, whereas the ephemeral nodes +-are mostly at the lower part. +- +-#### Memory Resident Set Size +- +-The average Resident Set Size (RSS) over all processes seems stable, and slightly growing toward the end. +-This might be related to the increased in transaction load observed above. +- +-![rotating-rss-avg](img34/v034_rotating_rss_avg.png) +- +-The memory taken by the validators and the ephemeral nodes (when they are up) is comparable. +- +-#### CPU utilization +- +-The plot shows metric `load1` for all nodes. +- +-![rotating-load1](img34/v034_rotating_load1.png) +- +-It is contained under 5 most of the time, which is considered normal load. +-The purple line, which follows a different pattern is the validator receiving all +-transactions, via RPC, from the load runner process. +- +-### Test Result +- +-**Result: N/A** +- +-Date: 2022-10-10 +- +-Version: a28c987f5a604ff66b515dd415270063e6fb069d diff --git a/patches/docs/qa/img34/baseline/avg_cpu.png.patch b/patches/docs/qa/img34/baseline/avg_cpu.png.patch new file mode 100644 index 00000000000..ce01c9117fa --- /dev/null +++ b/patches/docs/qa/img34/baseline/avg_cpu.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/baseline/avg_cpu.png b/docs/qa/img34/baseline/avg_cpu.png +deleted file mode 100644 +index 622456df6..000000000 +Binary files a/docs/qa/img34/baseline/avg_cpu.png and /dev/null differ diff --git a/patches/docs/qa/img34/baseline/avg_memory.png.patch b/patches/docs/qa/img34/baseline/avg_memory.png.patch new file mode 100644 index 00000000000..1f35462f4ed --- /dev/null +++ b/patches/docs/qa/img34/baseline/avg_memory.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/baseline/avg_memory.png b/docs/qa/img34/baseline/avg_memory.png +deleted file mode 100644 +index 55f213f5e..000000000 +Binary files a/docs/qa/img34/baseline/avg_memory.png and /dev/null differ diff --git a/patches/docs/qa/img34/baseline/avg_mempool_size.png.patch b/patches/docs/qa/img34/baseline/avg_mempool_size.png.patch new file mode 100644 index 00000000000..bb8763f34e1 --- /dev/null +++ b/patches/docs/qa/img34/baseline/avg_mempool_size.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/baseline/avg_mempool_size.png b/docs/qa/img34/baseline/avg_mempool_size.png +deleted file mode 100644 +index ec7407295..000000000 +Binary files a/docs/qa/img34/baseline/avg_mempool_size.png and /dev/null differ diff --git a/patches/docs/qa/img34/baseline/block_rate_regular.png.patch b/patches/docs/qa/img34/baseline/block_rate_regular.png.patch new file mode 100644 index 00000000000..69b69739e2c --- /dev/null +++ b/patches/docs/qa/img34/baseline/block_rate_regular.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/baseline/block_rate_regular.png b/docs/qa/img34/baseline/block_rate_regular.png +deleted file mode 100644 +index bdc7aa28d..000000000 +Binary files a/docs/qa/img34/baseline/block_rate_regular.png and /dev/null differ diff --git a/patches/docs/qa/img34/baseline/cpu.png.patch b/patches/docs/qa/img34/baseline/cpu.png.patch new file mode 100644 index 00000000000..26a37cb6f2d --- /dev/null +++ b/patches/docs/qa/img34/baseline/cpu.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/baseline/cpu.png b/docs/qa/img34/baseline/cpu.png +deleted file mode 100644 +index ac4fc2695..000000000 +Binary files a/docs/qa/img34/baseline/cpu.png and /dev/null differ diff --git a/patches/docs/qa/img34/baseline/memory.png.patch b/patches/docs/qa/img34/baseline/memory.png.patch new file mode 100644 index 00000000000..d1b85050370 --- /dev/null +++ b/patches/docs/qa/img34/baseline/memory.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/baseline/memory.png b/docs/qa/img34/baseline/memory.png +deleted file mode 100644 +index 17336bd1b..000000000 +Binary files a/docs/qa/img34/baseline/memory.png and /dev/null differ diff --git a/patches/docs/qa/img34/baseline/mempool_size.png.patch b/patches/docs/qa/img34/baseline/mempool_size.png.patch new file mode 100644 index 00000000000..40bd8d43d86 --- /dev/null +++ b/patches/docs/qa/img34/baseline/mempool_size.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/baseline/mempool_size.png b/docs/qa/img34/baseline/mempool_size.png +deleted file mode 100644 +index fafba68c1..000000000 +Binary files a/docs/qa/img34/baseline/mempool_size.png and /dev/null differ diff --git a/patches/docs/qa/img34/baseline/peers.png.patch b/patches/docs/qa/img34/baseline/peers.png.patch new file mode 100644 index 00000000000..3c524b1c39f --- /dev/null +++ b/patches/docs/qa/img34/baseline/peers.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/baseline/peers.png b/docs/qa/img34/baseline/peers.png +deleted file mode 100644 +index 05a288a35..000000000 +Binary files a/docs/qa/img34/baseline/peers.png and /dev/null differ diff --git a/patches/docs/qa/img34/baseline/rounds.png.patch b/patches/docs/qa/img34/baseline/rounds.png.patch new file mode 100644 index 00000000000..d3443c8ae24 --- /dev/null +++ b/patches/docs/qa/img34/baseline/rounds.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/baseline/rounds.png b/docs/qa/img34/baseline/rounds.png +deleted file mode 100644 +index 79f3348a2..000000000 +Binary files a/docs/qa/img34/baseline/rounds.png and /dev/null differ diff --git a/patches/docs/qa/img34/baseline/total_txs_rate_regular.png.patch b/patches/docs/qa/img34/baseline/total_txs_rate_regular.png.patch new file mode 100644 index 00000000000..4940ff358f5 --- /dev/null +++ b/patches/docs/qa/img34/baseline/total_txs_rate_regular.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/baseline/total_txs_rate_regular.png b/docs/qa/img34/baseline/total_txs_rate_regular.png +deleted file mode 100644 +index d80bef12c..000000000 +Binary files a/docs/qa/img34/baseline/total_txs_rate_regular.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt1tm1/all_experiments.png.patch b/patches/docs/qa/img34/cmt1tm1/all_experiments.png.patch new file mode 100644 index 00000000000..85479a6c086 --- /dev/null +++ b/patches/docs/qa/img34/cmt1tm1/all_experiments.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt1tm1/all_experiments.png b/docs/qa/img34/cmt1tm1/all_experiments.png +deleted file mode 100644 +index 4dc857edc..000000000 +Binary files a/docs/qa/img34/cmt1tm1/all_experiments.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt1tm1/avg_cpu.png.patch b/patches/docs/qa/img34/cmt1tm1/avg_cpu.png.patch new file mode 100644 index 00000000000..5793a24d6f9 --- /dev/null +++ b/patches/docs/qa/img34/cmt1tm1/avg_cpu.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt1tm1/avg_cpu.png b/docs/qa/img34/cmt1tm1/avg_cpu.png +deleted file mode 100644 +index cabd273a5..000000000 +Binary files a/docs/qa/img34/cmt1tm1/avg_cpu.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt1tm1/avg_memory.png.patch b/patches/docs/qa/img34/cmt1tm1/avg_memory.png.patch new file mode 100644 index 00000000000..3562456c076 --- /dev/null +++ b/patches/docs/qa/img34/cmt1tm1/avg_memory.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt1tm1/avg_memory.png b/docs/qa/img34/cmt1tm1/avg_memory.png +deleted file mode 100644 +index c8e576177..000000000 +Binary files a/docs/qa/img34/cmt1tm1/avg_memory.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt1tm1/avg_mempool_size.png.patch b/patches/docs/qa/img34/cmt1tm1/avg_mempool_size.png.patch new file mode 100644 index 00000000000..c6b2a1869a6 --- /dev/null +++ b/patches/docs/qa/img34/cmt1tm1/avg_mempool_size.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt1tm1/avg_mempool_size.png b/docs/qa/img34/cmt1tm1/avg_mempool_size.png +deleted file mode 100644 +index b41199dc0..000000000 +Binary files a/docs/qa/img34/cmt1tm1/avg_mempool_size.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt1tm1/block_rate_regular.png.patch b/patches/docs/qa/img34/cmt1tm1/block_rate_regular.png.patch new file mode 100644 index 00000000000..03e803baa46 --- /dev/null +++ b/patches/docs/qa/img34/cmt1tm1/block_rate_regular.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt1tm1/block_rate_regular.png b/docs/qa/img34/cmt1tm1/block_rate_regular.png +deleted file mode 100644 +index 9b3a0b827..000000000 +Binary files a/docs/qa/img34/cmt1tm1/block_rate_regular.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt1tm1/cpu.png.patch b/patches/docs/qa/img34/cmt1tm1/cpu.png.patch new file mode 100644 index 00000000000..846de4a004f --- /dev/null +++ b/patches/docs/qa/img34/cmt1tm1/cpu.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt1tm1/cpu.png b/docs/qa/img34/cmt1tm1/cpu.png +deleted file mode 100644 +index cd5acdeb2..000000000 +Binary files a/docs/qa/img34/cmt1tm1/cpu.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt1tm1/memory.png.patch b/patches/docs/qa/img34/cmt1tm1/memory.png.patch new file mode 100644 index 00000000000..f18170b4637 --- /dev/null +++ b/patches/docs/qa/img34/cmt1tm1/memory.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt1tm1/memory.png b/docs/qa/img34/cmt1tm1/memory.png +deleted file mode 100644 +index 6f56b3ccf..000000000 +Binary files a/docs/qa/img34/cmt1tm1/memory.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt1tm1/mempool_size.png.patch b/patches/docs/qa/img34/cmt1tm1/mempool_size.png.patch new file mode 100644 index 00000000000..6db2f7e41b2 --- /dev/null +++ b/patches/docs/qa/img34/cmt1tm1/mempool_size.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt1tm1/mempool_size.png b/docs/qa/img34/cmt1tm1/mempool_size.png +deleted file mode 100644 +index 862a0bdd4..000000000 +Binary files a/docs/qa/img34/cmt1tm1/mempool_size.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt1tm1/peers.png.patch b/patches/docs/qa/img34/cmt1tm1/peers.png.patch new file mode 100644 index 00000000000..d0a8dd7b9f9 --- /dev/null +++ b/patches/docs/qa/img34/cmt1tm1/peers.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt1tm1/peers.png b/docs/qa/img34/cmt1tm1/peers.png +deleted file mode 100644 +index 737cf3dff..000000000 +Binary files a/docs/qa/img34/cmt1tm1/peers.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt1tm1/rounds.png.patch b/patches/docs/qa/img34/cmt1tm1/rounds.png.patch new file mode 100644 index 00000000000..a13f03a75c2 --- /dev/null +++ b/patches/docs/qa/img34/cmt1tm1/rounds.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt1tm1/rounds.png b/docs/qa/img34/cmt1tm1/rounds.png +deleted file mode 100644 +index 17884813a..000000000 +Binary files a/docs/qa/img34/cmt1tm1/rounds.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt1tm1/total_txs_rate_regular.png.patch b/patches/docs/qa/img34/cmt1tm1/total_txs_rate_regular.png.patch new file mode 100644 index 00000000000..27a68291d93 --- /dev/null +++ b/patches/docs/qa/img34/cmt1tm1/total_txs_rate_regular.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt1tm1/total_txs_rate_regular.png b/docs/qa/img34/cmt1tm1/total_txs_rate_regular.png +deleted file mode 100644 +index 8b0cc0d42..000000000 +Binary files a/docs/qa/img34/cmt1tm1/total_txs_rate_regular.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt2tm1/all_experiments.png.patch b/patches/docs/qa/img34/cmt2tm1/all_experiments.png.patch new file mode 100644 index 00000000000..3c0f8bf3f21 --- /dev/null +++ b/patches/docs/qa/img34/cmt2tm1/all_experiments.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt2tm1/all_experiments.png b/docs/qa/img34/cmt2tm1/all_experiments.png +deleted file mode 100644 +index 4e6f73d35..000000000 +Binary files a/docs/qa/img34/cmt2tm1/all_experiments.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt2tm1/avg_cpu.png.patch b/patches/docs/qa/img34/cmt2tm1/avg_cpu.png.patch new file mode 100644 index 00000000000..a778358a889 --- /dev/null +++ b/patches/docs/qa/img34/cmt2tm1/avg_cpu.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt2tm1/avg_cpu.png b/docs/qa/img34/cmt2tm1/avg_cpu.png +deleted file mode 100644 +index 92fea31bd..000000000 +Binary files a/docs/qa/img34/cmt2tm1/avg_cpu.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt2tm1/avg_memory.png.patch b/patches/docs/qa/img34/cmt2tm1/avg_memory.png.patch new file mode 100644 index 00000000000..57ce9be5c84 --- /dev/null +++ b/patches/docs/qa/img34/cmt2tm1/avg_memory.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt2tm1/avg_memory.png b/docs/qa/img34/cmt2tm1/avg_memory.png +deleted file mode 100644 +index f362798d8..000000000 +Binary files a/docs/qa/img34/cmt2tm1/avg_memory.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt2tm1/avg_mempool_size.png.patch b/patches/docs/qa/img34/cmt2tm1/avg_mempool_size.png.patch new file mode 100644 index 00000000000..ec3d1da7dab --- /dev/null +++ b/patches/docs/qa/img34/cmt2tm1/avg_mempool_size.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt2tm1/avg_mempool_size.png b/docs/qa/img34/cmt2tm1/avg_mempool_size.png +deleted file mode 100644 +index b73e577b7..000000000 +Binary files a/docs/qa/img34/cmt2tm1/avg_mempool_size.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt2tm1/block_rate_regular.png.patch b/patches/docs/qa/img34/cmt2tm1/block_rate_regular.png.patch new file mode 100644 index 00000000000..11170a620fc --- /dev/null +++ b/patches/docs/qa/img34/cmt2tm1/block_rate_regular.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt2tm1/block_rate_regular.png b/docs/qa/img34/cmt2tm1/block_rate_regular.png +deleted file mode 100644 +index 5fc7a5560..000000000 +Binary files a/docs/qa/img34/cmt2tm1/block_rate_regular.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt2tm1/cpu.png.patch b/patches/docs/qa/img34/cmt2tm1/cpu.png.patch new file mode 100644 index 00000000000..3b0002d9ed3 --- /dev/null +++ b/patches/docs/qa/img34/cmt2tm1/cpu.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt2tm1/cpu.png b/docs/qa/img34/cmt2tm1/cpu.png +deleted file mode 100644 +index 15df58abb..000000000 +Binary files a/docs/qa/img34/cmt2tm1/cpu.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt2tm1/memory.png.patch b/patches/docs/qa/img34/cmt2tm1/memory.png.patch new file mode 100644 index 00000000000..b23e7853833 --- /dev/null +++ b/patches/docs/qa/img34/cmt2tm1/memory.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt2tm1/memory.png b/docs/qa/img34/cmt2tm1/memory.png +deleted file mode 100644 +index b0feab107..000000000 +Binary files a/docs/qa/img34/cmt2tm1/memory.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt2tm1/mempool_size.png.patch b/patches/docs/qa/img34/cmt2tm1/mempool_size.png.patch new file mode 100644 index 00000000000..a9b384fdca7 --- /dev/null +++ b/patches/docs/qa/img34/cmt2tm1/mempool_size.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt2tm1/mempool_size.png b/docs/qa/img34/cmt2tm1/mempool_size.png +deleted file mode 100644 +index b3a1514f9..000000000 +Binary files a/docs/qa/img34/cmt2tm1/mempool_size.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt2tm1/peers.png.patch b/patches/docs/qa/img34/cmt2tm1/peers.png.patch new file mode 100644 index 00000000000..ebd8e6a012a --- /dev/null +++ b/patches/docs/qa/img34/cmt2tm1/peers.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt2tm1/peers.png b/docs/qa/img34/cmt2tm1/peers.png +deleted file mode 100644 +index 558d4c129..000000000 +Binary files a/docs/qa/img34/cmt2tm1/peers.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt2tm1/rounds.png.patch b/patches/docs/qa/img34/cmt2tm1/rounds.png.patch new file mode 100644 index 00000000000..03af2f3ff78 --- /dev/null +++ b/patches/docs/qa/img34/cmt2tm1/rounds.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt2tm1/rounds.png b/docs/qa/img34/cmt2tm1/rounds.png +deleted file mode 100644 +index 3c22a5cf3..000000000 +Binary files a/docs/qa/img34/cmt2tm1/rounds.png and /dev/null differ diff --git a/patches/docs/qa/img34/cmt2tm1/total_txs_rate_regular.png.patch b/patches/docs/qa/img34/cmt2tm1/total_txs_rate_regular.png.patch new file mode 100644 index 00000000000..7a6c88f43d0 --- /dev/null +++ b/patches/docs/qa/img34/cmt2tm1/total_txs_rate_regular.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/cmt2tm1/total_txs_rate_regular.png b/docs/qa/img34/cmt2tm1/total_txs_rate_regular.png +deleted file mode 100644 +index ae98df217..000000000 +Binary files a/docs/qa/img34/cmt2tm1/total_txs_rate_regular.png and /dev/null differ diff --git a/patches/docs/qa/img34/homogeneous/all_experiments.png.patch b/patches/docs/qa/img34/homogeneous/all_experiments.png.patch new file mode 100644 index 00000000000..0c6ffcaa38d --- /dev/null +++ b/patches/docs/qa/img34/homogeneous/all_experiments.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/homogeneous/all_experiments.png b/docs/qa/img34/homogeneous/all_experiments.png +deleted file mode 100644 +index d8768f6a5..000000000 +Binary files a/docs/qa/img34/homogeneous/all_experiments.png and /dev/null differ diff --git a/patches/docs/qa/img34/homogeneous/avg_cpu.png.patch b/patches/docs/qa/img34/homogeneous/avg_cpu.png.patch new file mode 100644 index 00000000000..ed7c5b0dbb1 --- /dev/null +++ b/patches/docs/qa/img34/homogeneous/avg_cpu.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/homogeneous/avg_cpu.png b/docs/qa/img34/homogeneous/avg_cpu.png +deleted file mode 100644 +index 7df188951..000000000 +Binary files a/docs/qa/img34/homogeneous/avg_cpu.png and /dev/null differ diff --git a/patches/docs/qa/img34/homogeneous/avg_memory.png.patch b/patches/docs/qa/img34/homogeneous/avg_memory.png.patch new file mode 100644 index 00000000000..9b48c43dc30 --- /dev/null +++ b/patches/docs/qa/img34/homogeneous/avg_memory.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/homogeneous/avg_memory.png b/docs/qa/img34/homogeneous/avg_memory.png +deleted file mode 100644 +index e800cbce2..000000000 +Binary files a/docs/qa/img34/homogeneous/avg_memory.png and /dev/null differ diff --git a/patches/docs/qa/img34/homogeneous/avg_mempool_size.png.patch b/patches/docs/qa/img34/homogeneous/avg_mempool_size.png.patch new file mode 100644 index 00000000000..68926045a5f --- /dev/null +++ b/patches/docs/qa/img34/homogeneous/avg_mempool_size.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/homogeneous/avg_mempool_size.png b/docs/qa/img34/homogeneous/avg_mempool_size.png +deleted file mode 100644 +index beb323e64..000000000 +Binary files a/docs/qa/img34/homogeneous/avg_mempool_size.png and /dev/null differ diff --git a/patches/docs/qa/img34/homogeneous/block_rate_regular.png.patch b/patches/docs/qa/img34/homogeneous/block_rate_regular.png.patch new file mode 100644 index 00000000000..7d59c82728f --- /dev/null +++ b/patches/docs/qa/img34/homogeneous/block_rate_regular.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/homogeneous/block_rate_regular.png b/docs/qa/img34/homogeneous/block_rate_regular.png +deleted file mode 100644 +index 2a71ab70d..000000000 +Binary files a/docs/qa/img34/homogeneous/block_rate_regular.png and /dev/null differ diff --git a/patches/docs/qa/img34/homogeneous/cpu.png.patch b/patches/docs/qa/img34/homogeneous/cpu.png.patch new file mode 100644 index 00000000000..70c7d3e9105 --- /dev/null +++ b/patches/docs/qa/img34/homogeneous/cpu.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/homogeneous/cpu.png b/docs/qa/img34/homogeneous/cpu.png +deleted file mode 100644 +index 8e8c9227a..000000000 +Binary files a/docs/qa/img34/homogeneous/cpu.png and /dev/null differ diff --git a/patches/docs/qa/img34/homogeneous/memory.png.patch b/patches/docs/qa/img34/homogeneous/memory.png.patch new file mode 100644 index 00000000000..4434ea9389f --- /dev/null +++ b/patches/docs/qa/img34/homogeneous/memory.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/homogeneous/memory.png b/docs/qa/img34/homogeneous/memory.png +deleted file mode 100644 +index 190c622a3..000000000 +Binary files a/docs/qa/img34/homogeneous/memory.png and /dev/null differ diff --git a/patches/docs/qa/img34/homogeneous/mempool_size.png.patch b/patches/docs/qa/img34/homogeneous/mempool_size.png.patch new file mode 100644 index 00000000000..90051e545f6 --- /dev/null +++ b/patches/docs/qa/img34/homogeneous/mempool_size.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/homogeneous/mempool_size.png b/docs/qa/img34/homogeneous/mempool_size.png +deleted file mode 100644 +index ec1c79a24..000000000 +Binary files a/docs/qa/img34/homogeneous/mempool_size.png and /dev/null differ diff --git a/patches/docs/qa/img34/homogeneous/peers.png.patch b/patches/docs/qa/img34/homogeneous/peers.png.patch new file mode 100644 index 00000000000..fb03897bb2a --- /dev/null +++ b/patches/docs/qa/img34/homogeneous/peers.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/homogeneous/peers.png b/docs/qa/img34/homogeneous/peers.png +deleted file mode 100644 +index 3c8b0a2e0..000000000 +Binary files a/docs/qa/img34/homogeneous/peers.png and /dev/null differ diff --git a/patches/docs/qa/img34/homogeneous/rounds.png.patch b/patches/docs/qa/img34/homogeneous/rounds.png.patch new file mode 100644 index 00000000000..fc28ae6a7a0 --- /dev/null +++ b/patches/docs/qa/img34/homogeneous/rounds.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/homogeneous/rounds.png b/docs/qa/img34/homogeneous/rounds.png +deleted file mode 100644 +index 660f31d93..000000000 +Binary files a/docs/qa/img34/homogeneous/rounds.png and /dev/null differ diff --git a/patches/docs/qa/img34/homogeneous/total_txs_rate_regular.png.patch b/patches/docs/qa/img34/homogeneous/total_txs_rate_regular.png.patch new file mode 100644 index 00000000000..7c8ff1dc6f4 --- /dev/null +++ b/patches/docs/qa/img34/homogeneous/total_txs_rate_regular.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/homogeneous/total_txs_rate_regular.png b/docs/qa/img34/homogeneous/total_txs_rate_regular.png +deleted file mode 100644 +index a9025b666..000000000 +Binary files a/docs/qa/img34/homogeneous/total_txs_rate_regular.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_latencies.png.patch b/patches/docs/qa/img34/v034_200node_latencies.png.patch new file mode 100644 index 00000000000..f7ecd783a5c --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_latencies.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_latencies.png b/docs/qa/img34/v034_200node_latencies.png +deleted file mode 100644 +index afd1060ca..000000000 +Binary files a/docs/qa/img34/v034_200node_latencies.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_latencies_zoomed.png.patch b/patches/docs/qa/img34/v034_200node_latencies_zoomed.png.patch new file mode 100644 index 00000000000..8ece5e15cb8 --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_latencies_zoomed.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_latencies_zoomed.png b/docs/qa/img34/v034_200node_latencies_zoomed.png +deleted file mode 100644 +index 1ff936442..000000000 +Binary files a/docs/qa/img34/v034_200node_latencies_zoomed.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_tm2cmt1/all_experiments.png.patch b/patches/docs/qa/img34/v034_200node_tm2cmt1/all_experiments.png.patch new file mode 100644 index 00000000000..e0bcbbd8ce6 --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_tm2cmt1/all_experiments.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_tm2cmt1/all_experiments.png b/docs/qa/img34/v034_200node_tm2cmt1/all_experiments.png +deleted file mode 100644 +index e91a87eff..000000000 +Binary files a/docs/qa/img34/v034_200node_tm2cmt1/all_experiments.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_tm2cmt1/avg_cpu.png.patch b/patches/docs/qa/img34/v034_200node_tm2cmt1/avg_cpu.png.patch new file mode 100644 index 00000000000..66374541ca8 --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_tm2cmt1/avg_cpu.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_tm2cmt1/avg_cpu.png b/docs/qa/img34/v034_200node_tm2cmt1/avg_cpu.png +deleted file mode 100644 +index a1b0ef79e..000000000 +Binary files a/docs/qa/img34/v034_200node_tm2cmt1/avg_cpu.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_tm2cmt1/avg_memory.png.patch b/patches/docs/qa/img34/v034_200node_tm2cmt1/avg_memory.png.patch new file mode 100644 index 00000000000..8d04c28df93 --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_tm2cmt1/avg_memory.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_tm2cmt1/avg_memory.png b/docs/qa/img34/v034_200node_tm2cmt1/avg_memory.png +deleted file mode 100644 +index f9d9b9933..000000000 +Binary files a/docs/qa/img34/v034_200node_tm2cmt1/avg_memory.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_tm2cmt1/avg_mempool_size.png.patch b/patches/docs/qa/img34/v034_200node_tm2cmt1/avg_mempool_size.png.patch new file mode 100644 index 00000000000..a8e1c4d1ebd --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_tm2cmt1/avg_mempool_size.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_tm2cmt1/avg_mempool_size.png b/docs/qa/img34/v034_200node_tm2cmt1/avg_mempool_size.png +deleted file mode 100644 +index c2b896060..000000000 +Binary files a/docs/qa/img34/v034_200node_tm2cmt1/avg_mempool_size.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_tm2cmt1/block_rate_regular.png.patch b/patches/docs/qa/img34/v034_200node_tm2cmt1/block_rate_regular.png.patch new file mode 100644 index 00000000000..311290f0571 --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_tm2cmt1/block_rate_regular.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_tm2cmt1/block_rate_regular.png b/docs/qa/img34/v034_200node_tm2cmt1/block_rate_regular.png +deleted file mode 100644 +index 5a5417bdf..000000000 +Binary files a/docs/qa/img34/v034_200node_tm2cmt1/block_rate_regular.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_tm2cmt1/c2r200_merged.png.patch b/patches/docs/qa/img34/v034_200node_tm2cmt1/c2r200_merged.png.patch new file mode 100644 index 00000000000..529251b75c8 --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_tm2cmt1/c2r200_merged.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_tm2cmt1/c2r200_merged.png b/docs/qa/img34/v034_200node_tm2cmt1/c2r200_merged.png +deleted file mode 100644 +index 45de9ce72..000000000 +Binary files a/docs/qa/img34/v034_200node_tm2cmt1/c2r200_merged.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_tm2cmt1/cpu.png.patch b/patches/docs/qa/img34/v034_200node_tm2cmt1/cpu.png.patch new file mode 100644 index 00000000000..abd66c55bc0 --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_tm2cmt1/cpu.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_tm2cmt1/cpu.png b/docs/qa/img34/v034_200node_tm2cmt1/cpu.png +deleted file mode 100644 +index eabfa9661..000000000 +Binary files a/docs/qa/img34/v034_200node_tm2cmt1/cpu.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_tm2cmt1/memory.png.patch b/patches/docs/qa/img34/v034_200node_tm2cmt1/memory.png.patch new file mode 100644 index 00000000000..058bfc0dd6e --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_tm2cmt1/memory.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_tm2cmt1/memory.png b/docs/qa/img34/v034_200node_tm2cmt1/memory.png +deleted file mode 100644 +index 70014c1f9..000000000 +Binary files a/docs/qa/img34/v034_200node_tm2cmt1/memory.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_tm2cmt1/mempool_size.png.patch b/patches/docs/qa/img34/v034_200node_tm2cmt1/mempool_size.png.patch new file mode 100644 index 00000000000..910a9ca64f7 --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_tm2cmt1/mempool_size.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_tm2cmt1/mempool_size.png b/docs/qa/img34/v034_200node_tm2cmt1/mempool_size.png +deleted file mode 100644 +index 5f4c44b2a..000000000 +Binary files a/docs/qa/img34/v034_200node_tm2cmt1/mempool_size.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_tm2cmt1/peers.png.patch b/patches/docs/qa/img34/v034_200node_tm2cmt1/peers.png.patch new file mode 100644 index 00000000000..f75fc81c61b --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_tm2cmt1/peers.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_tm2cmt1/peers.png b/docs/qa/img34/v034_200node_tm2cmt1/peers.png +deleted file mode 100644 +index c35c84675..000000000 +Binary files a/docs/qa/img34/v034_200node_tm2cmt1/peers.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_tm2cmt1/rounds.png.patch b/patches/docs/qa/img34/v034_200node_tm2cmt1/rounds.png.patch new file mode 100644 index 00000000000..052c462e02d --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_tm2cmt1/rounds.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_tm2cmt1/rounds.png b/docs/qa/img34/v034_200node_tm2cmt1/rounds.png +deleted file mode 100644 +index 7d1034bcb..000000000 +Binary files a/docs/qa/img34/v034_200node_tm2cmt1/rounds.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_200node_tm2cmt1/total_txs_rate_regular.png.patch b/patches/docs/qa/img34/v034_200node_tm2cmt1/total_txs_rate_regular.png.patch new file mode 100644 index 00000000000..171c1100c34 --- /dev/null +++ b/patches/docs/qa/img34/v034_200node_tm2cmt1/total_txs_rate_regular.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_200node_tm2cmt1/total_txs_rate_regular.png b/docs/qa/img34/v034_200node_tm2cmt1/total_txs_rate_regular.png +deleted file mode 100644 +index 2e8a40af6..000000000 +Binary files a/docs/qa/img34/v034_200node_tm2cmt1/total_txs_rate_regular.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_latency_throughput.png.patch b/patches/docs/qa/img34/v034_latency_throughput.png.patch new file mode 100644 index 00000000000..fe9b32d5344 --- /dev/null +++ b/patches/docs/qa/img34/v034_latency_throughput.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_latency_throughput.png b/docs/qa/img34/v034_latency_throughput.png +deleted file mode 100644 +index 3674fe47b..000000000 +Binary files a/docs/qa/img34/v034_latency_throughput.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_r200c2_heights.png.patch b/patches/docs/qa/img34/v034_r200c2_heights.png.patch new file mode 100644 index 00000000000..c4ac782a47a --- /dev/null +++ b/patches/docs/qa/img34/v034_r200c2_heights.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_r200c2_heights.png b/docs/qa/img34/v034_r200c2_heights.png +deleted file mode 100644 +index 11f3bba43..000000000 +Binary files a/docs/qa/img34/v034_r200c2_heights.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_r200c2_load-runner.png.patch b/patches/docs/qa/img34/v034_r200c2_load-runner.png.patch new file mode 100644 index 00000000000..6646bba9f47 --- /dev/null +++ b/patches/docs/qa/img34/v034_r200c2_load-runner.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_r200c2_load-runner.png b/docs/qa/img34/v034_r200c2_load-runner.png +deleted file mode 100644 +index 70211b0d2..000000000 +Binary files a/docs/qa/img34/v034_r200c2_load-runner.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_r200c2_load1.png.patch b/patches/docs/qa/img34/v034_r200c2_load1.png.patch new file mode 100644 index 00000000000..6ba0cefbb6c --- /dev/null +++ b/patches/docs/qa/img34/v034_r200c2_load1.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_r200c2_load1.png b/docs/qa/img34/v034_r200c2_load1.png +deleted file mode 100644 +index 11012844d..000000000 +Binary files a/docs/qa/img34/v034_r200c2_load1.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_r200c2_mempool_size.png.patch b/patches/docs/qa/img34/v034_r200c2_mempool_size.png.patch new file mode 100644 index 00000000000..feb2d4b1e7f --- /dev/null +++ b/patches/docs/qa/img34/v034_r200c2_mempool_size.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_r200c2_mempool_size.png b/docs/qa/img34/v034_r200c2_mempool_size.png +deleted file mode 100644 +index c5d690200..000000000 +Binary files a/docs/qa/img34/v034_r200c2_mempool_size.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_r200c2_mempool_size_avg.png.patch b/patches/docs/qa/img34/v034_r200c2_mempool_size_avg.png.patch new file mode 100644 index 00000000000..760ffaf036c --- /dev/null +++ b/patches/docs/qa/img34/v034_r200c2_mempool_size_avg.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_r200c2_mempool_size_avg.png b/docs/qa/img34/v034_r200c2_mempool_size_avg.png +deleted file mode 100644 +index bda399fe5..000000000 +Binary files a/docs/qa/img34/v034_r200c2_mempool_size_avg.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_r200c2_peers.png.patch b/patches/docs/qa/img34/v034_r200c2_peers.png.patch new file mode 100644 index 00000000000..ef8792beed1 --- /dev/null +++ b/patches/docs/qa/img34/v034_r200c2_peers.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_r200c2_peers.png b/docs/qa/img34/v034_r200c2_peers.png +deleted file mode 100644 +index a0aea7ada..000000000 +Binary files a/docs/qa/img34/v034_r200c2_peers.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_r200c2_rounds.png.patch b/patches/docs/qa/img34/v034_r200c2_rounds.png.patch new file mode 100644 index 00000000000..0b5909050cb --- /dev/null +++ b/patches/docs/qa/img34/v034_r200c2_rounds.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_r200c2_rounds.png b/docs/qa/img34/v034_r200c2_rounds.png +deleted file mode 100644 +index 215be100d..000000000 +Binary files a/docs/qa/img34/v034_r200c2_rounds.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_r200c2_rss.png.patch b/patches/docs/qa/img34/v034_r200c2_rss.png.patch new file mode 100644 index 00000000000..4c04c5e3a11 --- /dev/null +++ b/patches/docs/qa/img34/v034_r200c2_rss.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_r200c2_rss.png b/docs/qa/img34/v034_r200c2_rss.png +deleted file mode 100644 +index 6d14dced0..000000000 +Binary files a/docs/qa/img34/v034_r200c2_rss.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_r200c2_rss_avg.png.patch b/patches/docs/qa/img34/v034_r200c2_rss_avg.png.patch new file mode 100644 index 00000000000..4687cdce378 --- /dev/null +++ b/patches/docs/qa/img34/v034_r200c2_rss_avg.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_r200c2_rss_avg.png b/docs/qa/img34/v034_r200c2_rss_avg.png +deleted file mode 100644 +index 8dec67da2..000000000 +Binary files a/docs/qa/img34/v034_r200c2_rss_avg.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_r200c2_total-txs.png.patch b/patches/docs/qa/img34/v034_r200c2_total-txs.png.patch new file mode 100644 index 00000000000..dd3cca47cc4 --- /dev/null +++ b/patches/docs/qa/img34/v034_r200c2_total-txs.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_r200c2_total-txs.png b/docs/qa/img34/v034_r200c2_total-txs.png +deleted file mode 100644 +index 177d5f1c3..000000000 +Binary files a/docs/qa/img34/v034_r200c2_total-txs.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_report_tabbed.txt.patch b/patches/docs/qa/img34/v034_report_tabbed.txt.patch new file mode 100644 index 00000000000..f91f8db7f69 --- /dev/null +++ b/patches/docs/qa/img34/v034_report_tabbed.txt.patch @@ -0,0 +1,58 @@ +diff --git a/docs/qa/img34/v034_report_tabbed.txt b/docs/qa/img34/v034_report_tabbed.txt +deleted file mode 100644 +index 251495474..000000000 +--- a/docs/qa/img34/v034_report_tabbed.txt ++++ /dev/null +@@ -1,52 +0,0 @@ +-Experiment ID: 3d5cf4ef-1a1a-4b46-aa2d-da5643d2e81e │Experiment ID: 80e472ec-13a1-4772-a827-3b0c907fb51d │Experiment ID: 07aca6cf-c5a4-4696-988f-e3270fc6333b +- │ │ +- Connections: 1 │ Connections: 2 │ Connections: 4 +- Rate: 25 │ Rate: 25 │ Rate: 25 +- Size: 1024 │ Size: 1024 │ Size: 1024 +- │ │ +- Total Valid Tx: 2225 │ Total Valid Tx: 4450 │ Total Valid Tx: 8900 +- Total Negative Latencies: 0 │ Total Negative Latencies: 0 │ Total Negative Latencies: 0 +- Minimum Latency: 599.404362ms │ Minimum Latency: 448.145181ms │ Minimum Latency: 412.485729ms +- Maximum Latency: 3.539686885s │ Maximum Latency: 3.237392049s │ Maximum Latency: 12.026665368s +- Average Latency: 1.441485349s │ Average Latency: 1.441267946s │ Average Latency: 2.150192457s +- Standard Deviation: 541.049869ms │ Standard Deviation: 525.040007ms │ Standard Deviation: 2.233852478s +- │ │ +-Experiment ID: 953dc544-dd40-40e8-8712-20c34c3ce45e │Experiment ID: d31fc258-16e7-45cd-9dc8-13ab87bc0b0a │Experiment ID: 15d90a7e-b941-42f4-b411-2f15f857739e +- │ │ +- Connections: 1 │ Connections: 2 │ Connections: 4 +- Rate: 50 │ Rate: 50 │ Rate: 50 +- Size: 1024 │ Size: 1024 │ Size: 1024 +- │ │ +- Total Valid Tx: 4450 │ Total Valid Tx: 8900 │ Total Valid Tx: 17800 +- Total Negative Latencies: 0 │ Total Negative Latencies: 0 │ Total Negative Latencies: 0 +- Minimum Latency: 482.046942ms │ Minimum Latency: 435.458913ms │ Minimum Latency: 510.746448ms +- Maximum Latency: 3.761483455s │ Maximum Latency: 7.175583584s │ Maximum Latency: 6.551497882s +- Average Latency: 1.450408183s │ Average Latency: 1.681673116s │ Average Latency: 1.738083875s +- Standard Deviation: 587.560056ms │ Standard Deviation: 1.147902047s │ Standard Deviation: 943.46522ms +- │ │ +-Experiment ID: 9a0b9980-9ce6-4db5-a80a-65ca70294b87 │Experiment ID: df8fa4f4-80af-4ded-8a28-356d15018b43 │Experiment ID: d0e41c2c-89c0-4f38-8e34-ca07adae593a +- │ │ +- Connections: 1 │ Connections: 2 │ Connections: 4 +- Rate: 100 │ Rate: 100 │ Rate: 100 +- Size: 1024 │ Size: 1024 │ Size: 1024 +- │ │ +- Total Valid Tx: 8900 │ Total Valid Tx: 17800 │ Total Valid Tx: 35600 +- Total Negative Latencies: 0 │ Total Negative Latencies: 0 │ Total Negative Latencies: 0 +- Minimum Latency: 477.417219ms │ Minimum Latency: 564.29247ms │ Minimum Latency: 840.71089ms +- Maximum Latency: 6.63744785s │ Maximum Latency: 6.988553219s │ Maximum Latency: 9.555312398s +- Average Latency: 1.561216103s │ Average Latency: 1.76419063s │ Average Latency: 3.200941683s +- Standard Deviation: 1.011333552s │ Standard Deviation: 1.068459423s │ Standard Deviation: 1.732346601s +- │ │ +-Experiment ID: 493df3ee-4a36-4bce-80f8-6d65da66beda │Experiment ID: 13060525-f04f-46f6-8ade-286684b2fe50 │Experiment ID: 1777cbd2-8c96-42e4-9ec7-9b21f2225e4d +- │ │ +- Connections: 1 │ Connections: 2 │ Connections: 4 +- Rate: 200 │ Rate: 200 │ Rate: 200 +- Size: 1024 │ Size: 1024 │ Size: 1024 +- │ │ +- Total Valid Tx: 17800 │ Total Valid Tx: 35600 │ Total Valid Tx: 38660 +- Total Negative Latencies: 0 │ Total Negative Latencies: 0 │ Total Negative Latencies: 0 +- Minimum Latency: 493.705261ms │ Minimum Latency: 955.090573ms │ Minimum Latency: 1.9485821s +- Maximum Latency: 7.440921872s │ Maximum Latency: 10.086673491s │ Maximum Latency: 17.73103976s +- Average Latency: 1.875510582s │ Average Latency: 3.438130099s │ Average Latency: 8.143862237s +- Standard Deviation: 1.304336995s │ Standard Deviation: 1.966391574s │ Standard Deviation: 3.943140002s +- diff --git a/patches/docs/qa/img34/v034_rotating_heights.png.patch b/patches/docs/qa/img34/v034_rotating_heights.png.patch new file mode 100644 index 00000000000..83d4dab9ac2 --- /dev/null +++ b/patches/docs/qa/img34/v034_rotating_heights.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_rotating_heights.png b/docs/qa/img34/v034_rotating_heights.png +deleted file mode 100644 +index 47913c282..000000000 +Binary files a/docs/qa/img34/v034_rotating_heights.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_rotating_heights_ephe.png.patch b/patches/docs/qa/img34/v034_rotating_heights_ephe.png.patch new file mode 100644 index 00000000000..5be608bc22c --- /dev/null +++ b/patches/docs/qa/img34/v034_rotating_heights_ephe.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_rotating_heights_ephe.png b/docs/qa/img34/v034_rotating_heights_ephe.png +deleted file mode 100644 +index 981b93d6c..000000000 +Binary files a/docs/qa/img34/v034_rotating_heights_ephe.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_rotating_latencies.png.patch b/patches/docs/qa/img34/v034_rotating_latencies.png.patch new file mode 100644 index 00000000000..d4eedb3237a --- /dev/null +++ b/patches/docs/qa/img34/v034_rotating_latencies.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_rotating_latencies.png b/docs/qa/img34/v034_rotating_latencies.png +deleted file mode 100644 +index f0a54ed5b..000000000 +Binary files a/docs/qa/img34/v034_rotating_latencies.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_rotating_latencies_uniq.png.patch b/patches/docs/qa/img34/v034_rotating_latencies_uniq.png.patch new file mode 100644 index 00000000000..77a8b069cca --- /dev/null +++ b/patches/docs/qa/img34/v034_rotating_latencies_uniq.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_rotating_latencies_uniq.png b/docs/qa/img34/v034_rotating_latencies_uniq.png +deleted file mode 100644 +index e5d694a16..000000000 +Binary files a/docs/qa/img34/v034_rotating_latencies_uniq.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_rotating_load1.png.patch b/patches/docs/qa/img34/v034_rotating_load1.png.patch new file mode 100644 index 00000000000..da648e09399 --- /dev/null +++ b/patches/docs/qa/img34/v034_rotating_load1.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_rotating_load1.png b/docs/qa/img34/v034_rotating_load1.png +deleted file mode 100644 +index e9c385b85..000000000 +Binary files a/docs/qa/img34/v034_rotating_load1.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_rotating_peers.png.patch b/patches/docs/qa/img34/v034_rotating_peers.png.patch new file mode 100644 index 00000000000..d70e4a2d184 --- /dev/null +++ b/patches/docs/qa/img34/v034_rotating_peers.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_rotating_peers.png b/docs/qa/img34/v034_rotating_peers.png +deleted file mode 100644 +index ab5c8732d..000000000 +Binary files a/docs/qa/img34/v034_rotating_peers.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_rotating_rss_avg.png.patch b/patches/docs/qa/img34/v034_rotating_rss_avg.png.patch new file mode 100644 index 00000000000..642b8ec27b5 --- /dev/null +++ b/patches/docs/qa/img34/v034_rotating_rss_avg.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_rotating_rss_avg.png b/docs/qa/img34/v034_rotating_rss_avg.png +deleted file mode 100644 +index 9a4167320..000000000 +Binary files a/docs/qa/img34/v034_rotating_rss_avg.png and /dev/null differ diff --git a/patches/docs/qa/img34/v034_rotating_total-txs.png.patch b/patches/docs/qa/img34/v034_rotating_total-txs.png.patch new file mode 100644 index 00000000000..e1739356079 --- /dev/null +++ b/patches/docs/qa/img34/v034_rotating_total-txs.png.patch @@ -0,0 +1,4 @@ +diff --git a/docs/qa/img34/v034_rotating_total-txs.png b/docs/qa/img34/v034_rotating_total-txs.png +deleted file mode 100644 +index 1ce5f47e9..000000000 +Binary files a/docs/qa/img34/v034_rotating_total-txs.png and /dev/null differ diff --git a/patches/docs/qa/method.md.patch b/patches/docs/qa/method.md.patch new file mode 100644 index 00000000000..c8ec26b1c53 --- /dev/null +++ b/patches/docs/qa/method.md.patch @@ -0,0 +1,263 @@ +diff --git a/docs/qa/method.md b/docs/qa/method.md +deleted file mode 100644 +index 6de0cbcf8..000000000 +--- a/docs/qa/method.md ++++ /dev/null +@@ -1,257 +0,0 @@ +---- +-order: 1 +-parent: +- title: Method +- order: 1 +---- +- +-# Method +- +-This document provides a detailed description of the QA process. +-It is intended to be used by engineers reproducing the experimental setup for future tests of CometBFT. +- +-The (first iteration of the) QA process as described [in the RELEASES.md document][releases] +-was applied to version v0.34.x in order to have a set of results acting as benchmarking baseline. +-This baseline is then compared with results obtained in later versions. +- +-Out of the testnet-based test cases described in [the releases document][releases] we focused on two of them: +-_200 Node Test_, and _Rotating Nodes Test_. +- +-[releases]: https://github.com/cometbft/cometbft/blob/main/RELEASES.md#large-scale-testnets +- +-## Software Dependencies +- +-### Infrastructure Requirements to Run the Tests +- +-* An account at Digital Ocean (DO), with a high droplet limit (>202) +-* The machine to orchestrate the tests should have the following installed: +- * A clone of the [testnet repository][testnet-repo] +- * This repository contains all the scripts mentioned in the reminder of this section +- * [Digital Ocean CLI][doctl] +- * [Terraform CLI][Terraform] +- * [Ansible CLI][Ansible] +- +-[testnet-repo]: https://github.com/cometbft/qa-infra +-[Ansible]: https://docs.ansible.com/ansible/latest/index.html +-[Terraform]: https://www.terraform.io/docs +-[doctl]: https://docs.digitalocean.com/reference/doctl/how-to/install/ +- +-### Requirements for Result Extraction +- +-* Matlab or Octave +-* [Prometheus][prometheus] server installed +-* blockstore DB of one of the full nodes in the testnet +-* Prometheus DB +- +-[prometheus]: https://prometheus.io/ +- +-## 200 Node Testnet +- +-### Running the test +- +-This section explains how the tests were carried out for reproducibility purposes. +- +-1. [If you haven't done it before] +- Follow steps 1-4 of the `README.md` at the top of the testnet repository to configure Terraform, and `doctl`. +-2. Copy file `testnets/testnet200.toml` onto `testnet.toml` (do NOT commit this change) +-3. Set the variable `VERSION_TAG` in the `Makefile` to the git hash that is to be tested. +- * If you are running the base test, which implies an homogeneous network (all nodes are running the same version), +- then make sure makefile variable `VERSION2_WEIGHT` is set to 0 +- * If you are running a mixed network, set the variable `VERSION_TAG2` to the other version you want deployed +- in the network. The, adjust the weight variables `VERSION_WEIGHT` and `VERSION2_WEIGHT` to configure the +- desired proportion of nodes running each of the two configured versions. +-4. Follow steps 5-10 of the `README.md` to configure and start the 200 node testnet +- * WARNING: Do NOT forget to run `make terraform-destroy` as soon as you are done with the tests (see step 9) +-5. As a sanity check, connect to the Prometheus node's web interface and check the graph for the `COMETBFT_CONSENSUS_HEIGHT` metric. +- All nodes should be increasing their heights. +-6. You now need to start the load runner that will produce transaction load +- * If you don't know the saturation load of the version you are testing, you need to discover it. +- * `ssh` into the `testnet-load-runner`, then copy script `script/200-node-loadscript.sh` and run it from the load runner node. +- * Before running it, you need to edit the script to provide the IP address of a full node. +- This node will receive all transactions from the load runner node. +- * This script will take about 40 mins to run. +- * It is running 90-seconds-long experiments in a loop with different loads. +- * If you already know the saturation load, you can simply run the test (several times) for 90 seconds with a load somewhat +- below saturation: +- * set makefile variables `ROTATE_CONNECTIONS`, `ROTATE_TX_RATE`, to values that will produce the desired transaction load. +- * set `ROTATE_TOTAL_TIME` to 90 (seconds). +- * run "make runload" and wait for it to complete. You may want to run this several times so the data from different runs can be compared. +-7. Run `make retrieve-data` to gather all relevant data from the testnet into the orchestrating machine +- * Alternatively, you may want to run `make retrieve-prometheus-data` and `make retrieve-blockstore` separately. +- The end result will be the same. +- * `make retrieve-blockstore` accepts the following values in makefile variable `RETRIEVE_TARGET_HOST` +- * `any`: (which is the default) picks up a full node and retrieves the blockstore from that node only. +- * `all`: retrieves the blockstore from all full nodes; this is extremely slow, and consumes plenty of bandwidth, +- so use it with care. +- * the name of a particular full node (e.g., `validator01`): retrieves the blockstore from that node only. +-8. Verify that the data was collected without errors +- * at least one blockstore DB for a CometBFT validator +- * the Prometheus database from the Prometheus node +- * for extra care, you can run `zip -T` on the `prometheus.zip` file and (one of) the `blockstore.db.zip` file(s) +-9. **Run `make terraform-destroy`** +- * Don't forget to type `yes`! Otherwise you're in trouble. +- +-### Result Extraction +- +-The method for extracting the results described here is highly manual (and exploratory) at this stage. +-The CometBFT team should improve it at every iteration to increase the amount of automation. +- +-#### Steps +- +-1. Unzip the blockstore into a directory +-2. Extract the latency report and the raw latencies for all the experiments. Run these commands from the directory containing the blockstore +- * ```bash +- mkdir results +- go run github.com/cometbft/cometbft/test/loadtime/cmd/report@f1aaa436d --database-type goleveldb --data-dir ./ > results/report.txt` +- go run github.com/cometbft/cometbft/test/loadtime/cmd/report@f1aaa436d --database-type goleveldb --data-dir ./ --csv results/raw.csv` +- ``` +-3. File `report.txt` contains an unordered list of experiments with varying concurrent connections and transaction rate +- * If you are looking for the saturation point +- * Create files `report01.txt`, `report02.txt`, `report04.txt` and, for each experiment in file `report.txt`, +- copy its related lines to the filename that matches the number of connections, for example +- ```bash +- for cnum in 1 2 3 4; do echo "$cnum"; grep "Connections: $cnum" results/report.txt -B 2 -A 10 > results/report$cnum.txt; done +- ``` +- +- * Sort the experiments in `report01.txt` in ascending tx rate order. Likewise for `report02.txt` and `report04.txt`. +- * Otherwise just keep `report.txt`, and skip step 4. +-4. Generate file `report_tabbed.txt` by showing the contents `report01.txt`, `report02.txt`, `report04.txt` side by side +- * This effectively creates a table where rows are a particular tx rate and columns are a particular number of websocket connections. +-5. Extract the raw latencies from file `raw.csv` using the following bash loop. This creates a `.csv` file and a `.dat` file per experiment. +- The format of the `.dat` files is amenable to loading them as matrices in Octave. +- * Adapt the values of the for loop variables according to the experiments that you ran (check `report.txt`). +- * Adapt `report*.txt` to the files you produced in step 3. +- +- ```bash +- uuids=($(cat report01.txt report02.txt report04.txt | grep '^Experiment ID: ' | awk '{ print $3 }')) +- c=1 +- rm -f *.dat +- for i in 01 02 04; do +- for j in 0025 0050 0100 0200; do +- echo $i $j $c "${uuids[$c]}" +- filename=c${i}_r${j} +- grep ${uuids[$c]} raw.csv > ${filename}.csv +- cat ${filename}.csv | tr , ' ' | awk '{ print $2, $3 }' >> ${filename}.dat +- c=$(expr $c + 1) +- done +- done +- ``` +- +-6. Enter Octave +-7. Load all `.dat` files generated in step 5 into matrices using this Octave code snippet +- +- ```octave +- conns = { "01"; "02"; "04" }; +- rates = { "0025"; "0050"; "0100"; "0200" }; +- for i = 1:length(conns) +- for j = 1:length(rates) +- filename = strcat("c", conns{i}, "_r", rates{j}, ".dat"); +- load("-ascii", filename); +- endfor +- endfor +- ``` +- +-8. Set variable release to the current release undergoing QA +- +- ```octave +- release = "v0.34.x"; +- ``` +- +-9. Generate a plot with all (or some) experiments, where the X axis is the experiment time, +- and the y axis is the latency of transactions. +- The following snippet plots all experiments. +- +- ```octave +- legends = {}; +- hold off; +- for i = 1:length(conns) +- for j = 1:length(rates) +- data_name = strcat("c", conns{i}, "_r", rates{j}); +- l = strcat("c=", conns{i}, " r=", rates{j}); +- m = eval(data_name); plot((m(:,1) - min(m(:,1))) / 1e+9, m(:,2) / 1e+9, "."); +- hold on; +- legends(1, end+1) = l; +- endfor +- endfor +- legend(legends, "location", "northeastoutside"); +- xlabel("experiment time (s)"); +- ylabel("latency (s)"); +- t = sprintf("200-node testnet - %s", release); +- title(t); +- ``` +- +-10. Consider adjusting the axis, in case you want to compare your results to the baseline, for instance +- +- ```octave +- axis([0, 100, 0, 30], "tic"); +- ``` +- +-11. Use Octave's GUI menu to save the plot (e.g. as `.png`) +- +-12. Repeat steps 9 and 10 to obtain as many plots as deemed necessary. +- +-13. To generate a latency vs throughput plot, using the raw CSV file generated +- in step 2, follow the instructions for the [`latency_throughput.py`] script. +- This plot is useful to visualize the saturation point. +- +-[`latency_throughput.py`]: ../../scripts/qa/reporting/README.md#Latency-vs-Throughput-Plotting +- +-14. Alternatively, follow the instructions for the [`latency_plotter.py`] script. +- This script generates a series of plots per experiment and configuration that my +- help with visualizing Latency vs Throughput variation. +- +-[`latency_plotter.py`]: ../../scripts/qa/reporting/README.md#Latency-vs-Throughput-Plotting-version-2 +- +-#### Extracting Prometheus Metrics +- +-1. Stop the prometheus server if it is running as a service (e.g. a `systemd` unit). +-2. Unzip the prometheus database retrieved from the testnet, and move it to replace the +- local prometheus database. +-3. Start the prometheus server and make sure no error logs appear at start up. +-4. Identify the time window you want to plot in your graphs. +-5. Execute the [`prometheus_plotter.py`] script for the time window. +- +-[`prometheus_plotter.py`]: ../../scripts/qa/reporting/README.md#prometheus-metrics +- +-## Rotating Node Testnet +- +-### Running the test +- +-This section explains how the tests were carried out for reproducibility purposes. +- +-1. [If you haven't done it before] +- Follow steps 1-4 of the `README.md` at the top of the testnet repository to configure Terraform, and `doctl`. +-2. Copy file `testnet_rotating.toml` onto `testnet.toml` (do NOT commit this change) +-3. Set variable `VERSION_TAG` to the git hash that is to be tested. +-4. Run `make terraform-apply EPHEMERAL_SIZE=25` +- * WARNING: Do NOT forget to run `make terraform-destroy` as soon as you are done with the tests +-5. Follow steps 6-10 of the `README.md` to configure and start the "stable" part of the rotating node testnet +-6. As a sanity check, connect to the Prometheus node's web interface and check the graph for the `tendermint_consensus_height` metric. +- All nodes should be increasing their heights. +-7. On a different shell, +- * run `make runload ROTATE_CONNECTIONS=X ROTATE_TX_RATE=Y` +- * `X` and `Y` should reflect a load below the saturation point (see, e.g., +- [this paragraph](CometBFT-QA-34.md#finding-the-saturation-point) for further info) +-8. Run `make rotate` to start the script that creates the ephemeral nodes, and kills them when they are caught up. +- * WARNING: If you run this command from your laptop, the laptop needs to be up and connected for full length +- of the experiment. +-9. When the height of the chain reaches 3000, stop the `make rotate` script +-10. When the rotate script has made two iterations (i.e., all ephemeral nodes have caught up twice) +- after height 3000 was reached, stop `make rotate` +-11. Run `make retrieve-data` to gather all relevant data from the testnet into the orchestrating machine +-12. Verify that the data was collected without errors +- * at least one blockstore DB for a CometBFT validator +- * the Prometheus database from the Prometheus node +- * for extra care, you can run `zip -T` on the `prometheus.zip` file and (one of) the `blockstore.db.zip` file(s) +-13. **Run `make terraform-destroy`** +- +-Steps 8 to 10 are highly manual at the moment and will be improved in next iterations. +- +-### Result Extraction +- +-In order to obtain a latency plot, follow the instructions above for the 200 node experiment, but: +- +-* The `results.txt` file contains only one experiment +-* Therefore, no need for any `for` loops +- +-As for prometheus, the same method as for the 200 node experiment can be applied. diff --git a/patches/docs/tools/README.md.patch b/patches/docs/tools/README.md.patch new file mode 100644 index 00000000000..dc2702d300e --- /dev/null +++ b/patches/docs/tools/README.md.patch @@ -0,0 +1,26 @@ +diff --git a/docs/tools/README.md b/docs/tools/README.md +deleted file mode 100644 +index de29e17f1..000000000 +--- a/docs/tools/README.md ++++ /dev/null +@@ -1,20 +0,0 @@ +---- +-order: 1 +-parent: +- title: Tools +- order: 6 +---- +- +-# Overview +- +-CometBFT has some tools that are associated with it for: +- +-- [Debugging](./debugging.md) +-- [Benchmarking](#benchmarking) +- +-## Benchmarking +- +-- +- +-`tm-load-test` is a distributed load testing tool (and framework) for load +-testing CometBFT networks. diff --git a/patches/docs/tools/debugging.md.patch b/patches/docs/tools/debugging.md.patch new file mode 100644 index 00000000000..07197d90c63 --- /dev/null +++ b/patches/docs/tools/debugging.md.patch @@ -0,0 +1,67 @@ +diff --git a/docs/tools/debugging.md b/docs/tools/debugging.md +deleted file mode 100644 +index 69449a93d..000000000 +--- a/docs/tools/debugging.md ++++ /dev/null +@@ -1,61 +0,0 @@ +---- +-order: 1 +---- +- +-# Debugging +- +-## CometBFT debug kill +- +-CometBFT comes with a `debug` sub-command that allows you to kill a live +-CometBFT process while collecting useful information in a compressed archive. +-The information includes the configuration used, consensus state, network +-state, the node' status, the WAL, and even the stack trace of the process +-before exit. These files can be useful to examine when debugging a faulty +-CometBFT process. +- +-```bash +-cometbft debug kill --home= +-``` +- +-will write debug info into a compressed archive. The archive will contain the +-following: +- +-```sh +-├── config.toml +-├── consensus_state.json +-├── net_info.json +-├── stacktrace.out +-├── status.json +-└── wal +-``` +- +-Under the hood, `debug kill` fetches info from `/status`, `/net_info`, and +-`/dump_consensus_state` HTTP endpoints, and kills the process with `-6`, which +-catches the go-routine dump. +- +-## CometBFT debug dump +- +-Also, the `debug dump` sub-command allows you to dump debugging data into +-compressed archives at a regular interval. These archives contain the goroutine +-and heap profiles in addition to the consensus state, network info, node +-status, and even the WAL. +- +-```bash +-cometbft debug dump --home= +-``` +- +-will perform similarly to `kill` except it only polls the node and +-dumps debugging data every frequency seconds to a compressed archive under a +-given destination directory. Each archive will contain: +- +-```sh +-├── consensus_state.json +-├── goroutine.out +-├── heap.out +-├── net_info.json +-├── status.json +-└── wal +-``` +- +-Note: goroutine.out and heap.out will only be written if a profile address is +-provided and is operational. This command is blocking and will log any error. diff --git a/patches/go.mod.patch b/patches/go.mod.patch new file mode 100644 index 00000000000..c23aa8b221c --- /dev/null +++ b/patches/go.mod.patch @@ -0,0 +1,376 @@ +diff --git a/go.mod b/go.mod +index 03fb0d1a5..3127a10d5 100644 +--- a/go.mod ++++ b/go.mod +@@ -1,298 +1,145 @@ + module github.com/tendermint/tendermint + +-go 1.21 ++go 1.23.1 + + require ( +- github.com/BurntSushi/toml v1.2.1 ++ github.com/BurntSushi/toml v1.4.1-0.20240526193622-a339e1f7089c + github.com/ChainSafe/go-schnorrkel v1.0.0 ++ github.com/Masterminds/semver/v3 v3.3.0 + github.com/Workiva/go-datastructures v1.0.53 + github.com/adlio/schema v1.3.3 ++ github.com/aws/aws-sdk-go v1.40.45 ++ github.com/btcsuite/btcd/btcec/v2 v2.3.4 ++ github.com/btcsuite/btcd/btcutil v1.1.3 ++ github.com/celestiaorg/nmt v0.22.3 ++ github.com/cometbft/cometbft-db v0.7.0 ++ github.com/cometbft/cometbft-load-test v0.3.0 + github.com/fortytw2/leaktest v1.3.0 ++ github.com/go-git/go-git/v5 v5.13.1 + github.com/go-kit/kit v0.12.0 + github.com/go-kit/log v0.2.1 +- github.com/go-logfmt/logfmt v0.5.1 +- github.com/gofrs/uuid v4.3.0+incompatible +- github.com/golangci/golangci-lint v1.50.1 ++ github.com/go-logfmt/logfmt v0.6.0 ++ github.com/gofrs/uuid v4.4.0+incompatible ++ github.com/gogo/protobuf v1.3.2 ++ github.com/golang/mock v1.4.4 ++ github.com/golang/protobuf v1.5.3 + github.com/google/orderedcode v0.0.1 +- github.com/gorilla/websocket v1.5.0 ++ github.com/google/uuid v1.6.0 ++ github.com/gorilla/websocket v1.5.3 ++ github.com/grafana/otel-profiling-go v0.5.1 ++ github.com/grafana/pyroscope-go v1.1.2 + github.com/gtank/merlin v0.1.1 +- github.com/lib/pq v1.10.6 ++ github.com/lib/pq v1.10.9 + github.com/libp2p/go-buffer-pool v0.1.0 +- github.com/minio/highwayhash v1.0.2 ++ github.com/minio/highwayhash v1.0.3 + github.com/ory/dockertest v3.3.5+incompatible + github.com/pkg/errors v0.9.1 +- github.com/prometheus/client_golang v1.14.0 ++ github.com/prometheus/client_golang v1.20.3 + github.com/rcrowley/go-metrics v0.0.0-20201227073835-cf1acfcdf475 +- github.com/rs/cors v1.8.2 ++ github.com/rs/cors v1.8.3 + github.com/sasha-s/go-deadlock v0.3.1 + github.com/snikch/goodman v0.0.0-20171125024755-10e37e294daa +- github.com/spf13/cobra v1.8.0 +- github.com/spf13/viper v1.18.1 +- github.com/stretchr/testify v1.8.4 +- golang.org/x/crypto v0.21.0 +- golang.org/x/net v0.23.0 +- google.golang.org/grpc v1.60.0 +-) +- +-require github.com/google/uuid v1.4.0 +- +-require ( +- github.com/gogo/protobuf v1.3.2 +- github.com/informalsystems/tm-load-test v1.3.0 +-) +- +-require ( +- github.com/bufbuild/buf v1.9.0 +- github.com/creachadair/taskgroup v0.3.2 ++ github.com/spf13/cobra v1.8.1 ++ github.com/spf13/viper v1.15.0 ++ github.com/stretchr/testify v1.10.0 + github.com/syndtr/goleveldb v1.0.1-0.20210819022825-2ae1ddf74ef7 ++ go.opentelemetry.io/otel v1.30.0 ++ go.opentelemetry.io/otel/exporters/stdout/stdouttrace v1.18.0 ++ go.opentelemetry.io/otel/sdk v1.30.0 ++ golang.org/x/crypto v0.31.0 ++ golang.org/x/net v0.33.0 ++ golang.org/x/sync v0.10.0 ++ gonum.org/v1/gonum v0.12.0 ++ google.golang.org/grpc v1.66.0 ++ google.golang.org/protobuf v1.34.2 + ) + + require ( +- github.com/Masterminds/semver/v3 v3.2.0 +- github.com/btcsuite/btcd/btcec/v2 v2.2.1 +- github.com/btcsuite/btcd/btcutil v1.1.2 +- github.com/cometbft/cometbft-db v0.9.1 +- github.com/go-git/go-git/v5 v5.11.0 +- github.com/golang/protobuf v1.5.3 +- github.com/vektra/mockery/v2 v2.14.0 +- golang.org/x/sync v0.5.0 +- gonum.org/v1/gonum v0.8.2 +- google.golang.org/protobuf v1.31.0 +-) +- +-require ( +- 4d63.com/gochecknoglobals v0.1.0 // indirect + dario.cat/mergo v1.0.0 // indirect +- github.com/Abirdcfly/dupword v0.0.7 // indirect +- github.com/Antonboom/errname v0.1.7 // indirect +- github.com/Antonboom/nilnil v0.1.1 // indirect +- github.com/Azure/go-ansiterm v0.0.0-20210617225240-d185dfc1b5a1 // indirect +- github.com/Djarvur/go-err113 v0.0.0-20210108212216-aea10b59be24 // indirect +- github.com/GaijinEntertainment/go-exhaustruct/v2 v2.3.0 // indirect +- github.com/Masterminds/semver v1.5.0 // indirect ++ github.com/Azure/go-ansiterm v0.0.0-20230124172434-306776ec8161 // indirect + github.com/Microsoft/go-winio v0.6.1 // indirect + github.com/Nvveen/Gotty v0.0.0-20120604004816-cd527374f1e5 // indirect +- github.com/OpenPeeDeeP/depguard v1.1.1 // indirect +- github.com/ProtonMail/go-crypto v0.0.0-20230828082145-3c4c8a2d2371 // indirect +- github.com/alexkohler/prealloc v1.0.0 // indirect +- github.com/alingse/asasalint v0.0.11 // indirect +- github.com/ashanbrown/forbidigo v1.3.0 // indirect +- github.com/ashanbrown/makezero v1.1.1 // indirect ++ github.com/ProtonMail/go-crypto v1.1.3 // indirect + github.com/beorn7/perks v1.0.1 // indirect +- github.com/bkielbasa/cyclop v1.2.0 // indirect +- github.com/blizzy78/varnamelen v0.8.0 // indirect +- github.com/bombsimon/wsl/v3 v3.3.0 // indirect +- github.com/breml/bidichk v0.2.3 // indirect +- github.com/breml/errchkjson v0.3.0 // indirect +- github.com/bufbuild/connect-go v1.0.0 // indirect +- github.com/bufbuild/protocompile v0.1.0 // indirect +- github.com/butuzov/ireturn v0.1.1 // indirect + github.com/cenkalti/backoff v2.2.1+incompatible // indirect + github.com/cespare/xxhash v1.1.0 // indirect +- github.com/cespare/xxhash/v2 v2.2.0 // indirect +- github.com/charithe/durationcheck v0.0.9 // indirect +- github.com/chavacava/garif v0.0.0-20220630083739-93517212f375 // indirect ++ github.com/cespare/xxhash/v2 v2.3.0 // indirect + github.com/cloudflare/circl v1.3.7 // indirect +- github.com/containerd/containerd v1.6.8 // indirect + github.com/containerd/continuity v0.3.0 // indirect +- github.com/containerd/typeurl v1.0.2 // indirect + github.com/cosmos/go-bip39 v0.0.0-20180819234021-555e2067c45d // indirect +- github.com/cpuguy83/go-md2man/v2 v2.0.3 // indirect +- github.com/curioswitch/go-reassign v0.2.0 // indirect +- github.com/cyphar/filepath-securejoin v0.2.4 // indirect +- github.com/daixiang0/gci v0.8.1 // indirect ++ github.com/cyphar/filepath-securejoin v0.3.6 // indirect + github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc // indirect + github.com/decred/dcrd/dcrec/secp256k1/v4 v4.0.1 // indirect +- github.com/denis-tingaikin/go-header v0.4.3 // indirect + github.com/dgraph-io/badger/v2 v2.2007.4 // indirect +- github.com/dgraph-io/ristretto v0.0.3 // indirect ++ github.com/dgraph-io/ristretto v0.1.1 // indirect + github.com/dgryski/go-farm v0.0.0-20200201041132-a6ae2369ad13 // indirect +- github.com/docker/distribution v2.8.1+incompatible // indirect +- github.com/docker/docker v20.10.19+incompatible // indirect ++ github.com/docker/cli v23.0.1+incompatible // indirect ++ github.com/docker/docker v23.0.1+incompatible // indirect + github.com/docker/go-connections v0.4.0 // indirect + github.com/docker/go-units v0.5.0 // indirect + github.com/dustin/go-humanize v1.0.1 // indirect + github.com/emirpasic/gods v1.18.1 // indirect +- github.com/esimonov/ifshort v1.0.4 // indirect +- github.com/ettle/strcase v0.1.1 // indirect + github.com/facebookgo/ensure v0.0.0-20200202191622-63f1cf65ac4c // indirect + github.com/facebookgo/stack v0.0.0-20160209184415-751773369052 // indirect + github.com/facebookgo/subset v0.0.0-20200203212716-c811ad88dec4 // indirect +- github.com/fatih/color v1.14.1 // indirect +- github.com/fatih/structtag v1.2.0 // indirect +- github.com/firefart/nonamedreturns v1.0.4 // indirect + github.com/fsnotify/fsnotify v1.7.0 // indirect +- github.com/fzipp/gocyclo v0.6.0 // indirect +- github.com/go-chi/chi/v5 v5.0.7 // indirect +- github.com/go-critic/go-critic v0.6.5 // indirect + github.com/go-git/gcfg v1.5.1-0.20230307220236-3a3c6141e376 // indirect +- github.com/go-git/go-billy/v5 v5.5.0 // indirect +- github.com/go-logr/logr v1.2.3 // indirect ++ github.com/go-git/go-billy/v5 v5.6.1 // indirect ++ github.com/go-logr/logr v1.4.2 // indirect + github.com/go-logr/stdr v1.2.2 // indirect +- github.com/go-toolsmith/astcast v1.0.0 // indirect +- github.com/go-toolsmith/astcopy v1.0.2 // indirect +- github.com/go-toolsmith/astequal v1.0.3 // indirect +- github.com/go-toolsmith/astfmt v1.0.0 // indirect +- github.com/go-toolsmith/astp v1.0.0 // indirect +- github.com/go-toolsmith/strparse v1.0.0 // indirect +- github.com/go-toolsmith/typep v1.0.2 // indirect +- github.com/go-xmlfmt/xmlfmt v0.0.0-20191208150333-d5b6f63a941b // indirect +- github.com/gobwas/glob v0.2.3 // indirect +- github.com/gofrs/flock v0.8.1 // indirect ++ github.com/go-sql-driver/mysql v1.7.1 // indirect ++ github.com/golang/glog v1.2.1 // indirect + github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da // indirect + github.com/golang/snappy v0.0.4 // indirect +- github.com/golangci/check v0.0.0-20180506172741-cfe4005ccda2 // indirect +- github.com/golangci/dupl v0.0.0-20180902072040-3e9179ac440a // indirect +- github.com/golangci/go-misc v0.0.0-20220329215616-d24fe342adfe // indirect +- github.com/golangci/gofmt v0.0.0-20220901101216-f2edd75033f2 // indirect +- github.com/golangci/lint-1 v0.0.0-20191013205115-297bf364a8e0 // indirect +- github.com/golangci/maligned v0.0.0-20180506175553-b1d89398deca // indirect +- github.com/golangci/misspell v0.3.5 // indirect +- github.com/golangci/revgrep v0.0.0-20220804021717-745bb2f7c2e6 // indirect +- github.com/golangci/unconvert v0.0.0-20180507085042-28b1c447d1f4 // indirect + github.com/google/btree v1.1.2 // indirect +- github.com/google/go-cmp v0.6.0 // indirect +- github.com/gordonklaus/ineffassign v0.0.0-20210914165742-4cc7213b9bc8 // indirect +- github.com/gostaticanalysis/analysisutil v0.7.1 // indirect +- github.com/gostaticanalysis/comment v1.4.2 // indirect +- github.com/gostaticanalysis/forcetypeassert v0.1.0 // indirect +- github.com/gostaticanalysis/nilerr v0.1.1 // indirect +- github.com/gotestyourself/gotestyourself v1.4.0 // indirect +- github.com/grpc-ecosystem/go-grpc-middleware v1.3.0 // indirect ++ github.com/gotestyourself/gotestyourself v2.2.0+incompatible // indirect ++ github.com/grafana/pyroscope-go/godeltaprof v0.1.8 // indirect + github.com/gtank/ristretto255 v0.1.2 // indirect +- github.com/hashicorp/errwrap v1.1.0 // indirect +- github.com/hashicorp/go-multierror v1.1.1 // indirect +- github.com/hashicorp/go-version v1.6.0 // indirect + github.com/hashicorp/hcl v1.0.0 // indirect +- github.com/hexops/gotextdiff v1.0.3 // indirect + github.com/inconshreveable/mousetrap v1.1.0 // indirect + github.com/jbenet/go-context v0.0.0-20150711004518-d14ea06fba99 // indirect +- github.com/jdxcode/netrc v0.0.0-20210204082910-926c7f70242a // indirect +- github.com/jgautheron/goconst v1.5.1 // indirect +- github.com/jingyugao/rowserrcheck v1.1.1 // indirect +- github.com/jirfag/go-printf-func-name v0.0.0-20200119135958-7558a9eaa5af // indirect ++ github.com/jmespath/go-jmespath v0.4.0 // indirect + github.com/jmhodges/levigo v1.0.0 // indirect +- github.com/julz/importas v0.1.0 // indirect + github.com/kevinburke/ssh_config v1.2.0 // indirect +- github.com/kisielk/errcheck v1.6.2 // indirect +- github.com/kisielk/gotool v1.0.0 // indirect +- github.com/kkHAIKE/contextcheck v1.1.3 // indirect +- github.com/klauspost/compress v1.17.0 // indirect +- github.com/klauspost/pgzip v1.2.5 // indirect +- github.com/kulti/thelper v0.6.3 // indirect +- github.com/kunwardeep/paralleltest v1.0.6 // indirect +- github.com/kyoh86/exportloopref v0.1.8 // indirect +- github.com/ldez/gomoddirectives v0.2.3 // indirect +- github.com/ldez/tagliatelle v0.3.1 // indirect +- github.com/leonklingele/grouper v1.1.0 // indirect +- github.com/linxGnu/grocksdb v1.8.6 // indirect +- github.com/lufeee/execinquery v1.2.1 // indirect ++ github.com/klauspost/compress v1.17.9 // indirect + github.com/magiconair/properties v1.8.7 // indirect +- github.com/maratori/testableexamples v1.0.0 // indirect +- github.com/maratori/testpackage v1.1.0 // indirect +- github.com/matoous/godox v0.0.0-20210227103229-6504466cf951 // indirect +- github.com/mattn/go-colorable v0.1.13 // indirect +- github.com/mattn/go-isatty v0.0.17 // indirect +- github.com/mattn/go-runewidth v0.0.9 // indirect +- github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369 // indirect +- github.com/mbilski/exhaustivestruct v1.2.0 // indirect +- github.com/mgechev/revive v1.2.4 // indirect + github.com/mimoo/StrobeGo v0.0.0-20210601165009-122bf33a46e0 // indirect +- github.com/mitchellh/go-homedir v1.1.0 // indirect + github.com/mitchellh/mapstructure v1.5.0 // indirect +- github.com/moby/buildkit v0.10.4 // indirect +- github.com/moby/term v0.0.0-20220808134915-39b0c02b01ae // indirect +- github.com/moricho/tparallel v0.2.1 // indirect +- github.com/morikuni/aec v1.0.0 // indirect +- github.com/nakabonne/nestif v0.3.1 // indirect +- github.com/nbutton23/zxcvbn-go v0.0.0-20210217022336-fa2cb2858354 // indirect +- github.com/nishanths/exhaustive v0.8.3 // indirect +- github.com/nishanths/predeclared v0.2.2 // indirect +- github.com/olekukonko/tablewriter v0.0.5 // indirect ++ github.com/moby/term v0.0.0-20221205130635-1aeaba878587 // indirect ++ github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 // indirect ++ github.com/onsi/gomega v1.34.2 // indirect + github.com/opencontainers/go-digest v1.0.0 // indirect + github.com/opencontainers/image-spec v1.1.0-rc2 // indirect + github.com/opencontainers/runc v1.1.3 // indirect +- github.com/pelletier/go-toml/v2 v2.1.0 // indirect ++ github.com/pelletier/go-toml/v2 v2.2.3 // indirect + github.com/petermattis/goid v0.0.0-20180202154549-b0b1615b78e5 // indirect +- github.com/phayes/checkstyle v0.0.0-20170904204023-bfd46e6a821d // indirect + github.com/pjbgf/sha1cd v0.3.0 // indirect +- github.com/pkg/browser v0.0.0-20210911075715-681adbf594b8 // indirect +- github.com/pkg/profile v1.6.0 // indirect + github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2 // indirect +- github.com/polyfloyd/go-errorlint v1.0.5 // indirect +- github.com/prometheus/client_model v0.3.0 // indirect +- github.com/prometheus/common v0.37.0 // indirect +- github.com/prometheus/procfs v0.8.0 // indirect +- github.com/quasilyte/go-ruleguard v0.3.18 // indirect +- github.com/quasilyte/gogrep v0.0.0-20220828223005-86e4605de09f // indirect +- github.com/quasilyte/regex/syntax v0.0.0-20200407221936-30656e2c4a95 // indirect +- github.com/quasilyte/stdinfo v0.0.0-20220114132959-f7386bf02567 // indirect +- github.com/rs/zerolog v1.27.0 // indirect +- github.com/russross/blackfriday/v2 v2.1.0 // indirect +- github.com/ryancurrah/gomodguard v1.2.4 // indirect +- github.com/ryanrolds/sqlclosecheck v0.3.0 // indirect +- github.com/sagikazarmark/locafero v0.4.0 // indirect +- github.com/sagikazarmark/slog-shim v0.1.0 // indirect +- github.com/sanposhiho/wastedassign/v2 v2.0.6 // indirect +- github.com/sashamelentyev/interfacebloat v1.1.0 // indirect +- github.com/sashamelentyev/usestdlibvars v1.20.0 // indirect +- github.com/satori/go.uuid v1.2.0 // indirect +- github.com/securego/gosec/v2 v2.13.1 // indirect +- github.com/sergi/go-diff v1.2.0 // indirect +- github.com/shazow/go-diff v0.0.0-20160112020656-b6b7b6733b8c // indirect +- github.com/sirupsen/logrus v1.9.0 // indirect +- github.com/sivchari/containedctx v1.0.2 // indirect +- github.com/sivchari/nosnakecase v1.7.0 // indirect +- github.com/sivchari/tenv v1.7.0 // indirect +- github.com/skeema/knownhosts v1.2.1 // indirect +- github.com/sonatard/noctx v0.0.1 // indirect +- github.com/sourcegraph/conc v0.3.0 // indirect +- github.com/sourcegraph/go-diff v0.6.1 // indirect ++ github.com/prometheus/client_model v0.6.1 // indirect ++ github.com/prometheus/common v0.55.0 // indirect ++ github.com/prometheus/procfs v0.15.1 // indirect ++ github.com/sergi/go-diff v1.3.2-0.20230802210424-5b0b94c5c0d3 // indirect ++ github.com/sirupsen/logrus v1.9.3 // indirect ++ github.com/skeema/knownhosts v1.3.0 // indirect + github.com/spf13/afero v1.11.0 // indirect + github.com/spf13/cast v1.6.0 // indirect ++ github.com/spf13/jwalterweatherman v1.1.0 // indirect + github.com/spf13/pflag v1.0.5 // indirect +- github.com/ssgreg/nlreturn/v2 v2.2.1 // indirect +- github.com/stbenjam/no-sprintf-host-port v0.1.1 // indirect +- github.com/stretchr/objx v0.5.0 // indirect +- github.com/subosito/gotenv v1.6.0 // indirect +- github.com/tdakkota/asciicheck v0.1.1 // indirect ++ github.com/stretchr/objx v0.5.2 // indirect ++ github.com/subosito/gotenv v1.4.2 // indirect + github.com/tecbot/gorocksdb v0.0.0-20191217155057-f0fad39f321c // indirect +- github.com/tetafro/godot v1.4.11 // indirect +- github.com/timakin/bodyclose v0.0.0-20210704033933-f49887972144 // indirect +- github.com/timonwong/loggercheck v0.9.3 // indirect +- github.com/tomarrell/wrapcheck/v2 v2.7.0 // indirect +- github.com/tommy-muehle/go-mnd/v2 v2.5.1 // indirect +- github.com/ultraware/funlen v0.0.3 // indirect +- github.com/ultraware/whitespace v0.0.5 // indirect +- github.com/uudashr/gocognit v1.0.6 // indirect + github.com/xanzy/ssh-agent v0.3.3 // indirect +- github.com/yagipy/maintidx v1.0.0 // indirect +- github.com/yeya24/promlinter v0.2.0 // indirect +- gitlab.com/bosi/decorder v0.2.3 // indirect +- go.etcd.io/bbolt v1.3.8 // indirect +- go.opencensus.io v0.24.0 // indirect +- go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.36.3 // indirect +- go.opentelemetry.io/otel v1.11.0 // indirect +- go.opentelemetry.io/otel/metric v0.32.3 // indirect +- go.opentelemetry.io/otel/trace v1.11.0 // indirect +- go.uber.org/atomic v1.10.0 // indirect +- go.uber.org/multierr v1.9.0 // indirect +- go.uber.org/zap v1.23.0 // indirect +- golang.org/x/exp v0.0.0-20230905200255-921286631fa9 // indirect +- golang.org/x/exp/typeparams v0.0.0-20220827204233-334a2380cb91 // indirect +- golang.org/x/mod v0.12.0 // indirect +- golang.org/x/sys v0.18.0 // indirect +- golang.org/x/term v0.18.0 // indirect +- golang.org/x/text v0.14.0 // indirect +- golang.org/x/tools v0.13.0 // indirect +- google.golang.org/genproto/googleapis/rpc v0.0.0-20231120223509-83a465c0220f // indirect ++ go.etcd.io/bbolt v1.3.6 // indirect ++ go.opentelemetry.io/otel/metric v1.30.0 // indirect ++ go.opentelemetry.io/otel/trace v1.30.0 // indirect ++ golang.org/x/exp v0.0.0-20240904232852-e7e105dedf7e // indirect ++ golang.org/x/mod v0.21.0 // indirect ++ golang.org/x/sys v0.28.0 // indirect ++ golang.org/x/text v0.21.0 // indirect ++ golang.org/x/tools v0.24.0 // indirect ++ google.golang.org/genproto/googleapis/rpc v0.0.0-20240903143218-8af14fe29dc1 // indirect + gopkg.in/ini.v1 v1.67.0 // indirect + gopkg.in/warnings.v0 v0.1.2 // indirect +- gopkg.in/yaml.v2 v2.4.0 // indirect + gopkg.in/yaml.v3 v3.0.1 // indirect +- honnef.co/go/tools v0.3.3 // indirect +- mvdan.cc/gofumpt v0.4.0 // indirect +- mvdan.cc/interfacer v0.0.0-20180901003855-c20040233aed // indirect +- mvdan.cc/lint v0.0.0-20170908181259-adc824a0674b // indirect +- mvdan.cc/unparam v0.0.0-20220706161116-678bad134442 // indirect ++ gotest.tools v2.2.0+incompatible // indirect + ) diff --git a/patches/go.sum.patch b/patches/go.sum.patch new file mode 100644 index 00000000000..9f09f33bf3e --- /dev/null +++ b/patches/go.sum.patch @@ -0,0 +1,1553 @@ +diff --git a/go.sum b/go.sum +index 722450f8c..c9d170e78 100644 +--- a/go.sum ++++ b/go.sum +@@ -1,69 +1,16 @@ +-4d63.com/gochecknoglobals v0.1.0 h1:zeZSRqj5yCg28tCkIV/z/lWbwvNm5qnKVS15PI8nhD0= +-4d63.com/gochecknoglobals v0.1.0/go.mod h1:wfdC5ZjKSPr7CybKEcgJhUOgeAQW1+7WcyK8OvUilfo= +-cloud.google.com/go v0.26.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw= +-cloud.google.com/go v0.34.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw= +-cloud.google.com/go v0.38.0/go.mod h1:990N+gfupTy94rShfmMCWGDn0LpTmnzTp2qbd1dvSRU= +-cloud.google.com/go v0.44.1/go.mod h1:iSa0KzasP4Uvy3f1mN/7PiObzGgflwredwwASm/v6AU= +-cloud.google.com/go v0.44.2/go.mod h1:60680Gw3Yr4ikxnPRS/oxxkBccT6SA1yMk63TGekxKY= +-cloud.google.com/go v0.45.1/go.mod h1:RpBamKRgapWJb87xiFSdk4g1CME7QZg3uwTez+TSTjc= +-cloud.google.com/go v0.46.3/go.mod h1:a6bKKbmY7er1mI7TEI4lsAkts/mkhTSZK8w33B4RAg0= +-cloud.google.com/go v0.50.0/go.mod h1:r9sluTvynVuxRIOHXQEHMFffphuXHOMZMycpNR5e6To= +-cloud.google.com/go v0.52.0/go.mod h1:pXajvRH/6o3+F9jDHZWQ5PbGhn+o8w9qiu/CffaVdO4= +-cloud.google.com/go v0.53.0/go.mod h1:fp/UouUEsRkN6ryDKNW/Upv/JBKnv6WDthjR6+vze6M= +-cloud.google.com/go v0.54.0/go.mod h1:1rq2OEkV3YMf6n/9ZvGWI3GWw0VoqH/1x2nd8Is/bPc= +-cloud.google.com/go v0.56.0/go.mod h1:jr7tqZxxKOVYizybht9+26Z/gUq7tiRzu+ACVAMbKVk= +-cloud.google.com/go v0.57.0/go.mod h1:oXiQ6Rzq3RAkkY7N6t3TcE6jE+CIBBbA36lwQ1JyzZs= +-cloud.google.com/go v0.62.0/go.mod h1:jmCYTdRCQuc1PHIIJ/maLInMho30T/Y0M4hTdTShOYc= +-cloud.google.com/go v0.65.0/go.mod h1:O5N8zS7uWy9vkA9vayVHs65eM1ubvY4h553ofrNHObY= +-cloud.google.com/go v0.110.10 h1:LXy9GEO+timppncPIAZoOj3l58LIU9k+kn48AN7IO3Y= +-cloud.google.com/go/bigquery v1.0.1/go.mod h1:i/xbL2UlR5RvWAURpBYZTtm/cXjCha9lbfbpx4poX+o= +-cloud.google.com/go/bigquery v1.3.0/go.mod h1:PjpwJnslEMmckchkHFfq+HTD2DmtT67aNFKH1/VBDHE= +-cloud.google.com/go/bigquery v1.4.0/go.mod h1:S8dzgnTigyfTmLBfrtrhyYhwRxG72rYxvftPBK2Dvzc= +-cloud.google.com/go/bigquery v1.5.0/go.mod h1:snEHRnqQbz117VIFhE8bmtwIDY80NLUZUMb4Nv6dBIg= +-cloud.google.com/go/bigquery v1.7.0/go.mod h1://okPTzCYNXSlb24MZs83e2Do+h+VXtc4gLoIoXIAPc= +-cloud.google.com/go/bigquery v1.8.0/go.mod h1:J5hqkt3O0uAFnINi6JXValWIb1v0goeZM77hZzJN/fQ= +-cloud.google.com/go/compute v1.23.3 h1:6sVlXXBmbd7jNX0Ipq0trII3e4n1/MsADLK6a+aiVlk= +-cloud.google.com/go/compute v1.23.3/go.mod h1:VCgBUoMnIVIR0CscqQiPJLAG25E3ZRZMzcFZeQ+h8CI= +-cloud.google.com/go/compute/metadata v0.2.3 h1:mg4jlk7mCAj6xXp9UJ4fjI9VUI5rubuGBW5aJ7UnBMY= +-cloud.google.com/go/compute/metadata v0.2.3/go.mod h1:VAV5nSsACxMJvgaAuX6Pk2AawlZn8kiOGuCv6gTkwuA= +-cloud.google.com/go/datastore v1.0.0/go.mod h1:LXYbyblFSglQ5pkeyhO+Qmw7ukd3C+pD7TKLgZqpHYE= +-cloud.google.com/go/datastore v1.1.0/go.mod h1:umbIZjpQpHh4hmRpGhH4tLFup+FVzqBi1b3c64qFpCk= +-cloud.google.com/go/pubsub v1.0.1/go.mod h1:R0Gpsv3s54REJCy4fxDixWD93lHJMoZTyQ2kNxGRt3I= +-cloud.google.com/go/pubsub v1.1.0/go.mod h1:EwwdRX2sKPjnvnqCa270oGRyludottCI76h+R3AArQw= +-cloud.google.com/go/pubsub v1.2.0/go.mod h1:jhfEVHT8odbXTkndysNHCcx0awwzvfOlguIAii9o8iA= +-cloud.google.com/go/pubsub v1.3.1/go.mod h1:i+ucay31+CNRpDW4Lu78I4xXG+O1r/MAHgjpRVR+TSU= +-cloud.google.com/go/storage v1.0.0/go.mod h1:IhtSnM/ZTZV8YYJWCY8RULGVqBDmpoyjwiyrjsg+URw= +-cloud.google.com/go/storage v1.5.0/go.mod h1:tpKbwo567HUNpVclU5sGELwQWBDZ8gh0ZeosJ0Rtdos= +-cloud.google.com/go/storage v1.6.0/go.mod h1:N7U0C8pVQ/+NIKOBQyamJIeKQKkZ+mxpohlUTyfDhBk= +-cloud.google.com/go/storage v1.8.0/go.mod h1:Wv1Oy7z6Yz3DshWRJFhqM/UCfaWIRTdp0RXyy7KQOVs= +-cloud.google.com/go/storage v1.10.0/go.mod h1:FLPqc6j+Ki4BU591ie1oL6qBQGu2Bl/tZ9ullr3+Kg0= + dario.cat/mergo v1.0.0 h1:AGCNq9Evsj31mOgNPcLyXc+4PNABt905YmuqPYYpBWk= + dario.cat/mergo v1.0.0/go.mod h1:uNxQE+84aUszobStD9th8a29P2fMDhsBdgRYvZOxGmk= +-dmitri.shuralyov.com/gpu/mtl v0.0.0-20190408044501-666a987793e9/go.mod h1:H6x//7gZCb22OMCxBHrMx7a5I7Hp++hsVxbQ4BYO7hU= +-github.com/Abirdcfly/dupword v0.0.7 h1:z14n0yytA3wNO2gpCD/jVtp/acEXPGmYu0esewpBt6Q= +-github.com/Abirdcfly/dupword v0.0.7/go.mod h1:K/4M1kj+Zh39d2aotRwypvasonOyAMH1c/IZJzE0dmk= +-github.com/Antonboom/errname v0.1.7 h1:mBBDKvEYwPl4WFFNwec1CZO096G6vzK9vvDQzAwkako= +-github.com/Antonboom/errname v0.1.7/go.mod h1:g0ONh16msHIPgJSGsecu1G/dcF2hlYR/0SddnIAGavU= +-github.com/Antonboom/nilnil v0.1.1 h1:PHhrh5ANKFWRBh7TdYmyyq2gyT2lotnvFvvFbylF81Q= +-github.com/Antonboom/nilnil v0.1.1/go.mod h1:L1jBqoWM7AOeTD+tSquifKSesRHs4ZdaxvZR+xdJEaI= +-github.com/Azure/go-ansiterm v0.0.0-20210617225240-d185dfc1b5a1 h1:UQHMgLO+TxOElx5B5HZ4hJQsoJ/PvUvKRhJHDQXO8P8= +-github.com/Azure/go-ansiterm v0.0.0-20210617225240-d185dfc1b5a1/go.mod h1:xomTg63KZ2rFqZQzSB4Vz2SUXa1BpHTVz9L5PTmPC4E= ++github.com/Azure/go-ansiterm v0.0.0-20230124172434-306776ec8161 h1:L/gRVlceqvL25UVaW/CKtUDjefjrs0SPonmDGUVOYP0= ++github.com/Azure/go-ansiterm v0.0.0-20230124172434-306776ec8161/go.mod h1:xomTg63KZ2rFqZQzSB4Vz2SUXa1BpHTVz9L5PTmPC4E= + github.com/BurntSushi/toml v0.3.1/go.mod h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU= +-github.com/BurntSushi/toml v1.2.1 h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak= +-github.com/BurntSushi/toml v1.2.1/go.mod h1:CxXYINrC8qIiEnFrOxCa7Jy5BFHlXnUU2pbicEuybxQ= +-github.com/BurntSushi/xgb v0.0.0-20160522181843-27f122750802/go.mod h1:IVnqGOEym/WlBOVXweHU+Q+/VP0lqqI8lqeDx9IjBqo= ++github.com/BurntSushi/toml v1.4.1-0.20240526193622-a339e1f7089c h1:pxW6RcqyfI9/kWtOwnv/G+AzdKuy2ZrqINhenH4HyNs= ++github.com/BurntSushi/toml v1.4.1-0.20240526193622-a339e1f7089c/go.mod h1:ukJfTF/6rtPPRCnwkur4qwRxa8vTRFBF0uk2lLoLwho= + github.com/ChainSafe/go-schnorrkel v1.0.0 h1:3aDA67lAykLaG1y3AOjs88dMxC88PgUuHRrLeDnvGIM= + github.com/ChainSafe/go-schnorrkel v1.0.0/go.mod h1:dpzHYVxLZcp8pjlV+O+UR8K0Hp/z7vcchBSbMBEhCw4= + github.com/DATA-DOG/go-sqlmock v1.5.0 h1:Shsta01QNfFxHCfpW6YH2STWB0MudeXXEWMr20OEh60= + github.com/DATA-DOG/go-sqlmock v1.5.0/go.mod h1:f/Ixk793poVmq4qj/V1dPUg2JEAKC73Q5eFN3EC/SaM= +-github.com/Djarvur/go-err113 v0.0.0-20210108212216-aea10b59be24 h1:sHglBQTwgx+rWPdisA5ynNEsoARbiCBOyGcJM4/OzsM= +-github.com/Djarvur/go-err113 v0.0.0-20210108212216-aea10b59be24/go.mod h1:4UJr5HIiMZrwgkSPdsjy2uOQExX/WEILpIrO9UPGuXs= +-github.com/GaijinEntertainment/go-exhaustruct/v2 v2.3.0 h1:+r1rSv4gvYn0wmRjC8X7IAzX8QezqtFV9m0MUHFJgts= +-github.com/GaijinEntertainment/go-exhaustruct/v2 v2.3.0/go.mod h1:b3g59n2Y+T5xmcxJL+UEG2f8cQploZm1mR/v6BW0mU0= +-github.com/Masterminds/semver v1.5.0 h1:H65muMkzWKEuNDnfl9d70GUjFniHKHRbFPGBuZ3QEww= +-github.com/Masterminds/semver v1.5.0/go.mod h1:MB6lktGJrhw8PrUyiEoblNEGEQ+RzHPF078ddwwvV3Y= +-github.com/Masterminds/semver/v3 v3.2.0 h1:3MEsd0SM6jqZojhjLWWeBY+Kcjy9i6MQAeY7YgDP83g= +-github.com/Masterminds/semver/v3 v3.2.0/go.mod h1:qvl/7zhW3nngYb5+80sSMF+FG2BjYrf8m9wsX0PNOMQ= ++github.com/Masterminds/semver/v3 v3.3.0 h1:B8LGeaivUe71a5qox1ICM/JLl0NqZSW5CHyL+hmvYS0= ++github.com/Masterminds/semver/v3 v3.3.0/go.mod h1:4V+yj/TJE1HU9XfppCwVMZq3I84lprf4nC11bSS5beM= + github.com/Microsoft/go-winio v0.5.2/go.mod h1:WpS1mjBmmwHBEWmogvA2mj8546UReBk4v8QkMxJ6pZY= + github.com/Microsoft/go-winio v0.6.1 h1:9/kr64B9VUZrLm5YYwbGtUJnMgqWVOdUAXu6Migciow= + github.com/Microsoft/go-winio v0.6.1/go.mod h1:LRdKpFKfdobln8UmuiYcKPot9D2v6svN5+sAH+4kjUM= +@@ -71,10 +18,8 @@ github.com/Nvveen/Gotty v0.0.0-20120604004816-cd527374f1e5 h1:TngWCqHvy9oXAN6lEV + github.com/Nvveen/Gotty v0.0.0-20120604004816-cd527374f1e5/go.mod h1:lmUJ/7eu/Q8D7ML55dXQrVaamCz2vxCfdQBasLZfHKk= + github.com/OneOfOne/xxhash v1.2.2 h1:KMrpdQIwFcEqXDklaen+P1axHaj9BSKzvpUUfnHldSE= + github.com/OneOfOne/xxhash v1.2.2/go.mod h1:HSdplMjZKSmBqAxg5vPj2TmRDmfkzw+cTzAElWljhcU= +-github.com/OpenPeeDeeP/depguard v1.1.1 h1:TSUznLjvp/4IUP+OQ0t/4jF4QUyxIcVX8YnghZdunyA= +-github.com/OpenPeeDeeP/depguard v1.1.1/go.mod h1:JtAMzWkmFEzDPyAd+W0NHl1lvpQKTvT9jnRVsohBKpc= +-github.com/ProtonMail/go-crypto v0.0.0-20230828082145-3c4c8a2d2371 h1:kkhsdkhsCvIsutKu5zLMgWtgh9YxGCNAw8Ad8hjwfYg= +-github.com/ProtonMail/go-crypto v0.0.0-20230828082145-3c4c8a2d2371/go.mod h1:EjAoLdwvbIOoOQr3ihjnSoLZRtE8azugULFRteWMNc0= ++github.com/ProtonMail/go-crypto v1.1.3 h1:nRBOetoydLeUb4nHajyO2bKqMLfWQ/ZPwkXqXxPxCFk= ++github.com/ProtonMail/go-crypto v1.1.3/go.mod h1:rA3QumHc/FZ8pAHreoekgiAbzpNsfQAosU5td4SnOrE= + github.com/VividCortex/gohistogram v1.0.0 h1:6+hBz+qvs0JOrrNhhmR7lFxo5sINxBCGXrdtl/UvroE= + github.com/VividCortex/gohistogram v1.0.0/go.mod h1:Pf5mBqqDxYaXu3hDrrU+w6nw50o/4+TcAqDqk/vUH7g= + github.com/Workiva/go-datastructures v1.0.53 h1:J6Y/52yX10Xc5JjXmGtWoSSxs3mZnGSaq37xZZh7Yig= +@@ -82,53 +27,27 @@ github.com/Workiva/go-datastructures v1.0.53/go.mod h1:1yZL+zfsztete+ePzZz/Zb1/t + github.com/adlio/schema v1.3.3 h1:oBJn8I02PyTB466pZO1UZEn1TV5XLlifBSyMrmHl/1I= + github.com/adlio/schema v1.3.3/go.mod h1:1EsRssiv9/Ce2CMzq5DoL7RiMshhuigQxrR4DMV9fHg= + github.com/aead/siphash v1.0.1/go.mod h1:Nywa3cDsYNNK3gaciGTWPwHt0wlpNV15vwmswBAUSII= +-github.com/ajstarks/svgo v0.0.0-20180226025133-644b8db467af/go.mod h1:K08gAheRH3/J6wwsYMMT4xOr94bZjxIelGM0+d/wbFw= +-github.com/alecthomas/template v0.0.0-20160405071501-a0175ee3bccc/go.mod h1:LOuyumcjzFXgccqObfd/Ljyb9UuFJ6TxHnclSeseNhc= +-github.com/alecthomas/template v0.0.0-20190718012654-fb15b899a751/go.mod h1:LOuyumcjzFXgccqObfd/Ljyb9UuFJ6TxHnclSeseNhc= +-github.com/alecthomas/units v0.0.0-20151022065526-2efee857e7cf/go.mod h1:ybxpYRFXyAe+OPACYpWeL0wqObRcbAqCMya13uyzqw0= +-github.com/alecthomas/units v0.0.0-20190717042225-c3de453c63f4/go.mod h1:ybxpYRFXyAe+OPACYpWeL0wqObRcbAqCMya13uyzqw0= +-github.com/alecthomas/units v0.0.0-20190924025748-f65c72e2690d/go.mod h1:rBZYJk541a8SKzHPHnH3zbiI+7dagKZ0cgpgrD7Fyho= +-github.com/alexkohler/prealloc v1.0.0 h1:Hbq0/3fJPQhNkN0dR95AVrr6R7tou91y0uHG5pOcUuw= +-github.com/alexkohler/prealloc v1.0.0/go.mod h1:VetnK3dIgFBBKmg0YnD9F9x6Icjd+9cvfHR56wJVlKE= +-github.com/alingse/asasalint v0.0.11 h1:SFwnQXJ49Kx/1GghOFz1XGqHYKp21Kq1nHad/0WQRnw= +-github.com/alingse/asasalint v0.0.11/go.mod h1:nCaoMhw7a9kSJObvQyVzNTPBDbNpdocqrSP7t/cW5+I= + github.com/anmitsu/go-shlex v0.0.0-20200514113438-38f4b401e2be h1:9AeTilPcZAjCFIImctFaOjnTIavg87rW78vTPkQqLI8= + github.com/anmitsu/go-shlex v0.0.0-20200514113438-38f4b401e2be/go.mod h1:ySMOLuWl6zY27l47sB3qLNK6tF2fkHG55UZxx8oIVo4= + github.com/armon/consul-api v0.0.0-20180202201655-eb2c6b5be1b6/go.mod h1:grANhF5doyWs3UAsr3K4I6qtAmlQcZDesFNEHPZAzj8= + github.com/armon/go-socks5 v0.0.0-20160902184237-e75332964ef5 h1:0CwZNZbxp69SHPdPJAN/hZIm0C4OItdklCFmMRWYpio= + github.com/armon/go-socks5 v0.0.0-20160902184237-e75332964ef5/go.mod h1:wHh0iHkYZB8zMSxRWpUBQtwG5a7fFgvEO+odwuTv2gs= +-github.com/ashanbrown/forbidigo v1.3.0 h1:VkYIwb/xxdireGAdJNZoo24O4lmnEWkactplBlWTShc= +-github.com/ashanbrown/forbidigo v1.3.0/go.mod h1:vVW7PEdqEFqapJe95xHkTfB1+XvZXBFg8t0sG2FIxmI= +-github.com/ashanbrown/makezero v1.1.1 h1:iCQ87C0V0vSyO+M9E/FZYbu65auqH0lnsOkf5FcB28s= +-github.com/ashanbrown/makezero v1.1.1/go.mod h1:i1bJLCRSCHOcOa9Y6MyF2FTfMZMFdHvxKHxgO5Z1axI= +-github.com/benbjohnson/clock v1.3.0 h1:ip6w0uFQkncKQ979AypyG0ER7mqUSBdKLOgAle/AT8A= +-github.com/benbjohnson/clock v1.3.0/go.mod h1:J11/hYXuz8f4ySSvYwY0FKfm+ezbsZBKZxNJlLklBHA= +-github.com/beorn7/perks v0.0.0-20180321164747-3a771d992973/go.mod h1:Dwedo/Wpr24TaqPxmxbtue+5NUziq4I4S80YR8gNf3Q= +-github.com/beorn7/perks v1.0.0/go.mod h1:KWe93zE9D1o94FZ5RNwFwVgaQK1VOXiVxmqh+CedLV8= ++github.com/aws/aws-sdk-go v1.40.45 h1:QN1nsY27ssD/JmW4s83qmSb+uL6DG4GmCDzjmJB4xUI= ++github.com/aws/aws-sdk-go v1.40.45/go.mod h1:585smgzpB/KqRA+K3y/NL/oYRqQvpNJYvLm+LY1U59Q= + github.com/beorn7/perks v1.0.1 h1:VlbKKnNfV8bJzeqoa4cOKqO6bYr3WgKZxO8Z16+hsOM= + github.com/beorn7/perks v1.0.1/go.mod h1:G2ZrVWU2WbWT9wwq4/hrbKbnv/1ERSJQ0ibhJ6rlkpw= +-github.com/bkielbasa/cyclop v1.2.0 h1:7Jmnh0yL2DjKfw28p86YTd/B4lRGcNuu12sKE35sM7A= +-github.com/bkielbasa/cyclop v1.2.0/go.mod h1:qOI0yy6A7dYC4Zgsa72Ppm9kONl0RoIlPbzot9mhmeI= +-github.com/blizzy78/varnamelen v0.8.0 h1:oqSblyuQvFsW1hbBHh1zfwrKe3kcSj0rnXkKzsQ089M= +-github.com/blizzy78/varnamelen v0.8.0/go.mod h1:V9TzQZ4fLJ1DSrjVDfl89H7aMnTvKkApdHeyESmyR7k= +-github.com/bombsimon/wsl/v3 v3.3.0 h1:Mka/+kRLoQJq7g2rggtgQsjuI/K5Efd87WX96EWFxjM= +-github.com/bombsimon/wsl/v3 v3.3.0/go.mod h1:st10JtZYLE4D5sC7b8xV4zTKZwAQjCH/Hy2Pm1FNZIc= +-github.com/breml/bidichk v0.2.3 h1:qe6ggxpTfA8E75hdjWPZ581sY3a2lnl0IRxLQFelECI= +-github.com/breml/bidichk v0.2.3/go.mod h1:8u2C6DnAy0g2cEq+k/A2+tr9O1s+vHGxWn0LTc70T2A= +-github.com/breml/errchkjson v0.3.0 h1:YdDqhfqMT+I1vIxPSas44P+9Z9HzJwCeAzjB8PxP1xw= +-github.com/breml/errchkjson v0.3.0/go.mod h1:9Cogkyv9gcT8HREpzi3TiqBxCqDzo8awa92zSDFcofU= + github.com/btcsuite/btcd v0.20.1-beta/go.mod h1:wVuoA8VJLEcwgqHBwHmzLRazpKxTv13Px/pDuV7OomQ= + github.com/btcsuite/btcd v0.22.0-beta.0.20220111032746-97732e52810c/go.mod h1:tjmYdS6MLJ5/s0Fj4DbLgSbDHbEqLJrtnHecBFkdz5M= + github.com/btcsuite/btcd v0.23.0 h1:V2/ZgjfDFIygAX3ZapeigkVBoVUtOJKSwrhZdlpSvaA= + github.com/btcsuite/btcd v0.23.0/go.mod h1:0QJIIN1wwIXF/3G/m87gIwGniDMDQqjVn4SZgnFpsYY= + github.com/btcsuite/btcd/btcec/v2 v2.1.0/go.mod h1:2VzYrv4Gm4apmbVVsSq5bqf1Ec8v56E48Vt0Y/umPgA= + github.com/btcsuite/btcd/btcec/v2 v2.1.3/go.mod h1:ctjw4H1kknNJmRN4iP1R7bTQ+v3GJkZBd6mui8ZsAZE= +-github.com/btcsuite/btcd/btcec/v2 v2.2.1 h1:xP60mv8fvp+0khmrN0zTdPC3cNm24rfeE6lh2R/Yv3E= +-github.com/btcsuite/btcd/btcec/v2 v2.2.1/go.mod h1:9/CSmJxmuvqzX9Wh2fXMWToLOHhPd11lSPuIupwTkI8= ++github.com/btcsuite/btcd/btcec/v2 v2.3.4 h1:3EJjcN70HCu/mwqlUsGK8GcNVyLVxFDlWurTXGPFfiQ= ++github.com/btcsuite/btcd/btcec/v2 v2.3.4/go.mod h1:zYzJ8etWJQIv1Ogk7OzpWjowwOdXY1W/17j2MW85J04= + github.com/btcsuite/btcd/btcutil v1.0.0/go.mod h1:Uoxwv0pqYWhD//tfTiipkxNfdhG9UrLwaeswfjfdF0A= + github.com/btcsuite/btcd/btcutil v1.1.0/go.mod h1:5OapHB7A2hBBWLm48mmw4MOHNJCcUBTwmWH/0Jn8VHE= +-github.com/btcsuite/btcd/btcutil v1.1.2 h1:XLMbX8JQEiwMcYft2EGi8zPUkoa0abKIU6/BJSRsjzQ= +-github.com/btcsuite/btcd/btcutil v1.1.2/go.mod h1:UR7dsSJzJUfMmFiiLlIrMq1lS9jh9EdCV7FStZSnpi0= ++github.com/btcsuite/btcd/btcutil v1.1.3 h1:xfbtw8lwpp0G6NwSHb+UE67ryTFHJAiNuipusjXSohQ= ++github.com/btcsuite/btcd/btcutil v1.1.3/go.mod h1:UR7dsSJzJUfMmFiiLlIrMq1lS9jh9EdCV7FStZSnpi0= + github.com/btcsuite/btcd/chaincfg/chainhash v1.0.0/go.mod h1:7SFka0XMvUgj3hfZtydOrQY2mwhPclbT2snogU7SQQc= + github.com/btcsuite/btcd/chaincfg/chainhash v1.0.1 h1:q0rUy8C/TYNBQS1+CGKw68tLOFYSNEs0TFnxxnS9+4U= + github.com/btcsuite/btcd/chaincfg/chainhash v1.0.1/go.mod h1:7SFka0XMvUgj3hfZtydOrQY2mwhPclbT2snogU7SQQc= +@@ -141,77 +60,40 @@ github.com/btcsuite/snappy-go v0.0.0-20151229074030-0bdef8d06723/go.mod h1:8woku + github.com/btcsuite/snappy-go v1.0.0/go.mod h1:8woku9dyThutzjeg+3xrA5iCpBRH8XEEg3lh6TiUghc= + github.com/btcsuite/websocket v0.0.0-20150119174127-31079b680792/go.mod h1:ghJtEyQwv5/p4Mg4C0fgbePVuGr935/5ddU9Z3TmDRY= + github.com/btcsuite/winsvc v1.0.0/go.mod h1:jsenWakMcC0zFBFurPLEAyrnc/teJEM1O46fmI40EZs= +-github.com/bufbuild/buf v1.9.0 h1:8a60qapVuRj6crerWR0rny4UUV/MhZSL5gagJuBxmx8= +-github.com/bufbuild/buf v1.9.0/go.mod h1:1Q+rMHiMVcfgScEF/GOldxmu4o9TrQ2sQQh58K6MscE= +-github.com/bufbuild/connect-go v1.0.0 h1:htSflKUT8y1jxhoPhPYTZMrsY3ipUXjjrbcZR5O2cVo= +-github.com/bufbuild/connect-go v1.0.0/go.mod h1:9iNvh/NOsfhNBUH5CtvXeVUskQO1xsrEviH7ZArwZ3I= +-github.com/bufbuild/protocompile v0.1.0 h1:HjgJBI85hY/qmW5tw/66sNDZ7z0UDdVSi/5r40WHw4s= +-github.com/bufbuild/protocompile v0.1.0/go.mod h1:ix/MMMdsT3fzxfw91dvbfzKW3fRRnuPCP47kpAm5m/4= +-github.com/butuzov/ireturn v0.1.1 h1:QvrO2QF2+/Cx1WA/vETCIYBKtRjc30vesdoPUNo1EbY= +-github.com/butuzov/ireturn v0.1.1/go.mod h1:Wh6Zl3IMtTpaIKbmwzqi6olnM9ptYQxxVacMsOEFPoc= +-github.com/bwesterb/go-ristretto v1.2.3/go.mod h1:fUIoIZaG73pV5biE2Blr2xEzDoMj7NFEuV9ekS419A0= ++github.com/celestiaorg/nmt v0.22.3 h1:5k+fG7rF6zDcyyJgwr57usAFwL0h1jy+b79qDuTE3ko= ++github.com/celestiaorg/nmt v0.22.3/go.mod h1:kYfIjRq5rmA2mJnv41GLWkxn5KyLNPlma3v5Q68rHdI= + github.com/cenkalti/backoff v2.2.1+incompatible h1:tNowT99t7UNflLxfYYSlKYsBpXdEet03Pg2g16Swow4= + github.com/cenkalti/backoff v2.2.1+incompatible/go.mod h1:90ReRw6GdpyfrHakVjL/QHaoyV4aDUVVkXQJJJ3NXXM= + github.com/cenkalti/backoff/v4 v4.1.3 h1:cFAlzYUlVYDysBEH2T5hyJZMh3+5+WCBvSnK6Q8UtC4= + github.com/cenkalti/backoff/v4 v4.1.3/go.mod h1:scbssz8iZGpm3xbr14ovlUdkxfGXNInqkPWOWmG2CLw= +-github.com/census-instrumentation/opencensus-proto v0.2.1/go.mod h1:f6KPmirojxKA12rnyqOA5BBL4O983OfeGPqjHWSTneU= + github.com/cespare/xxhash v1.1.0 h1:a6HrQnmkObjyL+Gs60czilIUGqrzKutQD6XZog3p+ko= + github.com/cespare/xxhash v1.1.0/go.mod h1:XrSqR1VqqWfGrhpAt58auRo0WTKS1nRRg3ghfAqPWnc= + github.com/cespare/xxhash/v2 v2.1.1/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs= +-github.com/cespare/xxhash/v2 v2.1.2/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs= +-github.com/cespare/xxhash/v2 v2.2.0 h1:DC2CZ1Ep5Y4k3ZQ899DldepgrayRUGE6BBZ/cd9Cj44= +-github.com/cespare/xxhash/v2 v2.2.0/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs= +-github.com/charithe/durationcheck v0.0.9 h1:mPP4ucLrf/rKZiIG/a9IPXHGlh8p4CzgpyTy6EEutYk= +-github.com/charithe/durationcheck v0.0.9/go.mod h1:SSbRIBVfMjCi/kEB6K65XEA83D6prSM8ap1UCpNKtgg= +-github.com/chavacava/garif v0.0.0-20220630083739-93517212f375 h1:E7LT642ysztPWE0dfz43cWOvMiF42DyTRC+eZIaO4yI= +-github.com/chavacava/garif v0.0.0-20220630083739-93517212f375/go.mod h1:4m1Rv7xfuwWPNKXlThldNuJvutYM6J95wNuuVmn55To= ++github.com/cespare/xxhash/v2 v2.3.0 h1:UL815xU9SqsFlibzuggzjXhog7bL6oX9BbNZnL2UFvs= ++github.com/cespare/xxhash/v2 v2.3.0/go.mod h1:VGX0DQ3Q6kWi7AoAeZDth3/j3BFtOZR5XLFGgcrjCOs= + github.com/checkpoint-restore/go-criu/v5 v5.3.0/go.mod h1:E/eQpaFtUKGOOSEBZgmKAcn+zUUwWxqcaKZlF54wK8E= +-github.com/chzyer/logex v1.1.10/go.mod h1:+Ywpsq7O8HXn0nuIou7OrIPyXbp3wmkHB+jjWRnGsAI= +-github.com/chzyer/readline v0.0.0-20180603132655-2972be24d48e/go.mod h1:nSuG5e5PlCu98SY8svDHJxuZscDgtXS6KTTbou5AhLI= +-github.com/chzyer/test v0.0.0-20180213035817-a1ea475d72b1/go.mod h1:Q3SI9o4m/ZMnBNeIyt5eFwwo7qiLfzFZmjNmxjkiQlU= + github.com/cilium/ebpf v0.7.0/go.mod h1:/oI2+1shJiTGAMgl6/RgJr36Eo1jzrRcAWbcXO2usCA= +-github.com/client9/misspell v0.3.4/go.mod h1:qj6jICC3Q7zFZvVWo7KLAzC3yx5G7kyvSDkc90ppPyw= +-github.com/cloudflare/circl v1.3.3/go.mod h1:5XYMA4rFBvNIrhs50XuiBJ15vF2pZn4nnUKZrLbUZFA= + github.com/cloudflare/circl v1.3.7 h1:qlCDlTPz2n9fu58M0Nh1J/JzcFpfgkFHHX3O35r5vcU= + github.com/cloudflare/circl v1.3.7/go.mod h1:sRTcRWXGLrKw6yIGJ+l7amYJFfAXbZG0kBSc8r4zxgA= +-github.com/cncf/udpa/go v0.0.0-20191209042840-269d4d468f6f/go.mod h1:M8M6+tZqaGXZJjfX53e64911xZQV5JYwmTeXPW+k8Sc= +-github.com/cncf/xds/go v0.0.0-20230607035331-e9ce68804cb4 h1:/inchEIKaYC1Akx+H+gqO04wryn5h75LSazbRlnya1k= +-github.com/cncf/xds/go v0.0.0-20230607035331-e9ce68804cb4/go.mod h1:eXthEFrGJvWHgFFCl3hGmgk+/aYT6PnTQLykKQRLhEs= + github.com/cometbft/cometbft-db v0.7.0 h1:uBjbrBx4QzU0zOEnU8KxoDl18dMNgDh+zZRUE0ucsbo= + github.com/cometbft/cometbft-db v0.7.0/go.mod h1:yiKJIm2WKrt6x8Cyxtq9YTEcIMPcEe4XPxhgX59Fzf0= +-github.com/cometbft/cometbft-db v0.9.1 h1:MIhVX5ja5bXNHF8EYrThkG9F7r9kSfv8BX4LWaxWJ4M= +-github.com/cometbft/cometbft-db v0.9.1/go.mod h1:iliyWaoV0mRwBJoizElCwwRA9Tf7jZJOURcRZF9m60U= ++github.com/cometbft/cometbft-load-test v0.3.0 h1:z6iZZvFwhci29ca/EZQaWh/d92NLe8bK4eBvFyv2EKY= ++github.com/cometbft/cometbft-load-test v0.3.0/go.mod h1:zKrQpRm3Ay5+RfeRTNWoLniFJNIPnw9JPEM1wuWS3TA= + github.com/containerd/console v1.0.3/go.mod h1:7LqA/THxQ86k76b8c/EMSiaJ3h1eZkMkXar0TQ1gf3U= +-github.com/containerd/containerd v1.6.8 h1:h4dOFDwzHmqFEP754PgfgTeVXFnLiRc6kiqC7tplDJs= +-github.com/containerd/containerd v1.6.8/go.mod h1:By6p5KqPK0/7/CgO/A6t/Gz+CUYUu2zf1hUaaymVXB0= + github.com/containerd/continuity v0.3.0 h1:nisirsYROK15TAMVukJOUyGJjz4BNQJBVsNvAXZJ/eg= + github.com/containerd/continuity v0.3.0/go.mod h1:wJEAIwKOm/pBZuBd0JmeTvnLquTB1Ag8espWhkykbPM= +-github.com/containerd/typeurl v1.0.2 h1:Chlt8zIieDbzQFzXzAeBEF92KhExuE4p9p92/QmY7aY= +-github.com/containerd/typeurl v1.0.2/go.mod h1:9trJWW2sRlGub4wZJRTW83VtbOLS6hwcDZXTn6oPz9s= + github.com/coreos/etcd v3.3.10+incompatible/go.mod h1:uF7uidLiAD3TWHmW31ZFd/JWoc32PjwdhPthX9715RE= + github.com/coreos/go-etcd v2.0.0+incompatible/go.mod h1:Jez6KQU2B/sWsbdaef3ED8NzMklzPG4d5KIOhIy30Tk= + github.com/coreos/go-semver v0.2.0/go.mod h1:nnelYz7RCh+5ahJtPPxZlU+153eP4D4r3EedlOD2RNk= + github.com/coreos/go-systemd/v22 v22.3.2/go.mod h1:Y58oyj3AT4RCenI/lSvhwexgC+NSVTIJ3seZv2GcEnc= +-github.com/coreos/go-systemd/v22 v22.3.3-0.20220203105225-a9a7ef127534/go.mod h1:Y58oyj3AT4RCenI/lSvhwexgC+NSVTIJ3seZv2GcEnc= + github.com/cosmos/go-bip39 v0.0.0-20180819234021-555e2067c45d h1:49RLWk1j44Xu4fjHb6JFYmeUnDORVwHNkDxaQ0ctCVU= + github.com/cosmos/go-bip39 v0.0.0-20180819234021-555e2067c45d/go.mod h1:tSxLoYXyBmiFeKpvmq4dzayMdCjCnu8uqmCysIGBT2Y= + github.com/cpuguy83/go-md2man v1.0.10/go.mod h1:SmD6nW6nTyfqj6ABTjUi3V3JVMnlJmwcJI5acqYI6dE= + github.com/cpuguy83/go-md2man/v2 v2.0.0-20190314233015-f79a8a8ca69d/go.mod h1:maD7wRr/U5Z6m/iR4s+kqSMx2CaBsrgA7czyZG/E6dU= +-github.com/cpuguy83/go-md2man/v2 v2.0.3 h1:qMCsGGgs+MAzDFyp9LpAe1Lqy/fY/qCovCm0qnXZOBM= +-github.com/cpuguy83/go-md2man/v2 v2.0.3/go.mod h1:tgQtvFlXSQOSOSIRvRPT7W67SCa46tRHOmNcaadrF8o= +-github.com/creachadair/taskgroup v0.3.2 h1:zlfutDS+5XG40AOxcHDSThxKzns8Tnr9jnr6VqkYlkM= +-github.com/creachadair/taskgroup v0.3.2/go.mod h1:wieWwecHVzsidg2CsUnFinW1faVN4+kq+TDlRJQ0Wbk= +-github.com/creack/pty v1.1.9/go.mod h1:oKZEueFk5CKHvIhNR5MUki03XCEU+Q6VDXinZuGJ33E= +-github.com/creack/pty v1.1.11 h1:07n33Z8lZxZ2qwegKbObQohDhXDQxiMMz1NOUGYlesw= +-github.com/creack/pty v1.1.11/go.mod h1:oKZEueFk5CKHvIhNR5MUki03XCEU+Q6VDXinZuGJ33E= +-github.com/cristalhq/acmd v0.8.1/go.mod h1:LG5oa43pE/BbxtfMoImHCQN++0Su7dzipdgBjMCBVDQ= +-github.com/curioswitch/go-reassign v0.2.0 h1:G9UZyOcpk/d7Gd6mqYgd8XYWFMw/znxwGDUstnC9DIo= +-github.com/curioswitch/go-reassign v0.2.0/go.mod h1:x6OpXuWvgfQaMGks2BZybTngWjT84hqJfKoO8Tt/Roc= ++github.com/cpuguy83/go-md2man/v2 v2.0.4/go.mod h1:tgQtvFlXSQOSOSIRvRPT7W67SCa46tRHOmNcaadrF8o= + github.com/cyphar/filepath-securejoin v0.2.3/go.mod h1:aPGpWjXOXUn2NCNjFvBE6aRxGGx79pTxQpKOJNYHHl4= +-github.com/cyphar/filepath-securejoin v0.2.4 h1:Ugdm7cg7i6ZK6x3xDF1oEu1nfkyfH53EtKeQYTC3kyg= +-github.com/cyphar/filepath-securejoin v0.2.4/go.mod h1:aPGpWjXOXUn2NCNjFvBE6aRxGGx79pTxQpKOJNYHHl4= +-github.com/daixiang0/gci v0.8.1 h1:T4xpSC+hmsi4CSyuYfIJdMZAr9o7xZmHpQVygMghGZ4= +-github.com/daixiang0/gci v0.8.1/go.mod h1:EpVfrztufwVgQRXjnX4zuNinEpLj5OmMjtu/+MB0V0c= ++github.com/cyphar/filepath-securejoin v0.3.6 h1:4d9N5ykBnSp5Xn2JkhocYDkOpURL/18CYMpo6xB9uWM= ++github.com/cyphar/filepath-securejoin v0.3.6/go.mod h1:Sdj7gXlvMcPZsbhwhQ33GguGLDGQL7h7bg04C/+u9jI= + github.com/davecgh/go-spew v0.0.0-20171005155431-ecdeabc65495/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= + github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= + github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= +@@ -222,62 +104,38 @@ github.com/decred/dcrd/crypto/blake256 v1.0.0/go.mod h1:sQl2p6Y26YV+ZOcSTP6thNdn + github.com/decred/dcrd/dcrec/secp256k1/v4 v4.0.1 h1:YLtO71vCjJRCBcrPMtQ9nqBsqpA1m5sE92cU+pd5Mcc= + github.com/decred/dcrd/dcrec/secp256k1/v4 v4.0.1/go.mod h1:hyedUtir6IdtD/7lIxGeCxkaw7y45JueMRL4DIyJDKs= + github.com/decred/dcrd/lru v1.0.0/go.mod h1:mxKOwFd7lFjN2GZYsiz/ecgqR6kkYAl+0pz0tEMk218= +-github.com/denis-tingaikin/go-header v0.4.3 h1:tEaZKAlqql6SKCY++utLmkPLd6K8IBM20Ha7UVm+mtU= +-github.com/denis-tingaikin/go-header v0.4.3/go.mod h1:0wOCWuN71D5qIgE2nz9KrKmuYBAC2Mra5RassOIQ2/c= + github.com/denisenkom/go-mssqldb v0.12.0 h1:VtrkII767ttSPNRfFekePK3sctr+joXgO58stqQbtUA= + github.com/denisenkom/go-mssqldb v0.12.0/go.mod h1:iiK0YP1ZeepvmBQk/QpLEhhTNJgfzrpArPY/aFvc9yU= + github.com/dgraph-io/badger/v2 v2.2007.4 h1:TRWBQg8UrlUhaFdco01nO2uXwzKS7zd+HVdwV/GHc4o= + github.com/dgraph-io/badger/v2 v2.2007.4/go.mod h1:vSw/ax2qojzbN6eXHIx6KPKtCSHJN/Uz0X0VPruTIhk= +-github.com/dgraph-io/ristretto v0.0.3-0.20200630154024-f66de99634de h1:t0UHb5vdojIDUqktM6+xJAfScFBsVpXZmqC9dsgJmeA= + github.com/dgraph-io/ristretto v0.0.3-0.20200630154024-f66de99634de/go.mod h1:KPxhHT9ZxKefz+PCeOGsrHpl1qZ7i70dGTu2u+Ahh6E= +-github.com/dgraph-io/ristretto v0.0.3 h1:jh22xisGBjrEVnRZ1DVTpBVQm0Xndu8sMl0CWDzSIBI= +-github.com/dgraph-io/ristretto v0.0.3/go.mod h1:KPxhHT9ZxKefz+PCeOGsrHpl1qZ7i70dGTu2u+Ahh6E= +-github.com/dgryski/go-farm v0.0.0-20190423205320-6a90982ecee2 h1:tdlZCpZ/P9DhczCTSixgIKmwPv6+wP5DGjqLYw5SUiA= ++github.com/dgraph-io/ristretto v0.1.1 h1:6CWw5tJNgpegArSHpNHJKldNeq03FQCwYvfMVWajOK8= ++github.com/dgraph-io/ristretto v0.1.1/go.mod h1:S1GPSBCYCIhmVNfcth17y2zZtQT6wzkzgwUve0VDWWA= + github.com/dgryski/go-farm v0.0.0-20190423205320-6a90982ecee2/go.mod h1:SqUrOPUnsFjfmXRMNPybcSiG0BgUW2AuFH8PAnS2iTw= + github.com/dgryski/go-farm v0.0.0-20200201041132-a6ae2369ad13 h1:fAjc9m62+UWV/WAFKLNi6ZS0675eEUC9y3AlwSbQu1Y= + github.com/dgryski/go-farm v0.0.0-20200201041132-a6ae2369ad13/go.mod h1:SqUrOPUnsFjfmXRMNPybcSiG0BgUW2AuFH8PAnS2iTw= +-github.com/docker/cli v20.10.17+incompatible h1:eO2KS7ZFeov5UJeaDmIs1NFEDRf32PaqRpvoEkKBy5M= +-github.com/docker/cli v20.10.17+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8= +-github.com/docker/distribution v2.8.1+incompatible h1:Q50tZOPR6T/hjNsyc9g8/syEs6bk8XXApsHjKukMl68= +-github.com/docker/distribution v2.8.1+incompatible/go.mod h1:J2gT2udsDAN96Uj4KfcMRqY0/ypR+oyYUYmja8H+y+w= +-github.com/docker/docker v20.10.19+incompatible h1:lzEmjivyNHFHMNAFLXORMBXyGIhw/UP4DvJwvyKYq64= +-github.com/docker/docker v20.10.19+incompatible/go.mod h1:eEKB0N0r5NX/I1kEveEz05bcu8tLC/8azJZsviup8Sk= ++github.com/docker/cli v23.0.1+incompatible h1:LRyWITpGzl2C9e9uGxzisptnxAn1zfZKXy13Ul2Q5oM= ++github.com/docker/cli v23.0.1+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8= ++github.com/docker/docker v23.0.1+incompatible h1:vjgvJZxprTTE1A37nm+CLNAdwu6xZekyoiVlUZEINcY= ++github.com/docker/docker v23.0.1+incompatible/go.mod h1:eEKB0N0r5NX/I1kEveEz05bcu8tLC/8azJZsviup8Sk= + github.com/docker/go-connections v0.4.0 h1:El9xVISelRB7BuFusrZozjnkIM5YnzCViNKohAFqRJQ= + github.com/docker/go-connections v0.4.0/go.mod h1:Gbd7IOopHjR8Iph03tsViu4nIes5XhDvyHbTtUxmeec= + github.com/docker/go-units v0.4.0/go.mod h1:fgPhTUdO+D/Jk86RDLlptpiXQzgHJF7gydDDbaIK4Dk= + github.com/docker/go-units v0.5.0 h1:69rxXcBk27SvSaaxTtLh/8llcHD8vYHT7WSdRZ/jvr4= + github.com/docker/go-units v0.5.0/go.mod h1:fgPhTUdO+D/Jk86RDLlptpiXQzgHJF7gydDDbaIK4Dk= +-github.com/dustin/go-humanize v1.0.0 h1:VSnTsYCnlFHaM2/igO1h6X3HA71jcobQuxemgkq4zYo= + github.com/dustin/go-humanize v1.0.0/go.mod h1:HtrtbFcZ19U5GC7JDqmcUSB87Iq5E25KnS6fMYU6eOk= + github.com/dustin/go-humanize v1.0.1 h1:GzkhY7T5VNhEkwH0PVJgjz+fX1rhBrR7pRT3mDkpeCY= + github.com/dustin/go-humanize v1.0.1/go.mod h1:Mu1zIs6XwVuF/gI1OepvI0qD18qycQx+mFykh5fBlto= +-github.com/elazarl/goproxy v0.0.0-20230808193330-2592e75ae04a h1:mATvB/9r/3gvcejNsXKSkQ6lcIaNec2nyfOdlTBR2lU= +-github.com/elazarl/goproxy v0.0.0-20230808193330-2592e75ae04a/go.mod h1:Ro8st/ElPeALwNFlcTpWmkr6IoMFfkjXAvTHpevnDsM= ++github.com/elazarl/goproxy v1.2.3 h1:xwIyKHbaP5yfT6O9KIeYJR5549MXRQkoQMRXGztz8YQ= ++github.com/elazarl/goproxy v1.2.3/go.mod h1:YfEbZtqP4AetfO6d40vWchF3znWX7C7Vd6ZMfdL8z64= + github.com/emirpasic/gods v1.18.1 h1:FXtiHYKDGKCW2KzwZKx0iC0PQmdlorYgdFG9jPXJ1Bc= + github.com/emirpasic/gods v1.18.1/go.mod h1:8tpGGwCnJ5H4r6BWwaV6OrWmMoPhUl5jm/FMNAnJvWQ= +-github.com/envoyproxy/go-control-plane v0.9.0/go.mod h1:YTl/9mNaCwkRvm6d1a2C3ymFceY/DCBVvsKhRF0iEA4= +-github.com/envoyproxy/go-control-plane v0.9.1-0.20191026205805-5f8ba28d4473/go.mod h1:YTl/9mNaCwkRvm6d1a2C3ymFceY/DCBVvsKhRF0iEA4= +-github.com/envoyproxy/go-control-plane v0.9.4/go.mod h1:6rpuAdCZL397s3pYoYcLgu1mIlRU8Am5FuJP05cCM98= +-github.com/envoyproxy/protoc-gen-validate v0.1.0/go.mod h1:iSmxcyjqTsJpI2R4NaDN7+kN2VEUnK/pcBlmesArF7c= +-github.com/envoyproxy/protoc-gen-validate v1.0.2 h1:QkIBuU5k+x7/QXPvPPnWXWlCdaBFApVqftFV6k087DA= +-github.com/envoyproxy/protoc-gen-validate v1.0.2/go.mod h1:GpiZQP3dDbg4JouG/NNS7QWXpgx6x8QiMKdmN72jogE= +-github.com/esimonov/ifshort v1.0.4 h1:6SID4yGWfRae/M7hkVDVVyppy8q/v9OuxNdmjLQStBA= +-github.com/esimonov/ifshort v1.0.4/go.mod h1:Pe8zjlRrJ80+q2CxHLfEOfTwxCZ4O+MuhcHcfgNWTk0= +-github.com/ettle/strcase v0.1.1 h1:htFueZyVeE1XNnMEfbqp5r67qAN/4r6ya1ysq8Q+Zcw= +-github.com/ettle/strcase v0.1.1/go.mod h1:hzDLsPC7/lwKyBOywSHEP89nt2pDgdy+No1NBA9o9VY= + github.com/facebookgo/ensure v0.0.0-20200202191622-63f1cf65ac4c h1:8ISkoahWXwZR41ois5lSJBSVw4D0OV19Ht/JSTzvSv0= + github.com/facebookgo/ensure v0.0.0-20200202191622-63f1cf65ac4c/go.mod h1:Yg+htXGokKKdzcwhuNDwVvN+uBxDGXJ7G/VN1d8fa64= + github.com/facebookgo/stack v0.0.0-20160209184415-751773369052 h1:JWuenKqqX8nojtoVVWjGfOF9635RETekkoH6Cc9SX0A= + github.com/facebookgo/stack v0.0.0-20160209184415-751773369052/go.mod h1:UbMTZqLaRiH3MsBH8va0n7s1pQYcu3uTb8G4tygF4Zg= + github.com/facebookgo/subset v0.0.0-20200203212716-c811ad88dec4 h1:7HZCaLC5+BZpmbhCOZJ293Lz68O7PYrF2EzeiFMwCLk= + github.com/facebookgo/subset v0.0.0-20200203212716-c811ad88dec4/go.mod h1:5tD+neXqOorC30/tWg0LCSkrqj/AR6gu8yY8/fpw1q0= +-github.com/fatih/color v1.14.1 h1:qfhVLaG5s+nCROl1zJsZRxFeYrHLqWroPOQ8BWiNb4w= +-github.com/fatih/color v1.14.1/go.mod h1:2oHN61fhTpgcxD3TSWCgKDiH1+x4OiDVVGH8WlgGZGg= +-github.com/fatih/structtag v1.2.0 h1:/OdNE99OxoI/PqaW/SuSK9uxxT3f/tcSZgon/ssNSx4= +-github.com/fatih/structtag v1.2.0/go.mod h1:mBJUNpUnHmRKrKlQQlmCrh5PuhftFbNv8Ys4/aAZl94= +-github.com/firefart/nonamedreturns v1.0.4 h1:abzI1p7mAEPYuR4A+VLKn4eNDOycjYo2phmY9sfv40Y= +-github.com/firefart/nonamedreturns v1.0.4/go.mod h1:TDhe/tjI1BXo48CmYbUduTV7BdIga8MAO/xbKdcVsGI= +-github.com/fogleman/gg v1.2.1-0.20190220221249-0403632d5b90/go.mod h1:R/bRT+9gY/C5z7JzPU0zXsXHKM4/ayA+zqcVNZzPa1k= + github.com/fortytw2/leaktest v1.3.0 h1:u8491cBMTQ8ft8aeV+adlcytMZylmA5nnwwkRZjI8vw= + github.com/fortytw2/leaktest v1.3.0/go.mod h1:jDsjWgpAGjm2CA7WthBh/CdZYEPF31XHquHwclZch5g= + github.com/frankban/quicktest v1.11.3/go.mod h1:wRf/ReqHper53s+kmmSZizM8NamnL3IM0I9ntUbOk+k= +@@ -287,275 +145,120 @@ github.com/fsnotify/fsnotify v1.4.7/go.mod h1:jwhsz4b93w/PPRr/qN1Yymfu8t87LnFCMo + github.com/fsnotify/fsnotify v1.4.9/go.mod h1:znqG4EE+3YCdAaPaxE2ZRY/06pZUdp0tY4IgpuI1SZQ= + github.com/fsnotify/fsnotify v1.7.0 h1:8JEhPFa5W2WU7YfeZzPNqzMP6Lwt7L2715Ggo0nosvA= + github.com/fsnotify/fsnotify v1.7.0/go.mod h1:40Bi/Hjc2AVfZrqy+aj+yEI+/bRxZnMJyTJwOpGvigM= +-github.com/fzipp/gocyclo v0.6.0 h1:lsblElZG7d3ALtGMx9fmxeTKZaLLpU8mET09yN4BBLo= +-github.com/fzipp/gocyclo v0.6.0/go.mod h1:rXPyn8fnlpa0R2csP/31uerbiVBugk5whMdlyaLkLoA= +-github.com/gliderlabs/ssh v0.3.5 h1:OcaySEmAQJgyYcArR+gGGTHCyE7nvhEMTlYY+Dp8CpY= +-github.com/gliderlabs/ssh v0.3.5/go.mod h1:8XB4KraRrX39qHhT6yxPsHedjA08I/uBVwj4xC+/+z4= +-github.com/go-chi/chi/v5 v5.0.7 h1:rDTPXLDHGATaeHvVlLcR4Qe0zftYethFucbjVQ1PxU8= +-github.com/go-chi/chi/v5 v5.0.7/go.mod h1:DslCQbL2OYiznFReuXYUmQ2hGd1aDpCnlMNITLSKoi8= +-github.com/go-critic/go-critic v0.6.5 h1:fDaR/5GWURljXwF8Eh31T2GZNz9X4jeboS912mWF8Uo= +-github.com/go-critic/go-critic v0.6.5/go.mod h1:ezfP/Lh7MA6dBNn4c6ab5ALv3sKnZVLx37tr00uuaOY= ++github.com/gliderlabs/ssh v0.3.8 h1:a4YXD1V7xMF9g5nTkdfnja3Sxy1PVDCj1Zg4Wb8vY6c= ++github.com/gliderlabs/ssh v0.3.8/go.mod h1:xYoytBv1sV0aL3CavoDuJIQNURXkkfPA/wxQ1pL1fAU= + github.com/go-git/gcfg v1.5.1-0.20230307220236-3a3c6141e376 h1:+zs/tPmkDkHx3U66DAb0lQFJrpS6731Oaa12ikc+DiI= + github.com/go-git/gcfg v1.5.1-0.20230307220236-3a3c6141e376/go.mod h1:an3vInlBmSxCcxctByoQdvwPiA7DTK7jaaFDBTtu0ic= +-github.com/go-git/go-billy/v5 v5.5.0 h1:yEY4yhzCDuMGSv83oGxiBotRzhwhNr8VZyphhiu+mTU= +-github.com/go-git/go-billy/v5 v5.5.0/go.mod h1:hmexnoNsr2SJU1Ju67OaNz5ASJY3+sHgFRpCtpDCKow= ++github.com/go-git/go-billy/v5 v5.6.1 h1:u+dcrgaguSSkbjzHwelEjc0Yj300NUevrrPphk/SoRA= ++github.com/go-git/go-billy/v5 v5.6.1/go.mod h1:0AsLr1z2+Uksi4NlElmMblP5rPcDZNRCD8ujZCRR2BE= + github.com/go-git/go-git-fixtures/v4 v4.3.2-0.20231010084843-55a94097c399 h1:eMje31YglSBqCdIqdhKBW8lokaMrL3uTkpGYlE2OOT4= + github.com/go-git/go-git-fixtures/v4 v4.3.2-0.20231010084843-55a94097c399/go.mod h1:1OCfN199q1Jm3HZlxleg+Dw/mwps2Wbk9frAWm+4FII= +-github.com/go-git/go-git/v5 v5.11.0 h1:XIZc1p+8YzypNr34itUfSvYJcv+eYdTnTvOZ2vD3cA4= +-github.com/go-git/go-git/v5 v5.11.0/go.mod h1:6GFcX2P3NM7FPBfpePbpLd21XxsgdAt+lKqXmCUiUCY= +-github.com/go-gl/glfw v0.0.0-20190409004039-e6da0acd62b1/go.mod h1:vR7hzQXu2zJy9AVAgeJqvqgH9Q5CA+iKCZ2gyEVpxRU= +-github.com/go-gl/glfw/v3.3/glfw v0.0.0-20191125211704-12ad95a8df72/go.mod h1:tQ2UAYgL5IevRw8kRxooKSPJfGvJ9fJQFa0TUsXzTg8= +-github.com/go-gl/glfw/v3.3/glfw v0.0.0-20200222043503-6f7a984d4dc4/go.mod h1:tQ2UAYgL5IevRw8kRxooKSPJfGvJ9fJQFa0TUsXzTg8= +-github.com/go-kit/kit v0.8.0/go.mod h1:xBxKIO96dXMWWy0MnWVtmwkA9/13aqxPnvrjFYMA2as= +-github.com/go-kit/kit v0.9.0/go.mod h1:xBxKIO96dXMWWy0MnWVtmwkA9/13aqxPnvrjFYMA2as= ++github.com/go-git/go-git/v5 v5.13.1 h1:DAQ9APonnlvSWpvolXWIuV6Q6zXy2wHbN4cVlNR5Q+M= ++github.com/go-git/go-git/v5 v5.13.1/go.mod h1:qryJB4cSBoq3FRoBRf5A77joojuBcmPJ0qu3XXXVixc= + github.com/go-kit/kit v0.12.0 h1:e4o3o3IsBfAKQh5Qbbiqyfu97Ku7jrO/JbohvztANh4= + github.com/go-kit/kit v0.12.0/go.mod h1:lHd+EkCZPIwYItmGDDRdhinkzX2A1sj+M9biaEaizzs= +-github.com/go-kit/log v0.1.0/go.mod h1:zbhenjAZHb184qTLMA9ZjW7ThYL0H2mk7Q6pNt4vbaY= +-github.com/go-kit/log v0.2.0/go.mod h1:NwTd00d/i8cPZ3xOwwiv2PO5MOcx78fFErGNcVmBjv0= + github.com/go-kit/log v0.2.1 h1:MRVx0/zhvdseW+Gza6N9rVzU/IVzaeE1SFI4raAhmBU= + github.com/go-kit/log v0.2.1/go.mod h1:NwTd00d/i8cPZ3xOwwiv2PO5MOcx78fFErGNcVmBjv0= +-github.com/go-logfmt/logfmt v0.3.0/go.mod h1:Qt1PoO58o5twSAckw1HlFXLmHsOX5/0LbT9GBnD5lWE= +-github.com/go-logfmt/logfmt v0.4.0/go.mod h1:3RMwSq7FuexP4Kalkev3ejPJsZTpXXBr9+V4qmtdjCk= +-github.com/go-logfmt/logfmt v0.5.0/go.mod h1:wCYkCAKZfumFQihp8CzCvQ3paCTfi41vtzG1KdI/P7A= +-github.com/go-logfmt/logfmt v0.5.1 h1:otpy5pqBCBZ1ng9RQ0dPu4PN7ba75Y/aA+UpowDyNVA= +-github.com/go-logfmt/logfmt v0.5.1/go.mod h1:WYhtIu8zTZfxdn5+rREduYbwxfcBr/Vr6KEVveWlfTs= ++github.com/go-logfmt/logfmt v0.6.0 h1:wGYYu3uicYdqXVgoYbvnkrPVXkuLM1p1ifugDMEdRi4= ++github.com/go-logfmt/logfmt v0.6.0/go.mod h1:WYhtIu8zTZfxdn5+rREduYbwxfcBr/Vr6KEVveWlfTs= + github.com/go-logr/logr v1.2.2/go.mod h1:jdQByPbusPIv2/zmleS9BjJVeZ6kBagPoEUsqbVz/1A= +-github.com/go-logr/logr v1.2.3 h1:2DntVwHkVopvECVRSlL5PSo9eG+cAkDCuckLubN+rq0= +-github.com/go-logr/logr v1.2.3/go.mod h1:jdQByPbusPIv2/zmleS9BjJVeZ6kBagPoEUsqbVz/1A= ++github.com/go-logr/logr v1.3.0/go.mod h1:9T104GzyrTigFIr8wt5mBrctHMim0Nb2HLGrmQ40KvY= ++github.com/go-logr/logr v1.4.2 h1:6pFjapn8bFcIbiKo3XT4j/BhANplGihG6tvd+8rYgrY= ++github.com/go-logr/logr v1.4.2/go.mod h1:9T104GzyrTigFIr8wt5mBrctHMim0Nb2HLGrmQ40KvY= + github.com/go-logr/stdr v1.2.2 h1:hSWxHoqTgW2S2qGc0LTAI563KZ5YKYRhT3MFKZMbjag= + github.com/go-logr/stdr v1.2.2/go.mod h1:mMo/vtBO5dYbehREoey6XUKy/eSumjCCveDpRre4VKE= +-github.com/go-sql-driver/mysql v1.4.0/go.mod h1:zAC/RDZ24gD3HViQzih4MyKcchzm+sOG5ZlKdlhCg5w= +-github.com/go-sql-driver/mysql v1.6.0 h1:BCTh4TKNUYmOmMUcQ3IipzF5prigylS7XXjEkfCHuOE= +-github.com/go-sql-driver/mysql v1.6.0/go.mod h1:DCzpHaOWr8IXmIStZouvnhqoel9Qv2LBy8hT2VhHyBg= +-github.com/go-stack/stack v1.8.0/go.mod h1:v0f6uXyyMGvRgIKkXu+yp6POWl0qKG85gN/melR3HDY= +-github.com/go-toolsmith/astcast v1.0.0 h1:JojxlmI6STnFVG9yOImLeGREv8W2ocNUM+iOhR6jE7g= +-github.com/go-toolsmith/astcast v1.0.0/go.mod h1:mt2OdQTeAQcY4DQgPSArJjHCcOwlX+Wl/kwN+LbLGQ4= +-github.com/go-toolsmith/astcopy v1.0.2 h1:YnWf5Rnh1hUudj11kei53kI57quN/VH6Hp1n+erozn0= +-github.com/go-toolsmith/astcopy v1.0.2/go.mod h1:4TcEdbElGc9twQEYpVo/aieIXfHhiuLh4aLAck6dO7Y= +-github.com/go-toolsmith/astequal v1.0.0/go.mod h1:H+xSiq0+LtiDC11+h1G32h7Of5O3CYFJ99GVbS5lDKY= +-github.com/go-toolsmith/astequal v1.0.2/go.mod h1:9Ai4UglvtR+4up+bAD4+hCj7iTo4m/OXVTSLnCyTAx4= +-github.com/go-toolsmith/astequal v1.0.3 h1:+LVdyRatFS+XO78SGV4I3TCEA0AC7fKEGma+fH+674o= +-github.com/go-toolsmith/astequal v1.0.3/go.mod h1:9Ai4UglvtR+4up+bAD4+hCj7iTo4m/OXVTSLnCyTAx4= +-github.com/go-toolsmith/astfmt v1.0.0 h1:A0vDDXt+vsvLEdbMFJAUBI/uTbRw1ffOPnxsILnFL6k= +-github.com/go-toolsmith/astfmt v1.0.0/go.mod h1:cnWmsOAuq4jJY6Ct5YWlVLmcmLMn1JUPuQIHCY7CJDw= +-github.com/go-toolsmith/astp v1.0.0 h1:alXE75TXgcmupDsMK1fRAy0YUzLzqPVvBKoyWV+KPXg= +-github.com/go-toolsmith/astp v1.0.0/go.mod h1:RSyrtpVlfTFGDYRbrjyWP1pYu//tSFcvdYrA8meBmLI= +-github.com/go-toolsmith/pkgload v1.0.2-0.20220101231613-e814995d17c5 h1:eD9POs68PHkwrx7hAB78z1cb6PfGq/jyWn3wJywsH1o= +-github.com/go-toolsmith/pkgload v1.0.2-0.20220101231613-e814995d17c5/go.mod h1:3NAwwmD4uY/yggRxoEjk/S00MIV3A+H7rrE3i87eYxM= +-github.com/go-toolsmith/strparse v1.0.0 h1:Vcw78DnpCAKlM20kSbAyO4mPfJn/lyYA4BJUDxe2Jb4= +-github.com/go-toolsmith/strparse v1.0.0/go.mod h1:YI2nUKP9YGZnL/L1/DLFBfixrcjslWct4wyljWhSRy8= +-github.com/go-toolsmith/typep v1.0.2 h1:8xdsa1+FSIH/RhEkgnD1j2CJOy5mNllW1Q9tRiYwvlk= +-github.com/go-toolsmith/typep v1.0.2/go.mod h1:JSQCQMUPdRlMZFswiq3TGpNp1GMktqkR2Ns5AIQkATU= +-github.com/go-xmlfmt/xmlfmt v0.0.0-20191208150333-d5b6f63a941b h1:khEcpUM4yFcxg4/FHQWkvVRmgijNXRfzkIDHh23ggEo= +-github.com/go-xmlfmt/xmlfmt v0.0.0-20191208150333-d5b6f63a941b/go.mod h1:aUCEOzzezBEjDBbFBoSiya/gduyIiWYRP6CnSFIV8AM= +-github.com/gobwas/glob v0.2.3 h1:A4xDbljILXROh+kObIiy5kIaPYD8e96x1tgBhUI5J+Y= +-github.com/gobwas/glob v0.2.3/go.mod h1:d3Ez4x06l9bZtSvzIay5+Yzi0fmZzPgnTbPcKjJAkT8= ++github.com/go-sql-driver/mysql v1.7.1 h1:lUIinVbN1DY0xBg0eMOzmmtGoHwWBbvnWubQUrtU8EI= ++github.com/go-sql-driver/mysql v1.7.1/go.mod h1:OXbVy3sEdcQ2Doequ6Z5BW6fXNQTmx+9S1MCJN5yJMI= + github.com/godbus/dbus/v5 v5.0.4/go.mod h1:xhWf0FNVPg57R7Z0UbKHbJfkEywrmjJnf7w5xrFpKfA= + github.com/godbus/dbus/v5 v5.0.6/go.mod h1:xhWf0FNVPg57R7Z0UbKHbJfkEywrmjJnf7w5xrFpKfA= +-github.com/gofrs/flock v0.8.1 h1:+gYjHKf32LDeiEEFhQaotPbLuUXjY5ZqxKgXy7n59aw= +-github.com/gofrs/flock v0.8.1/go.mod h1:F1TvTiK9OcQqauNUHlbJvyl9Qa1QvF/gOUDKA14jxHU= +-github.com/gofrs/uuid v4.3.0+incompatible h1:CaSVZxm5B+7o45rtab4jC2G37WGYX1zQfuU2i6DSvnc= +-github.com/gofrs/uuid v4.3.0+incompatible/go.mod h1:b2aQJv3Z4Fp6yNu3cdSllBxTCLRxnplIgP/c0N/04lM= +-github.com/gogo/protobuf v1.1.1/go.mod h1:r8qH/GZQm5c6nD/R0oafs1akxWv10x8SbQlK7atdtwQ= ++github.com/gofrs/uuid v4.4.0+incompatible h1:3qXRTX8/NbyulANqlc0lchS1gqAVxRgsuW1YrTJupqA= ++github.com/gofrs/uuid v4.4.0+incompatible/go.mod h1:b2aQJv3Z4Fp6yNu3cdSllBxTCLRxnplIgP/c0N/04lM= + github.com/gogo/protobuf v1.3.2 h1:Ov1cvc58UF3b5XjBnZv7+opcTcQFZebYjWzi34vdm4Q= + github.com/gogo/protobuf v1.3.2/go.mod h1:P1XiOD3dCwIKUDQYPy72D8LYyHL2YPYrpS2s69NZV8Q= + github.com/golang-sql/civil v0.0.0-20190719163853-cb61b32ac6fe h1:lXe2qZdvpiX5WZkZR4hgp4KJVfY3nMkvmwbVkpv1rVY= + github.com/golang-sql/civil v0.0.0-20190719163853-cb61b32ac6fe/go.mod h1:8vg3r2VgvsThLBIFL93Qb5yWzgyZWhEmBwUJWevAkK0= + github.com/golang-sql/sqlexp v0.0.0-20170517235910-f1bb20e5a188 h1:+eHOFJl1BaXrQxKX+T06f78590z4qA2ZzBTqahsKSE4= + github.com/golang-sql/sqlexp v0.0.0-20170517235910-f1bb20e5a188/go.mod h1:vXjM/+wXQnTPR4KqTKDgJukSZ6amVRtWMPEjE6sQoK8= +-github.com/golang/freetype v0.0.0-20170609003504-e2365dfdc4a0/go.mod h1:E/TSTwGwJL78qG/PmXZO1EjYhfJinVAhrmmHX6Z8B9k= + github.com/golang/glog v0.0.0-20160126235308-23def4e6c14b/go.mod h1:SBH7ygxi8pfUlaOkMMuAQtPIUF8ecWP5IEl/CR7VP2Q= +-github.com/golang/groupcache v0.0.0-20190702054246-869f871628b6/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc= +-github.com/golang/groupcache v0.0.0-20191227052852-215e87163ea7/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc= +-github.com/golang/groupcache v0.0.0-20200121045136-8c9f03a8e57e/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc= ++github.com/golang/glog v1.2.1 h1:OptwRhECazUx5ix5TTWC3EZhsZEHWcYWY4FQHTIubm4= ++github.com/golang/glog v1.2.1/go.mod h1:6AhwSGph0fcJtXVM/PEHPqZlFeoLxhs7/t5UDAwmO+w= + github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da h1:oI5xCqsCo564l8iNU+DwB5epxmsaqB+rhGL0m5jtYqE= + github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da/go.mod h1:cIg4eruTrX1D+g88fzRXU5OdNfaM+9IcxsU14FzY7Hc= +-github.com/golang/mock v1.1.1/go.mod h1:oTYuIxOrZwtPieC+H1uAHpcLFnEyAGVDL/k47Jfbm0A= +-github.com/golang/mock v1.2.0/go.mod h1:oTYuIxOrZwtPieC+H1uAHpcLFnEyAGVDL/k47Jfbm0A= +-github.com/golang/mock v1.3.1/go.mod h1:sBzyDLLjw3U8JLTeZvSv8jJB+tU5PVekmnlKIyFUx0Y= +-github.com/golang/mock v1.4.0/go.mod h1:UOMv5ysSaYNkG+OFQykRIcU/QvvxJf3p21QfJ2Bt3cw= +-github.com/golang/mock v1.4.1/go.mod h1:UOMv5ysSaYNkG+OFQykRIcU/QvvxJf3p21QfJ2Bt3cw= +-github.com/golang/mock v1.4.3/go.mod h1:UOMv5ysSaYNkG+OFQykRIcU/QvvxJf3p21QfJ2Bt3cw= ++github.com/golang/mock v1.4.4 h1:l75CXGRSwbaYNpl/Z2X1XIIAMSCquvXgpVZDhwEIJsc= + github.com/golang/mock v1.4.4/go.mod h1:l3mdAwkq5BuhzHwde/uurv3sEJeZMXNpwsxVWU71h+4= + github.com/golang/protobuf v1.2.0/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U= + github.com/golang/protobuf v1.3.1/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U= +-github.com/golang/protobuf v1.3.2/go.mod h1:6lQm79b+lXiMfvg/cZm0SGofjICqVBUtrP5yJMmIC1U= +-github.com/golang/protobuf v1.3.3/go.mod h1:vzj43D7+SQXF/4pzW/hwtAqwc6iTitCiVSaWz5lYuqw= +-github.com/golang/protobuf v1.3.4/go.mod h1:vzj43D7+SQXF/4pzW/hwtAqwc6iTitCiVSaWz5lYuqw= +-github.com/golang/protobuf v1.3.5/go.mod h1:6O5/vntMXwX2lRkT1hjjk0nAC1IDOTvTlVgjlRvqsdk= + github.com/golang/protobuf v1.4.0-rc.1/go.mod h1:ceaxUfeHdC40wWswd/P6IGgMaK3YpKi5j83Wpe3EHw8= + github.com/golang/protobuf v1.4.0-rc.1.0.20200221234624-67d41d38c208/go.mod h1:xKAWHe0F5eneWXFV3EuXVDTCmh+JuBKY0li0aMyXATA= + github.com/golang/protobuf v1.4.0-rc.2/go.mod h1:LlEzMj4AhA7rCAGe4KMBDvJI+AwstrUpVNzEA03Pprs= + github.com/golang/protobuf v1.4.0-rc.4.0.20200313231945-b860323f09d0/go.mod h1:WU3c8KckQ9AFe+yFwt9sWVRKCVIyN9cPHBJSNnbL67w= + github.com/golang/protobuf v1.4.0/go.mod h1:jodUvKwWbYaEsadDk5Fwe5c77LiNKVO9IDvqG2KuDX0= +-github.com/golang/protobuf v1.4.1/go.mod h1:U8fpvMrcmy5pZrNK1lt4xCsGvpyWQ/VVv6QDs8UjoX8= + github.com/golang/protobuf v1.4.2/go.mod h1:oDoupMAO8OvCJWAcko0GGGIgR6R6ocIYbsSw735rRwI= +-github.com/golang/protobuf v1.4.3/go.mod h1:oDoupMAO8OvCJWAcko0GGGIgR6R6ocIYbsSw735rRwI= + github.com/golang/protobuf v1.5.0/go.mod h1:FsONVRAS9T7sI+LIUmWTfcYkHO4aIWwzhcaSAoJOfIk= +-github.com/golang/protobuf v1.5.2/go.mod h1:XVQd3VNwM+JqD3oG2Ue2ip4fOMUkwXdXDdiuN0vRsmY= + github.com/golang/protobuf v1.5.3 h1:KhyjKVUg7Usr/dYsdSqoFveMYd5ko72D+zANwlG1mmg= + github.com/golang/protobuf v1.5.3/go.mod h1:XVQd3VNwM+JqD3oG2Ue2ip4fOMUkwXdXDdiuN0vRsmY= + github.com/golang/snappy v0.0.3/go.mod h1:/XxbfmMg8lxefKM7IXC3fBNl/7bRcc72aCRzEWrmP2Q= + github.com/golang/snappy v0.0.4 h1:yAGX7huGHXlcLOEtBnF4w7FQwA26wojNCwOYAEhLjQM= + github.com/golang/snappy v0.0.4/go.mod h1:/XxbfmMg8lxefKM7IXC3fBNl/7bRcc72aCRzEWrmP2Q= +-github.com/golangci/check v0.0.0-20180506172741-cfe4005ccda2 h1:23T5iq8rbUYlhpt5DB4XJkc6BU31uODLD1o1gKvZmD0= +-github.com/golangci/check v0.0.0-20180506172741-cfe4005ccda2/go.mod h1:k9Qvh+8juN+UKMCS/3jFtGICgW8O96FVaZsaxdzDkR4= +-github.com/golangci/dupl v0.0.0-20180902072040-3e9179ac440a h1:w8hkcTqaFpzKqonE9uMCefW1WDie15eSP/4MssdenaM= +-github.com/golangci/dupl v0.0.0-20180902072040-3e9179ac440a/go.mod h1:ryS0uhF+x9jgbj/N71xsEqODy9BN81/GonCZiOzirOk= +-github.com/golangci/go-misc v0.0.0-20220329215616-d24fe342adfe h1:6RGUuS7EGotKx6J5HIP8ZtyMdiDscjMLfRBSPuzVVeo= +-github.com/golangci/go-misc v0.0.0-20220329215616-d24fe342adfe/go.mod h1:gjqyPShc/m8pEMpk0a3SeagVb0kaqvhscv+i9jI5ZhQ= +-github.com/golangci/gofmt v0.0.0-20220901101216-f2edd75033f2 h1:amWTbTGqOZ71ruzrdA+Nx5WA3tV1N0goTspwmKCQvBY= +-github.com/golangci/gofmt v0.0.0-20220901101216-f2edd75033f2/go.mod h1:9wOXstvyDRshQ9LggQuzBCGysxs3b6Uo/1MvYCR2NMs= +-github.com/golangci/golangci-lint v1.50.1 h1:C829clMcZXEORakZlwpk7M4iDw2XiwxxKaG504SZ9zY= +-github.com/golangci/golangci-lint v1.50.1/go.mod h1:AQjHBopYS//oB8xs0y0M/dtxdKHkdhl0RvmjUct0/4w= +-github.com/golangci/lint-1 v0.0.0-20191013205115-297bf364a8e0 h1:MfyDlzVjl1hoaPzPD4Gpb/QgoRfSBR0jdhwGyAWwMSA= +-github.com/golangci/lint-1 v0.0.0-20191013205115-297bf364a8e0/go.mod h1:66R6K6P6VWk9I95jvqGxkqJxVWGFy9XlDwLwVz1RCFg= +-github.com/golangci/maligned v0.0.0-20180506175553-b1d89398deca h1:kNY3/svz5T29MYHubXix4aDDuE3RWHkPvopM/EDv/MA= +-github.com/golangci/maligned v0.0.0-20180506175553-b1d89398deca/go.mod h1:tvlJhZqDe4LMs4ZHD0oMUlt9G2LWuDGoisJTBzLMV9o= +-github.com/golangci/misspell v0.3.5 h1:pLzmVdl3VxTOncgzHcvLOKirdvcx/TydsClUQXTehjo= +-github.com/golangci/misspell v0.3.5/go.mod h1:dEbvlSfYbMQDtrpRMQU675gSDLDNa8sCPPChZ7PhiVA= +-github.com/golangci/revgrep v0.0.0-20220804021717-745bb2f7c2e6 h1:DIPQnGy2Gv2FSA4B/hh8Q7xx3B7AIDk3DAMeHclH1vQ= +-github.com/golangci/revgrep v0.0.0-20220804021717-745bb2f7c2e6/go.mod h1:0AKcRCkMoKvUvlf89F6O7H2LYdhr1zBh736mBItOdRs= +-github.com/golangci/unconvert v0.0.0-20180507085042-28b1c447d1f4 h1:zwtduBRr5SSWhqsYNgcuWO2kFlpdOZbP0+yRjmvPGys= +-github.com/golangci/unconvert v0.0.0-20180507085042-28b1c447d1f4/go.mod h1:Izgrg8RkN3rCIMLGE9CyYmU9pY2Jer6DgANEnZ/L/cQ= +-github.com/google/btree v0.0.0-20180813153112-4030bb1f1f0c/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ= +-github.com/google/btree v1.0.0/go.mod h1:lNA+9X1NB3Zf8V7Ke586lFgjr2dZNuvo3lPJSGZ5JPQ= + github.com/google/btree v1.1.2 h1:xf4v41cLI2Z6FxbKm+8Bu+m8ifhj15JuZ9sa0jZCMUU= + github.com/google/btree v1.1.2/go.mod h1:qOPhT0dTNdNzV6Z/lhRX0YXUafgPLFUh+gZMl761Gm4= +-github.com/google/go-cmp v0.2.0/go.mod h1:oXzfMopK8JAjlY9xF4vHSVASa0yLyX7SntLO5aqRK0M= + github.com/google/go-cmp v0.3.0/go.mod h1:8QqcDgzrUqlUb/G2PQTWiueGozuR1884gddMywk6iLU= + github.com/google/go-cmp v0.3.1/go.mod h1:8QqcDgzrUqlUb/G2PQTWiueGozuR1884gddMywk6iLU= + github.com/google/go-cmp v0.4.0/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE= +-github.com/google/go-cmp v0.4.1/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE= +-github.com/google/go-cmp v0.5.0/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE= +-github.com/google/go-cmp v0.5.1/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE= +-github.com/google/go-cmp v0.5.2/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE= +-github.com/google/go-cmp v0.5.3/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE= + github.com/google/go-cmp v0.5.4/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE= + github.com/google/go-cmp v0.5.5/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE= +-github.com/google/go-cmp v0.5.8/go.mod h1:17dUlkBOakJ0+DkrSSNjCkIjxS6bF9zb3elmeNGIjoY= + github.com/google/go-cmp v0.6.0 h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI= + github.com/google/go-cmp v0.6.0/go.mod h1:17dUlkBOakJ0+DkrSSNjCkIjxS6bF9zb3elmeNGIjoY= +-github.com/google/gofuzz v1.0.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg= +-github.com/google/martian v2.1.0+incompatible/go.mod h1:9I4somxYTbIHy5NJKHRl3wXiIaQGbYVAs8BPL6v8lEs= +-github.com/google/martian/v3 v3.0.0/go.mod h1:y5Zk1BBys9G+gd6Jrk0W3cC1+ELVxBWuIGO+w/tUAp0= ++github.com/google/gofuzz v1.2.0 h1:xRy4A+RhZaiKjJ1bPfwQ8sedCA+YS2YcCHW6ec7JMi0= ++github.com/google/gofuzz v1.2.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg= + github.com/google/orderedcode v0.0.1 h1:UzfcAexk9Vhv8+9pNOgRu41f16lHq725vPwnSeiG/Us= + github.com/google/orderedcode v0.0.1/go.mod h1:iVyU4/qPKHY5h/wSd6rZZCDcLJNxiWO6dvsYES2Sb20= +-github.com/google/pprof v0.0.0-20181206194817-3ea8567a2e57/go.mod h1:zfwlbNMJ+OItoe0UupaVj+oy1omPYYDuagoSzA8v9mc= +-github.com/google/pprof v0.0.0-20190515194954-54271f7e092f/go.mod h1:zfwlbNMJ+OItoe0UupaVj+oy1omPYYDuagoSzA8v9mc= +-github.com/google/pprof v0.0.0-20191218002539-d4f498aebedc/go.mod h1:ZgVRPoUq/hfqzAqh7sHMqb3I9Rq5C59dIz2SbBwJ4eM= +-github.com/google/pprof v0.0.0-20200212024743-f11f1df84d12/go.mod h1:ZgVRPoUq/hfqzAqh7sHMqb3I9Rq5C59dIz2SbBwJ4eM= +-github.com/google/pprof v0.0.0-20200229191704-1ebb73c60ed3/go.mod h1:ZgVRPoUq/hfqzAqh7sHMqb3I9Rq5C59dIz2SbBwJ4eM= +-github.com/google/pprof v0.0.0-20200430221834-fc25d7d30c6d/go.mod h1:ZgVRPoUq/hfqzAqh7sHMqb3I9Rq5C59dIz2SbBwJ4eM= +-github.com/google/pprof v0.0.0-20200708004538-1a94d8640e99/go.mod h1:ZgVRPoUq/hfqzAqh7sHMqb3I9Rq5C59dIz2SbBwJ4eM= +-github.com/google/renameio v0.1.0/go.mod h1:KWCgfxg9yswjAJkECMjeO8J8rahYeXnNhOm40UhjYkI= + github.com/google/shlex v0.0.0-20191202100458-e7afc7fbc510 h1:El6M4kTTCOh6aBiKaUGG7oYTSPP8MxqL4YI3kZKwcP4= + github.com/google/shlex v0.0.0-20191202100458-e7afc7fbc510/go.mod h1:pupxD2MaaD3pAXIBCelhxNneeOaAeabZDe5s4K6zSpQ= +-github.com/google/uuid v1.1.2/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo= +-github.com/google/uuid v1.4.0 h1:MtMxsa51/r9yyhkyLsVeVt0B+BGQZzpQiTQ4eHZ8bc4= +-github.com/google/uuid v1.4.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo= +-github.com/googleapis/gax-go/v2 v2.0.4/go.mod h1:0Wqv26UfaUD9n4G6kQubkQ+KchISgw+vpHVxEJEs9eg= +-github.com/googleapis/gax-go/v2 v2.0.5/go.mod h1:DWXyrwAJ9X0FpwwEdw+IPEYBICEFu5mhpdKc/us6bOk= +-github.com/gordonklaus/ineffassign v0.0.0-20210914165742-4cc7213b9bc8 h1:PVRE9d4AQKmbelZ7emNig1+NT27DUmKZn5qXxfio54U= +-github.com/gordonklaus/ineffassign v0.0.0-20210914165742-4cc7213b9bc8/go.mod h1:Qcp2HIAYhR7mNUVSIxZww3Guk4it82ghYcEXIAk+QT0= +-github.com/gorilla/websocket v1.5.0 h1:PPwGk2jz7EePpoHN/+ClbZu8SPxiqlu12wZP/3sWmnc= +-github.com/gorilla/websocket v1.5.0/go.mod h1:YR8l580nyteQvAITg2hZ9XVh4b55+EU/adAjf1fMHhE= +-github.com/gostaticanalysis/analysisutil v0.0.0-20190318220348-4088753ea4d3/go.mod h1:eEOZF4jCKGi+aprrirO9e7WKB3beBRtWgqGunKl6pKE= +-github.com/gostaticanalysis/analysisutil v0.0.3/go.mod h1:eEOZF4jCKGi+aprrirO9e7WKB3beBRtWgqGunKl6pKE= +-github.com/gostaticanalysis/analysisutil v0.1.0/go.mod h1:dMhHRU9KTiDcuLGdy87/2gTR8WruwYZrKdRq9m1O6uw= +-github.com/gostaticanalysis/analysisutil v0.7.1 h1:ZMCjoue3DtDWQ5WyU16YbjbQEQ3VuzwxALrpYd+HeKk= +-github.com/gostaticanalysis/analysisutil v0.7.1/go.mod h1:v21E3hY37WKMGSnbsw2S/ojApNWb6C1//mXO48CXbVc= +-github.com/gostaticanalysis/comment v1.3.0/go.mod h1:xMicKDx7XRXYdVwY9f9wQpDJVnqWxw9wCauCMKp+IBI= +-github.com/gostaticanalysis/comment v1.4.1/go.mod h1:ih6ZxzTHLdadaiSnF5WY3dxUoXfXAlTaRzuaNDlSado= +-github.com/gostaticanalysis/comment v1.4.2 h1:hlnx5+S2fY9Zo9ePo4AhgYsYHbM2+eAv8m/s1JiCd6Q= +-github.com/gostaticanalysis/comment v1.4.2/go.mod h1:KLUTGDv6HOCotCH8h2erHKmpci2ZoR8VPu34YA2uzdM= +-github.com/gostaticanalysis/forcetypeassert v0.1.0 h1:6eUflI3DiGusXGK6X7cCcIgVCpZ2CiZ1Q7jl6ZxNV70= +-github.com/gostaticanalysis/forcetypeassert v0.1.0/go.mod h1:qZEedyP/sY1lTGV1uJ3VhWZ2mqag3IkWsDHVbplHXak= +-github.com/gostaticanalysis/nilerr v0.1.1 h1:ThE+hJP0fEp4zWLkWHWcRyI2Od0p7DlgYG3Uqrmrcpk= +-github.com/gostaticanalysis/nilerr v0.1.1/go.mod h1:wZYb6YI5YAxxq0i1+VJbY0s2YONW0HU0GPE3+5PWN4A= +-github.com/gostaticanalysis/testutil v0.3.1-0.20210208050101-bfb5c8eec0e4/go.mod h1:D+FIZ+7OahH3ePw/izIEeH5I06eKs1IKI4Xr64/Am3M= +-github.com/gostaticanalysis/testutil v0.4.0 h1:nhdCmubdmDF6VEatUNjgUZBJKWRqugoISdUv3PPQgHY= +-github.com/gostaticanalysis/testutil v0.4.0/go.mod h1:bLIoPefWXrRi/ssLFWX1dx7Repi5x3CuviD3dgAZaBU= +-github.com/gotestyourself/gotestyourself v1.4.0 h1:CDSlSIuRL/Fsc72Ln5lMybtrCvSRDddsHsDRG/nP7Rg= +-github.com/gotestyourself/gotestyourself v1.4.0/go.mod h1:zZKM6oeNM8k+FRljX1mnzVYeS8wiGgQyvST1/GafPbY= +-github.com/grpc-ecosystem/go-grpc-middleware v1.3.0 h1:+9834+KizmvFV7pXQGSXQTsaWhq2GjuNUt0aUU0YBYw= +-github.com/grpc-ecosystem/go-grpc-middleware v1.3.0/go.mod h1:z0ButlSOZa5vEBq9m2m2hlwIgKw+rp3sdCBRoJY+30Y= ++github.com/google/uuid v1.6.0 h1:NIvaJDMOsjHA8n1jAhLSgzrAzy1Hgr+hNrb57e+94F0= ++github.com/google/uuid v1.6.0/go.mod h1:TIyPZe4MgqvfeYDBFedMoGGpEw/LqOeaOT+nhxU+yHo= ++github.com/gorilla/websocket v1.5.3 h1:saDtZ6Pbx/0u+bgYQ3q96pZgCzfhKXGPqt7kZ72aNNg= ++github.com/gorilla/websocket v1.5.3/go.mod h1:YR8l580nyteQvAITg2hZ9XVh4b55+EU/adAjf1fMHhE= ++github.com/gotestyourself/gotestyourself v2.2.0+incompatible h1:AQwinXlbQR2HvPjQZOmDhRqsv5mZf+Jb1RnSLxcqZcI= ++github.com/gotestyourself/gotestyourself v2.2.0+incompatible/go.mod h1:zZKM6oeNM8k+FRljX1mnzVYeS8wiGgQyvST1/GafPbY= ++github.com/grafana/otel-profiling-go v0.5.1 h1:stVPKAFZSa7eGiqbYuG25VcqYksR6iWvF3YH66t4qL8= ++github.com/grafana/otel-profiling-go v0.5.1/go.mod h1:ftN/t5A/4gQI19/8MoWurBEtC6gFw8Dns1sJZ9W4Tls= ++github.com/grafana/pyroscope-go v1.1.2 h1:7vCfdORYQMCxIzI3NlYAs3FcBP760+gWuYWOyiVyYx8= ++github.com/grafana/pyroscope-go v1.1.2/go.mod h1:HSSmHo2KRn6FasBA4vK7BMiQqyQq8KSuBKvrhkXxYPU= ++github.com/grafana/pyroscope-go/godeltaprof v0.1.8 h1:iwOtYXeeVSAeYefJNaxDytgjKtUuKQbJqgAIjlnicKg= ++github.com/grafana/pyroscope-go/godeltaprof v0.1.8/go.mod h1:2+l7K7twW49Ct4wFluZD3tZ6e0SjanjcUUBPVD/UuGU= + github.com/gtank/merlin v0.1.1-0.20191105220539-8318aed1a79f/go.mod h1:T86dnYJhcGOh5BjZFCJWTDeTK7XW8uE+E21Cy/bIQ+s= + github.com/gtank/merlin v0.1.1 h1:eQ90iG7K9pOhtereWsmyRJ6RAwcP4tHTDBHXNg+u5is= + github.com/gtank/merlin v0.1.1/go.mod h1:T86dnYJhcGOh5BjZFCJWTDeTK7XW8uE+E21Cy/bIQ+s= + github.com/gtank/ristretto255 v0.1.2 h1:JEqUCPA1NvLq5DwYtuzigd7ss8fwbYay9fi4/5uMzcc= + github.com/gtank/ristretto255 v0.1.2/go.mod h1:Ph5OpO6c7xKUGROZfWVLiJf9icMDwUeIvY4OmlYW69o= +-github.com/hashicorp/errwrap v1.0.0/go.mod h1:YH+1FKiLXxHSkmPseP+kNlulaMuP3n2brvKWEqk/Jc4= +-github.com/hashicorp/errwrap v1.1.0 h1:OxrOeh75EUXMY8TBjag2fzXGZ40LB6IKw45YeGUDY2I= +-github.com/hashicorp/errwrap v1.1.0/go.mod h1:YH+1FKiLXxHSkmPseP+kNlulaMuP3n2brvKWEqk/Jc4= +-github.com/hashicorp/go-multierror v1.1.1 h1:H5DkEtf6CXdFp0N0Em5UCwQpXMWke8IA0+lD48awMYo= +-github.com/hashicorp/go-multierror v1.1.1/go.mod h1:iw975J/qwKPdAO1clOe2L8331t/9/fmwbPZ6JB6eMoM= +-github.com/hashicorp/go-version v1.2.1/go.mod h1:fltr4n8CU8Ke44wwGCBoEymUuxUHl09ZGVZPK5anwXA= +-github.com/hashicorp/go-version v1.6.0 h1:feTTfFNnjP967rlCxM/I9g701jU+RN74YKx2mOkIeek= +-github.com/hashicorp/go-version v1.6.0/go.mod h1:fltr4n8CU8Ke44wwGCBoEymUuxUHl09ZGVZPK5anwXA= +-github.com/hashicorp/golang-lru v0.5.0/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8= +-github.com/hashicorp/golang-lru v0.5.1/go.mod h1:/m3WP610KZHVQ1SGc6re/UDhFvYD7pJ4Ao+sR/qLZy8= + github.com/hashicorp/hcl v1.0.0 h1:0Anlzjpi4vEasTeNFn2mLJgTSwt0+6sfsiTG8qcWGx4= + github.com/hashicorp/hcl v1.0.0/go.mod h1:E5yfLk+7swimpb2L/Alb/PJmXilQ/rhwaUYs4T20WEQ= +-github.com/hexops/gotextdiff v1.0.3 h1:gitA9+qJrrTCsiCl7+kh75nPqQt1cx4ZkudSTLoUqJM= +-github.com/hexops/gotextdiff v1.0.3/go.mod h1:pSWU5MAI3yDq+fZBTazCSJysOMbxWL1BSow5/V2vxeg= + github.com/hpcloud/tail v1.0.0/go.mod h1:ab1qPbhIpdTxEkNHXyeSf5vhxWSCs/tWer42PpOxQnU= +-github.com/ianlancetaylor/demangle v0.0.0-20181102032728-5e5cf60278f6/go.mod h1:aSSvb/t6k1mPoxDqO4vJh6VOCGPwU4O0C2/Eqndh1Sc= + github.com/imdario/mergo v0.3.13 h1:lFzP57bqS/wsqKssCGmtLAb8A0wKjLGrve2q3PPVcBk= + github.com/imdario/mergo v0.3.13/go.mod h1:4lJ1jqUDcsbIECGy0RUJAXNIhg+6ocWgb1ALK2O4oXg= + github.com/inconshreveable/mousetrap v1.0.0/go.mod h1:PxqpIevigyE2G7u3NXJIT2ANytuPF1OarO4DADm73n8= + github.com/inconshreveable/mousetrap v1.1.0 h1:wN+x4NVGpMsO7ErUn/mUI3vEoE6Jt13X2s0bqwp9tc8= + github.com/inconshreveable/mousetrap v1.1.0/go.mod h1:vpF70FUmC8bwa3OWnCshd2FqLfsEA9PFc4w1p2J65bw= +-github.com/informalsystems/tm-load-test v1.3.0 h1:FGjKy7vBw6mXNakt+wmNWKggQZRsKkEYpaFk/zR64VA= +-github.com/informalsystems/tm-load-test v1.3.0/go.mod h1:OQ5AQ9TbT5hKWBNIwsMjn6Bf4O0U4b1kRc+0qZlQJKw= + github.com/jbenet/go-context v0.0.0-20150711004518-d14ea06fba99 h1:BQSFePA1RWJOlocH6Fxy8MmwDt+yVQYULKfN0RoTN8A= + github.com/jbenet/go-context v0.0.0-20150711004518-d14ea06fba99/go.mod h1:1lJo3i6rXxKeerYnT8Nvf0QmHCRC1n8sfWVwXF2Frvo= +-github.com/jdxcode/netrc v0.0.0-20210204082910-926c7f70242a h1:d4+I1YEKVmWZrgkt6jpXBnLgV2ZjO0YxEtLDdfIZfH4= +-github.com/jdxcode/netrc v0.0.0-20210204082910-926c7f70242a/go.mod h1:Zi/ZFkEqFHTm7qkjyNJjaWH4LQA9LQhGJyF0lTYGpxw= + github.com/jessevdk/go-flags v0.0.0-20141203071132-1679536dcc89/go.mod h1:4FA24M0QyGHXBuZZK/XkWh8h0e1EYbRYJSGM75WSRxI= + github.com/jessevdk/go-flags v1.4.0/go.mod h1:4FA24M0QyGHXBuZZK/XkWh8h0e1EYbRYJSGM75WSRxI= +-github.com/jgautheron/goconst v1.5.1 h1:HxVbL1MhydKs8R8n/HE5NPvzfaYmQJA3o879lE4+WcM= +-github.com/jgautheron/goconst v1.5.1/go.mod h1:aAosetZ5zaeC/2EfMeRswtxUFBpe2Hr7HzkgX4fanO4= +-github.com/jhump/protoreflect v1.13.1-0.20220928232736-101791cb1b4c h1:XImQJfpJLmGEEd8ll5yPVyL/aEvmgGHW4WYTyNseLOM= +-github.com/jhump/protoreflect v1.13.1-0.20220928232736-101791cb1b4c/go.mod h1:JytZfP5d0r8pVNLZvai7U/MCuTWITgrI4tTg7puQFKI= +-github.com/jingyugao/rowserrcheck v1.1.1 h1:zibz55j/MJtLsjP1OF4bSdgXxwL1b+Vn7Tjzq7gFzUs= +-github.com/jingyugao/rowserrcheck v1.1.1/go.mod h1:4yvlZSDb3IyDTUZJUmpZfm2Hwok+Dtp+nu2qOq+er9c= +-github.com/jirfag/go-printf-func-name v0.0.0-20200119135958-7558a9eaa5af h1:KA9BjwUk7KlCh6S9EAGWBt1oExIUv9WyNCiRz5amv48= +-github.com/jirfag/go-printf-func-name v0.0.0-20200119135958-7558a9eaa5af/go.mod h1:HEWGJkRDzjJY2sqdDwxccsGicWEf9BQOZsq2tV+xzM0= ++github.com/jmespath/go-jmespath v0.4.0 h1:BEgLn5cpjn8UN1mAw4NjwDrS35OdebyEtFe+9YPoQUg= ++github.com/jmespath/go-jmespath v0.4.0/go.mod h1:T8mJZnbsbmF+m6zOOFylbeCJqk5+pHWvzYPziyZiYoo= ++github.com/jmespath/go-jmespath/internal/testify v1.5.1 h1:shLQSRRSCCPj3f2gpwzGwWFoC7ycTf1rcQZHOlsJ6N8= ++github.com/jmespath/go-jmespath/internal/testify v1.5.1/go.mod h1:L3OGu8Wl2/fWfCI6z80xFu9LTZmf1ZRjMHUOPmWr69U= + github.com/jmhodges/levigo v1.0.0 h1:q5EC36kV79HWeTBWsod3mG11EgStG3qArTKcvlksN1U= + github.com/jmhodges/levigo v1.0.0/go.mod h1:Q6Qx+uH3RAqyK4rFQroq9RL7mdkABMcfhEI+nNuzMJQ= +-github.com/jmoiron/sqlx v1.2.0/go.mod h1:1FEQNm3xlJgrMD+FBdI9+xvCksHtbpVBBw5dYhBSsks= +-github.com/jpillora/backoff v1.0.0/go.mod h1:J/6gKK9jxlEcS3zixgDgUAsiuZ7yrSoa/FX5e0EB2j4= + github.com/jrick/logrotate v1.0.0/go.mod h1:LNinyqDIJnpAur+b8yyulnQw/wDuN1+BYKlTRt3OuAQ= +-github.com/json-iterator/go v1.1.6/go.mod h1:+SdeFBvtyEkXs7REEP0seUULqWtbJapLOCVDaaPEHmU= +-github.com/json-iterator/go v1.1.10/go.mod h1:KdQUCv79m/52Kvf8AW2vK1V8akMuk1QjK/uOdHXbAo4= +-github.com/json-iterator/go v1.1.11/go.mod h1:KdQUCv79m/52Kvf8AW2vK1V8akMuk1QjK/uOdHXbAo4= +-github.com/json-iterator/go v1.1.12/go.mod h1:e30LSqwooZae/UwlEbR2852Gd8hjQvJoHmT4TnhNGBo= +-github.com/jstemmer/go-junit-report v0.0.0-20190106144839-af01ea7f8024/go.mod h1:6v2b51hI/fHJwM22ozAgKL4VKDeJcHhJFhtBdhmNjmU= +-github.com/jstemmer/go-junit-report v0.9.1/go.mod h1:Brl9GWCQeLvo8nXZwPNNblvFj/XSXhF0NWZEnDohbsk= +-github.com/julienschmidt/httprouter v1.2.0/go.mod h1:SYymIcj16QtmaHHD7aYtjjsJG7VTCxuUUipMqKk8s4w= +-github.com/julienschmidt/httprouter v1.3.0/go.mod h1:JR6WtHb+2LUe8TCKY3cZOxFyyO8IZAc4RVcycCCAKdM= +-github.com/julz/importas v0.1.0 h1:F78HnrsjY3cR7j0etXy5+TU1Zuy7Xt08X/1aJnH5xXY= +-github.com/julz/importas v0.1.0/go.mod h1:oSFU2R4XK/P7kNBrnL/FEQlDGN1/6WoxXEjSSXO0DV0= +-github.com/jung-kurt/gofpdf v1.0.3-0.20190309125859-24315acbbda5/go.mod h1:7Id9E/uU8ce6rXgefFLlgrJj/GYY22cpxn+r32jIOes= + github.com/kevinburke/ssh_config v1.2.0 h1:x584FjTGwHzMwvHx18PXxbBVzfnxogHaAReU4gf13a4= + github.com/kevinburke/ssh_config v1.2.0/go.mod h1:CT57kijsi8u/K/BOFA39wgDQJ9CxiF4nAY/ojJ6r6mM= + github.com/kisielk/errcheck v1.5.0/go.mod h1:pFxgyoBC7bSaBwPgfKdkLd5X25qrDl4LWUI2bnpBCr8= +-github.com/kisielk/errcheck v1.6.2 h1:uGQ9xI8/pgc9iOoCe7kWQgRE6SBTrCGmTSf0LrEtY7c= +-github.com/kisielk/errcheck v1.6.2/go.mod h1:nXw/i/MfnvRHqXa7XXmQMUB0oNFGuBrNI8d8NLy0LPw= +-github.com/kisielk/gotool v1.0.0 h1:AV2c/EiW3KqPNT9ZKl07ehoAGi4C5/01Cfbblndcapg= + github.com/kisielk/gotool v1.0.0/go.mod h1:XhKaO+MFFWcvkIS/tQcRk01m1F5IRFswLeQ+oQHNcck= +-github.com/kkHAIKE/contextcheck v1.1.3 h1:l4pNvrb8JSwRd51ojtcOxOeHJzHek+MtOyXbaR0uvmw= +-github.com/kkHAIKE/contextcheck v1.1.3/go.mod h1:PG/cwd6c0705/LM0KTr1acO2gORUxkSVWyLJOFW5qoo= + github.com/kkdai/bstream v0.0.0-20161212061736-f391b8402d23/go.mod h1:J+Gs4SYgM6CZQHDETBtE9HaSEkGmuNXF86RwHhHUvq4= + github.com/klauspost/compress v1.12.3/go.mod h1:8dP1Hq4DHOhN9w426knH3Rhby4rFm6D8eO+e+Dq5Gzg= +-github.com/klauspost/compress v1.17.0 h1:Rnbp4K9EjcDuVuHtd0dgA4qNuv9yKDYKK1ulpJwgrqM= +-github.com/klauspost/compress v1.17.0/go.mod h1:ntbaceVETuRiXiv4DpjP66DpAtAGkEQskQzEyD//IeE= +-github.com/klauspost/pgzip v1.2.5 h1:qnWYvvKqedOF2ulHpMG72XQol4ILEJ8k2wwRl/Km8oE= +-github.com/klauspost/pgzip v1.2.5/go.mod h1:Ch1tH69qFZu15pkjo5kYi6mth2Zzwzt50oCQKQE9RUs= +-github.com/konsorten/go-windows-terminal-sequences v1.0.1/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ= +-github.com/konsorten/go-windows-terminal-sequences v1.0.3/go.mod h1:T0+1ngSBFLxvqU3pZ+m/2kptfBszLMUkC4ZK/EgS/cQ= +-github.com/kr/logfmt v0.0.0-20140226030751-b84e30acd515/go.mod h1:+0opPa2QZZtGFBFZlji/RkVcI2GknAs/DXo4wKdlNEc= ++github.com/klauspost/compress v1.17.9 h1:6KIumPrER1LHsvBVuDa0r5xaG0Es51mhhB9BQB2qeMA= ++github.com/klauspost/compress v1.17.9/go.mod h1:Di0epgTjJY877eYKx5yC51cX2A2Vl2ibi7bDH9ttBbw= + github.com/kr/pretty v0.1.0/go.mod h1:dAy3ld7l9f0ibDNOQOHHMYYIIbhfbHSm3C4ZsoJORNo= + github.com/kr/pretty v0.2.1/go.mod h1:ipq/a2n7PKx3OHsz4KJII5eveXtPO4qwEXGdVfWzfnI= + github.com/kr/pretty v0.3.1 h1:flRD4NNwYAUpkphVc1HcthR4KEIFJ65n8Mw5qdRn3LE= +@@ -564,110 +267,45 @@ github.com/kr/pty v1.1.1/go.mod h1:pFQYn66WHrOpPYNljwOMqo10TkYh1fy3cYio2l3bCsQ= + github.com/kr/text v0.1.0/go.mod h1:4Jbv+DJW3UT/LiOwJeYQe1efqtUx/iVham/4vfdArNI= + github.com/kr/text v0.2.0 h1:5Nx0Ya0ZqY2ygV366QzturHI13Jq95ApcVaJBhpS+AY= + github.com/kr/text v0.2.0/go.mod h1:eLer722TekiGuMkidMxC/pM04lWEeraHUUmBw8l2grE= +-github.com/kulti/thelper v0.6.3 h1:ElhKf+AlItIu+xGnI990no4cE2+XaSu1ULymV2Yulxs= +-github.com/kulti/thelper v0.6.3/go.mod h1:DsqKShOvP40epevkFrvIwkCMNYxMeTNjdWL4dqWHZ6I= +-github.com/kunwardeep/paralleltest v1.0.6 h1:FCKYMF1OF2+RveWlABsdnmsvJrei5aoyZoaGS+Ugg8g= +-github.com/kunwardeep/paralleltest v1.0.6/go.mod h1:Y0Y0XISdZM5IKm3TREQMZ6iteqn1YuwCsJO/0kL9Zes= +-github.com/kyoh86/exportloopref v0.1.8 h1:5Ry/at+eFdkX9Vsdw3qU4YkvGtzuVfzT4X7S77LoN/M= +-github.com/kyoh86/exportloopref v0.1.8/go.mod h1:1tUcJeiioIs7VWe5gcOObrux3lb66+sBqGZrRkMwPgg= +-github.com/ldez/gomoddirectives v0.2.3 h1:y7MBaisZVDYmKvt9/l1mjNCiSA1BVn34U0ObUcJwlhA= +-github.com/ldez/gomoddirectives v0.2.3/go.mod h1:cpgBogWITnCfRq2qGoDkKMEVSaarhdBr6g8G04uz6d0= +-github.com/ldez/tagliatelle v0.3.1 h1:3BqVVlReVUZwafJUwQ+oxbx2BEX2vUG4Yu/NOfMiKiM= +-github.com/ldez/tagliatelle v0.3.1/go.mod h1:8s6WJQwEYHbKZDsp/LjArytKOG8qaMrKQQ3mFukHs88= +-github.com/leonklingele/grouper v1.1.0 h1:tC2y/ygPbMFSBOs3DcyaEMKnnwH7eYKzohOtRrf0SAg= +-github.com/leonklingele/grouper v1.1.0/go.mod h1:uk3I3uDfi9B6PeUjsCKi6ndcf63Uy7snXgR4yDYQVDY= +-github.com/lib/pq v1.0.0/go.mod h1:5WUZQaWbwv1U+lTReE5YruASi9Al49XbQIvNi/34Woo= +-github.com/lib/pq v1.10.6 h1:jbk+ZieJ0D7EVGJYpL9QTz7/YW6UHbmdnZWYyK5cdBs= +-github.com/lib/pq v1.10.6/go.mod h1:AlVN5x4E4T544tWzH6hKfbfQvm3HdbOxrmggDNAPY9o= ++github.com/kylelemons/godebug v1.1.0 h1:RPNrshWIDI6G2gRW9EHilWtl7Z6Sb1BR0xunSBf0SNc= ++github.com/kylelemons/godebug v1.1.0/go.mod h1:9/0rRGxNHcop5bhtWyNeEfOS8JIWk580+fNqagV/RAw= ++github.com/lib/pq v1.10.9 h1:YXG7RB+JIjhP29X+OtkiDnYaXQwpS4JEWq7dtCCRUEw= ++github.com/lib/pq v1.10.9/go.mod h1:AlVN5x4E4T544tWzH6hKfbfQvm3HdbOxrmggDNAPY9o= + github.com/libp2p/go-buffer-pool v0.1.0 h1:oK4mSFcQz7cTQIfqbe4MIj9gLW+mnanjyFtc6cdF0Y8= + github.com/libp2p/go-buffer-pool v0.1.0/go.mod h1:N+vh8gMqimBzdKkSMVuydVDq+UV5QTWy5HSiZacSbPg= +-github.com/linxGnu/grocksdb v1.8.6 h1:O7I6SIGPrypf3f/gmrrLUBQDKfO8uOoYdWf4gLS06tc= +-github.com/linxGnu/grocksdb v1.8.6/go.mod h1:xZCIb5Muw+nhbDK4Y5UJuOrin5MceOuiXkVUR7vp4WY= +-github.com/lufeee/execinquery v1.2.1 h1:hf0Ems4SHcUGBxpGN7Jz78z1ppVkP/837ZlETPCEtOM= +-github.com/lufeee/execinquery v1.2.1/go.mod h1:EC7DrEKView09ocscGHC+apXMIaorh4xqSxS/dy8SbM= + github.com/magiconair/properties v1.8.0/go.mod h1:PppfXfuXeibc/6YijjN8zIbojt8czPbwD3XqdrwzmxQ= + github.com/magiconair/properties v1.8.7 h1:IeQXZAiQcpL9mgcAe1Nu6cX9LLw6ExEHKjN0VQdvPDY= + github.com/magiconair/properties v1.8.7/go.mod h1:Dhd985XPs7jluiymwWYZ0G4Z61jb3vdS329zhj2hYo0= +-github.com/maratori/testableexamples v1.0.0 h1:dU5alXRrD8WKSjOUnmJZuzdxWOEQ57+7s93SLMxb2vI= +-github.com/maratori/testableexamples v1.0.0/go.mod h1:4rhjL1n20TUTT4vdh3RDqSizKLyXp7K2u6HgraZCGzE= +-github.com/maratori/testpackage v1.1.0 h1:GJY4wlzQhuBusMF1oahQCBtUV/AQ/k69IZ68vxaac2Q= +-github.com/maratori/testpackage v1.1.0/go.mod h1:PeAhzU8qkCwdGEMTEupsHJNlQu2gZopMC6RjbhmHeDc= +-github.com/matoous/godox v0.0.0-20210227103229-6504466cf951 h1:pWxk9e//NbPwfxat7RXkts09K+dEBJWakUWwICVqYbA= +-github.com/matoous/godox v0.0.0-20210227103229-6504466cf951/go.mod h1:1BELzlh859Sh1c6+90blK8lbYy0kwQf1bYlBhBysy1s= +-github.com/matryer/is v1.4.0 h1:sosSmIWwkYITGrxZ25ULNDeKiMNzFSr4V/eqBQP0PeE= +-github.com/matryer/is v1.4.0/go.mod h1:8I/i5uYgLzgsgEloJE1U6xx5HkBQpAZvepWuujKwMRU= +-github.com/mattn/go-colorable v0.1.12/go.mod h1:u5H1YNBxpqRaxsYJYSkiCWKzEfiAb1Gb520KVy5xxl4= +-github.com/mattn/go-colorable v0.1.13 h1:fFA4WZxdEF4tXPZVKMLwD8oUnCTTo08duU7wxecdEvA= +-github.com/mattn/go-colorable v0.1.13/go.mod h1:7S9/ev0klgBDR4GtXTXX8a3vIGJpMovkB8vQcUbaXHg= +-github.com/mattn/go-isatty v0.0.14/go.mod h1:7GGIvUiUoEMVVmxf/4nioHXj79iQHKdU27kJ6hsGG94= +-github.com/mattn/go-isatty v0.0.16/go.mod h1:kYGgaQfpe5nmfYZH+SKPsOc2e4SrIfOl2e/yFXSvRLM= +-github.com/mattn/go-isatty v0.0.17 h1:BTarxUcIeDqL27Mc+vyvdWYSL28zpIhv3RoTdsLMPng= +-github.com/mattn/go-isatty v0.0.17/go.mod h1:kYGgaQfpe5nmfYZH+SKPsOc2e4SrIfOl2e/yFXSvRLM= +-github.com/mattn/go-runewidth v0.0.9 h1:Lm995f3rfxdpd6TSmuVCHVb/QhupuXlYr8sCI/QdE+0= +-github.com/mattn/go-runewidth v0.0.9/go.mod h1:H031xJmbD/WCDINGzjvQ9THkh0rPKHF+m2gUSrubnMI= +-github.com/mattn/go-sqlite3 v1.9.0/go.mod h1:FPy6KqzDD04eiIsT53CuJW3U88zkxoIYsOqkbpncsNc= + github.com/mattn/go-sqlite3 v1.14.9 h1:10HX2Td0ocZpYEjhilsuo6WWtUqttj2Kb0KtD86/KYA= + github.com/mattn/go-sqlite3 v1.14.9/go.mod h1:NyWgC/yNuGj7Q9rpYnZvas74GogHl5/Z4A/KQRfk6bU= +-github.com/matttproud/golang_protobuf_extensions v1.0.1/go.mod h1:D8He9yQNgCq6Z5Ld7szi9bcBfOoFv/3dc6xSMkL2PC0= +-github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369 h1:I0XW9+e1XWDxdcEniV4rQAIOPUGDq67JSCiRCgGCZLI= +-github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369/go.mod h1:BSXmuO+STAnVfrANrmjBb36TMTDstsz7MSK+HVaYKv4= +-github.com/mbilski/exhaustivestruct v1.2.0 h1:wCBmUnSYufAHO6J4AVWY6ff+oxWxsVFrwgOdMUQePUo= +-github.com/mbilski/exhaustivestruct v1.2.0/go.mod h1:OeTBVxQWoEmB2J2JCHmXWPJ0aksxSUOUy+nvtVEfzXc= +-github.com/mgechev/revive v1.2.4 h1:+2Hd/S8oO2H0Ikq2+egtNwQsVhAeELHjxjIUFX5ajLI= +-github.com/mgechev/revive v1.2.4/go.mod h1:iAWlQishqCuj4yhV24FTnKSXGpbAA+0SckXB8GQMX/Q= + github.com/mimoo/StrobeGo v0.0.0-20181016162300-f8f6d4d2b643/go.mod h1:43+3pMjjKimDBf5Kr4ZFNGbLql1zKkbImw+fZbw3geM= + github.com/mimoo/StrobeGo v0.0.0-20210601165009-122bf33a46e0 h1:QRUSJEgZn2Snx0EmT/QLXibWjSUDjKWvXIT19NBVp94= + github.com/mimoo/StrobeGo v0.0.0-20210601165009-122bf33a46e0/go.mod h1:43+3pMjjKimDBf5Kr4ZFNGbLql1zKkbImw+fZbw3geM= +-github.com/minio/highwayhash v1.0.2 h1:Aak5U0nElisjDCfPSG79Tgzkn2gl66NxOMspRrKnA/g= +-github.com/minio/highwayhash v1.0.2/go.mod h1:BQskDq+xkJ12lmlUUi7U0M5Swg3EWR+dLTk+kldvVxY= +-github.com/mitchellh/go-homedir v1.1.0 h1:lukF9ziXFxDFPkA1vsr5zpc1XuPDn/wFntq5mG+4E0Y= ++github.com/minio/highwayhash v1.0.3 h1:kbnuUMoHYyVl7szWjSxJnxw11k2U709jqFPPmIUyD6Q= ++github.com/minio/highwayhash v1.0.3/go.mod h1:GGYsuwP/fPD6Y9hMiXuapVvlIUEhFhMTh0rxU3ik1LQ= + github.com/mitchellh/go-homedir v1.1.0/go.mod h1:SfyaCUpYCn1Vlf4IUYiD9fPX4A5wJrkLzIz1N1q0pr0= + github.com/mitchellh/mapstructure v1.1.2/go.mod h1:FVVH3fgwuzCH5S8UJGiWEs2h04kUh9fWfEaFds41c1Y= + github.com/mitchellh/mapstructure v1.5.0 h1:jeMsZIYE/09sWLaz43PL7Gy6RuMjD2eJVyuac5Z2hdY= + github.com/mitchellh/mapstructure v1.5.0/go.mod h1:bFUtVrKA4DC2yAKiSyO/QUcy7e+RRV2QTWOzhPopBRo= +-github.com/moby/buildkit v0.10.4 h1:FvC+buO8isGpUFZ1abdSLdGHZVqg9sqI4BbFL8tlzP4= +-github.com/moby/buildkit v0.10.4/go.mod h1:Yajz9vt1Zw5q9Pp4pdb3TCSUXJBIroIQGQ3TTs/sLug= + github.com/moby/sys/mountinfo v0.5.0/go.mod h1:3bMD3Rg+zkqx8MRYPi7Pyb0Ie97QEBmdxbhnCLlSvSU= +-github.com/moby/term v0.0.0-20220808134915-39b0c02b01ae h1:O4SWKdcHVCvYqyDV+9CJA1fcDN2L11Bule0iFy3YlAI= +-github.com/moby/term v0.0.0-20220808134915-39b0c02b01ae/go.mod h1:E2VnQOmVuvZB6UYnnDB0qG5Nq/1tD9acaOpo6xmt0Kw= +-github.com/modern-go/concurrent v0.0.0-20180228061459-e0a39a4cb421/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q= +-github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd/go.mod h1:6dJC0mAP4ikYIbvyc7fijjWJddQyLn8Ig3JB5CqoB9Q= +-github.com/modern-go/reflect2 v0.0.0-20180701023420-4b7aa43c6742/go.mod h1:bx2lNnkwVCuqBIxFjflWJWanXIb3RllmbCylyMrvgv0= +-github.com/modern-go/reflect2 v1.0.1/go.mod h1:bx2lNnkwVCuqBIxFjflWJWanXIb3RllmbCylyMrvgv0= +-github.com/modern-go/reflect2 v1.0.2/go.mod h1:yWuevngMOJpCy52FWWMvUC8ws7m/LJsjYzDa0/r8luk= +-github.com/moricho/tparallel v0.2.1 h1:95FytivzT6rYzdJLdtfn6m1bfFJylOJK41+lgv/EHf4= +-github.com/moricho/tparallel v0.2.1/go.mod h1:fXEIZxG2vdfl0ZF8b42f5a78EhjjD5mX8qUplsoSU4k= +-github.com/morikuni/aec v1.0.0 h1:nP9CBfwrvYnBRgY6qfDQkygYDmYwOilePFkwzv4dU8A= +-github.com/morikuni/aec v1.0.0/go.mod h1:BbKIizmSmc5MMPqRYbxO4ZU0S0+P200+tUnFx7PXmsc= ++github.com/moby/term v0.0.0-20221205130635-1aeaba878587 h1:HfkjXDfhgVaN5rmueG8cL8KKeFNecRCXFhaJ2qZ5SKA= ++github.com/moby/term v0.0.0-20221205130635-1aeaba878587/go.mod h1:8FzsFHVUBGZdbDsJw/ot+X+d5HLUbvklYLJ9uGfcI3Y= + github.com/mrunalp/fileutils v0.5.0/go.mod h1:M1WthSahJixYnrXQl/DFQuteStB1weuxD2QJNHXfbSQ= +-github.com/mwitkow/go-conntrack v0.0.0-20161129095857-cc309e4a2223/go.mod h1:qRWi+5nqEBWmkhHvq77mSJWrCKwh8bxhgT7d/eI7P4U= +-github.com/mwitkow/go-conntrack v0.0.0-20190716064945-2f068394615f/go.mod h1:qRWi+5nqEBWmkhHvq77mSJWrCKwh8bxhgT7d/eI7P4U= +-github.com/nakabonne/nestif v0.3.1 h1:wm28nZjhQY5HyYPx+weN3Q65k6ilSBxDb8v5S81B81U= +-github.com/nakabonne/nestif v0.3.1/go.mod h1:9EtoZochLn5iUprVDmDjqGKPofoUEBL8U4Ngq6aY7OE= +-github.com/nbutton23/zxcvbn-go v0.0.0-20210217022336-fa2cb2858354 h1:4kuARK6Y6FxaNu/BnU2OAaLF86eTVhP2hjTB6iMvItA= +-github.com/nbutton23/zxcvbn-go v0.0.0-20210217022336-fa2cb2858354/go.mod h1:KSVJerMDfblTH7p5MZaTt+8zaT2iEk3AkVb9PQdZuE8= +-github.com/niemeyer/pretty v0.0.0-20200227124842-a10e7caefd8e/go.mod h1:zD1mROLANZcx1PVRCS0qkT7pwLkGfwJo4zjcN/Tysno= +-github.com/nishanths/exhaustive v0.8.3 h1:pw5O09vwg8ZaditDp/nQRqVnrMczSJDxRDJMowvhsrM= +-github.com/nishanths/exhaustive v0.8.3/go.mod h1:qj+zJJUgJ76tR92+25+03oYUhzF4R7/2Wk7fGTfCHmg= +-github.com/nishanths/predeclared v0.2.2 h1:V2EPdZPliZymNAn79T8RkNApBjMmVKh5XRpLm/w98Vk= +-github.com/nishanths/predeclared v0.2.2/go.mod h1:RROzoN6TnGQupbC+lqggsOlcgysk3LMK/HI84Mp280c= ++github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 h1:C3w9PqII01/Oq1c1nUAm88MOHcQC9l5mIlSMApZMrHA= ++github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822/go.mod h1:+n7T8mK8HuQTcFwEeznm/DIxMOiR9yIdICNftLE1DvQ= + github.com/nxadm/tail v1.4.4 h1:DQuhQpB1tVlglWS2hLQ5OV6B5r8aGxSrPc5Qo6uTN78= + github.com/nxadm/tail v1.4.4/go.mod h1:kenIhsEOeOJmVchQTgglprH7qJGnHDVpk1VPCcaMI8A= +-github.com/olekukonko/tablewriter v0.0.5 h1:P2Ga83D34wi1o9J6Wh1mRuqd4mF/x/lgBS7N7AbDhec= +-github.com/olekukonko/tablewriter v0.0.5/go.mod h1:hPp6KlRPjbx+hW8ykQs1w3UBbZlj6HuIJcUGPhkA7kY= + github.com/onsi/ginkgo v1.6.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE= + github.com/onsi/ginkgo v1.7.0/go.mod h1:lLunBs/Ym6LB5Z9jYTR76FiuTmxDTDusOGeTQH+WWjE= + github.com/onsi/ginkgo v1.12.1/go.mod h1:zj2OWP4+oCPe1qIXoGWkgMRwljMUYCdkwsT2108oapk= + github.com/onsi/ginkgo v1.14.0 h1:2mOpI4JVVPBN+WQRa0WKH2eXR+Ey+uK4n7Zj0aYpIQA= + github.com/onsi/ginkgo v1.14.0/go.mod h1:iSB4RoI2tjJc9BBv4NKIKWKya62Rps+oPG/Lv9klQyY= +-github.com/onsi/ginkgo/v2 v2.1.4 h1:GNapqRSid3zijZ9H77KrgVG4/8KqiyRsxcSxe+7ApXY= +-github.com/onsi/ginkgo/v2 v2.1.4/go.mod h1:um6tUpWM/cxCK3/FK8BXqEiUMUwRgSM4JXG47RKZmLU= + github.com/onsi/gomega v1.4.1/go.mod h1:C1qb7wdrVGGVU+Z6iS04AVkA3Q65CEZX59MT0QO5uiA= + github.com/onsi/gomega v1.4.3/go.mod h1:ex+gbHU/CVuBBDIJjb2X0qEXbFg53c61hWP/1CpauHY= + github.com/onsi/gomega v1.7.1/go.mod h1:XdKZgCCFLUoM/7CFJVPcG8C1xQ1AJ0vpAezJrB7JYyY= + github.com/onsi/gomega v1.10.1/go.mod h1:iN09h71vgCQne3DLsj+A5owkum+a2tYe+TOCB1ybHNo= +-github.com/onsi/gomega v1.27.10 h1:naR28SdDFlqrG6kScpT8VWpu1xWY5nJRCF3XaYyBjhI= +-github.com/onsi/gomega v1.27.10/go.mod h1:RsS8tutOdbdgzbPtzzATp12yT7kM5I5aElG3evPbQ0M= ++github.com/onsi/gomega v1.34.2 h1:pNCwDkzrsv7MS9kpaQvVb1aVLahQXyJ/Tv5oAZMI3i8= ++github.com/onsi/gomega v1.34.2/go.mod h1:v1xfxRgk0KIsG+QOdm7p8UosrOzPYRo60fd3B/1Dukc= + github.com/opencontainers/go-digest v1.0.0 h1:apOUWs51W5PlhuyGyz9FCeeBIOUDA/6nW8Oi/yOhh5U= + github.com/opencontainers/go-digest v1.0.0/go.mod h1:0JzlMkj0TRzQZfJkVvzbP0HBR3IKzErnv2BNG4W4MAM= + github.com/opencontainers/image-spec v1.1.0-rc2 h1:2zx/Stx4Wc5pIPDvIxHXvXtQFW/7XWJGmnM7r3wg034= +@@ -676,144 +314,55 @@ github.com/opencontainers/runc v1.1.3 h1:vIXrkId+0/J2Ymu2m7VjGvbSlAId9XNRPhn2p4b + github.com/opencontainers/runc v1.1.3/go.mod h1:1J5XiS+vdZ3wCyZybsuxXZWGrgSr8fFJHLXuG2PsnNg= + github.com/opencontainers/runtime-spec v1.0.3-0.20210326190908-1c3f411f0417/go.mod h1:jwyrGlmzljRJv/Fgzds9SsS/C5hL+LL3ko9hs6T5lQ0= + github.com/opencontainers/selinux v1.10.0/go.mod h1:2i0OySw99QjzBBQByd1Gr9gSjvuho1lHsJxIJ3gGbJI= +-github.com/opentracing/opentracing-go v1.1.0/go.mod h1:UkNAQd3GIcIGf0SeVgPpRdFStlNbqXla1AfSYxPUl2o= + github.com/ory/dockertest v3.3.5+incompatible h1:iLLK6SQwIhcbrG783Dghaaa3WPzGc+4Emza6EbVUUGA= + github.com/ory/dockertest v3.3.5+incompatible/go.mod h1:1vX4m9wsvi00u5bseYwXaSnhNrne+V0E6LAcBILJdPs= + github.com/ory/dockertest/v3 v3.9.1 h1:v4dkG+dlu76goxMiTT2j8zV7s4oPPEppKT8K8p2f1kY= + github.com/ory/dockertest/v3 v3.9.1/go.mod h1:42Ir9hmvaAPm0Mgibk6mBPi7SFvTXxEcnztDYOJ//uM= +-github.com/otiai10/copy v1.2.0 h1:HvG945u96iNadPoG2/Ja2+AUJeW5YuFQMixq9yirC+k= +-github.com/otiai10/copy v1.2.0/go.mod h1:rrF5dJ5F0t/EWSYODDu4j9/vEeYHMkc8jt0zJChqQWw= +-github.com/otiai10/curr v0.0.0-20150429015615-9b4961190c95/go.mod h1:9qAhocn7zKJG+0mI8eUu6xqkFDYS2kb2saOteoSB3cE= +-github.com/otiai10/curr v1.0.0/go.mod h1:LskTG5wDwr8Rs+nNQ+1LlxRjAtTZZjtJW4rMXl6j4vs= +-github.com/otiai10/mint v1.3.0/go.mod h1:F5AjcsTsWUqX+Na9fpHb52P8pcRX2CI6A3ctIT91xUo= +-github.com/otiai10/mint v1.3.1/go.mod h1:/yxELlJQ0ufhjUwhshSj+wFjZ78CnZ48/1wtmBH1OTc= + github.com/pelletier/go-toml v1.2.0/go.mod h1:5z9KED0ma1S8pY6P1sdut58dfprrGBbd/94hg7ilaic= +-github.com/pelletier/go-toml/v2 v2.1.0 h1:FnwAJ4oYMvbT/34k9zzHuZNrhlz48GB3/s6at6/MHO4= +-github.com/pelletier/go-toml/v2 v2.1.0/go.mod h1:tJU2Z3ZkXwnxa4DPO899bsyIoywizdUvyaeZurnPPDc= ++github.com/pelletier/go-toml/v2 v2.2.3 h1:YmeHyLY8mFWbdkNWwpr+qIL2bEqT0o95WSdkNHvL12M= ++github.com/pelletier/go-toml/v2 v2.2.3/go.mod h1:MfCQTFTvCcUyyvvwm1+G6H/jORL20Xlb6rzQu9GuUkc= + github.com/petermattis/goid v0.0.0-20180202154549-b0b1615b78e5 h1:q2e307iGHPdTGp0hoxKjt1H5pDo6utceo3dQVK3I5XQ= + github.com/petermattis/goid v0.0.0-20180202154549-b0b1615b78e5/go.mod h1:jvVRKCrJTQWu0XVbaOlby/2lO20uSCHEMzzplHXte1o= +-github.com/phayes/checkstyle v0.0.0-20170904204023-bfd46e6a821d h1:CdDQnGF8Nq9ocOS/xlSptM1N3BbrA6/kmaep5ggwaIA= +-github.com/phayes/checkstyle v0.0.0-20170904204023-bfd46e6a821d/go.mod h1:3OzsM7FXDQlpCiw2j81fOmAwQLnZnLGXVKUzeKQXIAw= + github.com/philhofer/fwd v1.1.1/go.mod h1:gk3iGcWd9+svBvR0sR+KPcfE+RNWozjowpeBVG3ZVNU= + github.com/pjbgf/sha1cd v0.3.0 h1:4D5XXmUUBUl/xQ6IjCkEAbqXskkq/4O7LmGn0AqMDs4= + github.com/pjbgf/sha1cd v0.3.0/go.mod h1:nZ1rrWOcGJ5uZgEEVL1VUM9iRQiZvWdbZjkKyFzPPsI= +-github.com/pkg/browser v0.0.0-20210911075715-681adbf594b8 h1:KoWmjvw+nsYOo29YJK9vDA65RGE3NrOnUtO7a+RF9HU= +-github.com/pkg/browser v0.0.0-20210911075715-681adbf594b8/go.mod h1:HKlIX3XHQyzLZPlr7++PzdhaXEj94dEiJgZDTsxEqUI= +-github.com/pkg/errors v0.8.0/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0= + github.com/pkg/errors v0.8.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0= + github.com/pkg/errors v0.9.1 h1:FEBLx1zS214owpjy7qsBeixbURkuhQAwrK5UwLGTwt4= + github.com/pkg/errors v0.9.1/go.mod h1:bwawxfHBFNV+L2hUp1rHADufV3IMtnDRdf1r5NINEl0= +-github.com/pkg/profile v1.6.0 h1:hUDfIISABYI59DyeB3OTay/HxSRwTQ8rB/H83k6r5dM= +-github.com/pkg/profile v1.6.0/go.mod h1:qBsxPvzyUincmltOk6iyRVxHYg4adc0OFOv72ZdLa18= + github.com/pmezard/go-difflib v1.0.0/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4= + github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2 h1:Jamvg5psRIccs7FGNTlIRMkT8wgtp5eCXdBlqhYGL6U= + github.com/pmezard/go-difflib v1.0.1-0.20181226105442-5d4384ee4fb2/go.mod h1:iKH77koFhYxTK1pcRnkKkqfTogsbg7gZNVY4sRDYZ/4= +-github.com/polyfloyd/go-errorlint v1.0.5 h1:AHB5JRCjlmelh9RrLxT9sgzpalIwwq4hqE8EkwIwKdY= +-github.com/polyfloyd/go-errorlint v1.0.5/go.mod h1:APVvOesVSAnne5SClsPxPdfvZTVDojXh1/G3qb5wjGI= +-github.com/prometheus/client_golang v0.9.1/go.mod h1:7SWBe2y4D6OKWSNQJUaRYU/AaXPKyh/dDVn+NZz0KFw= +-github.com/prometheus/client_golang v1.0.0/go.mod h1:db9x61etRT2tGnBNRi70OPL5FsnadC4Ky3P0J6CfImo= +-github.com/prometheus/client_golang v1.7.1/go.mod h1:PY5Wy2awLA44sXw4AOSfFBetzPP4j5+D6mVACh+pe2M= +-github.com/prometheus/client_golang v1.11.0/go.mod h1:Z6t4BnS23TR94PD6BsDNk8yVqroYurpAkEiz0P2BEV0= +-github.com/prometheus/client_golang v1.12.1/go.mod h1:3Z9XVyYiZYEO+YQWt3RD2R3jrbd179Rt297l4aS6nDY= +-github.com/prometheus/client_golang v1.14.0 h1:nJdhIvne2eSX/XRAFV9PcvFFRbrjbcTUj0VP62TMhnw= +-github.com/prometheus/client_golang v1.14.0/go.mod h1:8vpkKitgIVNcqrRBWh1C4TIUQgYNtG/XQE4E/Zae36Y= +-github.com/prometheus/client_model v0.0.0-20180712105110-5c3871d89910/go.mod h1:MbSGuTsp3dbXC40dX6PRTWyKYBIrTGTE9sqQNg2J8bo= +-github.com/prometheus/client_model v0.0.0-20190129233127-fd36f4220a90/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA= +-github.com/prometheus/client_model v0.0.0-20190812154241-14fe0d1b01d4/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA= +-github.com/prometheus/client_model v0.2.0/go.mod h1:xMI15A0UPsDsEKsMN9yxemIoYk6Tm2C1GtYGdfGttqA= +-github.com/prometheus/client_model v0.3.0 h1:UBgGFHqYdG/TPFD1B1ogZywDqEkwp3fBMvqdiQ7Xew4= +-github.com/prometheus/client_model v0.3.0/go.mod h1:LDGWKZIo7rky3hgvBe+caln+Dr3dPggB5dvjtD7w9+w= +-github.com/prometheus/common v0.4.1/go.mod h1:TNfzLD0ON7rHzMJeJkieUDPYmFC7Snx/y86RQel1bk4= +-github.com/prometheus/common v0.10.0/go.mod h1:Tlit/dnDKsSWFlCLTWaA1cyBgKHSMdTB80sz/V91rCo= +-github.com/prometheus/common v0.26.0/go.mod h1:M7rCNAaPfAosfx8veZJCuw84e35h3Cfd9VFqTh1DIvc= +-github.com/prometheus/common v0.32.1/go.mod h1:vu+V0TpY+O6vW9J44gczi3Ap/oXXR10b+M/gUGO4Hls= +-github.com/prometheus/common v0.37.0 h1:ccBbHCgIiT9uSoFY0vX8H3zsNR5eLt17/RQLUvn8pXE= +-github.com/prometheus/common v0.37.0/go.mod h1:phzohg0JFMnBEFGxTDbfu3QyL5GI8gTQJFhYO5B3mfA= +-github.com/prometheus/procfs v0.0.0-20181005140218-185b4288413d/go.mod h1:c3At6R/oaqEKCNdg8wHV1ftS6bRYblBhIjjI8uT2IGk= +-github.com/prometheus/procfs v0.0.2/go.mod h1:TjEm7ze935MbeOT/UhFTIMYKhuLP4wbCsTZCD3I8kEA= +-github.com/prometheus/procfs v0.1.3/go.mod h1:lV6e/gmhEcM9IjHGsFOCxxuZ+z1YqCvr4OA4YeYWdaU= +-github.com/prometheus/procfs v0.6.0/go.mod h1:cz+aTbrPOrUb4q7XlbU9ygM+/jj0fzG6c1xBZuNvfVA= +-github.com/prometheus/procfs v0.7.3/go.mod h1:cz+aTbrPOrUb4q7XlbU9ygM+/jj0fzG6c1xBZuNvfVA= +-github.com/prometheus/procfs v0.8.0 h1:ODq8ZFEaYeCaZOJlZZdJA2AbQR98dSHSM1KW/You5mo= +-github.com/prometheus/procfs v0.8.0/go.mod h1:z7EfXMXOkbkqb9IINtpCn86r/to3BnA0uaxHdg830/4= +-github.com/quasilyte/go-ruleguard v0.3.1-0.20210203134552-1b5a410e1cc8/go.mod h1:KsAh3x0e7Fkpgs+Q9pNLS5XpFSvYCEVl5gP9Pp1xp30= +-github.com/quasilyte/go-ruleguard v0.3.18 h1:sd+abO1PEI9fkYennwzHn9kl3nqP6M5vE7FiOzZ+5CE= +-github.com/quasilyte/go-ruleguard v0.3.18/go.mod h1:lOIzcYlgxrQ2sGJ735EHXmf/e9MJ516j16K/Ifcttvs= +-github.com/quasilyte/go-ruleguard/dsl v0.3.0/go.mod h1:KeCP03KrjuSO0H1kTuZQCWlQPulDV6YMIXmpQss17rU= +-github.com/quasilyte/go-ruleguard/dsl v0.3.21/go.mod h1:KeCP03KrjuSO0H1kTuZQCWlQPulDV6YMIXmpQss17rU= +-github.com/quasilyte/go-ruleguard/rules v0.0.0-20201231183845-9e62ed36efe1/go.mod h1:7JTjp89EGyU1d6XfBiXihJNG37wB2VRkd125Q1u7Plc= +-github.com/quasilyte/go-ruleguard/rules v0.0.0-20211022131956-028d6511ab71/go.mod h1:4cgAphtvu7Ftv7vOT2ZOYhC6CvBxZixcasr8qIOTA50= +-github.com/quasilyte/gogrep v0.0.0-20220828223005-86e4605de09f h1:6Gtn2i04RD0gVyYf2/IUMTIs+qYleBt4zxDqkLTcu4U= +-github.com/quasilyte/gogrep v0.0.0-20220828223005-86e4605de09f/go.mod h1:Cm9lpz9NZjEoL1tgZ2OgeUKPIxL1meE7eo60Z6Sk+Ng= +-github.com/quasilyte/regex/syntax v0.0.0-20200407221936-30656e2c4a95 h1:L8QM9bvf68pVdQ3bCFZMDmnt9yqcMBro1pC7F+IPYMY= +-github.com/quasilyte/regex/syntax v0.0.0-20200407221936-30656e2c4a95/go.mod h1:rlzQ04UMyJXu/aOvhd8qT+hvDrFpiwqp8MRXDY9szc0= +-github.com/quasilyte/stdinfo v0.0.0-20220114132959-f7386bf02567 h1:M8mH9eK4OUR4lu7Gd+PU1fV2/qnDNfzT635KRSObncs= +-github.com/quasilyte/stdinfo v0.0.0-20220114132959-f7386bf02567/go.mod h1:DWNGW8A4Y+GyBgPuaQJuWiy0XYftx4Xm/y5Jqk9I6VQ= ++github.com/prometheus/client_golang v1.20.3 h1:oPksm4K8B+Vt35tUhw6GbSNSgVlVSBH0qELP/7u83l4= ++github.com/prometheus/client_golang v1.20.3/go.mod h1:PIEt8X02hGcP8JWbeHyeZ53Y/jReSnHgO035n//V5WE= ++github.com/prometheus/client_model v0.6.1 h1:ZKSh/rekM+n3CeS952MLRAdFwIKqeY8b62p8ais2e9E= ++github.com/prometheus/client_model v0.6.1/go.mod h1:OrxVMOVHjw3lKMa8+x6HeMGkHMQyHDk9E3jmP2AmGiY= ++github.com/prometheus/common v0.55.0 h1:KEi6DK7lXW/m7Ig5i47x0vRzuBsHuvJdi5ee6Y3G1dc= ++github.com/prometheus/common v0.55.0/go.mod h1:2SECS4xJG1kd8XF9IcM1gMX6510RAEL65zxzNImwdc8= ++github.com/prometheus/procfs v0.15.1 h1:YagwOFzUgYfKKHX6Dr+sHT7km/hxC76UB0learggepc= ++github.com/prometheus/procfs v0.15.1/go.mod h1:fB45yRUv8NstnjriLhBQLuOUt+WW4BsoGhij/e3PBqk= + github.com/rcrowley/go-metrics v0.0.0-20201227073835-cf1acfcdf475 h1:N/ElC8H3+5XpJzTSTfLsJV/mx9Q9g7kxmchpfZyxgzM= + github.com/rcrowley/go-metrics v0.0.0-20201227073835-cf1acfcdf475/go.mod h1:bCqnVzQkZxMG4s8nGwiZ5l3QUCyqpo9Y+/ZMZ9VjZe4= +-github.com/rogpeppe/go-internal v1.3.0/go.mod h1:M8bDsm7K2OlrFYOpmOWEs/qY81heoFRclV5y23lUDJ4= +-github.com/rogpeppe/go-internal v1.11.0 h1:cWPaGQEPrBb5/AsnsZesgZZ9yb1OQ+GOISoDNXVBh4M= +-github.com/rogpeppe/go-internal v1.11.0/go.mod h1:ddIwULY96R17DhadqLgMfk9H9tvdUzkipdSkR5nkCZA= +-github.com/rs/cors v1.8.2 h1:KCooALfAYGs415Cwu5ABvv9n9509fSiG5SQJn/AQo4U= +-github.com/rs/cors v1.8.2/go.mod h1:XyqrcTp5zjWr1wsJ8PIRZssZ8b/WMcMf71DJnit4EMU= +-github.com/rs/xid v1.3.0/go.mod h1:trrq9SKmegXys3aeAKXMUTdJsYXVwGY3RLcfgqegfbg= +-github.com/rs/zerolog v1.27.0 h1:1T7qCieN22GVc8S4Q2yuexzBb1EqjbgjSH9RohbMjKs= +-github.com/rs/zerolog v1.27.0/go.mod h1:7frBqO0oezxmnO7GF86FY++uy8I0Tk/If5ni1G9Qc0U= ++github.com/rogpeppe/go-internal v1.12.0 h1:exVL4IDcn6na9z1rAb56Vxr+CgyK3nn3O+epU5NdKM8= ++github.com/rogpeppe/go-internal v1.12.0/go.mod h1:E+RYuTGaKKdloAfM02xzb0FW3Paa99yedzYV+kq4uf4= ++github.com/rs/cors v1.8.3 h1:O+qNyWn7Z+F9M0ILBHgMVPuB1xTOucVd5gtaYyXBpRo= ++github.com/rs/cors v1.8.3/go.mod h1:XyqrcTp5zjWr1wsJ8PIRZssZ8b/WMcMf71DJnit4EMU= + github.com/russross/blackfriday v1.5.2/go.mod h1:JO/DiYxRf+HjHt06OyowR9PTA263kcR/rfWxYHBV53g= + github.com/russross/blackfriday/v2 v2.0.1/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM= +-github.com/russross/blackfriday/v2 v2.1.0 h1:JIOH55/0cWyOuilr9/qlrm0BSXldqnqwMsf35Ld67mk= + github.com/russross/blackfriday/v2 v2.1.0/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM= +-github.com/ryancurrah/gomodguard v1.2.4 h1:CpMSDKan0LtNGGhPrvupAoLeObRFjND8/tU1rEOtBp4= +-github.com/ryancurrah/gomodguard v1.2.4/go.mod h1:+Kem4VjWwvFpUJRJSwa16s1tBJe+vbv02+naTow2f6M= +-github.com/ryanrolds/sqlclosecheck v0.3.0 h1:AZx+Bixh8zdUBxUA1NxbxVAS78vTPq4rCb8OUZI9xFw= +-github.com/ryanrolds/sqlclosecheck v0.3.0/go.mod h1:1gREqxyTGR3lVtpngyFo3hZAgk0KCtEdgEkHwDbigdA= +-github.com/sagikazarmark/locafero v0.4.0 h1:HApY1R9zGo4DBgr7dqsTH/JJxLTTsOt7u6keLGt6kNQ= +-github.com/sagikazarmark/locafero v0.4.0/go.mod h1:Pe1W6UlPYUk/+wc/6KFhbORCfqzgYEpgQ3O5fPuL3H4= +-github.com/sagikazarmark/slog-shim v0.1.0 h1:diDBnUNK9N/354PgrxMywXnAwEr1QZcOr6gto+ugjYE= +-github.com/sagikazarmark/slog-shim v0.1.0/go.mod h1:SrcSrq8aKtyuqEI1uvTDTK1arOWRIczQRv+GVI1AkeQ= +-github.com/sanposhiho/wastedassign/v2 v2.0.6 h1:+6/hQIHKNJAUixEj6EmOngGIisyeI+T3335lYTyxRoA= +-github.com/sanposhiho/wastedassign/v2 v2.0.6/go.mod h1:KyZ0MWTwxxBmfwn33zh3k1dmsbF2ud9pAAGfoLfjhtI= + github.com/sasha-s/go-deadlock v0.3.1 h1:sqv7fDNShgjcaxkO0JNcOAlr8B9+cV5Ey/OB71efZx0= + github.com/sasha-s/go-deadlock v0.3.1/go.mod h1:F73l+cr82YSh10GxyRI6qZiCgK64VaZjwesgfQ1/iLM= +-github.com/sashamelentyev/interfacebloat v1.1.0 h1:xdRdJp0irL086OyW1H/RTZTr1h/tMEOsumirXcOJqAw= +-github.com/sashamelentyev/interfacebloat v1.1.0/go.mod h1:+Y9yU5YdTkrNvoX0xHc84dxiN1iBi9+G8zZIhPVoNjQ= +-github.com/sashamelentyev/usestdlibvars v1.20.0 h1:K6CXjqqtSYSsuyRDDC7Sjn6vTMLiSJa4ZmDkiokoqtw= +-github.com/sashamelentyev/usestdlibvars v1.20.0/go.mod h1:0GaP+ecfZMXShS0A94CJn6aEuPRILv8h/VuWI9n1ygg= +-github.com/satori/go.uuid v1.2.0 h1:0uYX9dsZ2yD7q2RtLRtPSdGDWzjeM3TbMJP9utgA0ww= +-github.com/satori/go.uuid v1.2.0/go.mod h1:dA0hQrYB0VpLJoorglMZABFdXlWrHn1NEOzdhQKdks0= + github.com/seccomp/libseccomp-golang v0.9.2-0.20220502022130-f33da4d89646/go.mod h1:JA8cRccbGaA1s33RQf7Y1+q9gHmZX1yB/z9WDN1C6fg= +-github.com/securego/gosec/v2 v2.13.1 h1:7mU32qn2dyC81MH9L2kefnQyRMUarfDER3iQyMHcjYM= +-github.com/securego/gosec/v2 v2.13.1/go.mod h1:EO1sImBMBWFjOTFzMWfTRrZW6M15gm60ljzrmy/wtHo= +-github.com/sergi/go-diff v1.2.0 h1:XU+rvMAioB0UC3q1MFrIQy4Vo5/4VsRDQQXHsEya6xQ= +-github.com/sergi/go-diff v1.2.0/go.mod h1:STckp+ISIX8hZLjrqAeVduY0gWCT9IjLuqbuNXdaHfM= +-github.com/shazow/go-diff v0.0.0-20160112020656-b6b7b6733b8c h1:W65qqJCIOVP4jpqPQ0YvHYKwcMEMVWIzWC5iNQQfBTU= +-github.com/shazow/go-diff v0.0.0-20160112020656-b6b7b6733b8c/go.mod h1:/PevMnwAxekIXwN8qQyfc5gl2NlkB3CQlkizAbOkeBs= +-github.com/shurcooL/go v0.0.0-20180423040247-9e1955d9fb6e/go.mod h1:TDJrrUr11Vxrven61rcy3hJMUqaf/CLWYhHNPmT14Lk= +-github.com/shurcooL/go-goon v0.0.0-20170922171312-37c2f522c041/go.mod h1:N5mDOmsrJOB+vfqUK+7DmDyjhSLIIBnXo9lvZJj3MWQ= ++github.com/sergi/go-diff v1.3.2-0.20230802210424-5b0b94c5c0d3 h1:n661drycOFuPLCN3Uc8sB6B/s6Z4t2xvBgU1htSHuq8= ++github.com/sergi/go-diff v1.3.2-0.20230802210424-5b0b94c5c0d3/go.mod h1:A0bzQcvG0E7Rwjx0REVgAGH58e96+X0MeOfepqsbeW4= + github.com/shurcooL/sanitized_anchor_name v1.0.0/go.mod h1:1NzhyTcUVG4SuEtjjoZeVRXNmyL/1OwPU0+IJeTBvfc= +-github.com/sirupsen/logrus v1.2.0/go.mod h1:LxeOpSwHxABJmUn/MG1IvRgCAasNZTLOkJPxbbu5VWo= +-github.com/sirupsen/logrus v1.4.2/go.mod h1:tLMulIdttU9McNUspp0xgXVQah82FyeX6MwdIuYE2rE= +-github.com/sirupsen/logrus v1.6.0/go.mod h1:7uNnSEd1DgxDLC74fIahvMZmmYsHGZGEOFrfsX/uA88= + github.com/sirupsen/logrus v1.7.0/go.mod h1:yWOB1SBYBC5VeMP7gHvWumXLIWorT60ONWic61uBYv0= + github.com/sirupsen/logrus v1.8.1/go.mod h1:yWOB1SBYBC5VeMP7gHvWumXLIWorT60ONWic61uBYv0= +-github.com/sirupsen/logrus v1.9.0 h1:trlNQbNUG3OdDrDil03MCb1H2o9nJ1x4/5LYw7byDE0= +-github.com/sirupsen/logrus v1.9.0/go.mod h1:naHLuLoDiP4jHNo9R0sCBMtWGeIprob74mVsIT4qYEQ= +-github.com/sivchari/containedctx v1.0.2 h1:0hLQKpgC53OVF1VT7CeoFHk9YKstur1XOgfYIc1yrHI= +-github.com/sivchari/containedctx v1.0.2/go.mod h1:PwZOeqm4/DLoJOqMSIJs3aKqXRX4YO+uXww087KZ7Bw= +-github.com/sivchari/nosnakecase v1.7.0 h1:7QkpWIRMe8x25gckkFd2A5Pi6Ymo0qgr4JrhGt95do8= +-github.com/sivchari/nosnakecase v1.7.0/go.mod h1:CwDzrzPea40/GB6uynrNLiorAlgFRvRbFSgJx2Gs+QY= +-github.com/sivchari/tenv v1.7.0 h1:d4laZMBK6jpe5PWepxlV9S+LC0yXqvYHiq8E6ceoVVE= +-github.com/sivchari/tenv v1.7.0/go.mod h1:64yStXKSOxDfX47NlhVwND4dHwfZDdbp2Lyl018Icvg= +-github.com/skeema/knownhosts v1.2.1 h1:SHWdIUa82uGZz+F+47k8SY4QhhI291cXCpopT1lK2AQ= +-github.com/skeema/knownhosts v1.2.1/go.mod h1:xYbVRSPxqBZFrdmDyMmsOs+uX1UZC3nTN3ThzgDxUwo= ++github.com/sirupsen/logrus v1.9.3 h1:dueUQJ1C2q9oE3F7wvmSGAaVtTmUizReu6fjN8uqzbQ= ++github.com/sirupsen/logrus v1.9.3/go.mod h1:naHLuLoDiP4jHNo9R0sCBMtWGeIprob74mVsIT4qYEQ= ++github.com/skeema/knownhosts v1.3.0 h1:AM+y0rI04VksttfwjkSTNQorvGqmwATnvnAHpSgc0LY= ++github.com/skeema/knownhosts v1.3.0/go.mod h1:sPINvnADmT/qYH1kfv+ePMmOBTH6Tbl7b5LvTDjFK7M= + github.com/snikch/goodman v0.0.0-20171125024755-10e37e294daa h1:YJfZp12Z3AFhSBeXOlv4BO55RMwPn2NoQeDsrdWnBtY= + github.com/snikch/goodman v0.0.0-20171125024755-10e37e294daa/go.mod h1:oJyF+mSPHbB5mVY2iO9KV3pTt/QbIkGaO8gQ2WrDbP4= +-github.com/sonatard/noctx v0.0.1 h1:VC1Qhl6Oxx9vvWo3UDgrGXYCeKCe3Wbw7qAWL6FrmTY= +-github.com/sonatard/noctx v0.0.1/go.mod h1:9D2D/EoULe8Yy2joDHJj7bv3sZoq9AaSb8B4lqBjiZI= +-github.com/sourcegraph/conc v0.3.0 h1:OQTbbt6P72L20UqAkXXuLOj79LfEanQ+YQFNpLA9ySo= +-github.com/sourcegraph/conc v0.3.0/go.mod h1:Sdozi7LEKbFPqYX2/J+iBAM6HpqSLTASQIKqDmF7Mt0= +-github.com/sourcegraph/go-diff v0.6.1 h1:hmA1LzxW0n1c3Q4YbrFgg4P99GSnebYa3x8gr0HZqLQ= +-github.com/sourcegraph/go-diff v0.6.1/go.mod h1:iBszgVvyxdc8SFZ7gm69go2KDdt3ag071iBaWPF6cjs= + github.com/spaolacci/murmur3 v0.0.0-20180118202830-f09979ecbc72/go.mod h1:JwIasOWyU6f++ZhiEuf87xNszmSA2myDM2Kzu9HwQUA= + github.com/spaolacci/murmur3 v1.1.0 h1:7c1g84S4BPRrfL5Xrdp6fOJ206sU9y293DDHaoy0bLI= + github.com/spaolacci/murmur3 v1.1.0/go.mod h1:JwIasOWyU6f++ZhiEuf87xNszmSA2myDM2Kzu9HwQUA= +@@ -824,70 +373,47 @@ github.com/spf13/cast v1.3.0/go.mod h1:Qx5cxh0v+4UWYiBimWS+eyWzqEqokIECu5etghLkU + github.com/spf13/cast v1.6.0 h1:GEiTHELF+vaR5dhz3VqZfFSzZjYbgeKDpBxQVS4GYJ0= + github.com/spf13/cast v1.6.0/go.mod h1:ancEpBxwJDODSW/UG4rDrAqiKolqNNh2DX3mk86cAdo= + github.com/spf13/cobra v0.0.5/go.mod h1:3K3wKZymM7VvHMDS9+Akkh4K60UwM26emMESw8tLCHU= +-github.com/spf13/cobra v1.8.0 h1:7aJaZx1B85qltLMc546zn58BxxfZdR/W22ej9CFoEf0= +-github.com/spf13/cobra v1.8.0/go.mod h1:WXLWApfZ71AjXPya3WOlMsY9yMs7YeiHhFVlvLyhcho= ++github.com/spf13/cobra v1.8.1 h1:e5/vxKd/rZsfSJMUX1agtjeTDf+qv1/JdBF8gg5k9ZM= ++github.com/spf13/cobra v1.8.1/go.mod h1:wHxEcudfqmLYa8iTfL+OuZPbBZkmvliBWKIezN3kD9Y= + github.com/spf13/jwalterweatherman v1.0.0/go.mod h1:cQK4TGJAtQXfYWX+Ddv3mKDzgVb68N+wFjFa4jdeBTo= ++github.com/spf13/jwalterweatherman v1.1.0 h1:ue6voC5bR5F8YxI5S67j9i582FU4Qvo2bmqnqMYADFk= ++github.com/spf13/jwalterweatherman v1.1.0/go.mod h1:aNWZUN0dPAAO/Ljvb5BEdw96iTZ0EXowPYD95IqWIGo= + github.com/spf13/pflag v1.0.3/go.mod h1:DYY7MBk1bdzusC3SYhjObp+wFpr4gzcvqqNjLnInEg4= + github.com/spf13/pflag v1.0.5 h1:iy+VFUOCP1a+8yFto/drg2CJ5u0yRoB7fZw3DKv/JXA= + github.com/spf13/pflag v1.0.5/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg= + github.com/spf13/viper v1.3.2/go.mod h1:ZiWeW+zYFKm7srdB9IoDzzZXaJaI5eL9QjNiN/DMA2s= +-github.com/spf13/viper v1.18.1 h1:rmuU42rScKWlhhJDyXZRKJQHXFX02chSVW1IvkPGiVM= +-github.com/spf13/viper v1.18.1/go.mod h1:EKmWIqdnk5lOcmR72yw6hS+8OPYcwD0jteitLMVB+yk= +-github.com/ssgreg/nlreturn/v2 v2.2.1 h1:X4XDI7jstt3ySqGU86YGAURbxw3oTDPK9sPEi6YEwQ0= +-github.com/ssgreg/nlreturn/v2 v2.2.1/go.mod h1:E/iiPB78hV7Szg2YfRgyIrk1AD6JVMTRkkxBiELzh2I= +-github.com/stbenjam/no-sprintf-host-port v0.1.1 h1:tYugd/yrm1O0dV+ThCbaKZh195Dfm07ysF0U6JQXczc= +-github.com/stbenjam/no-sprintf-host-port v0.1.1/go.mod h1:TLhvtIvONRzdmkFiio4O8LHsN9N74I+PhRquPsxpL0I= ++github.com/spf13/viper v1.15.0 h1:js3yy885G8xwJa6iOISGFwd+qlUo5AvyXb7CiihdtiU= ++github.com/spf13/viper v1.15.0/go.mod h1:fFcTBJxvhhzSJiZy8n+PeW6t8l+KeT/uTARa0jHOQLA= + github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME= +-github.com/stretchr/objx v0.1.1/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME= + github.com/stretchr/objx v0.4.0/go.mod h1:YvHI0jy2hoMjB+UWwv71VJQ9isScKT/TqJzVSSt89Yw= +-github.com/stretchr/objx v0.5.0 h1:1zr/of2m5FGMsad5YfcqgdqdWrIhu+EBEJRhR1U7z/c= + github.com/stretchr/objx v0.5.0/go.mod h1:Yh+to48EsGEfYuaHDzXPcE3xhTkx73EhmCGUpEOglKo= +-github.com/stretchr/testify v1.1.4/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs= ++github.com/stretchr/objx v0.5.2 h1:xuMeJ0Sdp5ZMRXx/aWO6RZxdr3beISkG5/G/aIRr3pY= ++github.com/stretchr/objx v0.5.2/go.mod h1:FRsXN1f5AsAjCGJKqEizvkpNtU+EGNCLh3NxZ/8L+MA= + github.com/stretchr/testify v1.2.2/go.mod h1:a8OnRcib4nhh0OaRAV+Yts87kKdq0PP7pXfy6kDkUVs= +-github.com/stretchr/testify v1.3.0/go.mod h1:M5WIy9Dh21IEIfnGCwXGc5bZfKNJtfHm1UVUgZn+9EI= + github.com/stretchr/testify v1.4.0/go.mod h1:j7eGeouHqKxXV5pUuKE4zz7dFj8WfuZ+81PSLYec5m4= +-github.com/stretchr/testify v1.5.1/go.mod h1:5W2xD1RspED5o8YsWQXVCued0rvSQ+mT+I5cxcmMvtA= + github.com/stretchr/testify v1.7.0/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg= + github.com/stretchr/testify v1.7.1/go.mod h1:6Fq8oRcR53rry900zMqJjRRixrwX3KX962/h/Wwjteg= + github.com/stretchr/testify v1.8.0/go.mod h1:yNjHg4UonilssWZ8iaSj1OCr/vHnekPRkoO+kdMU+MU= +-github.com/stretchr/testify v1.8.1/go.mod h1:w2LPCIKwWwSfY2zedu0+kehJoqGctiVI29o6fzry7u4= +-github.com/stretchr/testify v1.8.4 h1:CcVxjf3Q8PM0mHUKJCdn+eZZtm5yQwehR5yeSVQQcUk= + github.com/stretchr/testify v1.8.4/go.mod h1:sz/lmYIOXD/1dqDmKjjqLyZ2RngseejIcXlSw2iwfAo= +-github.com/subosito/gotenv v1.6.0 h1:9NlTDc1FTs4qu0DDq7AEtTPNw6SVm7uBMsUCUjABIf8= +-github.com/subosito/gotenv v1.6.0/go.mod h1:Dk4QP5c2W3ibzajGcXpNraDfq2IrhjMIvMSWPKKo0FU= ++github.com/stretchr/testify v1.10.0 h1:Xv5erBjTwe/5IxqUQTdXv5kgmIvbHo3QQyRwhJsOfJA= ++github.com/stretchr/testify v1.10.0/go.mod h1:r2ic/lqez/lEtzL7wO/rwa5dbSLXVDPFyf8C91i36aY= ++github.com/subosito/gotenv v1.4.2 h1:X1TuBLAMDFbaTAChgCBLu3DU3UPyELpnF2jjJ2cz/S8= ++github.com/subosito/gotenv v1.4.2/go.mod h1:ayKnFf/c6rvx/2iiLrJUk1e6plDbT3edrFNGqEflhK0= + github.com/syndtr/gocapability v0.0.0-20200815063812-42c35b437635/go.mod h1:hkRG7XYTFWNJGYcbNJQlaLq0fg1yr4J4t/NcTQtrfww= + github.com/syndtr/goleveldb v1.0.1-0.20210819022825-2ae1ddf74ef7 h1:epCh84lMvA70Z7CTTCmYQn2CKbY8j86K7/FAIr141uY= + github.com/syndtr/goleveldb v1.0.1-0.20210819022825-2ae1ddf74ef7/go.mod h1:q4W45IWZaF22tdD+VEXcAWRA037jwmWEB5VWYORlTpc= +-github.com/tdakkota/asciicheck v0.1.1 h1:PKzG7JUTUmVspQTDqtkX9eSiLGossXTybutHwTXuO0A= +-github.com/tdakkota/asciicheck v0.1.1/go.mod h1:yHp0ai0Z9gUljN3o0xMhYJnH/IcvkdTBOX2fmJ93JEM= + github.com/tecbot/gorocksdb v0.0.0-20191217155057-f0fad39f321c h1:g+WoO5jjkqGAzHWCjJB1zZfXPIAaDpzXIEJ0eS6B5Ok= + github.com/tecbot/gorocksdb v0.0.0-20191217155057-f0fad39f321c/go.mod h1:ahpPrc7HpcfEWDQRZEmnXMzHY03mLDYMCxeDzy46i+8= +-github.com/tenntenn/modver v1.0.1 h1:2klLppGhDgzJrScMpkj9Ujy3rXPUspSjAcev9tSEBgA= +-github.com/tenntenn/modver v1.0.1/go.mod h1:bePIyQPb7UeioSRkw3Q0XeMhYZSMx9B8ePqg6SAMGH0= +-github.com/tenntenn/text/transform v0.0.0-20200319021203-7eef512accb3 h1:f+jULpRQGxTSkNYKJ51yaw6ChIqO+Je8UqsTKN/cDag= +-github.com/tenntenn/text/transform v0.0.0-20200319021203-7eef512accb3/go.mod h1:ON8b8w4BN/kE1EOhwT0o+d62W65a6aPw1nouo9LMgyY= +-github.com/tetafro/godot v1.4.11 h1:BVoBIqAf/2QdbFmSwAWnaIqDivZdOV0ZRwEm6jivLKw= +-github.com/tetafro/godot v1.4.11/go.mod h1:LR3CJpxDVGlYOWn3ZZg1PgNZdTUvzsZWu8xaEohUpn8= +-github.com/timakin/bodyclose v0.0.0-20210704033933-f49887972144 h1:kl4KhGNsJIbDHS9/4U9yQo1UcPQM0kOMJHn29EoH/Ro= +-github.com/timakin/bodyclose v0.0.0-20210704033933-f49887972144/go.mod h1:Qimiffbc6q9tBWlVV6x0P9sat/ao1xEkREYPPj9hphk= +-github.com/timonwong/loggercheck v0.9.3 h1:ecACo9fNiHxX4/Bc02rW2+kaJIAMAes7qJ7JKxt0EZI= +-github.com/timonwong/loggercheck v0.9.3/go.mod h1:wUqnk9yAOIKtGA39l1KLE9Iz0QiTocu/YZoOf+OzFdw= ++github.com/tidwall/gjson v1.18.0 h1:FIDeeyB800efLX89e5a8Y0BNH+LOngJyGrIWxG2FKQY= ++github.com/tidwall/gjson v1.18.0/go.mod h1:/wbyibRr2FHMks5tjHJ5F8dMZh3AcwJEMf5vlfC0lxk= ++github.com/tidwall/match v1.1.1 h1:+Ho715JplO36QYgwN9PGYNhgZvoUSc9X2c80KVTi+GA= ++github.com/tidwall/match v1.1.1/go.mod h1:eRSPERbgtNPcGhD8UCthc6PmLEQXEWd3PRB5JTxsfmM= ++github.com/tidwall/pretty v1.2.1 h1:qjsOFOWWQl+N3RsoF5/ssm1pHmJJwhjlSbZ51I6wMl4= ++github.com/tidwall/pretty v1.2.1/go.mod h1:ITEVvHYasfjBbM0u2Pg8T2nJnzm8xPwvNhhsoaGGjNU= + github.com/tinylib/msgp v1.1.5/go.mod h1:eQsjooMTnV42mHu917E26IogZ2930nFyBQdofk10Udg= +-github.com/tomarrell/wrapcheck/v2 v2.7.0 h1:J/F8DbSKJC83bAvC6FoZaRjZiZ/iKoueSdrEkmGeacA= +-github.com/tomarrell/wrapcheck/v2 v2.7.0/go.mod h1:ao7l5p0aOlUNJKI0qVwB4Yjlqutd0IvAB9Rdwyilxvg= +-github.com/tommy-muehle/go-mnd/v2 v2.5.1 h1:NowYhSdyE/1zwK9QCLeRb6USWdoif80Ie+v+yU8u1Zw= +-github.com/tommy-muehle/go-mnd/v2 v2.5.1/go.mod h1:WsUAkMJMYww6l/ufffCD3m+P7LEvr8TnZn9lwVDlgzw= + github.com/ttacon/chalk v0.0.0-20160626202418-22c06c80ed31/go.mod h1:onvgF043R+lC5RZ8IT9rBXDaEDnpnw/Cl+HFiw+v/7Q= + github.com/ugorji/go/codec v0.0.0-20181204163529-d75b2dcb6bc8/go.mod h1:VFNgLljTbGfSG7qAOspJ7OScBnGdDN/yBr0sguwnwf0= +-github.com/ultraware/funlen v0.0.3 h1:5ylVWm8wsNwH5aWo9438pwvsK0QiqVuUrt9bn7S/iLA= +-github.com/ultraware/funlen v0.0.3/go.mod h1:Dp4UiAus7Wdb9KUZsYWZEWiRzGuM2kXM1lPbfaF6xhA= +-github.com/ultraware/whitespace v0.0.5 h1:hh+/cpIcopyMYbZNVov9iSxvJU3OYQg78Sfaqzi/CzI= +-github.com/ultraware/whitespace v0.0.5/go.mod h1:aVMh/gQve5Maj9hQ/hg+F75lr/X5A89uZnzAmWSineA= + github.com/urfave/cli v1.22.1/go.mod h1:Gos4lmkARVdJ6EkW0WaNv/tZAAMe9V7XWyB60NtXRu0= +-github.com/uudashr/gocognit v1.0.6 h1:2Cgi6MweCsdB6kpcVQp7EW4U23iBFQWfTXiWlyp842Y= +-github.com/uudashr/gocognit v1.0.6/go.mod h1:nAIUuVBnYU7pcninia3BHOvQkpQCeO76Uscky5BOwcY= +-github.com/vektra/mockery/v2 v2.14.0 h1:KZ1p5Hrn8tiY+LErRMr14HHle6khxo+JKOXLBW/yfqs= +-github.com/vektra/mockery/v2 v2.14.0/go.mod h1:bnD1T8tExSgPD1ripLkDbr60JA9VtQeu12P3wgLZd7M= + github.com/vishvananda/netlink v1.1.0/go.mod h1:cTgwzPIzzgDAYoQrMm0EdrjRUBkTqKYppBueQtXaqoE= + github.com/vishvananda/netns v0.0.0-20191106174202-0a2b9b5464df/go.mod h1:JP3t17pCcGlemwknint6hfoeCVQrEMVwxRLRjXpq+BU= + github.com/xanzy/ssh-agent v0.3.3 h1:+/15pJfg/RsTxqYcX6fHqOXZwwMP+2VyYWJeWM2qQFM= +@@ -899,468 +425,131 @@ github.com/xeipuuv/gojsonreference v0.0.0-20180127040603-bd5ef7bd5415/go.mod h1: + github.com/xeipuuv/gojsonschema v1.2.0 h1:LhYJRs+L4fBtjZUfuSZIKGeVu0QRy8e5Xi7D17UxZ74= + github.com/xeipuuv/gojsonschema v1.2.0/go.mod h1:anYRn/JVcOK2ZgGU+IjEV4nwlhoK5sQluxsYJ78Id3Y= + github.com/xordataexchange/crypt v0.0.3-0.20170626215501-b2862e3d0a77/go.mod h1:aYKd//L2LvnjZzWKhF00oedf4jCCReLcmhLdhm1A27Q= +-github.com/yagipy/maintidx v1.0.0 h1:h5NvIsCz+nRDapQ0exNv4aJ0yXSI0420omVANTv3GJM= +-github.com/yagipy/maintidx v1.0.0/go.mod h1:0qNf/I/CCZXSMhsRsrEPDZ+DkekpKLXAJfsTACwgXLk= +-github.com/yeya24/promlinter v0.2.0 h1:xFKDQ82orCU5jQujdaD8stOHiv8UN68BSdn2a8u8Y3o= +-github.com/yeya24/promlinter v0.2.0/go.mod h1:u54lkmBOZrpEbQQ6gox2zWKKLKu2SGe+2KOiextY+IA= +-github.com/yuin/goldmark v1.1.25/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74= + github.com/yuin/goldmark v1.1.27/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74= +-github.com/yuin/goldmark v1.1.32/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74= + github.com/yuin/goldmark v1.2.1/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9decYSb74= +-github.com/yuin/goldmark v1.3.5/go.mod h1:mwnBkeHKe2W/ZEtQ+71ViKU8L12m81fl3OWwC1Zlc8k= +-github.com/yuin/goldmark v1.4.1/go.mod h1:mwnBkeHKe2W/ZEtQ+71ViKU8L12m81fl3OWwC1Zlc8k= +-github.com/yuin/goldmark v1.4.13/go.mod h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY= +-gitlab.com/bosi/decorder v0.2.3 h1:gX4/RgK16ijY8V+BRQHAySfQAb354T7/xQpDB2n10P0= +-gitlab.com/bosi/decorder v0.2.3/go.mod h1:9K1RB5+VPNQYtXtTDAzd2OEftsZb1oV0IrJrzChSdGE= + go.etcd.io/bbolt v1.3.6 h1:/ecaJf0sk1l4l6V4awd65v2C3ILy7MSj+s/x1ADCIMU= + go.etcd.io/bbolt v1.3.6/go.mod h1:qXsaaIqmgQH0T+OPdb99Bf+PKfBBQVAdyD6TY9G8XM4= +-go.etcd.io/bbolt v1.3.8 h1:xs88BrvEv273UsB79e0hcVrlUWmS0a8upikMFhSyAtA= +-go.etcd.io/bbolt v1.3.8/go.mod h1:N9Mkw9X8x5fupy0IKsmuqVtoGDyxsaDlbk4Rd05IAQw= +-go.opencensus.io v0.21.0/go.mod h1:mSImk1erAIZhrmZN+AvHh14ztQfjbGwt4TtuofqLduU= +-go.opencensus.io v0.22.0/go.mod h1:+kGneAE2xo2IficOXnaByMWTGM9T73dGwxeWcUqIpI8= +-go.opencensus.io v0.22.2/go.mod h1:yxeiOL68Rb0Xd1ddK5vPZ/oVn4vY4Ynel7k9FzqtOIw= +-go.opencensus.io v0.22.3/go.mod h1:yxeiOL68Rb0Xd1ddK5vPZ/oVn4vY4Ynel7k9FzqtOIw= +-go.opencensus.io v0.22.4/go.mod h1:yxeiOL68Rb0Xd1ddK5vPZ/oVn4vY4Ynel7k9FzqtOIw= +-go.opencensus.io v0.24.0 h1:y73uSU6J157QMP2kn2r30vwW1A2W2WFwSCGnAVxeaD0= +-go.opencensus.io v0.24.0/go.mod h1:vNK8G9p7aAivkbmorf4v+7Hgx+Zs0yY+0fOtgBfjQKo= +-go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.36.3 h1:syAz40OyelLZo42+3U68Phisvrx4qh+4wpdZw7eUUdY= +-go.opentelemetry.io/contrib/instrumentation/google.golang.org/grpc/otelgrpc v0.36.3/go.mod h1:Dts42MGkzZne2yCru741+bFiTMWkIj/LLRizad7b9tw= +-go.opentelemetry.io/otel v1.11.0 h1:kfToEGMDq6TrVrJ9Vht84Y8y9enykSZzDDZglV0kIEk= +-go.opentelemetry.io/otel v1.11.0/go.mod h1:H2KtuEphyMvlhZ+F7tg9GRhAOe60moNx61Ex+WmiKkk= +-go.opentelemetry.io/otel/metric v0.32.3 h1:dMpnJYk2KULXr0j8ph6N7+IcuiIQXlPXD4kix9t7L9c= +-go.opentelemetry.io/otel/metric v0.32.3/go.mod h1:pgiGmKohxHyTPHGOff+vrtIH39/R9fiO/WoenUQ3kcc= +-go.opentelemetry.io/otel/trace v1.11.0 h1:20U/Vj42SX+mASlXLmSGBg6jpI1jQtv682lZtTAOVFI= +-go.opentelemetry.io/otel/trace v1.11.0/go.mod h1:nyYjis9jy0gytE9LXGU+/m1sHTKbRY0fX0hulNNDP1U= +-go.uber.org/atomic v1.4.0/go.mod h1:gD2HeocX3+yG+ygLZcrzQJaqmWj9AIm7n08wl/qW/PE= +-go.uber.org/atomic v1.10.0 h1:9qC72Qh0+3MqyJbAn8YU5xVq1frD8bn3JtD2oXtafVQ= +-go.uber.org/atomic v1.10.0/go.mod h1:LUxbIzbOniOlMKjJjyPfpl4v+PKK2cNJn91OQbhoJI0= +-go.uber.org/goleak v1.1.11 h1:wy28qYRKZgnJTxGxvye5/wgWr1EKjmUDGYox5mGlRlI= +-go.uber.org/goleak v1.1.11/go.mod h1:cwTWslyiVhfpKIDGSZEM2HlOvcqm+tG4zioyIeLoqMQ= +-go.uber.org/multierr v1.1.0/go.mod h1:wR5kodmAFQ0UK8QlbwjlSNy0Z68gJhDJUG5sjR94q/0= +-go.uber.org/multierr v1.9.0 h1:7fIwc/ZtS0q++VgcfqFDxSBZVv/Xo49/SYnDFupUwlI= +-go.uber.org/multierr v1.9.0/go.mod h1:X2jQV1h+kxSjClGpnseKVIxpmcjrj7MNnI0bnlfKTVQ= +-go.uber.org/zap v1.10.0/go.mod h1:vwi/ZaCAaUcBkycHslxD9B2zi4UTXhF60s6SWpuDF0Q= +-go.uber.org/zap v1.23.0 h1:OjGQ5KQDEUawVHxNwQgPpiypGHOxo2mNZsOqTak4fFY= +-go.uber.org/zap v1.23.0/go.mod h1:D+nX8jyLsMHMYrln8A0rJjFt/T/9/bGgIhAqxv5URuY= ++go.opentelemetry.io/otel v1.21.0/go.mod h1:QZzNPQPm1zLX4gZK4cMi+71eaorMSGT3A4znnUvNNEo= ++go.opentelemetry.io/otel v1.30.0 h1:F2t8sK4qf1fAmY9ua4ohFS/K+FUuOPemHUIXHtktrts= ++go.opentelemetry.io/otel v1.30.0/go.mod h1:tFw4Br9b7fOS+uEao81PJjVMjW/5fvNCbpsDIXqP0pc= ++go.opentelemetry.io/otel/exporters/stdout/stdouttrace v1.18.0 h1:hSWWvDjXHVLq9DkmB+77fl8v7+t+yYiS+eNkiplDK54= ++go.opentelemetry.io/otel/exporters/stdout/stdouttrace v1.18.0/go.mod h1:zG7KQql1WjZCaUJd+L/ReSYx4bjbYJxg5ws9ws+mYes= ++go.opentelemetry.io/otel/metric v1.21.0/go.mod h1:o1p3CA8nNHW8j5yuQLdc1eeqEaPfzug24uvsyIEJRWM= ++go.opentelemetry.io/otel/metric v1.30.0 h1:4xNulvn9gjzo4hjg+wzIKG7iNFEaBMX00Qd4QIZs7+w= ++go.opentelemetry.io/otel/metric v1.30.0/go.mod h1:aXTfST94tswhWEb+5QjlSqG+cZlmyXy/u8jFpor3WqQ= ++go.opentelemetry.io/otel/sdk v1.21.0/go.mod h1:Nna6Yv7PWTdgJHVRD9hIYywQBRx7pbox6nwBnZIxl/E= ++go.opentelemetry.io/otel/sdk v1.30.0 h1:cHdik6irO49R5IysVhdn8oaiR9m8XluDaJAs4DfOrYE= ++go.opentelemetry.io/otel/sdk v1.30.0/go.mod h1:p14X4Ok8S+sygzblytT1nqG98QG2KYKv++HE0LY/mhg= ++go.opentelemetry.io/otel/trace v1.21.0/go.mod h1:LGbsEB0f9LGjN+OZaQQ26sohbOmiMR+BaslueVtS/qQ= ++go.opentelemetry.io/otel/trace v1.30.0 h1:7UBkkYzeg3C7kQX8VAidWh2biiQbtAKjyIML8dQ9wmc= ++go.opentelemetry.io/otel/trace v1.30.0/go.mod h1:5EyKqTzzmyqB9bwtCCq6pDLktPK6fmGf/Dph+8VI02o= + golang.org/x/crypto v0.0.0-20170930174604-9419663f5a44/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4= +-golang.org/x/crypto v0.0.0-20180904163835-0709b304e793/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4= + golang.org/x/crypto v0.0.0-20181203042331-505ab145d0a9/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4= + golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w= +-golang.org/x/crypto v0.0.0-20190510104115-cbcb75029529/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI= +-golang.org/x/crypto v0.0.0-20190605123033-f99c8df09eb5/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI= + golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI= + golang.org/x/crypto v0.0.0-20191206172530-e9b2fee46413/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto= + golang.org/x/crypto v0.0.0-20200622213623-75b288015ac9/go.mod h1:LzIPMQfyMNhhGPhUkYOs5KpL4U8rLKemX1yGLhDgUto= +-golang.org/x/crypto v0.0.0-20210921155107-089bfa567519/go.mod h1:GvvjBRRGRdwPK5ydBHafDWAxML/pGHZbMvKqRZ5+Abc= + golang.org/x/crypto v0.0.0-20220622213112-05595931fe9d/go.mod h1:IxCIyHEi3zRg3s0A5j5BB6A9Jmi73HwBIUl50j+osU4= +-golang.org/x/crypto v0.3.1-0.20221117191849-2c476679df9a/go.mod h1:hebNnKkNXi2UzZN1eVRvBB7co0a+JxK6XbPiWVs/3J4= +-golang.org/x/crypto v0.7.0/go.mod h1:pYwdfH91IfpZVANVyUOhSIPZaFoJGxTFbZhFTx+dXZU= +-golang.org/x/crypto v0.21.0 h1:X31++rzVUdKhX5sWmSOFZxx8UW/ldWx55cbf08iNAMA= +-golang.org/x/crypto v0.21.0/go.mod h1:0BP7YvVV9gBbVKyeTG0Gyn+gZm94bibOW5BjDEYAOMs= +-golang.org/x/exp v0.0.0-20180321215751-8460e604b9de/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA= +-golang.org/x/exp v0.0.0-20180807140117-3d87b88a115f/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA= +-golang.org/x/exp v0.0.0-20190121172915-509febef88a4/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA= +-golang.org/x/exp v0.0.0-20190125153040-c74c464bbbf2/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA= +-golang.org/x/exp v0.0.0-20190306152737-a1d7652674e8/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA= +-golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522/go.mod h1:ZjyILWgesfNpC6sMxTJOJm9Kp84zZh5NQWvqDGG3Qr8= +-golang.org/x/exp v0.0.0-20190829153037-c13cbed26979/go.mod h1:86+5VVa7VpoJ4kLfm080zCjGlMRFzhUhsZKEZO7MGek= +-golang.org/x/exp v0.0.0-20191030013958-a1ab85dbe136/go.mod h1:JXzH8nQsPlswgeRAPE3MuO9GYsAcnJvJ4vnMwN/5qkY= +-golang.org/x/exp v0.0.0-20191129062945-2f5052295587/go.mod h1:2RIsYlXP63K8oxa1u096TMicItID8zy7Y6sNkU49FU4= +-golang.org/x/exp v0.0.0-20191227195350-da58074b4299/go.mod h1:2RIsYlXP63K8oxa1u096TMicItID8zy7Y6sNkU49FU4= +-golang.org/x/exp v0.0.0-20200119233911-0405dc783f0a/go.mod h1:2RIsYlXP63K8oxa1u096TMicItID8zy7Y6sNkU49FU4= +-golang.org/x/exp v0.0.0-20200207192155-f17229e696bd/go.mod h1:J/WKrq2StrnmMY6+EHIKF9dgMWnmCNThgcyBT1FY9mM= +-golang.org/x/exp v0.0.0-20200224162631-6cc2880d07d6/go.mod h1:3jZMyOhIsHpP37uCMkUooju7aAi5cS1Q23tOzKc+0MU= +-golang.org/x/exp v0.0.0-20230905200255-921286631fa9 h1:GoHiUyI/Tp2nVkLI2mCxVkOjsbSXD66ic0XW0js0R9g= +-golang.org/x/exp v0.0.0-20230905200255-921286631fa9/go.mod h1:S2oDrQGGwySpoQPVqRShND87VCbxmc6bL1Yd2oYrm6k= +-golang.org/x/exp/typeparams v0.0.0-20220428152302-39d4317da171/go.mod h1:AbB0pIl9nAr9wVwH+Z2ZpaocVmF5I4GyWCDIsVjR0bk= +-golang.org/x/exp/typeparams v0.0.0-20220827204233-334a2380cb91 h1:Ic/qN6TEifvObMGQy72k0n1LlJr7DjWWEi+MOsDOiSk= +-golang.org/x/exp/typeparams v0.0.0-20220827204233-334a2380cb91/go.mod h1:AbB0pIl9nAr9wVwH+Z2ZpaocVmF5I4GyWCDIsVjR0bk= +-golang.org/x/image v0.0.0-20180708004352-c73c2afc3b81/go.mod h1:ux5Hcp/YLpHSI86hEcLt0YII63i6oz57MZXIpbrjZUs= +-golang.org/x/image v0.0.0-20190227222117-0694c2d4d067/go.mod h1:kZ7UVZpmo3dzQBMxlp+ypCbDeSB+sBbTgSJuh5dn5js= +-golang.org/x/image v0.0.0-20190802002840-cff245a6509b/go.mod h1:FeLwcggjj3mMvU+oOTbSwawSJRM1uh48EjtB4UJZlP0= +-golang.org/x/lint v0.0.0-20181026193005-c67002cb31c3/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE= +-golang.org/x/lint v0.0.0-20190227174305-5b3e6a55c961/go.mod h1:wehouNa3lNwaWXcvxsM5YxQ5yQlVC4a0KAMCusXpPoU= +-golang.org/x/lint v0.0.0-20190301231843-5614ed5bae6f/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE= +-golang.org/x/lint v0.0.0-20190313153728-d0100b6bd8b3/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc= +-golang.org/x/lint v0.0.0-20190409202823-959b441ac422/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc= +-golang.org/x/lint v0.0.0-20190909230951-414d861bb4ac/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc= +-golang.org/x/lint v0.0.0-20190930215403-16217165b5de/go.mod h1:6SW0HCj/g11FgYtHlgUYUwCkIfeOF89ocIRzGO/8vkc= +-golang.org/x/lint v0.0.0-20191125180803-fdd1cda4f05f/go.mod h1:5qLYkcX4OjUUV8bRuDixDT3tpyyb+LUpUlRWLxfhWrs= +-golang.org/x/lint v0.0.0-20200130185559-910be7a94367/go.mod h1:3xt1FjdF8hUf6vQPIChWIBhFzV8gjjsPE/fR3IyQdNY= +-golang.org/x/lint v0.0.0-20200302205851-738671d3881b/go.mod h1:3xt1FjdF8hUf6vQPIChWIBhFzV8gjjsPE/fR3IyQdNY= +-golang.org/x/mobile v0.0.0-20190312151609-d3739f865fa6/go.mod h1:z+o9i4GpDbdi3rU15maQ/Ox0txvL9dWGYEHz965HBQE= +-golang.org/x/mobile v0.0.0-20190719004257-d2bd2a29d028/go.mod h1:E/iHnbuqvinMTCcRqshq8CkpyQDoeVncDDYHnLhea+o= +-golang.org/x/mod v0.0.0-20190513183733-4bf6d317e70e/go.mod h1:mXi4GBBbnImb6dmsKGUJ2LatrhH/nqhxcFungHvyanc= +-golang.org/x/mod v0.1.0/go.mod h1:0QHyrYULN0/3qlju5TqG8bIK38QM8yzMo5ekMj3DlcY= +-golang.org/x/mod v0.1.1-0.20191105210325-c90efee705ee/go.mod h1:QqPTAvyqsEbceGzBzNggFXnrqF1CaUcvgkdR5Ot7KZg= +-golang.org/x/mod v0.1.1-0.20191107180719-034126e5016b/go.mod h1:QqPTAvyqsEbceGzBzNggFXnrqF1CaUcvgkdR5Ot7KZg= ++golang.org/x/crypto v0.31.0 h1:ihbySMvVjLAeSH1IbfcRTkD/iNscyz8rGzjF/E5hV6U= ++golang.org/x/crypto v0.31.0/go.mod h1:kDsLvtWBEx7MV9tJOj9bnXsPbxwJQ6csT/x4KIN4Ssk= ++golang.org/x/exp v0.0.0-20240904232852-e7e105dedf7e h1:I88y4caeGeuDQxgdoFPUq097j7kNfw6uvuiNxUBfcBk= ++golang.org/x/exp v0.0.0-20240904232852-e7e105dedf7e/go.mod h1:akd2r19cwCdwSwWeIdzYQGa/EZZyqcOdwWiwj5L5eKQ= + golang.org/x/mod v0.2.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA= + golang.org/x/mod v0.3.0/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA= +-golang.org/x/mod v0.4.1/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA= +-golang.org/x/mod v0.4.2/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA= +-golang.org/x/mod v0.5.1/go.mod h1:5OXOZSfqPIIbmVBIIKWRFfZjPR0E5r58TLhUjH0a2Ro= +-golang.org/x/mod v0.6.0-dev.0.20220106191415-9b9b3d81d5e3/go.mod h1:3p9vT2HGsQu2K1YbXdKPJLVgG5VJdoTa1poYQBtP1AY= +-golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4/go.mod h1:jJ57K6gSWd91VN4djpZkiMVwK6gcyfeH4XE8wZrZaV4= +-golang.org/x/mod v0.8.0/go.mod h1:iBbtSCu2XBx23ZKBPSOrRkjjQPZFPuis4dIYUhu/chs= +-golang.org/x/mod v0.12.0 h1:rmsUpXtvNzj340zd98LZ4KntptpfRHwpFOHG188oHXc= +-golang.org/x/mod v0.12.0/go.mod h1:iBbtSCu2XBx23ZKBPSOrRkjjQPZFPuis4dIYUhu/chs= ++golang.org/x/mod v0.21.0 h1:vvrHzRwRfVKSiLrG+d4FMl/Qi4ukBCE6kZlTUkDYRT0= ++golang.org/x/mod v0.21.0/go.mod h1:6SkKJ3Xj0I0BrPOZoBy3bdMptDDU9oJrpohJ3eWZ1fY= + golang.org/x/net v0.0.0-20180719180050-a680a1efc54d/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +-golang.org/x/net v0.0.0-20180724234803-3673e40ba225/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +-golang.org/x/net v0.0.0-20180826012351-8a410e7b638d/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= + golang.org/x/net v0.0.0-20180906233101-161cd47e91fd/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +-golang.org/x/net v0.0.0-20181114220301-adae6a3d119a/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +-golang.org/x/net v0.0.0-20190108225652-1e06a53dbb7e/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= +-golang.org/x/net v0.0.0-20190213061140-3a22650c66bd/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= + golang.org/x/net v0.0.0-20190311183353-d8887717615a/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg= + golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg= +-golang.org/x/net v0.0.0-20190501004415-9ce7a6920f09/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg= +-golang.org/x/net v0.0.0-20190503192946-f4e77d36d62c/go.mod h1:t9HGtf8HONx5eT2rtn7q6eTqICYqUVnKs3thJo3Qplg= +-golang.org/x/net v0.0.0-20190603091049-60506f45cf65/go.mod h1:HSz+uSET+XFnRR8LxR5pz3Of3rY3CfYBVs4xY44aLks= +-golang.org/x/net v0.0.0-20190613194153-d28f0bde5980/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= + golang.org/x/net v0.0.0-20190620200207-3b0461eec859/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= +-golang.org/x/net v0.0.0-20190628185345-da137c7871d7/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= +-golang.org/x/net v0.0.0-20190724013045-ca1201d0de80/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= +-golang.org/x/net v0.0.0-20191209160850-c0dbc17a3553/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= +-golang.org/x/net v0.0.0-20200114155413-6afb5195e5aa/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= +-golang.org/x/net v0.0.0-20200202094626-16171245cfb2/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= +-golang.org/x/net v0.0.0-20200222125558-5a598a2470a0/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= + golang.org/x/net v0.0.0-20200226121028-0de0cce0169b/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= +-golang.org/x/net v0.0.0-20200301022130-244492dfa37a/go.mod h1:z5CRVTTTmAJ677TzLLGU+0bjPO0LkuOLi4/5GtJWs/s= +-golang.org/x/net v0.0.0-20200324143707-d3edc9973b7e/go.mod h1:qpuaurCH72eLCgpAm/N6yyVIVM9cpaDIP3A8BGJEC5A= +-golang.org/x/net v0.0.0-20200501053045-e0ff5e5a1de5/go.mod h1:qpuaurCH72eLCgpAm/N6yyVIVM9cpaDIP3A8BGJEC5A= +-golang.org/x/net v0.0.0-20200506145744-7e3656a0809f/go.mod h1:qpuaurCH72eLCgpAm/N6yyVIVM9cpaDIP3A8BGJEC5A= +-golang.org/x/net v0.0.0-20200513185701-a91f0712d120/go.mod h1:qpuaurCH72eLCgpAm/N6yyVIVM9cpaDIP3A8BGJEC5A= + golang.org/x/net v0.0.0-20200520004742-59133d7f0dd7/go.mod h1:qpuaurCH72eLCgpAm/N6yyVIVM9cpaDIP3A8BGJEC5A= +-golang.org/x/net v0.0.0-20200520182314-0ba52f642ac2/go.mod h1:qpuaurCH72eLCgpAm/N6yyVIVM9cpaDIP3A8BGJEC5A= +-golang.org/x/net v0.0.0-20200625001655-4c5254603344/go.mod h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA= +-golang.org/x/net v0.0.0-20200707034311-ab3426394381/go.mod h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA= + golang.org/x/net v0.0.0-20200813134508-3edf25e44fcc/go.mod h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA= +-golang.org/x/net v0.0.0-20200822124328-c89045814202/go.mod h1:/O7V0waA8r7cgGh81Ro3o1hOxt32SMVPicZroKQ2sZA= + golang.org/x/net v0.0.0-20201021035429-f5854403a974/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU= +-golang.org/x/net v0.0.0-20201110031124-69a78807bb2b/go.mod h1:sp8m0HH+o8qH0wwXwYZr8TS3Oi6o0r6Gce1SSxlDquU= + golang.org/x/net v0.0.0-20201224014010-6772e930b67b/go.mod h1:m0MpNAwzfU5UDzcl9v0D8zg8gWTRqZa9RBIspLL5mdg= +-golang.org/x/net v0.0.0-20210226172049-e18ecbb05110/go.mod h1:m0MpNAwzfU5UDzcl9v0D8zg8gWTRqZa9RBIspLL5mdg= +-golang.org/x/net v0.0.0-20210405180319-a5a99cb37ef4/go.mod h1:p54w0d4576C0XHj96bSt6lcn1PtDYWL6XObtHCRCNQM= +-golang.org/x/net v0.0.0-20210525063256-abc453219eb5/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y= +-golang.org/x/net v0.0.0-20211015210444-4f30a5c0130f/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y= ++golang.org/x/net v0.0.0-20210614182718-04defd469f4e/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y= + golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2/go.mod h1:9nx3DQGgdP8bBQD5qxJ1jj9UTztislL4KSBs9R2vV5Y= +-golang.org/x/net v0.0.0-20220127200216-cd36cc0744dd/go.mod h1:CfG3xpIq0wQ8r1q4Su4UZFWDARRcnwPjda9FqA0JpMk= +-golang.org/x/net v0.0.0-20220225172249-27dd8689420f/go.mod h1:CfG3xpIq0wQ8r1q4Su4UZFWDARRcnwPjda9FqA0JpMk= +-golang.org/x/net v0.0.0-20220722155237-a158d28d115b/go.mod h1:XRhObCWvk6IyKnWLug+ECip1KBveYUHfp+8e9klMJ9c= +-golang.org/x/net v0.2.0/go.mod h1:KqCZLdyyvdV855qA2rE3GC2aiw5xGR5TEjj8smXukLY= +-golang.org/x/net v0.6.0/go.mod h1:2Tu9+aMcznHK/AK1HMvgo6xiTLG5rD5rZLDS+rp2Bjs= +-golang.org/x/net v0.8.0/go.mod h1:QVkue5JL9kW//ek3r6jTKnTFis1tRmNAW2P1shuFdJc= +-golang.org/x/net v0.23.0 h1:7EYJ93RZ9vYSZAIb2x3lnuvqO5zneoD6IvWjuhfxjTs= +-golang.org/x/net v0.23.0/go.mod h1:JKghWKKOSdJwpW2GEx0Ja7fmaKnMsbu+MWVZTokSYmg= +-golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U= +-golang.org/x/oauth2 v0.0.0-20190226205417-e64efc72b421/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw= +-golang.org/x/oauth2 v0.0.0-20190604053449-0f29369cfe45/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw= +-golang.org/x/oauth2 v0.0.0-20191202225959-858c2ad4c8b6/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw= +-golang.org/x/oauth2 v0.0.0-20200107190931-bf48bf16ab8d/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw= +-golang.org/x/oauth2 v0.0.0-20210514164344-f6687ab2804c/go.mod h1:KelEdhl1UZF7XfJ4dDtk6s++YSgaE7mD/BuKKDLBl4A= +-golang.org/x/oauth2 v0.0.0-20220223155221-ee480838109b/go.mod h1:DAh4E804XQdzx2j+YRIaUnCqCV2RuMz24cGBJ5QYIrc= +-golang.org/x/oauth2 v0.15.0 h1:s8pnnxNVzjWyrvYdFUQq5llS1PX2zhPXmccZv99h7uQ= +-golang.org/x/oauth2 v0.15.0/go.mod h1:q48ptWNTY5XWf+JNten23lcvHpLJ0ZSxF5ttTHKVCAM= ++golang.org/x/net v0.33.0 h1:74SYHlV8BIgHIFC/LrYkOGIwL19eTYXQ5wc6TBuO36I= ++golang.org/x/net v0.33.0/go.mod h1:HXLR5J+9DxmrqMwG9qjGCxZ+zKXxBru04zlTvWlWuN4= + golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +-golang.org/x/sync v0.0.0-20181108010431-42b317875d0f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +-golang.org/x/sync v0.0.0-20181221193216-37e7f081c4d4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +-golang.org/x/sync v0.0.0-20190227155943-e225da77a7e6/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= + golang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= + golang.org/x/sync v0.0.0-20190911185100-cd5d95a43a6e/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +-golang.org/x/sync v0.0.0-20200317015054-43a5402ce75a/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +-golang.org/x/sync v0.0.0-20200625203802-6e8e738ad208/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= + golang.org/x/sync v0.0.0-20201020160332-67f06af15bc9/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +-golang.org/x/sync v0.0.0-20201207232520-09787c993a3a/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +-golang.org/x/sync v0.0.0-20210220032951-036812b2e83c/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +-golang.org/x/sync v0.0.0-20220722155255-886fb9371eb4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +-golang.org/x/sync v0.1.0/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= +-golang.org/x/sync v0.5.0 h1:60k92dhOjHxJkrqnwsfl8KuaHbn/5dl0lUPUklKo3qE= +-golang.org/x/sync v0.5.0/go.mod h1:Czt+wKu1gCyEFDUtn0jG5QVvpJ6rzVqr5aXyt9drQfk= +-golang.org/x/sys v0.0.0-20180830151530-49385e6e1522/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +-golang.org/x/sys v0.0.0-20180905080454-ebe1bf3edb33/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= ++golang.org/x/sync v0.10.0 h1:3NQrjDixjgGwUOCaF8w2+VYHv0Ve/vGYSbdkTa98gmQ= ++golang.org/x/sync v0.10.0/go.mod h1:Czt+wKu1gCyEFDUtn0jG5QVvpJ6rzVqr5aXyt9drQfk= + golang.org/x/sys v0.0.0-20180909124046-d0be0721c37e/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +-golang.org/x/sys v0.0.0-20181116152217-5ac8a444bdc5/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= + golang.org/x/sys v0.0.0-20181205085412-a5c9d58dba9a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +-golang.org/x/sys v0.0.0-20190130150945-aca44879d564/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= + golang.org/x/sys v0.0.0-20190215142949-d0b11bdaac8a/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= +-golang.org/x/sys v0.0.0-20190312061237-fead79001313/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20190412213103-97732733099d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20190422165155-953cdadca894/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20190502145724-3ef323f4f1fd/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20190507160741-ecd444e8653b/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20190606165138-5da285871e9c/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20190606203320-7fc4e5ec1444/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20190624142023-c5567b49c5d0/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20190626221950-04f50cda93cb/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20190726091711-fc99dfbffb4e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20190904154756-749cb33beabd/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20191001151750-bb3f8db39f24/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20191005200804-aed5e4c7ecf9/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20191026070338-33540a1f6037/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20191115151921-52ab43148777/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20191120155948-bd437916bb0e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20191204072324-ce4227a45e2e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20191228213918-04cbcbbfeed8/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200106162015-b016eb3dc98e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200113162924-86b910548bc1/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200122134326-e047566fdf82/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200202164722-d101bd2416d5/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200212091648-12a6c2dcc1e4/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200223170610-d5e6a3e2c0ae/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200302150141-5c8b2ff67527/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20200323222414-85ca7c5b95cd/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200331124033-c3d80250170d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200501052902-10377860bb8e/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200511232937-7e40ca221e25/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200515095857-1151b9dac4a9/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20200519105757-fe76b779f299/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200523222454-059865788121/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200615200032-f1bc736245b1/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200625212154-ddb9806d33ae/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20200803210538-64077c9b5642/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20200814200057-3d37ad5750ed/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20200923182605-d9f96fdee20d/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20200930185726-fdedc70b468f/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20201119102817-f84b799fce68/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20210119212857-b64e53b001e4/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20210124154548-22da62e12c0c/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20210330210617-4fbd30eecc44/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= + golang.org/x/sys v0.0.0-20210423082822-04245dca01da/go.mod h1:h1NjWce9XRLGQEsW7wpKNCjG9DtNlClVuFLEZdDNbEs= +-golang.org/x/sys v0.0.0-20210510120138-977fb7262007/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.0.0-20210603081109-ebe580a85c40/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= + golang.org/x/sys v0.0.0-20210615035016-665e8c7367d1/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.0.0-20210616045830-e2b7044e8c71/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= + golang.org/x/sys v0.0.0-20210616094352-59db8d763f22/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.0.0-20210630005230-0f9fa26af87c/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= + golang.org/x/sys v0.0.0-20210906170528-6f6e22806c34/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.0.0-20210927094055-39ccf1dd6fa6/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.0.0-20211019181941-9d821ace8654/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= + golang.org/x/sys v0.0.0-20211025201205-69cdffdb9359/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.0.0-20211105183446-c75c47738b0c/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= + golang.org/x/sys v0.0.0-20211116061358-0a5406a5449c/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.0.0-20211216021012-1d35b9e2eb4e/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.0.0-20220114195835-da31bd327af9/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.0.0-20220520151302-bc2c85ada10a/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.0.0-20220702020025-31831981b65f/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= + golang.org/x/sys v0.0.0-20220715151400-c0bba94af5f8/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.0.0-20220722155257-8c9f86f7a55f/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.0.0-20220811171246-fbc7d0a398ab/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.2.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.3.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.5.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +-golang.org/x/sys v0.18.0 h1:DBdB3niSjOA/O0blCZBqDefyWNYveAYMNF1Wum0DYQ4= +-golang.org/x/sys v0.18.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA= ++golang.org/x/sys v0.0.0-20221010170243-090e33056c14/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= ++golang.org/x/sys v0.14.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA= ++golang.org/x/sys v0.21.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA= ++golang.org/x/sys v0.28.0 h1:Fksou7UEQUWlKvIdsqzJmUmCX3cZuD2+P3XyyzwMhlA= ++golang.org/x/sys v0.28.0/go.mod h1:/VUhepiaJMQUp4+oa/7Zr1D23ma6VTLIYjOOTFZPUcA= + golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo= +-golang.org/x/term v0.0.0-20210927222741-03fcf44c2211/go.mod h1:jbD1KX2456YbFQfuXm/mYQcufACuNUgVhRMnK/tPxf8= +-golang.org/x/term v0.2.0/go.mod h1:TVmDHMZPmdnySmBfhjOoOdhjzdE1h4u1VwSiw2l1Nuc= +-golang.org/x/term v0.5.0/go.mod h1:jMB1sMXY+tzblOD4FWmEbocvup2/aLOaQEp7JmGp78k= +-golang.org/x/term v0.6.0/go.mod h1:m6U89DPEgQRMq3DNkDClhWw02AUbt2daBVO4cn4Hv9U= +-golang.org/x/term v0.18.0 h1:FcHjZXDMxI8mM3nwhX9HlKop4C0YQvCVCdwYl2wOtE8= +-golang.org/x/term v0.18.0/go.mod h1:ILwASektA3OnRv7amZ1xhE/KTR+u50pbXfZ03+6Nx58= +-golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= ++golang.org/x/term v0.27.0 h1:WP60Sv1nlK1T6SupCHbXzSaN0b9wUmsPoRS9b61A23Q= ++golang.org/x/term v0.27.0/go.mod h1:iMsnZpn0cago0GOrHO2+Y7u7JPn5AylBrcoWkElMTSM= + golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= +-golang.org/x/text v0.3.1-0.20180807135948-17ff2d5776d2/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= + golang.org/x/text v0.3.2/go.mod h1:bEr9sfX3Q8Zfm5fL9x+3itogRgK3+ptLWKqgva+5dAk= + golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ= + golang.org/x/text v0.3.6/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ= +-golang.org/x/text v0.3.7/go.mod h1:u+2+/6zg+i71rQMx5EYifcz6MCKuco9NR6JIITiCfzQ= +-golang.org/x/text v0.4.0/go.mod h1:mrYo+phRRbMaCq/xk9113O4dZlRixOauAjOtrjsXDZ8= +-golang.org/x/text v0.7.0/go.mod h1:mrYo+phRRbMaCq/xk9113O4dZlRixOauAjOtrjsXDZ8= +-golang.org/x/text v0.8.0/go.mod h1:e1OnstbJyHTd6l/uOt8jFFHp6TRDWZR/bV3emEE/zU8= +-golang.org/x/text v0.14.0 h1:ScX5w1eTa3QqT8oi6+ziP7dTV1S2+ALU0bI+0zXKWiQ= +-golang.org/x/text v0.14.0/go.mod h1:18ZOQIKpY8NJVqYksKHtTdi31H5itFRjB5/qKTNYzSU= +-golang.org/x/time v0.0.0-20181108054448-85acf8d2951c/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ= +-golang.org/x/time v0.0.0-20190308202827-9d24e82272b4/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ= +-golang.org/x/time v0.0.0-20191024005414-555d28b269f0/go.mod h1:tRJNPiyCQ0inRvYxbN9jk5I+vvW/OXSQhTDSoE431IQ= +-golang.org/x/time v0.5.0 h1:o7cqy6amK/52YcAKIPlM3a+Fpj35zvRj2TP+e1xFSfk= +-golang.org/x/time v0.5.0/go.mod h1:3BpzKBy/shNhVucY/MWOyx10tF3SFh9QdLuxbVysPQM= +-golang.org/x/tools v0.0.0-20180525024113-a5b4c53f6e8b/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= ++golang.org/x/text v0.21.0 h1:zyQAAkrwaneQ066sspRyJaG9VNi/YJ1NfzcGB3hZ/qo= ++golang.org/x/text v0.21.0/go.mod h1:4IBbMaMmOPCJ8SecivzSH54+73PCFmPWxNTLm+vZkEQ= + golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +-golang.org/x/tools v0.0.0-20190114222345-bf090417da8b/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +-golang.org/x/tools v0.0.0-20190206041539-40960b6deb8e/go.mod h1:n7NCudcB/nEzxVGmLbDWY5pfWTLqBcC2KZ6jyYvM4mQ= +-golang.org/x/tools v0.0.0-20190226205152-f727befe758c/go.mod h1:9Yl7xja0Znq3iFh3HoIrodX9oNMXvdceNzlUR8zjMvY= +-golang.org/x/tools v0.0.0-20190307163923-6a08e3108db3/go.mod h1:25r3+/G6/xytQM8iWZKq3Hn0kr0rgFKPUNVEL/dr3z4= +-golang.org/x/tools v0.0.0-20190311212946-11955173bddd/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs= +-golang.org/x/tools v0.0.0-20190311215038-5c2858a9cfe5/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs= +-golang.org/x/tools v0.0.0-20190312151545-0bb0c0a6e846/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs= +-golang.org/x/tools v0.0.0-20190312170243-e65039ee4138/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs= +-golang.org/x/tools v0.0.0-20190321232350-e250d351ecad/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs= +-golang.org/x/tools v0.0.0-20190322203728-c1a832b0ad89/go.mod h1:LCzVGOaR6xXOjkQ3onu1FJEFr0SW1gC7cKk1uF8kGRs= + golang.org/x/tools v0.0.0-20190425150028-36563e24a262/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q= +-golang.org/x/tools v0.0.0-20190506145303-2d16b83fe98c/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q= +-golang.org/x/tools v0.0.0-20190524140312-2c0ae7006135/go.mod h1:RgjU9mgBXZiqYHBnxXauZ1Gv1EHHAz9KjViQ78xBX0Q= +-golang.org/x/tools v0.0.0-20190606124116-d0a3d012864b/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc= +-golang.org/x/tools v0.0.0-20190621195816-6e04913cbbac/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc= +-golang.org/x/tools v0.0.0-20190624222133-a101b041ded4/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc= +-golang.org/x/tools v0.0.0-20190628153133-6cdbf07be9d0/go.mod h1:/rFqwRUd4F7ZHNgwSSTFct+R/Kf4OFW1sUzUTQQTgfc= +-golang.org/x/tools v0.0.0-20190816200558-6889da9d5479/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= +-golang.org/x/tools v0.0.0-20190910044552-dd2b5c81c578/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= +-golang.org/x/tools v0.0.0-20190911174233-4f2ddba30aff/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= +-golang.org/x/tools v0.0.0-20190916130336-e45ffcd953cc/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= +-golang.org/x/tools v0.0.0-20191012152004-8de300cfc20a/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= +-golang.org/x/tools v0.0.0-20191108193012-7d206e10da11/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= +-golang.org/x/tools v0.0.0-20191113191852-77e3bb0ad9e7/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= +-golang.org/x/tools v0.0.0-20191115202509-3a792d9c32b2/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= + golang.org/x/tools v0.0.0-20191119224855-298f0cb1881e/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= +-golang.org/x/tools v0.0.0-20191125144606-a911d9008d1f/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= +-golang.org/x/tools v0.0.0-20191130070609-6e064ea0cf2d/go.mod h1:b+2E5dAYhXwXZwtnZ6UAqBI28+e2cm9otk0dWdXHAEo= +-golang.org/x/tools v0.0.0-20191216173652-a0e659d51361/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28= +-golang.org/x/tools v0.0.0-20191227053925-7b8e75db28f4/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28= +-golang.org/x/tools v0.0.0-20200117161641-43d50277825c/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28= +-golang.org/x/tools v0.0.0-20200117220505-0cba7a3a9ee9/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28= +-golang.org/x/tools v0.0.0-20200122220014-bf1340f18c4a/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28= +-golang.org/x/tools v0.0.0-20200130002326-2f3ba24bd6e7/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28= +-golang.org/x/tools v0.0.0-20200204074204-1cc6d1ef6c74/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28= +-golang.org/x/tools v0.0.0-20200207183749-b753a1ba74fa/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28= +-golang.org/x/tools v0.0.0-20200212150539-ea181f53ac56/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28= +-golang.org/x/tools v0.0.0-20200224181240-023911ca70b2/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28= +-golang.org/x/tools v0.0.0-20200227222343-706bc42d1f0d/go.mod h1:TB2adYChydJhpapKDTa4BR/hXlZSLoq2Wpct/0txZ28= +-golang.org/x/tools v0.0.0-20200304193943-95d2e580d8eb/go.mod h1:o4KQGtdN14AW+yjsvvwRTJJuXz8XRtIHtEnmAXLyFUw= +-golang.org/x/tools v0.0.0-20200312045724-11d5b4c81c7d/go.mod h1:o4KQGtdN14AW+yjsvvwRTJJuXz8XRtIHtEnmAXLyFUw= +-golang.org/x/tools v0.0.0-20200324003944-a576cf524670/go.mod h1:Sl4aGygMT6LrqrWclx+PTx3U+LnKx/seiNR+3G19Ar8= +-golang.org/x/tools v0.0.0-20200329025819-fd4102a86c65/go.mod h1:Sl4aGygMT6LrqrWclx+PTx3U+LnKx/seiNR+3G19Ar8= +-golang.org/x/tools v0.0.0-20200331025713-a30bf2db82d4/go.mod h1:Sl4aGygMT6LrqrWclx+PTx3U+LnKx/seiNR+3G19Ar8= +-golang.org/x/tools v0.0.0-20200414032229-332987a829c3/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE= +-golang.org/x/tools v0.0.0-20200501065659-ab2804fb9c9d/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE= +-golang.org/x/tools v0.0.0-20200512131952-2bc93b1c0c88/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE= +-golang.org/x/tools v0.0.0-20200515010526-7d3b6ebf133d/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE= +-golang.org/x/tools v0.0.0-20200618134242-20370b0cb4b2/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE= + golang.org/x/tools v0.0.0-20200619180055-7c47624df98f/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE= +-golang.org/x/tools v0.0.0-20200622203043-20e05c1c8ffa/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE= +-golang.org/x/tools v0.0.0-20200624225443-88f3c62a19ff/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE= +-golang.org/x/tools v0.0.0-20200625211823-6506e20df31f/go.mod h1:EkVYQZoAsY45+roYkvgYkIh4xh/qjgUK9TdY2XT94GE= +-golang.org/x/tools v0.0.0-20200724022722-7017fd6b1305/go.mod h1:njjCfa9FT2d7l9Bc6FUM5FLjQPp3cFF28FI3qnDFljA= +-golang.org/x/tools v0.0.0-20200729194436-6467de6f59a7/go.mod h1:njjCfa9FT2d7l9Bc6FUM5FLjQPp3cFF28FI3qnDFljA= +-golang.org/x/tools v0.0.0-20200804011535-6c149bb5ef0d/go.mod h1:njjCfa9FT2d7l9Bc6FUM5FLjQPp3cFF28FI3qnDFljA= +-golang.org/x/tools v0.0.0-20200812195022-5ae4c3c160a0/go.mod h1:njjCfa9FT2d7l9Bc6FUM5FLjQPp3cFF28FI3qnDFljA= +-golang.org/x/tools v0.0.0-20200820010801-b793a1359eac/go.mod h1:njjCfa9FT2d7l9Bc6FUM5FLjQPp3cFF28FI3qnDFljA= +-golang.org/x/tools v0.0.0-20200825202427-b303f430e36d/go.mod h1:njjCfa9FT2d7l9Bc6FUM5FLjQPp3cFF28FI3qnDFljA= +-golang.org/x/tools v0.0.0-20200831203904-5a2aa26beb65/go.mod h1:Cj7w3i3Rnn0Xh82ur9kSqwfTHTeVxaDqrfMjpcNT6bE= +-golang.org/x/tools v0.0.0-20201001104356-43ebab892c4c/go.mod h1:z6u4i615ZeAfBE4XtMziQW1fSVJXACjjbWkB/mvPzlU= +-golang.org/x/tools v0.0.0-20201002184944-ecd9fd270d5d/go.mod h1:z6u4i615ZeAfBE4XtMziQW1fSVJXACjjbWkB/mvPzlU= + golang.org/x/tools v0.0.0-20201022035929-9cf592e881e9/go.mod h1:emZCQorbCU4vsT4fOWvOPXz4eW1wZW4PmDk9uLelYpA= +-golang.org/x/tools v0.0.0-20201023174141-c8cfbd0f21e6/go.mod h1:emZCQorbCU4vsT4fOWvOPXz4eW1wZW4PmDk9uLelYpA= +-golang.org/x/tools v0.0.0-20201230224404-63754364767c/go.mod h1:emZCQorbCU4vsT4fOWvOPXz4eW1wZW4PmDk9uLelYpA= + golang.org/x/tools v0.0.0-20210106214847-113979e3529a/go.mod h1:emZCQorbCU4vsT4fOWvOPXz4eW1wZW4PmDk9uLelYpA= +-golang.org/x/tools v0.1.0/go.mod h1:xkSsbof2nBLbhDlRMhhhyNLN/zl3eTqcnHD5viDpcZ0= +-golang.org/x/tools v0.1.1-0.20210205202024-ef80cdb6ec6d/go.mod h1:9bzcO0MWcOuT0tm1iBGzDVPshzfwoVvREIui8C+MHqU= +-golang.org/x/tools v0.1.1-0.20210302220138-2ac05c832e1a/go.mod h1:9bzcO0MWcOuT0tm1iBGzDVPshzfwoVvREIui8C+MHqU= +-golang.org/x/tools v0.1.1/go.mod h1:o0xws9oXOQQZyjljx8fwUC0k7L1pTE6eaCbjGeHmOkk= +-golang.org/x/tools v0.1.5/go.mod h1:o0xws9oXOQQZyjljx8fwUC0k7L1pTE6eaCbjGeHmOkk= +-golang.org/x/tools v0.1.9-0.20211228192929-ee1ca4ffc4da/go.mod h1:nABZi5QlRsZVlzPpHl034qft6wpY4eDcsTt5AaioBiU= +-golang.org/x/tools v0.1.9/go.mod h1:nABZi5QlRsZVlzPpHl034qft6wpY4eDcsTt5AaioBiU= +-golang.org/x/tools v0.1.10/go.mod h1:Uh6Zz+xoGYZom868N8YTex3t7RhtHDBrE8Gzo9bV56E= +-golang.org/x/tools v0.1.11/go.mod h1:SgwaegtQh8clINPpECJMqnxLv9I09HLqnW3RMqW0CA4= +-golang.org/x/tools v0.1.12/go.mod h1:hNGJHUnrk76NpqgfD5Aqm5Crs+Hm0VOH/i9J2+nxYbc= +-golang.org/x/tools v0.6.0/go.mod h1:Xwgl3UAJ/d3gWutnCtw505GrjyAbvKui8lOU390QaIU= +-golang.org/x/tools v0.13.0 h1:Iey4qkscZuv0VvIt8E0neZjtPVQFSc870HQ448QgEmQ= +-golang.org/x/tools v0.13.0/go.mod h1:HvlwmtVNQAhOuCjW7xxvovg8wbNq7LwfXh/k7wXUl58= ++golang.org/x/tools v0.24.0 h1:J1shsA93PJUEVaUSaay7UXAyE8aimq3GW0pjlolpa24= ++golang.org/x/tools v0.24.0/go.mod h1:YhNqVBIfWHdzvTLs0d8LCuMhkKUgSUKldakyV7W/WDQ= + golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= + golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= + golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= + golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= +-gonum.org/v1/gonum v0.0.0-20180816165407-929014505bf4/go.mod h1:Y+Yx5eoAFn32cQvJDxZx5Dpnq+c3wtXuadVZAcxbbBo= +-gonum.org/v1/gonum v0.8.2 h1:CCXrcPKiGGotvnN6jfUsKk4rRqm7q09/YbKb5xCEvtM= +-gonum.org/v1/gonum v0.8.2/go.mod h1:oe/vMfY3deqTw+1EZJhuvEW2iwGF1bW9wwu7XCu0+v0= +-gonum.org/v1/netlib v0.0.0-20190313105609-8cb42192e0e0 h1:OE9mWmgKkjJyEmDAAtGMPjXu+YNeGvK9VTSHY6+Qihc= +-gonum.org/v1/netlib v0.0.0-20190313105609-8cb42192e0e0/go.mod h1:wa6Ws7BG/ESfp6dHfk7C6KdzKA7wR7u/rKwOGE66zvw= +-gonum.org/v1/plot v0.0.0-20190515093506-e2840ee46a6b/go.mod h1:Wt8AAjI+ypCyYX3nZBvf6cAIx93T+c/OS2HFAYskSZc= +-google.golang.org/api v0.4.0/go.mod h1:8k5glujaEP+g9n7WNsDg8QP6cUVNI86fCNMcbazEtwE= +-google.golang.org/api v0.7.0/go.mod h1:WtwebWUNSVBH/HAw79HIFXZNqEvBhG+Ra+ax0hx3E3M= +-google.golang.org/api v0.8.0/go.mod h1:o4eAsZoiT+ibD93RtjEohWalFOjRDx6CVaqeizhEnKg= +-google.golang.org/api v0.9.0/go.mod h1:o4eAsZoiT+ibD93RtjEohWalFOjRDx6CVaqeizhEnKg= +-google.golang.org/api v0.13.0/go.mod h1:iLdEw5Ide6rF15KTC1Kkl0iskquN2gFfn9o9XIsbkAI= +-google.golang.org/api v0.14.0/go.mod h1:iLdEw5Ide6rF15KTC1Kkl0iskquN2gFfn9o9XIsbkAI= +-google.golang.org/api v0.15.0/go.mod h1:iLdEw5Ide6rF15KTC1Kkl0iskquN2gFfn9o9XIsbkAI= +-google.golang.org/api v0.17.0/go.mod h1:BwFmGc8tA3vsd7r/7kR8DY7iEEGSU04BFxCo5jP/sfE= +-google.golang.org/api v0.18.0/go.mod h1:BwFmGc8tA3vsd7r/7kR8DY7iEEGSU04BFxCo5jP/sfE= +-google.golang.org/api v0.19.0/go.mod h1:BwFmGc8tA3vsd7r/7kR8DY7iEEGSU04BFxCo5jP/sfE= +-google.golang.org/api v0.20.0/go.mod h1:BwFmGc8tA3vsd7r/7kR8DY7iEEGSU04BFxCo5jP/sfE= +-google.golang.org/api v0.22.0/go.mod h1:BwFmGc8tA3vsd7r/7kR8DY7iEEGSU04BFxCo5jP/sfE= +-google.golang.org/api v0.24.0/go.mod h1:lIXQywCXRcnZPGlsd8NbLnOjtAoL6em04bJ9+z0MncE= +-google.golang.org/api v0.28.0/go.mod h1:lIXQywCXRcnZPGlsd8NbLnOjtAoL6em04bJ9+z0MncE= +-google.golang.org/api v0.29.0/go.mod h1:Lcubydp8VUV7KeIHD9z2Bys/sm/vGKnG1UHuDBSrHWM= +-google.golang.org/api v0.30.0/go.mod h1:QGmEvQ87FHZNiUVJkT14jQNYJ4ZJjdRF23ZXz5138Fc= +-google.golang.org/appengine v1.1.0/go.mod h1:EbEs0AVv82hx2wNQdGPgUI5lhzA/G0D9YwlJXL52JkM= +-google.golang.org/appengine v1.4.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4= +-google.golang.org/appengine v1.5.0/go.mod h1:xpcJRLb0r/rnEns0DIKYYv+WjYCduHsrkT7/EB5XEv4= +-google.golang.org/appengine v1.6.1/go.mod h1:i06prIuMbXzDqacNJfV5OdTW448YApPu5ww/cMBSeb0= +-google.golang.org/appengine v1.6.5/go.mod h1:8WjMMxjGQR8xUklV/ARdw2HLXBOI7O7uCIDZVag1xfc= +-google.golang.org/appengine v1.6.6/go.mod h1:8WjMMxjGQR8xUklV/ARdw2HLXBOI7O7uCIDZVag1xfc= +-google.golang.org/appengine v1.6.8 h1:IhEN5q69dyKagZPYMSdIjS2HqprW324FRQZJcGqPAsM= +-google.golang.org/appengine v1.6.8/go.mod h1:1jJ3jBArFh5pcgW8gCtRJnepW8FzD1V44FJffLiz/Ds= +-google.golang.org/genproto v0.0.0-20180817151627-c66870c02cf8/go.mod h1:JiN7NxoALGmiZfu7CAH4rXhgtRTLTxftemlI0sWmxmc= +-google.golang.org/genproto v0.0.0-20190307195333-5fe7a883aa19/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE= +-google.golang.org/genproto v0.0.0-20190418145605-e7d98fc518a7/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE= +-google.golang.org/genproto v0.0.0-20190425155659-357c62f0e4bb/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE= +-google.golang.org/genproto v0.0.0-20190502173448-54afdca5d873/go.mod h1:VzzqZJRnGkLBvHegQrXjBqPurQTc5/KpmUdxsrq26oE= +-google.golang.org/genproto v0.0.0-20190801165951-fa694d86fc64/go.mod h1:DMBHOl98Agz4BDEuKkezgsaosCRResVns1a3J2ZsMNc= +-google.golang.org/genproto v0.0.0-20190819201941-24fa4b261c55/go.mod h1:DMBHOl98Agz4BDEuKkezgsaosCRResVns1a3J2ZsMNc= +-google.golang.org/genproto v0.0.0-20190911173649-1774047e7e51/go.mod h1:IbNlFCBrqXvoKpeg0TB2l7cyZUmoaFKYIwrEpbDKLA8= +-google.golang.org/genproto v0.0.0-20191108220845-16a3f7862a1a/go.mod h1:n3cpQtvxv34hfy77yVDNjmbRyujviMdxYliBSkLhpCc= +-google.golang.org/genproto v0.0.0-20191115194625-c23dd37a84c9/go.mod h1:n3cpQtvxv34hfy77yVDNjmbRyujviMdxYliBSkLhpCc= +-google.golang.org/genproto v0.0.0-20191216164720-4f79533eabd1/go.mod h1:n3cpQtvxv34hfy77yVDNjmbRyujviMdxYliBSkLhpCc= +-google.golang.org/genproto v0.0.0-20191230161307-f3c370f40bfb/go.mod h1:n3cpQtvxv34hfy77yVDNjmbRyujviMdxYliBSkLhpCc= +-google.golang.org/genproto v0.0.0-20200115191322-ca5a22157cba/go.mod h1:n3cpQtvxv34hfy77yVDNjmbRyujviMdxYliBSkLhpCc= +-google.golang.org/genproto v0.0.0-20200122232147-0452cf42e150/go.mod h1:n3cpQtvxv34hfy77yVDNjmbRyujviMdxYliBSkLhpCc= +-google.golang.org/genproto v0.0.0-20200204135345-fa8e72b47b90/go.mod h1:GmwEX6Z4W5gMy59cAlVYjN9JhxgbQH6Gn+gFDQe2lzA= +-google.golang.org/genproto v0.0.0-20200212174721-66ed5ce911ce/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c= +-google.golang.org/genproto v0.0.0-20200224152610-e50cd9704f63/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c= +-google.golang.org/genproto v0.0.0-20200228133532-8c2c7df3a383/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c= +-google.golang.org/genproto v0.0.0-20200305110556-506484158171/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c= +-google.golang.org/genproto v0.0.0-20200312145019-da6875a35672/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c= +-google.golang.org/genproto v0.0.0-20200331122359-1ee6d9798940/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c= +-google.golang.org/genproto v0.0.0-20200423170343-7949de9c1215/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c= +-google.golang.org/genproto v0.0.0-20200430143042-b979b6f78d84/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c= +-google.golang.org/genproto v0.0.0-20200511104702-f5ebc3bea380/go.mod h1:55QSHmfGQM9UVYDPBsyGGes0y52j32PQ3BqQfXhyH3c= +-google.golang.org/genproto v0.0.0-20200515170657-fc4c6c6a6587/go.mod h1:YsZOwe1myG/8QRHRsmBRE1LrgQY60beZKjly0O1fX9U= +-google.golang.org/genproto v0.0.0-20200526211855-cb27e3aa2013/go.mod h1:NbSheEEYHJ7i3ixzK3sjbqSGDJWnxyFXZblF3eUsNvo= +-google.golang.org/genproto v0.0.0-20200618031413-b414f8b61790/go.mod h1:jDfRM7FcilCzHH/e9qn6dsT145K34l5v+OpcnNgKAAA= +-google.golang.org/genproto v0.0.0-20200729003335-053ba62fc06f/go.mod h1:FWY/as6DDZQgahTzZj3fqbO1CbirC29ZNUFHwi0/+no= +-google.golang.org/genproto v0.0.0-20200804131852-c06518451d9c/go.mod h1:FWY/as6DDZQgahTzZj3fqbO1CbirC29ZNUFHwi0/+no= +-google.golang.org/genproto v0.0.0-20200825200019-8632dd797987/go.mod h1:FWY/as6DDZQgahTzZj3fqbO1CbirC29ZNUFHwi0/+no= +-google.golang.org/genproto/googleapis/rpc v0.0.0-20231120223509-83a465c0220f h1:ultW7fxlIvee4HYrtnaRPon9HpEgFk5zYpmfMgtKB5I= +-google.golang.org/genproto/googleapis/rpc v0.0.0-20231120223509-83a465c0220f/go.mod h1:L9KNLi232K1/xB6f7AlSX692koaRnKaWSR0stBki0Yc= +-google.golang.org/grpc v1.19.0/go.mod h1:mqu4LbDTu4XGKhr4mRzUsmM4RtVoemTSY81AxZiDr8c= +-google.golang.org/grpc v1.20.1/go.mod h1:10oTOabMzJvdu6/UiuZezV6QK5dSlG84ov/aaiqXj38= +-google.golang.org/grpc v1.21.1/go.mod h1:oYelfM1adQP15Ek0mdvEgi9Df8B9CZIaU1084ijfRaM= +-google.golang.org/grpc v1.23.0/go.mod h1:Y5yQAOtifL1yxbo5wqy6BxZv8vAUGQwXBOALyacEbxg= +-google.golang.org/grpc v1.25.1/go.mod h1:c3i+UQWmh7LiEpx4sFZnkU36qjEYZ0imhYfXVyQciAY= +-google.golang.org/grpc v1.26.0/go.mod h1:qbnxyOmOxrQa7FizSgH+ReBfzJrCY1pSN7KXBS8abTk= +-google.golang.org/grpc v1.27.0/go.mod h1:qbnxyOmOxrQa7FizSgH+ReBfzJrCY1pSN7KXBS8abTk= +-google.golang.org/grpc v1.27.1/go.mod h1:qbnxyOmOxrQa7FizSgH+ReBfzJrCY1pSN7KXBS8abTk= +-google.golang.org/grpc v1.28.0/go.mod h1:rpkK4SK4GF4Ach/+MFLZUBavHOvF2JJB5uozKKal+60= +-google.golang.org/grpc v1.29.1/go.mod h1:itym6AZVZYACWQqET3MqgPpjcuV5QH3BxFS3IjizoKk= +-google.golang.org/grpc v1.30.0/go.mod h1:N36X2cJ7JwdamYAgDz+s+rVMFjt3numwzf/HckM8pak= +-google.golang.org/grpc v1.31.0/go.mod h1:N36X2cJ7JwdamYAgDz+s+rVMFjt3numwzf/HckM8pak= +-google.golang.org/grpc v1.33.2/go.mod h1:JMHMWHQWaTccqQQlmk3MJZS+GWXOdAesneDmEnv2fbc= +-google.golang.org/grpc v1.60.0 h1:6FQAR0kM31P6MRdeluor2w2gPaS4SVNrD/DNTxrQ15k= +-google.golang.org/grpc v1.60.0/go.mod h1:OlCHIeLYqSSsLi6i49B5QGdzaMZK9+M7LXN2FKz4eGM= ++gonum.org/v1/gonum v0.12.0 h1:xKuo6hzt+gMav00meVPUlXwSdoEJP46BR+wdxQEFK2o= ++gonum.org/v1/gonum v0.12.0/go.mod h1:73TDxJfAAHeA8Mk9mf8NlIppyhQNo5GLTcYeqgo2lvY= ++google.golang.org/genproto/googleapis/rpc v0.0.0-20240903143218-8af14fe29dc1 h1:pPJltXNxVzT4pK9yD8vR9X75DaWYYmLGMsEvBfFQZzQ= ++google.golang.org/genproto/googleapis/rpc v0.0.0-20240903143218-8af14fe29dc1/go.mod h1:UqMtugtsSgubUsoxbuAoiCXvqvErP7Gf0so0mK9tHxU= ++google.golang.org/grpc v1.66.0 h1:DibZuoBznOxbDQxRINckZcUvnCEvrW9pcWIE2yF9r1c= ++google.golang.org/grpc v1.66.0/go.mod h1:s3/l6xSSCURdVfAnL+TqCNMyTDAGN6+lZeVxnZR128Y= + google.golang.org/protobuf v0.0.0-20200109180630-ec00e32a8dfd/go.mod h1:DFci5gLYBciE7Vtevhsrf46CRTquxDuWsQurQQe4oz8= + google.golang.org/protobuf v0.0.0-20200221191635-4d8936d0db64/go.mod h1:kwYJMbMJ01Woi6D6+Kah6886xMZcty6N08ah7+eCXa0= + google.golang.org/protobuf v0.0.0-20200228230310-ab0ca4ff8a60/go.mod h1:cfTl7dwQJ+fmap5saPgwCLgHXTUD7jkjRqWcaiX5VyM= + google.golang.org/protobuf v1.20.1-0.20200309200217-e05f789c0967/go.mod h1:A+miEFZTKqfCUM6K7xSMQL9OKL/b6hQv+e19PK+JZNE= + google.golang.org/protobuf v1.21.0/go.mod h1:47Nbq4nVaFHyn7ilMalzfO3qCViNmqZ2kzikPIcrTAo= +-google.golang.org/protobuf v1.22.0/go.mod h1:EGpADcykh3NcUnDUJcl1+ZksZNG86OlYog2l/sGQquU= + google.golang.org/protobuf v1.23.0/go.mod h1:EGpADcykh3NcUnDUJcl1+ZksZNG86OlYog2l/sGQquU= +-google.golang.org/protobuf v1.23.1-0.20200526195155-81db48ad09cc/go.mod h1:EGpADcykh3NcUnDUJcl1+ZksZNG86OlYog2l/sGQquU= +-google.golang.org/protobuf v1.24.0/go.mod h1:r/3tXBNzIEhYS9I1OUVjXDlt8tc493IdKGjtUeSXeh4= +-google.golang.org/protobuf v1.25.0/go.mod h1:9JNX74DMeImyA3h4bdi1ymwjUzf21/xIlbajtzgsN7c= + google.golang.org/protobuf v1.26.0-rc.1/go.mod h1:jlhhOSvTdKEhbULTjvd4ARK9grFBp09yW+WbY/TyQbw= + google.golang.org/protobuf v1.26.0/go.mod h1:9q0QmTI4eRPtz6boOQmLYwt+qCgq0jsYwAQnmE0givc= + google.golang.org/protobuf v1.27.1/go.mod h1:9q0QmTI4eRPtz6boOQmLYwt+qCgq0jsYwAQnmE0givc= +-google.golang.org/protobuf v1.31.0 h1:g0LDEJHgrBl9N9r17Ru3sqWhkIx2NB67okBHPwC7hs8= +-google.golang.org/protobuf v1.31.0/go.mod h1:HV8QOd/L58Z+nl8r43ehVNZIU/HEI6OcFqwMG9pJV4I= +-gopkg.in/alecthomas/kingpin.v2 v2.2.6/go.mod h1:FMv+mEhP44yOT+4EoQTLFTRgOQ1FBLkstjWtayDeSgw= ++google.golang.org/protobuf v1.34.2 h1:6xV6lTsCfpGD21XK49h7MhtcApnLqkfYgPcdHftf6hg= ++google.golang.org/protobuf v1.34.2/go.mod h1:qYOHts0dSfpeUzUFpOMr/WGzszTmLH+DiWniOlNbLDw= + gopkg.in/check.v1 v0.0.0-20161208181325-20d25e280405/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= +-gopkg.in/check.v1 v1.0.0-20180628173108-788fd7840127/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= + gopkg.in/check.v1 v1.0.0-20190902080502-41f04d3bba15/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= +-gopkg.in/check.v1 v1.0.0-20200227125254-8fa46927fb4f/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= +-gopkg.in/check.v1 v1.0.0-20200902074654-038fdea0a05b/go.mod h1:Co6ibVJAznAaIkqp8huTwlJQCZ016jof/cbN4VW5Yz0= + gopkg.in/check.v1 v1.0.0-20201130134442-10cb98267c6c h1:Hei/4ADfdWqJk1ZMxUNpqntNwaWcugrBjAiHlqqRiVk= + gopkg.in/check.v1 v1.0.0-20201130134442-10cb98267c6c/go.mod h1:JHkPIbrfpd72SG/EVd6muEfDQjcINNoR0C8j2r3qZ4Q= +-gopkg.in/errgo.v2 v2.1.0/go.mod h1:hNsd1EY+bozCKY1Ytp96fpM3vjJbqLJn88ws8XvfDNI= + gopkg.in/fsnotify.v1 v1.4.7/go.mod h1:Tz8NjZHkW78fSQdbUxIjBTcgA1z1m8ZHf0WmKUhAMys= + gopkg.in/ini.v1 v1.67.0 h1:Dgnx+6+nfE+IfzjUEISNeydPJh9AXNNsWbGP9KzCsOA= + gopkg.in/ini.v1 v1.67.0/go.mod h1:pNLf8WUiyNEtQjuu5G5vTm06TEv9tsIgeAvK8hOrP4k= +@@ -1371,7 +560,6 @@ gopkg.in/warnings.v0 v0.1.2/go.mod h1:jksf8JmL6Qr/oQM2OXTHunEvvTAsrWBLb6OOjuVWRN + gopkg.in/yaml.v2 v2.2.1/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI= + gopkg.in/yaml.v2 v2.2.2/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI= + gopkg.in/yaml.v2 v2.2.4/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI= +-gopkg.in/yaml.v2 v2.2.5/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI= + gopkg.in/yaml.v2 v2.2.8/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI= + gopkg.in/yaml.v2 v2.3.0/go.mod h1:hI93XBmqTisBFMUTm0b8Fm+jr3Dg1NNxqwp+5A1VGuI= + gopkg.in/yaml.v2 v2.4.0 h1:D8xgwECY7CYvx+Y2n4sBz93Jn9JRvxdiyyo8CTfuKaY= +@@ -1379,27 +567,5 @@ gopkg.in/yaml.v2 v2.4.0/go.mod h1:RDklbk79AGWmwhnvt/jBztapEOGDOx6ZbXqjP6csGnQ= + gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM= + gopkg.in/yaml.v3 v3.0.1 h1:fxVm/GzAzEWqLHuvctI91KS9hhNmmWOoWu0XTYJS7CA= + gopkg.in/yaml.v3 v3.0.1/go.mod h1:K4uyk7z7BCEPqu6E+C64Yfv1cQ7kz7rIZviUmN+EgEM= +-gotest.tools/v3 v3.0.2/go.mod h1:3SzNCllyD9/Y+b5r9JIKQ474KzkZyqLqEfYqMsX94Bk= +-gotest.tools/v3 v3.0.3 h1:4AuOwCGf4lLR9u3YOe2awrHygurzhO/HeQ6laiA6Sx0= +-gotest.tools/v3 v3.0.3/go.mod h1:Z7Lb0S5l+klDB31fvDQX8ss/FlKDxtlFlw3Oa8Ymbl8= +-honnef.co/go/tools v0.0.0-20190102054323-c2f93a96b099/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4= +-honnef.co/go/tools v0.0.0-20190106161140-3f1c8253044a/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4= +-honnef.co/go/tools v0.0.0-20190418001031-e561f6794a2a/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4= +-honnef.co/go/tools v0.0.0-20190523083050-ea95bdfd59fc/go.mod h1:rf3lG4BRIbNafJWhAfAdb/ePZxsR/4RtNHQocxwk9r4= +-honnef.co/go/tools v0.0.1-2019.2.3/go.mod h1:a3bituU0lyd329TUQxRnasdCoJDkEUEAqEt0JzvZhAg= +-honnef.co/go/tools v0.0.1-2020.1.3/go.mod h1:X/FiERA/W4tHapMX5mGpAtMSVEeEUOyHaw9vFzvIQ3k= +-honnef.co/go/tools v0.0.1-2020.1.4/go.mod h1:X/FiERA/W4tHapMX5mGpAtMSVEeEUOyHaw9vFzvIQ3k= +-honnef.co/go/tools v0.3.3 h1:oDx7VAwstgpYpb3wv0oxiZlxY+foCpRAwY7Vk6XpAgA= +-honnef.co/go/tools v0.3.3/go.mod h1:jzwdWgg7Jdq75wlfblQxO4neNaFFSvgc1tD5Wv8U0Yw= +-mvdan.cc/gofumpt v0.4.0 h1:JVf4NN1mIpHogBj7ABpgOyZc65/UUOkKQFkoURsz4MM= +-mvdan.cc/gofumpt v0.4.0/go.mod h1:PljLOHDeZqgS8opHRKLzp2It2VBuSdteAgqUfzMTxlQ= +-mvdan.cc/interfacer v0.0.0-20180901003855-c20040233aed h1:WX1yoOaKQfddO/mLzdV4wptyWgoH/6hwLs7QHTixo0I= +-mvdan.cc/interfacer v0.0.0-20180901003855-c20040233aed/go.mod h1:Xkxe497xwlCKkIaQYRfC7CSLworTXY9RMqwhhCm+8Nc= +-mvdan.cc/lint v0.0.0-20170908181259-adc824a0674b h1:DxJ5nJdkhDlLok9K6qO+5290kphDJbHOQO1DFFFTeBo= +-mvdan.cc/lint v0.0.0-20170908181259-adc824a0674b/go.mod h1:2odslEg/xrtNQqCYg2/jCoyKnw3vv5biOc3JnIcYfL4= +-mvdan.cc/unparam v0.0.0-20220706161116-678bad134442 h1:seuXWbRB1qPrS3NQnHmFKLJLtskWyueeIzmLXghMGgk= +-mvdan.cc/unparam v0.0.0-20220706161116-678bad134442/go.mod h1:F/Cxw/6mVrNKqrR2YjFf5CaW0Bw4RL8RfbEf4GRggJk= +-rsc.io/binaryregexp v0.2.0/go.mod h1:qTv7/COck+e2FymRvadv62gMdZztPaShugOCi3I+8D8= +-rsc.io/pdf v0.1.1/go.mod h1:n8OzWcQ6Sp37PL01nO98y4iUCRdTGarVfzxY20ICaU4= +-rsc.io/quote/v3 v3.1.0/go.mod h1:yEA65RcK8LyAZtP9Kv3t0HmxON59tX3rD+tICJqUlj0= +-rsc.io/sampler v1.3.0/go.mod h1:T1hPZKmBbMNahiBKFy5HrXp6adAjACjK9JXDnKaTXpA= ++gotest.tools v2.2.0+incompatible h1:VsBPFP1AI068pPrMxtb/S8Zkgf9xEmTLJjfM+P5UIEo= ++gotest.tools v2.2.0+incompatible/go.mod h1:DsYFclhRJ6vuDpmuTbkuFWG+y2sxOXAzmJt81HFBacw= diff --git a/patches/mempool/cat/spec.md.patch b/patches/mempool/cat/spec.md.patch new file mode 100644 index 00000000000..4da14cafc26 --- /dev/null +++ b/patches/mempool/cat/spec.md.patch @@ -0,0 +1,107 @@ +diff --git a/mempool/cat/spec.md b/mempool/cat/spec.md +new file mode 100644 +index 000000000..fec54796a +--- /dev/null ++++ b/mempool/cat/spec.md +@@ -0,0 +1,101 @@ ++# Content Addressable Transaction Pool Specification ++ ++- 01.12.2022 | Initial specification (@cmwaters) ++- 09.12.2022 | Add Push/Pull mechanics (@cmwaters) ++ ++### Outline ++ ++This document specifies the properties, design and implementation of a content addressable transaction pool (CAT). This protocol is intended as an alternative to the FIFO and Priority mempools currently built-in to the Tendermint consensus protocol. The term content-addressable here, indicates that each transaction is identified by a smaller, unique tag (in this case a sha256 hash). These tags are broadcast among the transactions as a means of more compactly indicating which peers have which transactions. Tracking what each peer has aims at reducing the amount of duplication. In a network without content tracking, a peer may receive as many duplicate transactions as peers connected to. The tradeoff here therefore is that the transactions are significantly larger than the tag such that the sum of the data saved sending what would be duplicated transactions is larger than the sum of sending each peer a tag. ++ ++### Purpose ++ ++The objective of such a protocol is to transport transactions from the author (usually a client) to a proposed block, optimizing both latency and throughput i.e. how quickly can a transaction be proposed (and committed) and how many transactions can be transported into a block at once. ++ ++Typically the mempool serves to receive inbound transactions via an RPC endpoint, gossip them to all nodes in the network (regardless of whether they are capable of proposing a block or not), and stage groups of transactions to both consensus and the application to be included in a block. ++ ++### Assumptions ++ ++The following are assumptions inherited from existing Tendermint mempool protocols: ++ ++- `CheckTx` should be seen as a simple gatekeeper to what transactions enter the pool to be gossiped and staged. It is non-deterministic: one node may reject a transaction that another node keeps. ++- Applications implementing `CheckTx` are responsible for replay protection (i.e. the same transaction being present in multiple blocks). The mempool ensures that within the same block, no duplicate transactions can exist. ++- The underlying p2p layer guarantees eventually reliable broadcast. A transaction need only be sent once to eventually reach the target peer. ++ ++### Messages ++ ++The CAT protocol extends on the existing mempool implementations by introducing two new protobuf messages: ++ ++```protobuf ++message SeenTx { ++ bytes tx_key = 1; ++ optional string from = 2; ++} ++ ++message WantTx { ++ bytes tx_key = 1; ++} ++``` ++ ++Both `SeenTx` and `WantTx` contain the sha256 hash of the raw transaction bytes. `SeenTx` also contains an optional `p2p.ID` that corresponds to the peer that the node received the tx from. The only validation for both is that the byte slice of the `tx_key` MUST have a length of 32. ++ ++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. ++ ++### Outbound logic ++ ++A node in the protocol has two distinct modes: "broadcast" and "request/response". When a node receives a transaction via RPC (or specifically through `CheckTx`), it assumed that it is the only recipient from that client and thus will immediately send that transaction, after validation, to all connected peers. Afterwards, only "request/response" is used to disseminate that transaction to everyone else. ++ ++> **Note:** ++> Given that one can configure a mempool to switch off broadcast, there are no guarantees when a client submits a transaction via RPC and no error is returned that it will find its way into a proposers transaction pool. ++ ++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 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 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. ++ ++A `WantTx` message is always sent point to point and never broadcasted. A `WantTx` MUST only be sent after receiving a `SeenTx` message from that peer. There is one exception which is that a `WantTx` MAY also be sent by a node after receiving an identical `WantTx` message from a peer that had previously received the nodes `SeenTx` but which after the lapse in time, did no longer exist in the nodes transaction pool. This provides an optional synchronous method for communicating that a node no longer has a transaction rather than relying on the defaulted asynchronous approach which is to wait for a period of time and try again with a new peer. ++ ++`WantTx` must be tracked. A node SHOULD not send multiple `WantTx`s to multiple peers for the same transaction at once but wait for a period that matches the expected network latency before rerequesting the transaction to another peer. ++ ++### Inbound logic ++ ++Transaction pools are solely run in-memory; thus when a node stops, all transactions are discarded. To avoid the scenario where a node restarts and does not receive transactions because other nodes recorded a `SeenTx` message from their previous run, each transaction pool should track peer state based **per connection** and not per `NodeID`. ++ ++Upon receiving a `Txs` message: ++ ++- Check whether it is in response to a request or simply an unsolicited broadcast ++- Validate the tx against current resources and the applications `CheckTx` ++- If rejected or evicted, mark accordingly ++- If successful, send a `SeenTx` message to all connected peers excluding the original sender. If it was from an initial broadcast, the `SeenTx` should populate the `From` field with the `p2p.ID` of the recipient else if it is in response to a request `From` should remain empty. ++ ++Upon receiving a `SeenTx` message: ++ ++- It should mark the peer as having seen the message. ++- If the node has recently rejected that transaction, it SHOULD ignore the message. ++- If the node already has the transaction, it SHOULD ignore the 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. ++ ++Upon receiving a `WantTx` message: ++ ++- If it has the transaction, it MUST respond with a `Txs` message containing that transaction. ++- If it does not have the transaction, it MAY respond with an identical `WantTx` or rely on the timeout of the peer that requested the transaction to eventually ask another peer. ++ ++### Compatibility ++ ++CAT has Go API compatibility with the existing two mempool implementations. It implements both the `Reactor` interface required by Tendermint's P2P layer and the `Mempool` interface used by `consensus` and `rpc`. CAT is currently network compatible with existing implementations (by using another channel), but the protocol is unaware that it is communicating with a different mempool and that `SeenTx` and `WantTx` messages aren't reaching those peers thus it is recommended that the entire network use CAT. ++ diff --git a/patches/networks/local/localnode/Dockerfile.patch b/patches/networks/local/localnode/Dockerfile.patch new file mode 100644 index 00000000000..ba408095679 --- /dev/null +++ b/patches/networks/local/localnode/Dockerfile.patch @@ -0,0 +1,10 @@ +diff --git a/networks/local/localnode/Dockerfile b/networks/local/localnode/Dockerfile +index e1c3c4527..197d07a70 100644 +--- a/networks/local/localnode/Dockerfile ++++ b/networks/local/localnode/Dockerfile +@@ -1,4 +1,4 @@ +-FROM alpine:3.7 ++FROM alpine:3.14 + + RUN apk update && \ + apk upgrade && \ diff --git a/patches/pkg/trace/README.md.patch b/patches/pkg/trace/README.md.patch new file mode 100644 index 00000000000..840a9531e06 --- /dev/null +++ b/patches/pkg/trace/README.md.patch @@ -0,0 +1,108 @@ +diff --git a/pkg/trace/README.md b/pkg/trace/README.md +new file mode 100644 +index 000000000..09baeb903 +--- /dev/null ++++ b/pkg/trace/README.md +@@ -0,0 +1,102 @@ ++# trace package ++ ++The `trace` package provides a decently fast way to store traces locally. ++ ++## Usage ++ ++To enable the local tracer, add the following to the config.toml file: ++ ++```toml ++# The tracer to use for collecting trace data. ++trace_type = "local" ++ ++# The size of the batches that are sent to the database. ++trace_push_batch_size = 1000 ++ ++# The list of tables that are updated when tracing. All available tables and ++# their schema can be found in the pkg/trace/schema package. It is represented as a ++# comma separated string. For example: "consensus_round_state,mempool_tx". ++tracing_tables = "consensus_round_state,mempool_tx" ++``` ++ ++Trace data will now be stored to the `.celestia-app/data/traces` directory, and ++save the file to the specified directory in the `table_name.jsonl` format. ++ ++To read the contents of the file, open it and pass it the Decode function. This ++returns all of the events in that file as a slice. ++ ++```go ++events, err := DecodeFile[schema.MempoolTx](file) ++if err != nil { ++ return err ++} ++``` ++ ++### Pull Based Event Collection ++ ++Pull based event collection is where external servers connect to and pull trace ++data from the consensus node. ++ ++To use this, change the config.toml to store traces in the ++.celestia-app/data/traces directory. ++ ++```toml ++# The tracer pull address specifies which address will be used for pull based ++# event collection. If empty, the pull based server will not be started. ++trace_pull_address = ":26661" ++``` ++ ++To retrieve a table remotely using the pull based server, call the following ++function: ++ ++```go ++err := GetTable("http://1.2.3.4:26661", "mempool_tx", "directory to store the file") ++if err != nil { ++ return err ++} ++``` ++ ++This stores the data locally in the specified directory. ++ ++ ++### Push Based Event Collection ++ ++Push based event collection is where the consensus node pushes trace data to an ++external server. At the moment, this is just an S3 bucket. To use this, two options are available: ++#### Using push config file ++ ++Add the following to the config.toml file: ++ ++```toml ++# TracePushConfig is the relative path of the push config. ++# This second config contains credentials for where and how often to ++# push trace data to. For example, if the config is next to this config, ++# it would be "push_config.json". ++trace_push_config = "{{ .Instrumentation.TracePushConfig }}" ++``` ++ ++The push config file is a JSON file that should look like this: ++ ++```json ++{ ++ "bucket": "bucket-name", ++ "region": "region", ++ "access_key": "", ++ "secret_key": "", ++ "push_delay": 60 // number of seconds to wait between intervals of pushing all files ++} ++``` ++ ++#### Using environment variables for s3 bucket ++ ++Alternatively, you can set the following environment variables: ++ ++```bash ++export TRACE_PUSH_BUCKET_NAME=bucket-name ++export TRACE_PUSH_REGION=region ++export TRACE_PUSH_ACCESS_KEY=access-key ++export TRACE_PUSH_SECRET_KEY=secret-key ++export TRACE_PUSH_DELAY=push-delay ++``` ++ ++`bucket_name` , `region`, `access_key`, `secret_key` and `push_delay` are the s3 bucket name, region, access key, secret key and the delay between pushes respectively. diff --git a/patches/proto/buf.yaml.patch b/patches/proto/buf.yaml.patch new file mode 100644 index 00000000000..ce26b18c709 --- /dev/null +++ b/patches/proto/buf.yaml.patch @@ -0,0 +1,10 @@ +diff --git a/proto/buf.yaml b/proto/buf.yaml +index 90988439b..197d20181 100644 +--- a/proto/buf.yaml ++++ b/proto/buf.yaml +@@ -10,3 +10,5 @@ lint: + - BASIC + - FILE_LOWER_SNAKE_CASE + - UNARY_RPC ++ except: ++ - RPC_NO_SERVER_STREAMING diff --git a/patches/proto/tendermint/abci/types.proto.patch b/patches/proto/tendermint/abci/types.proto.patch new file mode 100644 index 00000000000..d12ffcb86c3 --- /dev/null +++ b/patches/proto/tendermint/abci/types.proto.patch @@ -0,0 +1,143 @@ +diff --git a/proto/tendermint/abci/types.proto b/proto/tendermint/abci/types.proto +index 44f861129..2adc2ba79 100644 +--- a/proto/tendermint/abci/types.proto ++++ b/proto/tendermint/abci/types.proto +@@ -11,6 +11,7 @@ import "tendermint/crypto/keys.proto"; + import "tendermint/types/params.proto"; + import "google/protobuf/timestamp.proto"; + import "gogoproto/gogo.proto"; ++import "google/protobuf/duration.proto"; + + // This file is copied from http://github.com/tendermint/abci + // NOTE: When using custom types, mind the warnings. +@@ -36,6 +37,8 @@ message Request { + RequestOfferSnapshot offer_snapshot = 13; + RequestLoadSnapshotChunk load_snapshot_chunk = 14; + RequestApplySnapshotChunk apply_snapshot_chunk = 15; ++ RequestPrepareProposal prepare_proposal = 16; ++ RequestProcessProposal process_proposal = 17; + } + } + +@@ -45,6 +48,11 @@ message RequestEcho { + + message RequestFlush {} + ++message TimeoutsInfo { ++ google.protobuf.Duration timeout_propose = 1 [(gogoproto.nullable) = false, (gogoproto.stdduration) = true]; ++ google.protobuf.Duration timeout_commit = 2 [(gogoproto.nullable) = false, (gogoproto.stdduration) = true]; ++} ++ + message RequestInfo { + string version = 1; + uint64 block_version = 2; +@@ -106,8 +114,9 @@ message RequestListSnapshots {} + + // offers a snapshot to the application + message RequestOfferSnapshot { +- Snapshot snapshot = 1; // snapshot offered by peers +- bytes app_hash = 2; // light client-verified app hash for snapshot height ++ Snapshot snapshot = 1; // snapshot offered by peers ++ bytes app_hash = 2; // light client-verified app hash for snapshot height ++ uint64 app_version = 3; // The application version at which the snapshot was taken + } + + // loads a snapshot chunk +@@ -124,6 +133,28 @@ message RequestApplySnapshotChunk { + string sender = 3; + } + ++message RequestPrepareProposal { ++ // BlockData is a slice of candidate transactions that may be included in a ++ // block. BlockData is sent to the application so that the application can ++ // filter and re-arrange the slice of candidate transactions. ++ tendermint.types.Data block_data = 1; ++ // BlockDataSize is the maximum size (in bytes) that BlockData should be. ++ int64 block_data_size = 2; ++ // chain_id is a unique identifier for the blockchain network this proposal ++ // belongs to (e.g. mocha-1). ++ string chain_id = 3; ++ // height is the height of the proposal block ++ int64 height = 4; ++ // time is the time that will end up in the header. This is the voting power ++ // weighted median of the last commit. ++ google.protobuf.Timestamp time = 5 [(gogoproto.nullable) = false, (gogoproto.stdtime) = true]; ++} ++ ++message RequestProcessProposal { ++ tendermint.types.Header header = 1 [(gogoproto.nullable) = false]; ++ tendermint.types.Data block_data = 2; ++} ++ + //---------------------------------------- + // Response types + +@@ -145,6 +176,8 @@ message Response { + ResponseOfferSnapshot offer_snapshot = 14; + ResponseLoadSnapshotChunk load_snapshot_chunk = 15; + ResponseApplySnapshotChunk apply_snapshot_chunk = 16; ++ ResponsePrepareProposal prepare_proposal = 17; ++ ResponseProcessProposal process_proposal = 18; + } + } + +@@ -167,6 +200,8 @@ message ResponseInfo { + + int64 last_block_height = 4; + bytes last_block_app_hash = 5; ++ ++ TimeoutsInfo timeouts = 6 [(gogoproto.nullable) = false]; + } + + // nondeterministic +@@ -181,6 +216,7 @@ message ResponseInitChain { + ConsensusParams consensus_params = 1; + repeated ValidatorUpdate validators = 2 [(gogoproto.nullable) = false]; + bytes app_hash = 3; ++ TimeoutsInfo timeouts = 4 [(gogoproto.nullable) = false]; + } + + message ResponseQuery { +@@ -238,6 +274,7 @@ message ResponseEndBlock { + ConsensusParams consensus_param_updates = 2; + repeated Event events = 3 + [(gogoproto.nullable) = false, (gogoproto.jsontag) = "events,omitempty"]; ++ TimeoutsInfo timeouts = 4 [(gogoproto.nullable) = false]; + } + + message ResponseCommit { +@@ -282,6 +319,21 @@ message ResponseApplySnapshotChunk { + } + } + ++message ResponsePrepareProposal { ++ tendermint.types.Data block_data = 1; ++} ++ ++message ResponseProcessProposal { ++ Result result = 1; ++ repeated bytes evidence = 2; ++ ++ enum Result { ++ UNKNOWN = 0; // Unknown result, invalidate ++ ACCEPT = 1; // proposal verified, vote on the proposal ++ REJECT = 2; // proposal invalidated ++ } ++} ++ + //---------------------------------------- + // Misc. + +@@ -406,8 +458,8 @@ service ABCIApplication { + rpc EndBlock(RequestEndBlock) returns (ResponseEndBlock); + rpc ListSnapshots(RequestListSnapshots) returns (ResponseListSnapshots); + rpc OfferSnapshot(RequestOfferSnapshot) returns (ResponseOfferSnapshot); +- rpc LoadSnapshotChunk(RequestLoadSnapshotChunk) +- returns (ResponseLoadSnapshotChunk); +- rpc ApplySnapshotChunk(RequestApplySnapshotChunk) +- returns (ResponseApplySnapshotChunk); ++ rpc LoadSnapshotChunk(RequestLoadSnapshotChunk) returns (ResponseLoadSnapshotChunk); ++ rpc ApplySnapshotChunk(RequestApplySnapshotChunk) returns (ResponseApplySnapshotChunk); ++ rpc PrepareProposal(RequestPrepareProposal) returns (ResponsePrepareProposal); ++ rpc ProcessProposal(RequestProcessProposal) returns (ResponseProcessProposal); + } diff --git a/patches/proto/tendermint/mempool/types.proto.patch b/patches/proto/tendermint/mempool/types.proto.patch new file mode 100644 index 00000000000..b53bf82a648 --- /dev/null +++ b/patches/proto/tendermint/mempool/types.proto.patch @@ -0,0 +1,24 @@ +diff --git a/proto/tendermint/mempool/types.proto b/proto/tendermint/mempool/types.proto +index b55d9717b..75602411d 100644 +--- a/proto/tendermint/mempool/types.proto ++++ b/proto/tendermint/mempool/types.proto +@@ -7,8 +7,18 @@ message Txs { + repeated bytes txs = 1; + } + ++message SeenTx { ++ bytes tx_key = 1; ++} ++ ++message WantTx { ++ bytes tx_key = 1; ++} ++ + message Message { + oneof sum { +- Txs txs = 1; ++ Txs txs = 1; ++ SeenTx seen_tx = 2; ++ WantTx want_tx = 3; + } + } diff --git a/patches/proto/tendermint/rpc/grpc/types.proto.patch b/patches/proto/tendermint/rpc/grpc/types.proto.patch new file mode 100644 index 00000000000..03ffc87b08e --- /dev/null +++ b/patches/proto/tendermint/rpc/grpc/types.proto.patch @@ -0,0 +1,143 @@ +diff --git a/proto/tendermint/rpc/grpc/types.proto b/proto/tendermint/rpc/grpc/types.proto +index ee948a406..f6886a658 100644 +--- a/proto/tendermint/rpc/grpc/types.proto ++++ b/proto/tendermint/rpc/grpc/types.proto +@@ -3,6 +3,12 @@ package tendermint.rpc.grpc; + option go_package = "github.com/tendermint/tendermint/rpc/grpc;coregrpc"; + + import "tendermint/abci/types.proto"; ++import "tendermint/types/types.proto"; ++import "tendermint/p2p/types.proto"; ++import "tendermint/crypto/keys.proto"; ++import "tendermint/types/validator.proto"; ++import "google/protobuf/timestamp.proto"; ++import "gogoproto/gogo.proto"; + + //---------------------------------------- + // Request types +@@ -13,6 +19,38 @@ message RequestBroadcastTx { + bytes tx = 1; + } + ++message BlockByHashRequest { ++ bytes hash = 1; ++ bool prove = 2; ++} ++ ++message BlockByHeightRequest { ++ // Height the requested block height. ++ // If height is equal to 0, the latest height stored in the block store ++ // will be used. ++ int64 height = 1; ++ // Prove set to true to return the parts proofs. ++ bool prove = 2; ++} ++ ++message CommitRequest { ++ // Height the requested block commit height. ++ // If height is equal to 0, the latest height stored in the block store ++ // will be used. ++ int64 height = 1; ++} ++ ++message ValidatorSetRequest { ++ // Height the requested validator set height. ++ // If height is equal to 0, the latest height stored in the block store ++ // will be used. ++ int64 height = 1; ++} ++ ++message SubscribeNewHeightsRequest {} ++ ++message StatusRequest {} ++ + //---------------------------------------- + // Response types + +@@ -23,6 +61,73 @@ message ResponseBroadcastTx { + tendermint.abci.ResponseDeliverTx deliver_tx = 2; + } + ++message StreamedBlockByHashResponse { ++ tendermint.types.Part block_part = 1; ++ // Commit is only set in the first part, and ++ // it stays nil in the remaining ones. ++ tendermint.types.Commit commit = 2; ++ // ValidatorSet is only set in the first part, and ++ // it stays nil in the remaining ones. ++ tendermint.types.ValidatorSet validator_set = 3; ++ bool is_last = 4; ++} ++ ++message StreamedBlockByHeightResponse { ++ tendermint.types.Part block_part = 1; ++ // Commit is only set in the first part, and ++ // it stays nil in the remaining ones. ++ tendermint.types.Commit commit = 2; ++ // ValidatorSet is only set in the first part, and ++ // it stays nil in the remaining ones. ++ tendermint.types.ValidatorSet validator_set = 3; ++ bool is_last = 4; ++} ++ ++message CommitResponse { ++ tendermint.types.Commit commit = 1; ++} ++ ++message ValidatorSetResponse { ++ // ValidatorSet the requested validator set. ++ tendermint.types.ValidatorSet validator_set = 1; ++ // Height the height corresponding to the returned ++ // validator set. ++ int64 height = 2; ++} ++ ++message NewHeightEvent { ++ int64 height = 1; ++ bytes hash = 2; ++} ++ ++message StatusResponse { ++ tendermint.p2p.DefaultNodeInfo node_info = 1; ++ SyncInfo sync_info = 2; ++ ValidatorInfo validator_info = 3; ++} ++ ++message SyncInfo { ++ bytes latest_block_hash = 1; ++ bytes latest_app_hash = 2; ++ int64 latest_block_height = 3; ++ google.protobuf.Timestamp latest_block_time = 4 ++ [(gogoproto.nullable) = false, (gogoproto.stdtime) = true]; ++ ++ bytes earliest_block_hash = 5; ++ bytes earliest_app_hash = 6; ++ int64 earliest_block_height = 7; ++ google.protobuf.Timestamp earliest_block_time = 8 ++ [(gogoproto.nullable) = false, (gogoproto.stdtime) = true]; ++ ++ bool catching_up = 9; ++} ++ ++message ValidatorInfo { ++ bytes address = 1; ++ tendermint.crypto.PublicKey pub_key = 2; ++ int64 voting_power = 3; ++} ++ + //---------------------------------------- + // Service Definition + +@@ -30,3 +135,12 @@ service BroadcastAPI { + rpc Ping(RequestPing) returns (ResponsePing); + rpc BroadcastTx(RequestBroadcastTx) returns (ResponseBroadcastTx); + } ++ ++service BlockAPI { ++ rpc BlockByHash(BlockByHashRequest) returns (stream StreamedBlockByHashResponse); ++ rpc BlockByHeight(BlockByHeightRequest) returns (stream StreamedBlockByHeightResponse); ++ rpc Commit(CommitRequest) returns (CommitResponse); ++ rpc ValidatorSet(ValidatorSetRequest) returns (ValidatorSetResponse); ++ rpc SubscribeNewHeights(SubscribeNewHeightsRequest) returns (stream NewHeightEvent); ++ rpc Status(StatusRequest) returns (StatusResponse); ++} diff --git a/patches/proto/tendermint/state/types.proto.patch b/patches/proto/tendermint/state/types.proto.patch new file mode 100644 index 00000000000..4df556070e5 --- /dev/null +++ b/patches/proto/tendermint/state/types.proto.patch @@ -0,0 +1,12 @@ +diff --git a/proto/tendermint/state/types.proto b/proto/tendermint/state/types.proto +index f3fdc0ef3..9796a8fc5 100644 +--- a/proto/tendermint/state/types.proto ++++ b/proto/tendermint/state/types.proto +@@ -77,4 +77,7 @@ message State { + + // the latest AppHash we've received from calling abci.Commit() + bytes app_hash = 13; ++ ++ // timeouts to be used for the next block height ++ tendermint.abci.TimeoutsInfo timeouts = 15 [(gogoproto.nullable) = false]; + } diff --git a/patches/proto/tendermint/store/types.proto.patch b/patches/proto/tendermint/store/types.proto.patch new file mode 100644 index 00000000000..678614e03ad --- /dev/null +++ b/patches/proto/tendermint/store/types.proto.patch @@ -0,0 +1,20 @@ +diff --git a/proto/tendermint/store/types.proto b/proto/tendermint/store/types.proto +index af2f97ad0..64a32d1f7 100644 +--- a/proto/tendermint/store/types.proto ++++ b/proto/tendermint/store/types.proto +@@ -7,3 +7,15 @@ message BlockStoreState { + int64 base = 1; + int64 height = 2; + } ++ ++// TxInfo describes the location of a tx inside a committed block ++// as well as the result of executing the transaction and the error log output. ++message TxInfo { ++ int64 height = 1; ++ uint32 index = 2; ++ // The response code of executing the tx. 0 means ++ // successfully executed, all others are error codes. ++ uint32 code = 3; ++ // The error log output generated if the transaction execution fails. ++ string error = 4; ++} diff --git a/patches/proto/tendermint/types/types.proto.patch b/patches/proto/tendermint/types/types.proto.patch new file mode 100644 index 00000000000..2685e5add2e --- /dev/null +++ b/patches/proto/tendermint/types/types.proto.patch @@ -0,0 +1,126 @@ +diff --git a/proto/tendermint/types/types.proto b/proto/tendermint/types/types.proto +index 3ce169459..d3ccf4a28 100644 +--- a/proto/tendermint/types/types.proto ++++ b/proto/tendermint/types/types.proto +@@ -81,12 +81,37 @@ message Header { + bytes proposer_address = 14; // original proposer of the block + } + +-// Data contains the set of transactions included in the block ++// Data contains all the information needed for a consensus full node to ++// reconstruct an extended data square. + message Data { +- // Txs that will be applied by state @ block.Height+1. +- // NOTE: not all txs here are valid. We're just agreeing on the order first. +- // This means that block.AppHash does not include these txs. ++ // Txs that will be applied to state in block.Height + 1 because deferred execution. ++ // This means that the block.AppHash of this block does not include these txs. ++ // NOTE: not all txs here are valid. We're just agreeing on the order first. + repeated bytes txs = 1; ++ ++ reserved 2, 3, 4; ++ // field number 2 is reserved for intermediate state roots ++ // field number 3 is reserved for evidence ++ // field number 4 is reserved for blobs ++ ++ // SquareSize is the number of rows or columns in the original data square. ++ uint64 square_size = 5; ++ ++ // Hash is the root of a binary Merkle tree where the leaves of the tree are ++ // the row and column roots of an extended data square. Hash is often referred ++ // to as the "data root". ++ bytes hash = 6; ++} ++ ++// Blob (named after binary large object) is a chunk of data submitted by a user ++// to be published to the Celestia blockchain. The data of a Blob is published ++// to a namespace and is encoded into shares based on the format specified by ++// share_version. ++message Blob { ++ bytes namespace_id = 1; ++ bytes data = 2; ++ uint32 share_version = 3; ++ uint32 namespace_version = 4; + } + + // Vote represents a prevote, precommit, or commit vote from validators for +@@ -149,9 +174,78 @@ message BlockMeta { + int64 num_txs = 4; + } + +-// TxProof represents a Merkle proof of the presence of a transaction in the Merkle tree. ++// TxProof represents a Merkle proof of the presence of a transaction in the ++// Merkle tree. ++// ++// Note: TxProof is not used in celestia-core because of modifications to the ++// data root. In a normal Cosmos chain, the data root is the root of a Merkle ++// tree of transactions in the block. However, in Celestia the data root is the ++// root of the row and column roots in the extended data square. See ++// https://github.com/celestiaorg/celestia-app/blob/852a229f11f0f269021b36f7621609f432bb858b/pkg/da/data_availability_header.go ++// for more details. Therefore, TxProof isn't sufficient to prove the existence ++// of a transaction in a Celestia block and ShareProof was defined instead. See ++// ShareProof for more details. + message TxProof { + bytes root_hash = 1; + bytes data = 2; + tendermint.crypto.Proof proof = 3; + } ++ ++// IndexWrapper adds index metadata to a transaction. This is used to track ++// transactions that pay for blobs, and where the blobs start in the square. ++message IndexWrapper { ++ bytes tx = 1; ++ repeated uint32 share_indexes = 2; ++ string type_id = 3; ++} ++ ++// BlobTx wraps an encoded sdk.Tx with a second field to contain blobs of data. ++// The raw bytes of the blobs are not signed over, instead we verify each blob ++// using the relevant MsgPayForBlobs that is signed over in the encoded sdk.Tx. ++message BlobTx { ++ bytes tx = 1; ++ repeated Blob blobs = 2; ++ string type_id = 3; ++} ++ ++// ShareProof is an NMT proof that a set of shares exist in a set of rows and a ++// Merkle proof that those rows exist in a Merkle tree with a given data root. ++message ShareProof { ++ repeated bytes data = 1; ++ repeated NMTProof share_proofs = 2; ++ bytes namespace_id = 3; ++ RowProof row_proof = 4; ++ uint32 namespace_version = 5; ++} ++ ++// RowProof is a Merkle proof that a set of rows exist in a Merkle tree with a ++// given data root. ++message RowProof { ++ repeated bytes row_roots = 1; ++ repeated tendermint.crypto.Proof proofs = 2; ++ bytes root = 3; ++ uint32 start_row = 4; ++ uint32 end_row = 5; ++} ++ ++// NMTProof is a proof of a namespace.ID in an NMT. ++// In case this proof proves the absence of a namespace.ID ++// in a tree it also contains the leaf hashes of the range ++// where that namespace would be. ++message NMTProof { ++ // Start index of this proof. ++ int32 start = 1; ++ // End index of this proof. ++ int32 end = 2; ++ // Nodes that together with the corresponding leaf values can be used to ++ // recompute the root and verify this proof. Nodes should consist of the max ++ // and min namespaces along with the actual hash, resulting in each being 48 ++ // bytes each ++ repeated bytes nodes = 3; ++ // leafHash are nil if the namespace is present in the NMT. In case the ++ // namespace to be proved is in the min/max range of the tree but absent, this ++ // will contain the leaf hash necessary to verify the proof of absence. Leaf ++ // hashes should consist of the namespace along with the actual hash, ++ // resulting 40 bytes total. ++ bytes leaf_hash = 4; ++} diff --git a/patches/rpc/openapi/README.md.patch b/patches/rpc/openapi/README.md.patch new file mode 100644 index 00000000000..247e9bb7add --- /dev/null +++ b/patches/rpc/openapi/README.md.patch @@ -0,0 +1,18 @@ +diff --git a/rpc/openapi/README.md b/rpc/openapi/README.md +new file mode 100644 +index 000000000..ef8d89814 +--- /dev/null ++++ b/rpc/openapi/README.md +@@ -0,0 +1,12 @@ ++--- ++order: 5 ++parent: ++title: RPC ++order: 5 ++--- ++ ++# RPC ++ ++The RPC documentation is hosted here: ++ ++- [RPC Documentation](https://docs.cometbft.com/v0.34/rpc) diff --git a/patches/rpc/openapi/openapi.yaml.patch b/patches/rpc/openapi/openapi.yaml.patch new file mode 100644 index 00000000000..37ec9eb52c5 --- /dev/null +++ b/patches/rpc/openapi/openapi.yaml.patch @@ -0,0 +1,433 @@ +diff --git a/rpc/openapi/openapi.yaml b/rpc/openapi/openapi.yaml +index f96b05ed1..7e8047260 100644 +--- a/rpc/openapi/openapi.yaml ++++ b/rpc/openapi/openapi.yaml +@@ -295,7 +295,7 @@ paths: + $ref: "#/components/schemas/ErrorResponse" + /net_info: + get: +- summary: Network informations ++ summary: Network information + operationId: net_info + tags: + - Info +@@ -439,6 +439,64 @@ paths: + application/json: + schema: + $ref: "#/components/schemas/ErrorResponse" ++ /header: ++ get: ++ summary: Get header at a specified height ++ operationId: header ++ parameters: ++ - in: query ++ name: height ++ schema: ++ type: integer ++ default: 0 ++ example: 1 ++ description: height to return. If no height is provided, it will fetch the latest header. ++ tags: ++ - Info ++ description: | ++ Get Header. ++ responses: ++ "200": ++ description: Header informations. ++ content: ++ application/json: ++ schema: ++ $ref: "#/components/schemas/BlockHeader" ++ "500": ++ description: Error ++ content: ++ application/json: ++ schema: ++ $ref: "#/components/schemas/ErrorResponse" ++ /header_by_hash: ++ get: ++ summary: Get header by hash ++ operationId: header_by_hash ++ parameters: ++ - in: query ++ name: hash ++ description: header hash ++ required: true ++ schema: ++ type: string ++ example: "0xD70952032620CC4E2737EB8AC379806359D8E0B17B0488F627997A0B043ABDED" ++ tags: ++ - Info ++ description: | ++ Get Header By Hash. ++ responses: ++ "200": ++ description: Header informations. ++ content: ++ application/json: ++ schema: ++ $ref: "#/components/schemas/BlockHeader" ++ "500": ++ description: Error ++ content: ++ application/json: ++ schema: ++ $ref: "#/components/schemas/ErrorResponse" + /block: + get: + summary: Get block at a specified height +@@ -944,7 +1002,181 @@ paths: + application/json: + schema: + $ref: "#/components/schemas/ErrorResponse" ++ /prove_shares: ++ get: ++ summary: Prove shares for a given share range. ++ description: | ++ Generates a proof of inclusion for a range of shares to the data root. ++ Note: shares are referenced by their range: startShare to endShare. ++ The share range is end exclusive. ++ Deprecated: Use '/prove_shares_v2' instead. ++ operationId: prove_shares ++ tags: ++ - Info ++ parameters: ++ - in: query ++ name: height ++ description: The block height ++ schema: ++ type: integer ++ default: 1 ++ example: 1 ++ - in: query ++ name: startShare ++ description: The starting share index ++ schema: ++ type: integer ++ default: 0 ++ example: 0 ++ - in: query ++ name: endShare ++ description: The end exclusive ending share index ++ schema: ++ type: integer ++ default: 1 ++ example: 1 ++ responses: ++ '200': ++ description: Successfully retrieved the share proof ++ content: ++ application/json: ++ schema: ++ $ref: '#/components/schemas/ShareProof' ++ '500': ++ description: Internal server error ++ ++ /prove_shares_v2: ++ get: ++ summary: Prove shares for a given share range. ++ description: | ++ Generates a proof of inclusion for a range of shares to the data root. ++ Note: shares are referenced by their range: startShare to endShare. ++ The share range is end exclusive. ++ Replaces '/prove_shares' ++ operationId: prove_shares_v2 ++ tags: ++ - Info ++ parameters: ++ - in: query ++ name: height ++ description: The block height ++ schema: ++ type: integer ++ default: 1 ++ example: 1 ++ - in: query ++ name: startShare ++ description: The starting share index ++ schema: ++ type: integer ++ default: 0 ++ example: 0 ++ - in: query ++ name: endShare ++ description: The end exclusive ending share index ++ schema: ++ type: integer ++ default: 1 ++ example: 1 ++ responses: ++ '200': ++ description: Successfully retrieved the share proof ++ content: ++ application/json: ++ schema: ++ $ref: '#/components/schemas/ResultShareProof' ++ '500': ++ description: Internal server error ++ ++ /data_commitment: ++ get: ++ summary: Generates a data commitment for a range of blocks ++ description: | ++ Generates a data commitment over an ordered list of blocks matching the provided range. ++ ++ The provided block range is end exclusive. ++ operationId: data_commitment ++ parameters: ++ - in: query ++ name: first_block ++ description: "the first block of the range of blocks" ++ required: true ++ schema: ++ type: integer ++ default: 1 ++ example: 1 ++ - in: query ++ name: last_block ++ description: "the last block of the range of blocks" ++ required: true ++ schema: ++ type: integer ++ default: 100 ++ example: 100 ++ tags: ++ - Info ++ responses: ++ "200": ++ description: Hex representation of the data commitment. ++ content: ++ application/json: ++ schema: ++ $ref: "#/components/schemas/DataCommitmentResponse" ++ "500": ++ description: Error ++ content: ++ application/json: ++ schema: ++ $ref: "#/components/schemas/ErrorResponse" ++ /data_root_inclusion_proof: ++ get: ++ summary: Creates a merkle proof for a data root ++ description: | ++ Generates a merkle proof for a data root defined by a height to the range of ++ blocks defined by first and last block. + ++ The provided block range is end exclusive. ++ operationId: data_root_inclusion_proof ++ parameters: ++ - in: query ++ name: height ++ description: "the height of the block to prove" ++ required: true ++ schema: ++ type: integer ++ default: 5 ++ example: 5 ++ - in: query ++ name: first_block ++ description: "the first block of the range of blocks" ++ required: true ++ schema: ++ type: integer ++ default: 1 ++ example: 1 ++ - in: query ++ name: last_block ++ description: "the last block of the range of blocks" ++ required: true ++ schema: ++ type: integer ++ default: 100 ++ example: 100 ++ tags: ++ - Info ++ responses: ++ "200": ++ description: merkle proof of the height to the data commitment. ++ content: ++ application/json: ++ schema: ++ $ref: "#/components/schemas/DataRootInclusionProofResponse" ++ "500": ++ description: Error ++ content: ++ application/json: ++ schema: ++ $ref: "#/components/schemas/ErrorResponse" + /tx: + get: + summary: Get transactions by hash +@@ -2314,6 +2546,73 @@ components: + example: "2" + type: object + ++ DataCommitmentResponse: ++ type: object ++ required: ++ - "jsonrpc" ++ - "id" ++ - "result" ++ properties: ++ jsonrpc: ++ type: string ++ example: "2.0" ++ id: ++ type: integer ++ example: 0 ++ result: ++ required: ++ - "DataCommitment" ++ properties: ++ DataCommitment: ++ type: string ++ example: "D70952032620CC4E2737EB8AC379806359D8E0B17B0488F627997A0B043ABDED" ++ description: the commitment is hex encoded ++ type: object ++ ++ DataRootInclusionProofResponse: ++ type: object ++ required: ++ - "jsonrpc" ++ - "id" ++ - "result" ++ properties: ++ jsonrpc: ++ type: string ++ example: "2.0" ++ id: ++ type: integer ++ example: 0 ++ result: ++ required: ++ - "Proof" ++ properties: ++ Proof: ++ required: ++ - "total" ++ - "index" ++ - "leaf_hash" ++ - "aunts" ++ properties: ++ total: ++ type: string ++ example: "2" ++ index: ++ type: string ++ example: "0" ++ leaf_hash: ++ type: string ++ example: "eoJxKCzF3m72Xiwb/Q43vJ37/2Sx8sfNS9JKJohlsYI=" ++ description: the leaf hash is base64 encoded ++ aunts: ++ type: array ++ items: ++ type: string ++ example: ++ - "eWb+HG/eMmukrQj4vNGyFYb3nKQncAWacq4HF5eFzDY=" ++ description: the aunts are base64 encoded ++ type: object ++ type: object ++ + TxResponse: + type: object + required: +@@ -2368,8 +2667,98 @@ components: + tx: + type: string + example: "5wHwYl3uCkaoo2GaChQmSIu8hxpJxLcCuIi8fiHN4TMwrRIU/Af1cEG7Rcs/6LjTl7YjRSymJfYaFAoFdWF0b20SCzE0OTk5OTk1MDAwEhMKDQoFdWF0b20SBDUwMDAQwJoMGmoKJuta6YchAwswBShaB1wkZBctLIhYqBC3JrAI28XGzxP+rVEticGEEkAc+khTkKL9CDE47aDvjEHvUNt+izJfT4KVF2v2JkC+bmlH9K08q3PqHeMI9Z5up+XMusnTqlP985KF+SI5J3ZOIhhNYWRlIGJ5IENpcmNsZSB3aXRoIGxvdmU=" ++ proof: ++ type: object ++ $ref: '#/components/schemas/ShareProof' ++ nullable: true ++ description: Optional proof of the transaction, provided only when requested. + type: object + ++ ResultShareProof: ++ type: object ++ properties: ++ share_proof: ++ $ref: '#/components/schemas/ShareProof' ++ description: API proof response of a set of shares. ++ ShareProof: ++ type: object ++ properties: ++ data: ++ type: array ++ items: ++ type: string ++ format: byte ++ description: The raw shares that are being proven. ++ shareProofs: ++ type: array ++ items: ++ $ref: '#/components/schemas/NMTProof' ++ description: NMT proofs that the shares in Data exist in a set of rows. ++ namespaceID: ++ type: string ++ format: byte ++ description: The namespace id of the shares being proven. ++ rowProof: ++ $ref: '#/components/schemas/RowProof' ++ namespaceVersion: ++ type: integer ++ format: uint32 ++ description: The version of the namespace used for verification. ++ NMTProof: ++ type: object ++ properties: ++ start: ++ type: integer ++ format: int32 ++ end: ++ type: integer ++ format: int32 ++ nodes: ++ type: array ++ items: ++ type: string ++ format: byte ++ description: Nodes used to verify the proof. ++ leaf_hash: ++ type: string ++ format: byte ++ description: Leaf hash necessary for proof of absence, if applicable. ++ RowProof: ++ type: object ++ properties: ++ rowRoots: ++ type: array ++ items: ++ type: string ++ format: byte ++ proofs: ++ type: array ++ items: ++ $ref: '#/components/schemas/Proof' ++ startRow: ++ type: integer ++ format: uint32 ++ endRow: ++ type: integer ++ format: uint32 ++ Proof: ++ type: object ++ description: Binary merkle proof ++ properties: ++ total: ++ type: integer ++ format: int64 ++ index: ++ type: integer ++ format: int64 ++ leafHash: ++ type: string ++ format: byte ++ aunts: ++ type: array ++ items: ++ type: string ++ format: byte + ABCIInfoResponse: + type: object + required: diff --git a/patches/rpc/openapi/rpc.html.patch b/patches/rpc/openapi/rpc.html.patch new file mode 100644 index 00000000000..093f0f2d2f3 --- /dev/null +++ b/patches/rpc/openapi/rpc.html.patch @@ -0,0 +1,33 @@ +diff --git a/rpc/openapi/rpc.html b/rpc/openapi/rpc.html +new file mode 100644 +index 000000000..77fc73f19 +--- /dev/null ++++ b/rpc/openapi/rpc.html +@@ -0,0 +1,27 @@ ++ ++ ++ ++ ++ ++ ++ CometBFT RPC ++ ++ ++ ++ ++ ++ ++
++ ++ ++ ++ diff --git a/patches/scripts/mockery_generate.sh.patch b/patches/scripts/mockery_generate.sh.patch new file mode 100644 index 00000000000..55e90571a5d --- /dev/null +++ b/patches/scripts/mockery_generate.sh.patch @@ -0,0 +1,11 @@ +diff --git a/scripts/mockery_generate.sh b/scripts/mockery_generate.sh +index 8b97f91e2..e03c86a9c 100755 +--- a/scripts/mockery_generate.sh ++++ b/scripts/mockery_generate.sh +@@ -3,5 +3,4 @@ + # Invoke Mockery v2 to update generated mocks for the given type. + # Last change was made based on changes for main in https://github.com/tendermint/tendermint/pull/9196 + +- +-go run github.com/vektra/mockery/v2 --disable-version-string --case underscore --name "$*" ++go run github.com/vektra/mockery/v2@latest --disable-version-string --case underscore --name "$*" diff --git a/patches/scripts/proto-gen.sh.patch b/patches/scripts/proto-gen.sh.patch new file mode 100644 index 00000000000..4585907a057 --- /dev/null +++ b/patches/scripts/proto-gen.sh.patch @@ -0,0 +1,13 @@ +diff --git a/scripts/proto-gen.sh b/scripts/proto-gen.sh +index 3edc0bff9..fffb84edd 100755 +--- a/scripts/proto-gen.sh ++++ b/scripts/proto-gen.sh +@@ -10,7 +10,7 @@ cd "$(git rev-parse --show-toplevel)" + + # Run inside Docker to install the correct versions of the required tools + # without polluting the local system. +-docker run --rm -i -v "$PWD":/w --workdir=/w golang:1.21-alpine sh <<"EOF" ++docker run --rm -i -v "$PWD":/w --workdir=/w golang:1.23.1-alpine sh <<"EOF" + apk add git make + + go install github.com/bufbuild/buf/cmd/buf diff --git a/patches/scripts/qa/reporting/requirements.txt.patch b/patches/scripts/qa/reporting/requirements.txt.patch new file mode 100644 index 00000000000..285d08cefc6 --- /dev/null +++ b/patches/scripts/qa/reporting/requirements.txt.patch @@ -0,0 +1,18 @@ +diff --git a/scripts/qa/reporting/requirements.txt b/scripts/qa/reporting/requirements.txt +index 335c842fd..a3117b924 100644 +--- a/scripts/qa/reporting/requirements.txt ++++ b/scripts/qa/reporting/requirements.txt +@@ -1,6 +1,6 @@ + contourpy==1.0.5 + cycler==0.11.0 +-fonttools==4.37.4 ++fonttools==4.53.1 + kiwisolver==1.4.4 + matplotlib==3.6.3 + numpy==1.24.2 +@@ -11,4 +11,4 @@ python-dateutil==2.8.2 + six==1.16.0 + pandas==1.5.3 + prometheus-pandas==0.3.2 +-requests==2.28.2 ++requests==2.32.3 diff --git a/patches/spec/abci/abci.md.patch b/patches/spec/abci/abci.md.patch new file mode 100644 index 00000000000..1b8edafa2c3 --- /dev/null +++ b/patches/spec/abci/abci.md.patch @@ -0,0 +1,111 @@ +diff --git a/spec/abci/abci.md b/spec/abci/abci.md +index 2d5cc4eaa..e3cf74885 100644 +--- a/spec/abci/abci.md ++++ b/spec/abci/abci.md +@@ -66,20 +66,20 @@ The handling of non-zero response codes by CometBFT is described below + + The `CheckTx` ABCI method controls what transactions are considered for inclusion in a block. + When CometBFT receives a `ResponseCheckTx` with a non-zero `Code`, the associated +-transaction will be not be added to CometBFT's mempool or it will be removed if ++transaction will not be added to CometBFT's mempool or it will be removed if + it is already included. + + ### DeliverTx + + The `DeliverTx` ABCI method delivers transactions from CometBFT to the application. +-When CometBFT recieves a `ResponseDeliverTx` with a non-zero `Code`, the response code is logged. ++When CometBFT receives a `ResponseDeliverTx` with a non-zero `Code`, the response code is logged. + The transaction was already included in a block, so the `Code` does not influence + CometBFT consensus. + + ### Query + + The `Query` ABCI method query queries the application for information about application state. +-When CometBFT receives a `ResponseQuery` with a non-zero `Code`, this code is ++When CometBFT receives a `ResponseQuery` with a non-zero `Code`, this code is + returned directly to the client that initiated the query. + + ## Events +@@ -91,7 +91,7 @@ transactions and blocks this metadata relates to. + Events returned via these ABCI methods do not impact CometBFT consensus in any way + and instead exist to power subscriptions and queries of CometBFT state. + +-An `Event` contains a `type` and a list of `EventAttributes`, which are key-value ++An `Event` contains a `type` and a list of `EventAttributes`, which are key-value + string pairs denoting metadata about what happened during the method's execution. + `Event` values can be used to index transactions and blocks according to what happened + during their execution. Note that the set of events returned for a block from +@@ -163,8 +163,8 @@ Example: + CometBFT's security model relies on the use of "evidence". Evidence is proof of + malicious behaviour by a network participant. It is the responsibility of CometBFT + to detect such malicious behaviour. When malicious behavior is detected, CometBFT +-will gossip evidence of the behavior to other nodes and commit the evidence to +-the chain once it is verified by all validators. This evidence will then be ++will gossip evidence of the behavior to other nodes and commit the evidence to ++the chain once it is verified by all validators. This evidence will then be + passed it on to the application through the ABCI. It is the responsibility of the + application to handle the evidence and exercise punishment. + +@@ -289,20 +289,20 @@ the blockchain's `AppHash` which is verified via [light client verification](../ + + * **Request**: + +- | Name | Type | Description | Field Number | +- |---------------|--------|------------------------------------------|--------------| ++ | Name | Type | Description | Field Number | ++ |---------------|--------|----------------------------------------|--------------| + | version | string | The CometBFT software semantic version | 1 | +- | block_version | uint64 | The CometBFT Block Protocol version | 2 | +- | p2p_version | uint64 | The CometBFT P2P Protocol version | 3 | ++ | block_version | uint64 | The CometBFT Block version | 2 | ++ | p2p_version | uint64 | The CometBFT P2P version | 3 | + | abci_version | string | The CometBFT ABCI semantic version | 4 | + + * **Response**: +- ++ + | Name | Type | Description | Field Number | + |---------------------|--------|--------------------------------------------------|--------------| + | data | string | Some arbitrary information | 1 | + | version | string | The application software semantic version | 2 | +- | app_version | uint64 | The application protocol version | 3 | ++ | app_version | uint64 | The application version | 3 | + | last_block_height | int64 | Latest block for which the app has called Commit | 4 | + | last_block_app_hash | bytes | Latest result of Commit | 5 | + +@@ -351,7 +351,7 @@ the blockchain's `AppHash` which is verified via [light client verification](../ + ### Query + + * **Request**: +- ++ + | Name | Type | Description | Field Number | + |--------|--------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------| + | data | bytes | Raw query bytes. Can be used with or in lieu of Path. | 1 | +@@ -411,7 +411,7 @@ the blockchain's `AppHash` which is verified via [light client verification](../ + | Name | Type | Description | Field Number | + |------|-------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------| + | tx | bytes | The request transaction bytes | 1 | +- | type | CheckTxType | One of `CheckTx_New` or `CheckTx_Recheck`. `CheckTx_New` is the default and means that a full check of the tranasaction is required. `CheckTx_Recheck` types are used when the mempool is initiating a normal recheck of a transaction. | 2 | ++ | type | CheckTxType | One of `CheckTx_New` or `CheckTx_Recheck`. `CheckTx_New` is the default and means that a full check of the transaction is required. `CheckTx_Recheck` types are used when the mempool is initiating a normal recheck of a transaction. | 2 | + + * **Response**: + +@@ -495,7 +495,7 @@ the blockchain's `AppHash` which is verified via [light client verification](../ + * `H+3`: `LastCommitInfo` is changed to include the altered validator set. + * `consensus_param_updates` returned for block `H` apply to the consensus + params for block `H+1`. For more information on the consensus parameters, +- see the [application spec entry on consensus parameters](../spec/abci/apps.md#consensus-parameters). ++ see the [application spec entry on consensus parameters](./apps.md#consensus-parameters). + + ### Commit + +@@ -562,7 +562,7 @@ the blockchain's `AppHash` which is verified via [light client verification](../ + + | Name | Type | Description | Field Number | + |-------|-------|-------------------------------------------------------------------------------------------------------------------------------------------------------|--------------| +- | chunk | bytes | The binary chunk contents, in an arbitray format. Chunk messages cannot be larger than 16 MB _including metadata_, so 10 MB is a good starting point. | 1 | ++ | chunk | bytes | The binary chunk contents, in an arbitrary format. Chunk messages cannot be larger than 16 MB _including metadata_, so 10 MB is a good starting point. | 1 | + + * **Usage**: + * Used during state sync to retrieve snapshot chunks from peers. diff --git a/patches/spec/abci/apps.md.patch b/patches/spec/abci/apps.md.patch new file mode 100644 index 00000000000..846b1fa04cf --- /dev/null +++ b/patches/spec/abci/apps.md.patch @@ -0,0 +1,34 @@ +diff --git a/spec/abci/apps.md b/spec/abci/apps.md +index 4296eaf95..8fd1d7ea0 100644 +--- a/spec/abci/apps.md ++++ b/spec/abci/apps.md +@@ -379,7 +379,7 @@ blockchain. + #### EndBlock + + ResponseEndBlock includes a ConsensusParams. +-If ConsensusParams nil, CometBFT will do nothing. ++If ConsensusParams is nil, CometBFT will do nothing. + If ConsensusParam is not nil, CometBFT will use it. + This way the application can update the consensus params over time. + +@@ -480,9 +480,9 @@ implementation of + + On startup, CometBFT calls the `Info` method on the Info Connection to get the latest + committed state of the app. The app MUST return information consistent with the +-last block it succesfully completed Commit for. ++last block it successfully completed Commit for. + +-If the app succesfully committed block H, then `last_block_height = H` and `last_block_app_hash = `. If the app ++If the app successfully committed block H, then `last_block_height = H` and `last_block_app_hash = `. If the app + failed during the Commit of block H, then `last_block_height = H-1` and + `last_block_app_hash = `. + +@@ -493,7 +493,7 @@ the app. + storeBlockHeight = height of the last block CometBFT saw a commit for + stateBlockHeight = height of the last block for which CometBFT completed all + block processing and saved all ABCI results to disk +-appBlockHeight = height of the last block for which ABCI app succesfully ++appBlockHeight = height of the last block for which ABCI app successfully + completed Commit + + ``` diff --git a/patches/spec/consensus/consensus-paper/IEEEtran.cls.patch b/patches/spec/consensus/consensus-paper/IEEEtran.cls.patch new file mode 100644 index 00000000000..48422cfd709 --- /dev/null +++ b/patches/spec/consensus/consensus-paper/IEEEtran.cls.patch @@ -0,0 +1,13 @@ +diff --git a/spec/consensus/consensus-paper/IEEEtran.cls b/spec/consensus/consensus-paper/IEEEtran.cls +index 9c967d555..6d18208f9 100644 +--- a/spec/consensus/consensus-paper/IEEEtran.cls ++++ b/spec/consensus/consensus-paper/IEEEtran.cls +@@ -268,7 +268,7 @@ + \newtoks\@IEEEtrantmptoksA + + % we use \CLASSOPTIONpt so that we can ID the point size (even for 9pt docs) +-% as well as LaTeX's \@ptsize to retain some compatability with some ++% as well as LaTeX's \@ptsize to retain some compatibility with some + % external packages + \def\@ptsize{0} + % LaTeX does not support 9pt, so we set \@ptsize to 0 - same as that of 10pt diff --git a/patches/spec/consensus/evidence.md.patch b/patches/spec/consensus/evidence.md.patch new file mode 100644 index 00000000000..9e95278a4c8 --- /dev/null +++ b/patches/spec/consensus/evidence.md.patch @@ -0,0 +1,31 @@ +diff --git a/spec/consensus/evidence.md b/spec/consensus/evidence.md +index b3f3de5c6..663546a21 100644 +--- a/spec/consensus/evidence.md ++++ b/spec/consensus/evidence.md +@@ -4,7 +4,7 @@ + # Evidence + + Evidence is an important component of CometBFT's security model. Whilst the core +-consensus protocol provides correctness gaurantees for state machine replication ++consensus protocol provides correctness guarantees for state machine replication + that can tolerate less than 1/3 failures, the evidence system looks to detect and + gossip byzantine faults whose combined power is greater than or equal to 1/3. It is worth noting that + the evidence system is designed purely to detect possible attacks, gossip them, +@@ -77,7 +77,7 @@ should be committed within a certain period from the point that it occurred + (timely). Timelines is defined by the `EvidenceParams`: `MaxAgeNumBlocks` and + `MaxAgeDuration`. In Proof of Stake chains where validators are bonded, evidence + age should be less than the unbonding period so validators still can be +-punished. Given these two propoerties the following initial checks are made. ++punished. Given these two properties the following initial checks are made. + + 1. Has the evidence expired? This is done by taking the height of the `Vote` + within `DuplicateVoteEvidence` or `CommonHeight` within +@@ -126,7 +126,7 @@ Valid Light Client Attack Evidence must adhere to the following rules: + + ## Gossiping + +-If a node verifies evidence it then broadcasts it to all peers, continously sending ++If a node verifies evidence it then broadcasts it to all peers, continuously sending + the same evidence once every 10 seconds until the evidence is seen on chain or + expires. + diff --git a/patches/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md.patch b/patches/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md.patch new file mode 100644 index 00000000000..297d259e655 --- /dev/null +++ b/patches/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md.patch @@ -0,0 +1,13 @@ +diff --git a/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md +index b42b3ab2f..82fd348c6 100644 +--- a/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md ++++ b/spec/consensus/proposer-based-timestamp/pbts-algorithm_001_draft.md +@@ -148,7 +148,7 @@ upon ⟨PROPOSAL, h_p, r, (v,t), ∗⟩ from proposer(h_p, r) AND 2f + 1 ⟨PREC + } + ``` + +-**All other rules remains unchanged.** ++**All other rules remain unchanged.** + + Back to [main document][main]. + diff --git a/patches/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md.patch b/patches/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md.patch new file mode 100644 index 00000000000..78e3ac9daf3 --- /dev/null +++ b/patches/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md.patch @@ -0,0 +1,13 @@ +diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md +index 1b0f9a3b7..48357ea99 100644 +--- a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md ++++ b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md +@@ -105,7 +105,7 @@ then the time `b.time` in the block `b` that is signed by `c` satisfies + - `beginConsensus(k) - PRECISION <= b.time < endConsensus(k) + PRECISION + MSGDELAY`. + + +-> [PBTS-CONSENSUS-TIME-VALID.0] is based on an analysis where the proposer is faulty (and does does not count towards `beginConsensus(k)` and `endConsensus(k)`), and we estimate the times at which correct validators receive and `accept` the `propose` message. If the proposer is correct we obtain ++> [PBTS-CONSENSUS-TIME-VALID.0] is based on an analysis where the proposer is faulty (and does not count towards `beginConsensus(k)` and `endConsensus(k)`), and we estimate the times at which correct validators receive and `accept` the `propose` message. If the proposer is correct we obtain + + #### **[PBTS-CONSENSUS-LIVE-VALID-CORR-PROP.0]** + diff --git a/patches/spec/consensus/proposer-based-timestamp/pbts_001_draft.md.patch b/patches/spec/consensus/proposer-based-timestamp/pbts_001_draft.md.patch new file mode 100644 index 00000000000..948a0f59472 --- /dev/null +++ b/patches/spec/consensus/proposer-based-timestamp/pbts_001_draft.md.patch @@ -0,0 +1,13 @@ +diff --git a/spec/consensus/proposer-based-timestamp/pbts_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts_001_draft.md +index bcb01d736..84509f8dd 100644 +--- a/spec/consensus/proposer-based-timestamp/pbts_001_draft.md ++++ b/spec/consensus/proposer-based-timestamp/pbts_001_draft.md +@@ -21,7 +21,7 @@ In CometBFT, the first version of how time is computed and stored in a block wor + 1. **Liveness.** The liveness of the protocol: + 1. does not depend on clock synchronization, + 1. depends on bounded message delays. +-1. **Relation to real time.** There is no clock synchronizaton, which implies that there is **no relation** between the computed block `time` and real time. ++1. **Relation to real time.** There is no clock synchronization, which implies that there is **no relation** between the computed block `time` and real time. + 1. **Aggregate signatures.** As the `precommit` messages contain the local times, all these `precommit` messages typically differ in the time field, which **prevents** the use of aggregate signatures. + + ## Suggested Proposer-Based Time diff --git a/patches/spec/consensus/proposer-based-timestamp/tla/TendermintPBT_001_draft.tla.patch b/patches/spec/consensus/proposer-based-timestamp/tla/TendermintPBT_001_draft.tla.patch new file mode 100644 index 00000000000..702d9fb1e85 --- /dev/null +++ b/patches/spec/consensus/proposer-based-timestamp/tla/TendermintPBT_001_draft.tla.patch @@ -0,0 +1,13 @@ +diff --git a/spec/consensus/proposer-based-timestamp/tla/TendermintPBT_001_draft.tla b/spec/consensus/proposer-based-timestamp/tla/TendermintPBT_001_draft.tla +index 585d0d8e8..a6c580893 100644 +--- a/spec/consensus/proposer-based-timestamp/tla/TendermintPBT_001_draft.tla ++++ b/spec/consensus/proposer-based-timestamp/tla/TendermintPBT_001_draft.tla +@@ -499,7 +499,7 @@ MessageProcessing(p) == + \/ OnRoundCatchup(p) + + (* +- * A system transition. In this specificatiom, the system may eventually deadlock, ++ * A system transition. In this specification, the system may eventually deadlock, + * e.g., when all processes decide. This is expected behavior, as we focus on safety. + *) + Next == diff --git a/patches/spec/consensus/proposer-selection.md.patch b/patches/spec/consensus/proposer-selection.md.patch new file mode 100644 index 00000000000..d791edb2003 --- /dev/null +++ b/patches/spec/consensus/proposer-selection.md.patch @@ -0,0 +1,13 @@ +diff --git a/spec/consensus/proposer-selection.md b/spec/consensus/proposer-selection.md +index 885682f2f..ca4e840a2 100644 +--- a/spec/consensus/proposer-selection.md ++++ b/spec/consensus/proposer-selection.md +@@ -5,7 +5,7 @@ order: 3 + # Proposer Selection Procedure + + This document specifies the Proposer Selection Procedure that is used in Tendermint, the consensus algorithm adopted in CometBFT, to choose a round proposer. +-As Tendermint is “leader-based consensus protocol”, the proposer selection is critical for its correct functioning. ++As Tendermint is "leader-based consensus protocol", the proposer selection is critical for its correct functioning. + + At a given block height, the proposer selection algorithm runs with the same validator set at each round . + Between heights, an updated validator set may be specified by the application as part of the ABCIResponses' EndBlock. diff --git a/patches/spec/consensus/signing.md.patch b/patches/spec/consensus/signing.md.patch new file mode 100644 index 00000000000..f245885f7ed --- /dev/null +++ b/patches/spec/consensus/signing.md.patch @@ -0,0 +1,13 @@ +diff --git a/spec/consensus/signing.md b/spec/consensus/signing.md +index 38afe3502..18fa1454f 100644 +--- a/spec/consensus/signing.md ++++ b/spec/consensus/signing.md +@@ -5,7 +5,7 @@ + + Here we specify the rules for validating a proposal and vote before signing. + First we include some general notes on validating data structures common to both types. +-We then provide specific validation rules for each. Finally, we include validation rules to prevent double-sigining. ++We then provide specific validation rules for each. Finally, we include validation rules to prevent double-signing. + + ## SignedMsgType + diff --git a/patches/spec/core/data_structures.md.patch b/patches/spec/core/data_structures.md.patch new file mode 100644 index 00000000000..2958788c087 --- /dev/null +++ b/patches/spec/core/data_structures.md.patch @@ -0,0 +1,43 @@ +diff --git a/spec/core/data_structures.md b/spec/core/data_structures.md +index 2dcb852f3..f9c3e045b 100644 +--- a/spec/core/data_structures.md ++++ b/spec/core/data_structures.md +@@ -121,9 +121,9 @@ the data in the current block, the previous block, and the results returned by t + + | Name | Type | Description | Validation | + |-------------------|---------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +-| Version | [Version](#version) | Version defines the application and protocol version being used. | Must adhere to the validation rules of [Version](#version) | ++| Version | [Version](#version) | Version defines the application and block versions being used. | Must adhere to the validation rules of [Version](#version) | + | ChainID | String | ChainID is the ID of the chain. This must be unique to your chain. | ChainID must be less than 50 bytes. | +-| Height | uint64 | Height is the height for this header. | Must be > 0, >= initialHeight, and == previous Height+1 | ++| Height | uint64 | Height is the height for this header. | Must be > 0, >= initialHeight, and == previous Height+1 | + | Time | [Time](#time) | The timestamp is equal to the weighted median of validators present in the last commit. Read more on time in the [BFT-time section](../consensus/bft-time.md). Note: the timestamp of a vote must be greater by at least one millisecond than that of the block being voted on. | Time must be >= previous header timestamp + consensus parameters TimeIotaMs. The timestamp of the first block must be equal to the genesis time (since there's no votes to compute the median). | + | LastBlockID | [BlockID](#blockid) | BlockID of the previous block. | Must adhere to the validation rules of [blockID](#blockid). The first block has `block.Header.LastBlockID == BlockID{}`. | + | LastCommitHash | slice of bytes (`[]byte`) | MerkleRoot of the lastCommit's signatures. The signatures represent the validators that committed to the last block. The first block has an empty slices of bytes for the hash. | Must be of length 32 | +@@ -131,9 +131,9 @@ the data in the current block, the previous block, and the results returned by t + | ValidatorHash | slice of bytes (`[]byte`) | MerkleRoot of the current validator set. The validators are first sorted by voting power (descending), then by address (ascending) prior to computing the MerkleRoot. | Must be of length 32 | + | NextValidatorHash | slice of bytes (`[]byte`) | MerkleRoot of the next validator set. The validators are first sorted by voting power (descending), then by address (ascending) prior to computing the MerkleRoot. | Must be of length 32 | + | ConsensusHash | slice of bytes (`[]byte`) | Hash of the protobuf encoded consensus parameters. | Must be of length 32 | +-| AppHash | slice of bytes (`[]byte`) | Arbitrary byte array returned by the application after executing and commiting the previous block. It serves as the basis for validating any merkle proofs that comes from the ABCI application and represents the state of the actual application rather than the state of the blockchain itself. The first block's `block.Header.AppHash` is given by `ResponseInitChain.app_hash`. | This hash is determined by the application, CometBFT can not perform validation on it. | ++| AppHash | slice of bytes (`[]byte`) | Arbitrary byte array returned by the application after executing and commiting the previous block. It serves as the basis for validating any merkle proofs that comes from the ABCI application and represents the state of the actual application rather than the state of the blockchain itself. The first block's `block.Header.AppHash` is given by `ResponseInitChain.app_hash`. | This hash is determined by the application, CometBFT can not perform validation on it. | + | LastResultHash | slice of bytes (`[]byte`) | `LastResultsHash` is the root hash of a Merkle tree built from `ResponseDeliverTx` responses (`Log`,`Info`, `Codespace` and `Events` fields are ignored). | Must be of length 32. The first block has `block.Header.ResultsHash == MerkleRoot(nil)`, i.e. the hash of an empty input, for RFC-6962 conformance. | +-| EvidenceHash | slice of bytes (`[]byte`) | MerkleRoot of the evidence of Byzantine behavior included in this block. | Must be of length 32 | ++| EvidenceHash | slice of bytes (`[]byte`) | MerkleRoot of the evidence of Byzantine behavior included in this block. | Must be of length 32 | + | ProposerAddress | slice of bytes (`[]byte`) | Address of the original proposer of the block. Validator must be in the current validatorSet. | Must be of length 20 | + + ## Version +@@ -142,10 +142,10 @@ NOTE: that this is more specifically the consensus version and doesn't include i + P2P Version. (TODO: we should write a comprehensive document about + versioning that this can refer to) + +-| Name | type | Description | Validation | +-|-------|--------|-----------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------| +-| Block | uint64 | This number represents the version of the block protocol and must be the same throughout an operational network | Must be equal to protocol version being used in a network (`block.Version.Block == state.Version.Consensus.Block`) | +-| App | uint64 | App version is decided on by the application. Read [here](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/abci/abci++_app_requirements.md) | `block.Version.App == state.Version.Consensus.App` | ++| Name | type | Description | Validation | ++|-------|--------|---------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------| ++| Block | uint64 | This number represents the block version and must be the same throughout an operational network | Must be equal to block version being used in a network (`block.Version.Block == state.Version.Consensus.Block`) | ++| App | uint64 | App version is decided on by the application. Read [here](https://github.com/cometbft/cometbft/blob/v0.34.x/spec/abci/abci++_app_requirements.md) | `block.Version.App == state.Version.Consensus.App` | + + ## BlockID + diff --git a/patches/spec/core/encoding.md.patch b/patches/spec/core/encoding.md.patch new file mode 100644 index 00000000000..c5f8128232a --- /dev/null +++ b/patches/spec/core/encoding.md.patch @@ -0,0 +1,22 @@ +diff --git a/spec/core/encoding.md b/spec/core/encoding.md +index 0c2fdb1f6..25d979b6c 100644 +--- a/spec/core/encoding.md ++++ b/spec/core/encoding.md +@@ -19,7 +19,7 @@ For details on varints, see the [protobuf + spec](https://developers.google.com/protocol-buffers/docs/encoding#varints). + + For example, the byte-array `[0xA, 0xB]` would be encoded as `0x020A0B`, +-while a byte-array containing 300 entires beginning with `[0xA, 0xB, ...]` would ++while a byte-array containing 300 entries beginning with `[0xA, 0xB, ...]` would + be encoded as `0xAC020A0B...` where `0xAC02` is the UVarint encoding of 300. + + ## Hashing +@@ -171,7 +171,7 @@ func getSplitPoint(k int) { ... } + func MerkleRoot(items [][]byte) []byte{ + switch len(items) { + case 0: +- return empthHash() ++ return emptyHash() + case 1: + return leafHash(items[0]) + default: diff --git a/patches/spec/ivy-proofs/README.md.patch b/patches/spec/ivy-proofs/README.md.patch new file mode 100644 index 00000000000..3fdf517e7c8 --- /dev/null +++ b/patches/spec/ivy-proofs/README.md.patch @@ -0,0 +1,14 @@ +diff --git a/spec/ivy-proofs/README.md b/spec/ivy-proofs/README.md +index 00a4bed25..9b0f16e73 100644 +--- a/spec/ivy-proofs/README.md ++++ b/spec/ivy-proofs/README.md +@@ -27,7 +27,7 @@ The license above applies to all files in this folder. + The easiest way to check the proofs is to use [Docker](https://www.docker.com/). + + 1. Install [Docker](https://docs.docker.com/get-docker/) and [Docker Compose](https://docs.docker.com/compose/install/). +-2. Build a Docker image: `docker-compose build` +-3. Run the proofs inside the Docker container: `docker-compose run ++2. Build a Docker image: `docker compose build` ++3. Run the proofs inside the Docker container: `docker compose run + tendermint-proof`. This will check all the proofs with the `ivy_check` + command and write the output of `ivy_check` to a subdirectory of `./output/' diff --git a/patches/spec/light-client/README.md.patch b/patches/spec/light-client/README.md.patch new file mode 100644 index 00000000000..904ec054fc8 --- /dev/null +++ b/patches/spec/light-client/README.md.patch @@ -0,0 +1,13 @@ +diff --git a/spec/light-client/README.md b/spec/light-client/README.md +index 4357dd7dd..8ba1ff88c 100644 +--- a/spec/light-client/README.md ++++ b/spec/light-client/README.md +@@ -103,7 +103,7 @@ version 001. The TLA+ properties can be found in the + [TLA+ specification](verification/Lightclient_A_1.tla). + The experiments were run in an AWS instance equipped with 32GB + RAM and a 4-core Intel® Xeon® CPU E5-2686 v4 @ 2.30GHz CPU. +-We write “✗=k” when a bug is reported at depth k, and “✓<=k” when ++We write "✗=k" when a bug is reported at depth k, and "✓<=k" when + no bug is reported up to depth k. + + ![Experimental results](experiments.png) diff --git a/patches/spec/light-client/accountability/README.md.patch b/patches/spec/light-client/accountability/README.md.patch new file mode 100644 index 00000000000..bde83581b25 --- /dev/null +++ b/patches/spec/light-client/accountability/README.md.patch @@ -0,0 +1,13 @@ +diff --git a/spec/light-client/accountability/README.md b/spec/light-client/accountability/README.md +index 64b475bec..75563df70 100644 +--- a/spec/light-client/accountability/README.md ++++ b/spec/light-client/accountability/README.md +@@ -231,7 +231,7 @@ Execution + + Consequences: + +-* The validators in F1 will be detectable by the the fork accountability mechanisms. ++* The validators in F1 will be detectable by the fork accountability mechanisms. + * The validators in F2 cannot be detected using this mechanism. + Only in case they signed something which conflicts with the application this can be used against them. Otherwise they do not do anything incorrect. + * This case is not covered by the report as it only assumes at most 2/3 of faulty validators. diff --git a/patches/spec/light-client/detection/detection_001_reviewed.md.patch b/patches/spec/light-client/detection/detection_001_reviewed.md.patch new file mode 100644 index 00000000000..b8bcb760ae0 --- /dev/null +++ b/patches/spec/light-client/detection/detection_001_reviewed.md.patch @@ -0,0 +1,13 @@ +diff --git a/spec/light-client/detection/detection_001_reviewed.md b/spec/light-client/detection/detection_001_reviewed.md +index b204677d6..a97108412 100644 +--- a/spec/light-client/detection/detection_001_reviewed.md ++++ b/spec/light-client/detection/detection_001_reviewed.md +@@ -722,7 +722,7 @@ func CreateEvidenceForPeer(peer PeerID, root LightBlock, trace LightStore) + #### Argument for [[LCD-DIST-INV-ATTACK.1]](#LCD-DIST-INV-ATTACK1) + + Under the assumption that root and trace are a verification trace, +-when in `CreateEvidenceForPeer` the detector the detector creates ++when in `CreateEvidenceForPeer` the detector creates + evidence, then the lightclient has seen two different headers (one via + `trace` and one via `VerifyToTarget` for the same height that can both + be verified in one step. diff --git a/patches/spec/p2p/config.md.patch b/patches/spec/p2p/config.md.patch new file mode 100644 index 00000000000..42a7b5f1362 --- /dev/null +++ b/patches/spec/p2p/config.md.patch @@ -0,0 +1,38 @@ +diff --git a/spec/p2p/config.md b/spec/p2p/config.md +index a087f8e1d..d9b615e6d 100644 +--- a/spec/p2p/config.md ++++ b/spec/p2p/config.md +@@ -12,14 +12,14 @@ and upon incoming connection shares some peers and disconnects. + + ## Seeds + +-`--p2p.seeds “id100000000000000000000000000000000@1.2.3.4:26656,id200000000000000000000000000000000@2.3.4.5:4444”` ++`--p2p.seeds "id100000000000000000000000000000000@1.2.3.4:26656,id200000000000000000000000000000000@2.3.4.5:4444"` + + Dials these seeds when we need more peers. They should return a list of peers and then disconnect. + If we already have enough peers in the address book, we may never need to dial them. + + ## Persistent Peers + +-`--p2p.persistent_peers “id100000000000000000000000000000000@1.2.3.4:26656,id200000000000000000000000000000000@2.3.4.5:26656”` ++`--p2p.persistent_peers "id100000000000000000000000000000000@1.2.3.4:26656,id200000000000000000000000000000000@2.3.4.5:26656"` + + Dial these peers and auto-redial them if the connection fails. + These are intended to be trusted persistent peers that can help +@@ -36,14 +36,14 @@ and that the node may not be able to keep the connection persistent. + + ## Private Peers + +-`--p2p.private_peer_ids “id100000000000000000000000000000000,id200000000000000000000000000000000”` ++`--p2p.private_peer_ids "id100000000000000000000000000000000,id200000000000000000000000000000000"` + + These are IDs of the peers that we do not add to the address book or gossip to + other peers. They stay private to us. + + ## Unconditional Peers + +-`--p2p.unconditional_peer_ids “id100000000000000000000000000000000,id200000000000000000000000000000000”` ++`--p2p.unconditional_peer_ids "id100000000000000000000000000000000,id200000000000000000000000000000000"` + + These are IDs of the peers which are allowed to be connected by both inbound or outbound regardless of + `max_num_inbound_peers` or `max_num_outbound_peers` of user's node reached or not. diff --git a/patches/spec/p2p/messages/state-sync.md.patch b/patches/spec/p2p/messages/state-sync.md.patch new file mode 100644 index 00000000000..ba63766794b --- /dev/null +++ b/patches/spec/p2p/messages/state-sync.md.patch @@ -0,0 +1,13 @@ +diff --git a/spec/p2p/messages/state-sync.md b/spec/p2p/messages/state-sync.md +index cfc958e08..8e739fce8 100644 +--- a/spec/p2p/messages/state-sync.md ++++ b/spec/p2p/messages/state-sync.md +@@ -108,7 +108,7 @@ In order to build the state, the state provider will request the params at the h + + ### ParamsResponse + +-A reciever to the request will use the state store to fetch the consensus params at that height and return it to the sender. ++A receiver to the request will use the state store to fetch the consensus params at that height and return it to the sender. + + | Name | Type | Description | Field Number | + |----------|--------|---------------------------------|--------------| diff --git a/patches/spec/p2p/reactors/mempool-v1.md.patch b/patches/spec/p2p/reactors/mempool-v1.md.patch new file mode 100644 index 00000000000..d3a1dc6314d --- /dev/null +++ b/patches/spec/p2p/reactors/mempool-v1.md.patch @@ -0,0 +1,97 @@ +diff --git a/spec/p2p/reactors/mempool-v1.md b/spec/p2p/reactors/mempool-v1.md +new file mode 100644 +index 000000000..16186adb9 +--- /dev/null ++++ b/spec/p2p/reactors/mempool-v1.md +@@ -0,0 +1,91 @@ ++# Mempool V1 Reactor ++ ++## Overview ++ ++The Celestia-core's p2p layer, which is a fork of CometBFT, consists of channels and reactors. Peers establish connections within specific channels, effectively forming peer-to-peer groups (each channel represents such a group). The transmission of messages within a channel is governed by the associated reactor, essentially containing the protocol rules for that channel. ++ ++One notable channel is the mempool channel, identified as [`MempoolChannel`](https://github.com/celestiaorg/celestia-core/blob/3f3b7cc57f5cfc5e846ce781a9a407920e54fb72/mempool/mempool.go#L14) with a specific channel ID of [`0x30`](https://github.com/celestiaorg/celestia-core/blob/3f3b7cc57f5cfc5e846ce781a9a407920e54fb72/mempool/mempool.go#L14). The mempool reactor manages the dissemination of transactions across the network. It's important to highlight that there's a direct correspondence between reactors and the channels they are connected to. Consequently, the mempool reactor is the exclusive reactor linked to the mempool channel with ID `0x30`. This document will provide an overview of the protocol implemented by the mempool v1 reactor along with its traffic analysis. ++ ++## Transaction Flow and Lifecycle in a Node ++ ++A node can receive a transaction through one of two pathways: either a user initiates the transaction directly to the node, or the node acquires a transaction from another peer. Upon receiving a transaction, the following steps occur: ++ ++1. The transaction's validity is assessed, and if it passes the validation criteria, it is added to the mempool. Furthermore, the height at which the transaction is received is set to the current block height. This information will later be useful in purging old transactions from the mempool once their time-to-live (TTL) has elapsed and have not been included in any blocks. ++2. **Peer Tracking**: In the event that the transaction originates from another peer, the sending peer is marked to prevent redundant transmission of the same transaction. ++Subsequently, there are two concurrent processes underway, namely, the _mempool management_ and _broadcast process_, as explained in the remaining items below. ++3. **Mempool Management**: ++ ++ - Transactions that find their way into the mempool remain there until one of two conditions is met: either the mempool reaches its capacity limit or a new block is committed. ++ - When a [block is committed](https://github.com/celestiaorg/celestia-core/blob/367caa33ef5ab618ea357189e88044dbdbd17776/state/execution.go#L324): ++ - The transactions within that block that are successfully delivered to the app are removed from the mempool ([ref](https://github.com/celestiaorg/celestia-core/blob/993c1228977f206c80cb0f87ac1d4f002826e904/mempool/v1/mempool.go#L418)). They are also placed in the mempool cache ([ref](https://github.com/celestiaorg/celestia-core/blob/993c1228977f206c80cb0f87ac1d4f002826e904/mempool/v1/mempool.go#L411-L412)). ++ - The remaining transactions are subjected to two checks: ++ - Their Time-to-Live (TTL) is examined ([ref](https://github.com/celestiaorg/celestia-core/blob/993c1228977f206c80cb0f87ac1d4f002826e904/mempool/v1/mempool.go#L421)), and any transactions that have expired are promptly removed from the mempool ([ref](https://github.com/celestiaorg/celestia-core/blob/993c1228977f206c80cb0f87ac1d4f002826e904/mempool/v1/mempool.go#L743)). ++ - Next, the remaining transactions are re-evaluated for validity against the updated state ([ref](https://github.com/celestiaorg/celestia-core/blob/993c1228977f206c80cb0f87ac1d4f002826e904/mempool/v1/mempool.go#L429-L430)) due to the mempool [`recheck` config](https://github.com/celestiaorg/celestia-core/blob/2f93fc823f17c36c7090f84694880c85d3244764/config/config.go#L708) that is set to `true` ([ref](https://github.com/celestiaorg/celestia-core/blob/2f93fc823f17c36c7090f84694880c85d3244764/config/config.go#L761)). Any transactions that are found to be invalid are removed from the mempool. ++4. **Broadcast Process**: ++ For each peer and for every transaction residing in the mempool, the following actions are taken ([ref](https://github.com/celestiaorg/celestia-core/blob/64cd9ab7c67c945d755fb4fbd5afb2d352874eea/mempool/v1/reactor.go#L244)): ++ - A copy of the transaction is dispatched to that peer if the peer ++ - is online ++ - supports the mempool channel ID ([ref](https://github.com/celestiaorg/celestia-core/blob/ad660fee8f186d6f7e5e567ea23ea813f5038d90/p2p/peer.go#L319)) ++ - has a height difference of one (meaning it lags behind the transaction by a single block). If the height difference is greater, a waiting period is observed to allow the peer to catch up ([ref](https://github.com/celestiaorg/celestia-core/blob/64cd9ab7c67c945d755fb4fbd5afb2d352874eea/mempool/v1/reactor.go#L286-L289)). ++ - **Peer Tracking**: Each transaction is sent to a peer only once, and the recipient peer is marked to prevent the retransmission of the same transaction ([ref](https://github.com/celestiaorg/celestia-core/blob/64cd9ab7c67c945d755fb4fbd5afb2d352874eea/mempool/v1/reactor.go#L304)). ++ ++## Constraints and Configurations ++ ++The relevant constraints and configurations for the mempool are as follows ([ref](https://github.com/celestiaorg/celestia-core/blob/2f93fc823f17c36c7090f84694880c85d3244764/config/config.go#L758)): ++ ++- `Size`: This parameter specifies the total number of transactions that the mempool can hold. It is a configurable setting, with a default value of `5000`. ++- `MaxTxsBytes`: The `MaxTxsBytes` parameter defines the maximum size of the mempool in bytes, with a default value of `1GB`. ++- `MaxTxBytes`: The `MaxTxBytes` parameter specifies the maximum size of an individual transaction, which is set to `1MB`. ++- `TTLNumBlocks` and `TTLDuration` : These settings determine the number of blocks and time after which a transaction is removed from the mempool if it has not been included in a block. The default is set to zero, however, on [celestia-app side](https://github.com/celestiaorg/celestia-app/blob/ccfb3e5e87d05d75a92ad85ab199d4f0c4879a0a/app/default_overrides.go#L221-L222) these values are over-written to `5` and `5*15 s`, respectively. ++ ++For each peer-to-peer connection, the following limits apply to the aggregate traffic rate of all the channels ([ref](https://github.com/celestiaorg/celestia-core/blob/3f3b7cc57f5cfc5e846ce781a9a407920e54fb72/libs/flowrate/flowrate.go#L177)): ++ ++- `SendRate`: The `SendRate` parameter enforces a default sending rate of [`5120000 B= 5MB/s`](https://github.com/celestiaorg/celestia-core/blob/2f93fc823f17c36c7090f84694880c85d3244764/config/config.go#L615). It ensures that data is sent at this maximum rate. This parameter does not seem to be overwritten by the celestia-app. ++- `RecvRate`: The `RecvRate` parameter enforces a default receiving rate of [`5120000 B= 5MB/s`](https://github.com/celestiaorg/celestia-core/blob/2f93fc823f17c36c7090f84694880c85d3244764/config/config.go#L616). It ensures that data is received at this maximum rate. This parameter does not seem to be overwritten by the celestia-app. ++- `MaxPacketMsgPayloadSize`: The `MaxPacketMsgPayloadSize` parameter sets the maximum payload size for packet messages to `1024` bytes. ++ ++ ++ ++ ++Other P2P configs ([ref](https://github.com/celestiaorg/celestia-core/blob/2f93fc823f17c36c7090f84694880c85d3244764/config/config.go#L524)) that would be relevant to the traffic analysis are: ++ ++- [`max_num_inbound_peers` and `max_num_outbound_peers`](https://github.com/celestiaorg/celestia-core/blob/37f950717381e8d8f6393437624652693e4775b8/config/config.go#L604-L605): These parameters indicate the total number of inbound and outbound peers, respectively. The default values are `40` for inbound peers and `10` for outbound peers ([excluding persistent peers](https://github.com/celestiaorg/celestia-core/blob/2f93fc823f17c36c7090f84694880c85d3244764/config/config.go#L553-L554)). ++ ++ ++## Traffic Rate Analysis ++ ++In the analysis provided below, we consider the knowledge of the following network parameters: ++ ++- `d`: Node degree (total incoming and outgoing connections) ++- `transaction_rate` which specifies that total size of transactions in bytes per second submitted to the network. ++ ++Transactions are assumed to comply with the transaction size, are valid and are accepted by the mempool. We also assume all the peers are up and running. ++ ++### Traffic Rate Analysis for a Node ++ ++We distinguish between the incoming and outgoing traffic rate, and denote them by `incoming_traffic_rate` and `outgoing_traffic_rate`, respectively. ++ ++- **Worst case scenario**: a transaction is exchanged by the two ends of ++connection simultaneously, contributing to both incoming and outgoing traffic. ++In a network, with transaction rate `transaction_rate` and a node with `d` degree, the traffic rates are calculated as follows: ++`incoming_traffic_rate = d * transaction_rate` ++`outgoing_traffic_rate = d * transaction_rate` ++ ++These max rates are further constrained by the `SendRate` and `RecvRate`. ++`incoming_traffic_rate = d * min(transaction_rate, RecvRate)` ++`outgoing_traffic_rate = d * min(transaction_rate, SendRate)` ++ ++- **Best case scenario**: a transaction is exchanged only once, contributing to either incoming or outgoing traffic. This is because both ends of the connection keep track of the transactions they have seen on a connection (whether via sending or receiving). If one peer sends a transaction before the other, they both mark it as sent/received, ensuring they do not redundantly transmit it to each other. ++In a network, with transaction rate `transaction_rate` and a node with degree of `d`, the node's traffic rate in best case would be: ++`traffic_rate (=incoming_traffic_rate + outgoing_traffic_rate) = d * transaction_rate` ++ ++We can draw the following conclusions (to be extended and verified): ++ ++- With a known given transaction rate `transaction_rate`, a node's (in + out) traffic rate should range from `d * transaction_rate` to `2 * d * transaction_rate`. ++- To handle a particular `transaction_rate` (network throughput), the node's `SendRate` and `RecvRate` should be at least `transaction_rate` to handle the worst case scenario (this is only to undertake the load incurred by the mempool reactor). ++ ++### Impact of mempool on other network aspects ++ ++- **Block size**: One immediate impact of mempool, is the size of mempool on the block size. Block size can not exceed the mempool size. In the current setting, the mempool size is at max `1GB` meaning Celestia blocks can get as large as that (excluding block header). ++- **Network throughput**: TBC ++- **Block Time**: TBC diff --git a/patches/spec/p2p/v0.34/configuration.md.patch b/patches/spec/p2p/v0.34/configuration.md.patch new file mode 100644 index 00000000000..9a29e329456 --- /dev/null +++ b/patches/spec/p2p/v0.34/configuration.md.patch @@ -0,0 +1,22 @@ +diff --git a/spec/p2p/v0.34/configuration.md b/spec/p2p/v0.34/configuration.md +index 53ac3183d..88d92804b 100644 +--- a/spec/p2p/v0.34/configuration.md ++++ b/spec/p2p/v0.34/configuration.md +@@ -32,13 +32,13 @@ These parameters can be set using the `$CMTHOME/config/config.toml` file. A subs + | Parameter | Flag| Example| + | --- | --- | ---| + | Listen address| `p2p.laddr` | "tcp://0.0.0.0:26656" | +-| Seed nodes | `p2p.seeds` | `--p2p.seeds “id100000000000000000000000000000000@1.2.3.4:26656,id200000000000000000000000000000000@2.3.4.5:4444”` | +-| Persistent peers | `p2p.persistent_peers` | `--p2p.persistent_peers “id100000000000000000000000000000000@1.2.3.4:26656,id200000000000000000000000000000000@2.3.4.5:26656”` | +-| Unconditional peers | `p2p.unconditional_peer_ids` | `--p2p.unconditional_peer_ids “id100000000000000000000000000000000,id200000000000000000000000000000000”` | ++| Seed nodes | `p2p.seeds` | `--p2p.seeds "id100000000000000000000000000000000@1.2.3.4:26656,id200000000000000000000000000000000@2.3.4.5:4444"` | ++| Persistent peers | `p2p.persistent_peers` | `--p2p.persistent_peers "id100000000000000000000000000000000@1.2.3.4:26656,id200000000000000000000000000000000@2.3.4.5:26656"` | ++| Unconditional peers | `p2p.unconditional_peer_ids` | `--p2p.unconditional_peer_ids "id100000000000000000000000000000000,id200000000000000000000000000000000"` | + | UPNP | `p2p.upnp` | `--p2p.upnp` | + | PexReactor | `p2p.pex` | `--p2p.pex` | + | Seed mode | `p2p.seed_mode` | `--p2p.seed_mode` | +- | Private peer ids | `p2p.private_peer_ids` | `--p2p.private_peer_ids “id100000000000000000000000000000000,id200000000000000000000000000000000”` | ++ | Private peer ids | `p2p.private_peer_ids` | `--p2p.private_peer_ids "id100000000000000000000000000000000,id200000000000000000000000000000000"` | + + **Note on persistent peers** + diff --git a/patches/spec/p2p/v0.34/pex.md.patch b/patches/spec/p2p/v0.34/pex.md.patch new file mode 100644 index 00000000000..fed4bdefa92 --- /dev/null +++ b/patches/spec/p2p/v0.34/pex.md.patch @@ -0,0 +1,12 @@ +diff --git a/spec/p2p/v0.34/pex.md b/spec/p2p/v0.34/pex.md +index 8243eaa55..8f49e84af 100644 +--- a/spec/p2p/v0.34/pex.md ++++ b/spec/p2p/v0.34/pex.md +@@ -106,6 +106,6 @@ A node receives two type of messages as part of the PEX protocol: + + - `PexRequest`: a request for addresses received from a peer, handled as + described [here](./pex-protocol.md#providing-addresses) +-- `PexAddrs`: a list of addresses received from a peer, as a reponse to a PEX ++- `PexAddrs`: a list of addresses received from a peer, as a response to a PEX + request sent by the node, as described [here](./pex-protocol.md#responses) + diff --git a/patches/test/docker/Dockerfile.patch b/patches/test/docker/Dockerfile.patch new file mode 100644 index 00000000000..cd6efac17e4 --- /dev/null +++ b/patches/test/docker/Dockerfile.patch @@ -0,0 +1,10 @@ +diff --git a/test/docker/Dockerfile b/test/docker/Dockerfile +index 65ec588eb..9e1aa79e0 100644 +--- a/test/docker/Dockerfile ++++ b/test/docker/Dockerfile +@@ -1,4 +1,4 @@ +-FROM golang:1.21 ++FROM golang:1.23.1 + + # Grab deps (jq, hexdump, xxd, killall) + RUN apt-get update && \ diff --git a/patches/test/e2e/docker/Dockerfile.patch b/patches/test/e2e/docker/Dockerfile.patch new file mode 100644 index 00000000000..286ad9c0dd0 --- /dev/null +++ b/patches/test/e2e/docker/Dockerfile.patch @@ -0,0 +1,16 @@ +diff --git a/test/e2e/docker/Dockerfile b/test/e2e/docker/Dockerfile +index 5591d61d6..e8e0395de 100644 +--- a/test/e2e/docker/Dockerfile ++++ b/test/e2e/docker/Dockerfile +@@ -1,9 +1,10 @@ + # We need to build in a Linux environment to support C libraries, e.g. RocksDB. + # We use Debian instead of Alpine, so that we can use binary database packages + # instead of spending time compiling them. +-FROM cometbft/cometbft-db-testing:v0.9.1 ++FROM golang:1.23.1-bullseye + + RUN apt-get -qq update -y && apt-get -qq upgrade -y >/dev/null ++RUN apt-get -qq install -y libleveldb-dev librocksdb-dev >/dev/null + + # Set up build directory /src/cometbft + ENV COMETBFT_BUILD_OPTIONS badgerdb,boltdb,cleveldb,rocksdb diff --git a/patches/test/loadtime/README.md.patch b/patches/test/loadtime/README.md.patch new file mode 100644 index 00000000000..13e51f4b138 --- /dev/null +++ b/patches/test/loadtime/README.md.patch @@ -0,0 +1,13 @@ +diff --git a/test/loadtime/README.md b/test/loadtime/README.md +index c19880c49..4226813b4 100644 +--- a/test/loadtime/README.md ++++ b/test/loadtime/README.md +@@ -22,7 +22,7 @@ make build + The `load` binary is built when `make build` is invoked. The `load` tool generates + transactions and broadcasts them to CometBFT. + +-`load` leverages the [tm-load-test](https://github.com/informalsystems/tm-load-test) ++`load` leverages the [cometbft-load-test](https://github.com/cometbft/cometbft-load-test) + framework. As a result, all flags and options specified on the `tm-load-test` apply to + `load`. + diff --git a/patches/tools/README.md.patch b/patches/tools/README.md.patch new file mode 100644 index 00000000000..371984720f6 --- /dev/null +++ b/patches/tools/README.md.patch @@ -0,0 +1,11 @@ +diff --git a/tools/README.md b/tools/README.md +deleted file mode 100644 +index 3b06cc59a..000000000 +--- a/tools/README.md ++++ /dev/null +@@ -1,5 +0,0 @@ +-# tools +- +-Tools for working with CometBFT and associated technologies. +-Documentation for these tools can be found online in the +-[CometBFT tools documentation](https://docs.cometbft.com/v0.34/tools/). diff --git a/patches/tools/proto/Dockerfile.patch b/patches/tools/proto/Dockerfile.patch new file mode 100644 index 00000000000..a8fe57fea9a --- /dev/null +++ b/patches/tools/proto/Dockerfile.patch @@ -0,0 +1,33 @@ +diff --git a/tools/proto/Dockerfile b/tools/proto/Dockerfile +deleted file mode 100644 +index 500822690..000000000 +--- a/tools/proto/Dockerfile ++++ /dev/null +@@ -1,27 +0,0 @@ +-FROM bufbuild/buf:latest as buf +- +-FROM golang:1.14-alpine3.11 as builder +- +-RUN apk add --update --no-cache build-base curl git upx && \ +- rm -rf /var/cache/apk/* +- +-ENV GOLANG_PROTOBUF_VERSION=1.3.1 \ +- GOGO_PROTOBUF_VERSION=1.3.2 +- +-RUN GO111MODULE=on go get \ +- github.com/golang/protobuf/protoc-gen-go@v${GOLANG_PROTOBUF_VERSION} \ +- github.com/gogo/protobuf/protoc-gen-gogo@v${GOGO_PROTOBUF_VERSION} \ +- github.com/gogo/protobuf/protoc-gen-gogofaster@v${GOGO_PROTOBUF_VERSION} && \ +- mv /go/bin/protoc-gen-go* /usr/local/bin/ +- +- +-FROM alpine:edge +- +-WORKDIR /work +- +-RUN echo 'http://dl-cdn.alpinelinux.org/alpine/edge/testing' >> /etc/apk/repositories && \ +- apk add --update --no-cache clang && \ +- rm -rf /var/cache/apk/* +- +-COPY --from=builder /usr/local/bin /usr/local/bin +-COPY --from=buf /usr/local/bin /usr/local/bin