-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
adr: Un-Ordered Transaction Inclusion #18553
Conversation
WalkthroughADR 069 proposes the introduction of an "un-ordered nonce lane" to support concurrent transaction inclusion, allowing gaps in nonce sequences. This feature aims to enhance the user experience for sending multiple transactions simultaneously, particularly for use cases such as IBC relayers and crypto exchanges. The proposal encompasses changes to the account structure, transaction format, and nonce management, utilizing a roaring bitmap for tracking gaps. Additionally, it introduces a new decorator for duplicate prevention and transaction handling, aiming to maintain nonce uniqueness with minimal overhead. Changes
TipsChat with CodeRabbit Bot (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Status
Actionable comments generated: 3
Configuration used: CodeRabbit UI
Files selected for processing (1)
- docs/architecture/adr-069-unordered-account.md (1 hunks)
Additional comments: 2
docs/architecture/adr-069-unordered-account.md (2)
26-30:
The addition of theGaps
field to theAccount
struct aligns with the proposed changes for supporting gaps in nonce values.56-87:
TheIntSet
implementation with methodsAdd
,Remove
, andContains
is consistent with the requirements for managing nonce gaps.
func(acc *Account) CheckNonce(nonce int64) error { | ||
switch { | ||
case nonce == acct.SequenceNumber: | ||
return errors.New("nonce is occupied") | ||
case nonce >= acct.SequenceNumber + 1: | ||
gaps := nonce - acct.SequenceNumber - 1 | ||
if gaps > MaxGap { | ||
return errors.New("max gap is exceeded") | ||
} | ||
for i := 0; i < gaps; i++ { | ||
acct.Gaps.Add(i + acct.SequenceNumber + 1) | ||
} | ||
acct.SequenceNumber = nonce | ||
case nonce < acct.SequenceNumber: | ||
if !acct.Gaps.Contains(nonce) { | ||
return errors.New("nonce is occupied") | ||
} | ||
acct.Gaps.Remove(nonce) | ||
} | ||
return nil | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The loop in lines 42-43 may introduce a performance issue if the gap is large. Consider optimizing this by using a more efficient method to add multiple gaps at once if such functionality is supported by the IntSet
.
func (is *IntSet) Add(n int) { | ||
if is.bitmap.Length() >= is.capacity { | ||
// pop the minimal one | ||
is.Remove(is.bitmap.Minimal()) | ||
} | ||
|
||
is.bitmap.Add(n) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The comment on line 73 might be misleading as it implies that the smallest value is always removed, which may not be the case if the smallest value is still a valid gap. Clarify the comment to reflect the actual behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
func NewIntSet(capacity int) *IntSet { | ||
return IntSet{ | ||
capacity: capacity, | ||
bitmap: *roaringbitmap.New(), | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The NewIntSet
function should return a pointer to IntSet
.
- return IntSet{
+ return &IntSet{
Commitable suggestion
❗ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
func NewIntSet(capacity int) *IntSet { | |
return IntSet{ | |
capacity: capacity, | |
bitmap: *roaringbitmap.New(), | |
} | |
func NewIntSet(capacity int) *IntSet { | |
return &IntSet{ | |
capacity: capacity, | |
bitmap: *roaringbitmap.New(), | |
} |
for i := 0; i < gaps; i++ { | ||
acct.Gaps.Add(i + acct.SequenceNumber + 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider optimizing this by using a more efficient method to add multiple gaps at once if such functionality is supported by the IntSet
.
// pop the minimal one | ||
is.Remove(is.bitmap.Minimal()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarify the comment to reflect the actual behavior.
This is a very interesting ADR and aligns very well with CometBFT vision and as such we would like to contribute. There have been several discussions about the pros and cons of using the mempool provided by CometBFT versus an app-side one, being the most recent in the context of ADR 111 The CometBFT teams believes that the end-to-end principle applies to the mempool and that application is best prepared implement it. Specially wrt ordering of transactions, even if CometBFT does not provide FIFO ordering guarantees (for example as discussed here), FIFO is frequently achieved and applications may have come to depend on it for performance, if not for correctness. If this ADR results in a lesser expectation of ordering from CometBFT, we could, for example, review the decision not to merge the changes made in the context of issue 1149, which provides a simple non-breaking change to saving bandwidth but which cause more frequent violations to FIFO. Regarding this ADR, some questions, which probably stem from my lacking of understanding of the SDK:
cc: @ancazamfir |
Actually the proposal is to allow including transactions into block and execute them out of order. So it's about state machine change, not just mempool. |
I see. In this case the problem I pointed wouldn't exist, since nodes will close the gaps in the same way. |
|
||
## Decision | ||
|
||
Change the nonce logic to allow gaps to exist, which can be filled by other transactions later, or never filled at all, the prototype implementation use a bitmap to record these gap values. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we allow gaps to exist and ordering here doesnt matter, should we look into making nonces expire. A nonce is accompanied with a blockheight or hash at which the nonce will expire.
This leads into the direction of not needing nonces at all. Since we move from caring about order and replay to only replay protection then nonces could be simplified.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, the basic idea is to allow "unordered" account with as low as possible overhead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we look into making nonces expire
based on the prototype implementation in this ADR, we can record the block height or time the latest nonce is created, and when it timeouts make all the "gaps" expire at the same time, in this way, the overhead should be minimal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it would be good to understand alternative ways of doing ordering of transactions. I do see people wanting this feature as well.
no, simply include and execute transactions out of order, they are still executed as the order as in the block. |
Talked with @yihuang in slack. I propose we do two things. First we keep the current design of nonces, ordering is important for some applications. Outright removing them would cause the need for ordering to happen elsewhere. Second, we introduce the notion of unordered nonces. This could be under a nonce namespace, in which we have an identifier appended to the nonce to signify there is no need to order the tx with the others. This keeps transaction ordering as a first class citizen like we have it now, but then we introduce unordered nonces. The main question for unordered nonces, for me, is if we can make them stateless while keeping replay protection. |
// pop the minimal one | ||
is.Remove(is.bitmap.Minimal()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we guaranteed for this nonce/gap to be used and safe to be discarded?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when it's removed from the set, it just means the nonce can't be used anymore, if there's a old pending transaction still using that nonce, it won't be accepted anymore, like an expiration.
so there are two kinds of expiration here, timestamp based, and gap set capacity based.
|
||
## Decision | ||
|
||
Change the nonce logic to allow gaps to exist, which can be filled by other transactions later, or never filled at all, the prototype implementation use a bitmap to record these gap values. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please add more to detail and generally explain the concept of "gaps". I think it's clear if you have context, but it'll be better for the reader.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a bit more in decisions sections, please re-review
## Status | ||
|
||
Proposed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Move this section to the top :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
Agree with @tac0turtle -- we need to provide an account with the ability to use standard ordering and concurrent ordering at the same time, in a graceful and clean way, i.e. allow the user to pick. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Status
Actionable comments generated: 2
Configuration used: CodeRabbit UI
Files selected for processing (1)
- docs/architecture/adr-069-unordered-account.md (1 hunks)
Additional comments: 1
docs/architecture/adr-069-unordered-account.md (1)
- 93-97: The
NewIntSet
function should return a pointer toIntSet
.- return IntSet{ + return &IntSet{
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Status
Actionable comments generated: 3
Configuration used: CodeRabbit UI
Files selected for processing (1)
- docs/architecture/adr-069-unordered-account.md (1 hunks)
Additional comments: 1
docs/architecture/adr-069-unordered-account.md (1)
- 99-131: The previous reviewer requested more detailed godocs for the
CheckNonce
function to clarify the logic of each case. It appears that this has not been addressed in the current hunk. Please consider adding more detailed comments to explain the logic, especially for the last two cases.
func (is *IntSet) Add(n uint64) { | ||
if is.bitmap.GetCardinality() >= is.capacity { | ||
// drop the smallest one | ||
is.bitmap.Remove(is.bitmap.Minimal()) | ||
} | ||
|
||
is.bitmap.Add(n) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similar to the AddRange
method, the Add
method in the IntSet
struct could be optimized. When the capacity is reached and a new element is to be added, the method removes the smallest element one by one. Consider optimizing this logic to handle the removal of elements more efficiently.
## Consequences | ||
|
||
### Positive | ||
|
||
* Support concurrent transaction inclusion. | ||
* Only optional fields are added to account state, no state migration is needed. | ||
* No runtime overhead when the new feature is not used. | ||
* No need to change transaction format. | ||
|
||
### Negative | ||
|
||
- Some runtime overhead when the new feature is used. | ||
|
||
## References |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While the document outlines the positive and negative consequences of the proposed changes, it may be beneficial to also discuss any potential security implications of introducing an unordered nonce lane, such as the risk of double-spending or other attack vectors.
Updated the ADR based on the discussion, now we create a new lane for un-ordered nonces, so we'll have both ordered and un-ordered lane runs at the same time, and it has minimal impact to existing user who don't use the unordered feature, please review again, @tac0turtle @lasarojc @alexanderbez One open question is: should we charge extra fee for extra overhead when user do use the un-ordered lane. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (1)
- docs/architecture/adr-069-unordered-account.md (1 hunks)
Additional comments: 5
docs/architecture/adr-069-unordered-account.md (5)
- 1-1: The title of the ADR is inconsistent with the PR objective and the summary provided. It should be updated to reflect the correct ADR number and the feature being introduced.
- # ADR 070: Un-Ordered Transaction Inclusion + # ADR 069: Un-Ordered Nonce Lane
- 13-13: The abstract incorrectly states that the proposed method doesn't use nonce at all, which contradicts the PR objective and the summary that mention the introduction of an unordered nonce feature.
- We propose a way to do replay-attack protection without enforcing the order of transactions, it don't use nonce at all. + We propose a way to do replay-attack protection without enforcing the order of transactions, by introducing unordered nonces.
21-23: The decision to add a boolean field
unordered
to the transaction body aligns with the comments from the previous review and the PR objective.31-36: The protobuf definition for
TxBody
correctly includes theunordered
boolean field as per the decision section.39-51: The implementation of the ante handlers for bypassing the nonce decorator for un-ordered transactions is consistent with the PR objective and the summary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
Files selected for processing (1)
- docs/architecture/adr-069-unordered-account.md (1 hunks)
Additional comments: 2
docs/architecture/adr-069-unordered-account.md (2)
1-1: The title of the ADR in the document is "ADR 070," which is inconsistent with the PR objective and summary that refer to "ADR 069." Please verify the correct ADR number.
13-13: The abstract states that the proposed method doesn't use nonce at all, which contradicts the PR objective and summary that mention introducing an unordered nonce feature. Please clarify whether nonces are used in any capacity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good, left a few questions in regards to startup. Not sure if replaying last x blocks makes a lot of sense. Its nondeterministic if the blocks are held
} | ||
|
||
// EndBlock remove expired tx hashes, need to wire in abci cycles. | ||
func (dtm *DedupTxHashManager) EndBlock(ctx sdk.Context) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how will this run in endblock? could we not do a quick check against current time and remove everything behind it? could be a DeleteUntil
then it checks and removes all previous hashes. This could be done async as well if we wanted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how will this run in endblock?
Wire into baseapp.
Yeah, it can run in background, the end blocker could be a trigger.
It could grab a read lock first and iterate to find out expired hashes, then grab write lock to do the deletion, that should have maximum parallel performance
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that sounds good. Since everything under current height wont be touched by the state machine, do we need locks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that sounds good. Since everything under current height wont be touched by the state machine, do we need locks?
we need locks because check tx runs concurrently, and we also have a background purging loop now.
|
||
### Negative | ||
|
||
- Start up overhead to scan historical blocks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we use the filesystem to write the known hashes at shutdown? On start we would populate from the file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as we write to disk, we need to handle commit, rollbacks the same as the other state machine state, to keep it consistent. So better to use existing non-iavl kvstore directly.
but we can cache the whole thing in memory on start up, so duplication checking is fast.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we do something like this in store, but not sure its exposed to things out side of store currently. The main worry i have is around upgrades, where everyone stops and starts, then the map would be empty. Looking back at the x blocks would be best but since we dont know if everyone has it, we could end up in a bad situation.
we could create a simple txhash store for store v1 that handles this and is exposed through baseapp.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, we need some support from storage layer here.
discussed on the team call, should we say 0 nonce = unordered? we can do this for backports, should we do this instead of the boolean as well? cc @alexanderbez |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ConceptACK.
|
||
When an un-ordered transaction are included into block, the transaction hash is recorded in a dictionary, new transactions are checked against this dictionary for duplicates, and to prevent the dictionary grow indefinitly, the transaction must specify `timeout_height` for expiration, so it's safe to removed it from the dictionary after it's expired. | ||
|
||
The dictionary can be simply implemented as an in-memory golang map, a preliminary analysis shows that the memory consumption won't be too big, for example `32M = 32 * 1024 * 1024` can support 1024 blocks where each block contains 1024 unordered transactions. For safty, we should limit the range of `timeout_height` to prevent very long expiration, and limit the size of the dictionary. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A short timeout_height
window also ensures a tighter bound on replay protection.
### EndBlocker | ||
|
||
Wire up the `EndBlock` method of `DedupTxHashManager` into the application's abci life cycle. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could simply purge the map during the FinalizeBlock
hook that app's can set. There are many places we can purge, it can be EndBlock
too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe Commit
event, I changed the method name to OnNewBlock
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, overall, my point is that I think this is a minor implementation detail in the grand scheme of things 👍
Although it don't change tx format, but it changes the behavior, there's a slight chance that an invalid tx before becomes valid now because of this change, I think we shouldn't backport this. |
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Status
Actionable comments generated: 4
Configuration used: CodeRabbit UI
Files selected for processing (1)
- docs/architecture/adr-069-unordered-account.md (1 hunks)
Additional comments: 4
docs/architecture/adr-069-unordered-account.md (4)
1-1: The ADR title in the document is "ADR 070", which is inconsistent with the summary that refers to "ADR 069". Please verify the correct ADR number.
53-90: The
EndBlock
method and other methods inDedupTxHashManager
use a mutex, but the mutex is not declared within the provided code. Ensure that the mutex is properly declared and initialized.98-104: The
AnteHandle
method inIncrementSequenceDecorator
correctly bypasses the nonce decorator for un-ordered transactions.165-173: The consequences section is concise and mentions the negative impact of start-up overhead. No further issues are identified based on the previous instructions to ignore old comments.
|
||
## Abstract | ||
|
||
We propose a way to do replay-attack protection without enforcing the order of transactions, it don't use nonce at all. In this way we can support un-ordered transaction inclusion. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The abstract contains a grammatical error. Consider revising to "it doesn't use nonces at all" for clarity and correctness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Status
Actionable comments generated: 4
Configuration used: CodeRabbit UI
Files selected for processing (1)
- docs/architecture/adr-069-unordered-account.md (1 hunks)
Additional comments: 1
docs/architecture/adr-069-unordered-account.md (1)
- 1-1: The ADR title is inconsistent with the PR title and the summary provided. The PR title and summary mention ADR 069, but the ADR document itself is titled ADR 070.
message TxBody { | ||
... | ||
|
||
boolean unordered = 4; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The unordered
field in the TxBody
message is incorrectly defined as boolean
. The correct Protobuf type is bool
.
dtm.mutex.RLock() | ||
defer dtm.mutex.RUnlock() | ||
|
||
return len(dtm).hashes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a syntax error in the Size
method of the DedupTxHashManager
struct. It should be len(dtm.hashes)
instead of len(dtm).hashes
.
if !ctx.IsCheckTx() { | ||
// a new tx included in the block, add the hash to the dictionary | ||
if dtd.m.Size() >= MaxNumberOfTxHash { | ||
return nil, errorsmod.Wrap(sdkerrors.ErrLogic, "dedup map is full") | ||
} | ||
dtd.m.Add(tx.Hash(), tx.TimeoutHeight()) | ||
} else { | ||
// check for duplicates | ||
if dtd.m.Contains(tx.Hash()) { | ||
return nil, errorsmod.Wrap(sdkerrors.ErrLogic, "tx is duplicated") | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The AnteHandle
method in DedupTxDecorator
should check for duplicates before adding a new transaction hash to the dictionary, even when !ctx.IsCheckTx()
is true.
|
||
### Negative | ||
|
||
- Start up overhead to scan historical blocks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The consequences section should include the negative aspect of the nonce max number becoming 2^63, as mentioned in the existing comments.
* feat: secp256k1 public key constant time (cosmos#18026) Signed-off-by: bizk <santiago.yanzon1999@gmail.com> * chore: Fixed changelog duplicated items (cosmos#18628) * adr: Un-Ordered Transaction Inclusion (cosmos#18553) Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com> * docs: lint ADR-070 (cosmos#18634) * fix(baseapp)!: postHandler should run regardless of result (cosmos#18627) * docs: fix typos in adr-007-specialization-groups.md (cosmos#18635) * chore: alphabetize labels (cosmos#18640) * docs(x/circuit): add note on ante handler (cosmos#18637) Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com> * fix: telemetry metric label variable (cosmos#18643) * chore: typos fix (cosmos#18642) * refactor(store/v2): updates from integration (cosmos#18633) * build(deps): Bump actions/setup-go from 4 to 5 (cosmos#18647) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com> * feat(store/v2): snapshot manager (cosmos#18458) * chore(client/v2): fix typos in the README.md (cosmos#18657) * fix(baseapp): protocompat.go gogoproto.Merge does not work with custom types (cosmos#18654) Co-authored-by: unknown unknown <unknown@unknown> * chore: fix several minor typos (cosmos#18660) * chore(tools/confix/cmd): fix typo in view.go (cosmos#18659) * refactor(x/staking): check duplicate addresses in StakeAuthorization's params (cosmos#18655) * feat(accounts): use gogoproto API instead of protov2. (cosmos#18653) Co-authored-by: unknown unknown <unknown@unknown> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> * fix(store/commitment/iavl): honor tree.Remove error firstly (cosmos#18651) * build(deps): Bump actions/stale from 8 to 9 (cosmos#18656) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * chore(docs): fix typos & wording in docs (cosmos#18667) * chore: fix several typos. (cosmos#18666) * feat(telemetry): enable `statsd` and `dogstatsd` telemetry sinks (cosmos#18646) Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com> Co-authored-by: marbar3778 <marbar3778@yahoo.com> Co-authored-by: Marko <marko@baricevic.me> * feat(store/v2): add SetInitialVersion in SC (cosmos#18665) * feat(client/keys): support display discreetly for `keys add` (cosmos#18663) Co-authored-by: Julien Robert <julien@rbrt.fr> * ci: add misspell action (cosmos#18671) * chore: typos fix by misspell-fixer (cosmos#18683) Co-authored-by: github-merge-queue <github-merge-queue@users.noreply.github.com> Co-authored-by: Julien Robert <julien@rbrt.fr> * chore: add v0.50.2 changelog to main (cosmos#18682) * build(deps): Bump github.com/jhump/protoreflect from 1.15.3 to 1.15.4 in /tests (cosmos#18678) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * refactor(bank): remove .String() calls (cosmos#18175) Co-authored-by: Facundo <facundomedica@gmail.com> * ci: use codespell instead of misspell-fixer (cosmos#18686) Co-authored-by: Marko <marbar3778@yahoo.com> * feat(gov): add proposal types and spam votes (cosmos#18532) * feat(accounts): use account number as state prefix for account state (cosmos#18664) Co-authored-by: unknown unknown <unknown@unknown> * chore: typos fixes by cosmos-sdk bot (cosmos#18689) Co-authored-by: github-merge-queue <github-merge-queue@users.noreply.github.com> Co-authored-by: Julien Robert <julien@rbrt.fr> Co-authored-by: marbar3778 <marbar3778@yahoo.com> * feat(client/keys): support display discreetly for keys mnemonic (cosmos#18688) * refactor: remove panic usage in keeper methods (cosmos#18636) * ci: rename pr name in misspell job (cosmos#18693) Co-authored-by: Marko <marko@baricevic.me> * build(deps): Bump github.com/pelletier/go-toml/v2 from 2.1.0 to 2.1.1 in /tools/confix (cosmos#18702) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com> * feat(client/keys): support display discreetly for keys export (cosmos#18684) * feat(x/gov): better gov genesis validation (cosmos#18707) --------- Signed-off-by: bizk <santiago.yanzon1999@gmail.com> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: Carlos Santiago Yanzon <27785807+bizk@users.noreply.github.com> Co-authored-by: yihuang <huang@crypto.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com> Co-authored-by: Facundo Medica <14063057+facundomedica@users.noreply.github.com> Co-authored-by: Akaonetwo <107335783+Akare123@users.noreply.github.com> Co-authored-by: Marko <marbar3778@yahoo.com> Co-authored-by: Julien Robert <julien@rbrt.fr> Co-authored-by: dreamweaverxyz <153101746+dreamweaverxyz@users.noreply.github.com> Co-authored-by: Pioua <136521243+dzizazda@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: cool-developer <51834436+cool-develope@users.noreply.github.com> Co-authored-by: leonarddt05 <139609434+leonarddt05@users.noreply.github.com> Co-authored-by: testinginprod <98415576+testinginprod@users.noreply.github.com> Co-authored-by: unknown unknown <unknown@unknown> Co-authored-by: Sukey <35202440+sukey2008@users.noreply.github.com> Co-authored-by: axie <152680487+azukiboy@users.noreply.github.com> Co-authored-by: Luke Ma <867273263@qq.com> Co-authored-by: Emmanuel T Odeke <emmanuel@orijtech.com> Co-authored-by: 0xn4de <109149873+0xn4de@users.noreply.github.com> Co-authored-by: hattizai <150505746+hattizai@users.noreply.github.com> Co-authored-by: Devon Bear <itsdevbear@berachain.com> Co-authored-by: Marko <marko@baricevic.me> Co-authored-by: Halimao <1065621723@qq.com> Co-authored-by: Cosmos SDK <113218068+github-prbot@users.noreply.github.com> Co-authored-by: github-merge-queue <github-merge-queue@users.noreply.github.com> Co-authored-by: Facundo <facundomedica@gmail.com> Co-authored-by: Likhita Polavarapu <78951027+likhita-809@users.noreply.github.com>
Description
replay-attack protection without using nonce.
rendered
ref: #13009
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
make lint
andmake test
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking changeSummary by CodeRabbit
Summary by CodeRabbit