-
Notifications
You must be signed in to change notification settings - Fork 12
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
Validate transactions against local mempool state #338
Conversation
1bac240
to
2ca2725
Compare
d9d70d0
to
cff3d44
Compare
pkg/abci/abci.go
Outdated
@@ -184,12 +205,72 @@ func (a *AbciApp) CheckTx(incoming abciTypes.RequestCheckTx) abciTypes.ResponseC | |||
zap.String("sender", hex.EncodeToString(tx.Sender)), | |||
zap.String("PayloadType", tx.Body.PayloadType.String())) | |||
|
|||
err = tx.Verify() | |||
a.mempoolState.mu.Lock() | |||
defer a.mempoolState.mu.Unlock() |
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.
I'm trying to think of a way to better abstract this. The other place that the mempool state gets locked is abstracted by a mempoolState
method. I'd love to figure out how to do the same thing here, but I think it would require a larger change to better abstract mempool
Still thinking a bit more, but it seems like we can maybe abstract away the mempool a bit better? This might not be possible, so if nothing comes to mind today then we will just continue as-is. But it just feels like the ABCI needs a lot of context on mempool, but mempool seems like it is really only account store specific, and could therefore be better abstracted |
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.
Just a couple quick comments that pertain to active discussions.
Still going through
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 to work as advertised, but have comments.
The one explicit panic is making me think though. Like why the method checks the map when it can just update the values in the *userAccount
that reference the map entry that we just pulled.
Some thought via hacking a diff (don't cherry-pick directly, just consider pls): ff28bad
6147f31
to
8cefede
Compare
@@ -193,33 +208,46 @@ func (a *AbciApp) BeginBlock(req abciTypes.RequestBeginBlock) abciTypes.Response | |||
func (a *AbciApp) CheckTx(incoming abciTypes.RequestCheckTx) abciTypes.ResponseCheckTx { | |||
logger := a.log.With(zap.String("stage", "ABCI CheckTx")) | |||
logger.Debug("check tx") | |||
ctx := context.Background() |
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.
Just an observation.
It seems all AbciApp.*Tx
methods, won't provide us a context through parameter, so it's really to us to manage context.
And all our abci modules methods receive Context.
So it's bit awkward to see in those AbciApp.*Tx
methods, we just created a context.Background()
context, without any kind of context management, I guess we'll add later ?
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 should manage our own contexts. Will raise an Issue on it
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.
This is another issue that goes away in cometbft v0.38. https://github.com/kwilteam/kwil-db/pull/310/files#diff-189346089c5af5194675f23ce4b8b6c0104c41948bb052ec2850be3224429481
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.
This is genuinely good, it feels right ABCI call the app with 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.
lgtm
if len(errs) > 0 { | ||
s.log.Error("errors while cancelling session", zap.Error(errors.Join(errs...))) | ||
if errs != nil { | ||
s.log.Error("errors while cancelling session", zap.Error(errs)) |
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.
OK to leave, but if you return an error you don't also log it.
if err != nil { | ||
return nil, err | ||
return resp(price), err |
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.
Why return a non-nil *ExecutionResponse
if error is non-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.
I had this doubt too, but in databases we seem to be returning execution response with tx price even during the errored scenarios. It's kinda unclear right now on the correct behavior as we don't have gas. Even with gas, what should be the tx fee on failed transactions?
a5a441f
to
236c0c5
Compare
* added extensible auth using build tags * go mod tidied * made gavins requested changes
236c0c5
to
66b164f
Compare
List of changes:
CheckTx
: Validates Tx payload, gas costs, nonces wrt local mempool stateProcessProposal()
checks for nonce ordering, gaps, duplicates, and continuity.Cancel()
calls of Committer typesGonna add integration tests, once the nonce override PR is pushed to the main.