-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
R4R: Enforce block maximum gas limit in DeliverTx #2795
Conversation
Cleanup needs to be done as this broke some other tests, but it appears the mechanism works as expected :) |
Codecov Report
@@ Coverage Diff @@
## develop #2795 +/- ##
===========================================
+ Coverage 56.84% 56.88% +0.03%
===========================================
Files 120 120
Lines 8298 8340 +42
===========================================
+ Hits 4717 4744 +27
- Misses 3263 3275 +12
- Partials 318 321 +3 |
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 think there's still a bug in gas handling, and I'm not sure why we need to store consensusParams
.
Also looks like test_lint
on CI still fails.
baseapp/baseapp.go
Outdated
@@ -629,6 +702,12 @@ func (app *BaseApp) runTx(mode runTxMode, txBytes []byte, tx sdk.Tx) (result sdk | |||
} | |||
} | |||
|
|||
// consume block gas whether panic or not. |
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.
What happens if this panics again? Won't DeliverTx
panic, whereas we want to just return an error?
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.
What would specifically panic again?
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 ConsumeGas
call in the recover handler here.
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 this panics it will be caught by the recover (just above this comment) - this comment simply notes that even if this consume gas panics, it will still affect the state of the BlockGasMeter which is important for ignoring future transactions... updating this comment to reflect this
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.
No, it won't. I've added a demonstrative failing testcase: 2d3e1af.
Run go test ./baseapp/... -v
, it panics with:
panic: (types.ErrorOutOfGas) (0xd2f3e0,0xc000909320) [recovered]
panic: (types.ErrorOutOfGas) (0xd2f3e0,0xc000909320)
goroutine 58 [running]:
testing.tRunner.func1(0xc000183100)
/usr/lib/go/src/testing/testing.go:792 +0x387
panic(0xd2f3e0, 0xc000909320)
/usr/lib/go/src/runtime/panic.go:513 +0x1b9
github.com/cosmos/cosmos-sdk/types.(*basicGasMeter).ConsumeGas(0xc00090dc00, 0x9, 0xe25a9f, 0xf)
/home/cwgoes/working/go/src/github.com/cosmos/cosmos-sdk/types/gas.go:82 +0xab
github.com/cosmos/cosmos-sdk/baseapp.(*BaseApp).runTx.func1(0xc000479358, 0x2, 0xc0004790f0, 0xc0004790c8)
/home/cwgoes/working/go/src/github.com/cosmos/cosmos-sdk/baseapp/baseapp.go:711 +0x33a
github.com/cosmos/cosmos-sdk/baseapp.(*BaseApp).runTx(0xc000914000, 0xc000206302, 0x0, 0x0, 0x0, 0x10396c0, 0xc0009169f0, 0x0, 0x0, 0x0, ...)
/home/cwgoes/working/go/src/github.com/cosmos/cosmos-sdk/baseapp/baseapp.go:771 +0x340
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 solid -- just a few tidbits of feedback 👍
consensusParamsBz := mainStore.Get(mainConsensusParamsKey) | ||
if consensusParamsBz != nil { | ||
var consensusParams = &abci.ConsensusParams{} | ||
err := proto.Unmarshal(consensusParamsBz, consensusParams) |
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 don't want to use a codec here?
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.
not sure @jaekwon
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.
switched to codec - Jae can switch back if there is a good reason. Otherwise yeah staying consistent makes sense
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 should be proto because abci.ConsensusParams are protobuf messages.
baseapp/baseapp.go
Outdated
@@ -629,6 +702,12 @@ func (app *BaseApp) runTx(mode runTxMode, txBytes []byte, tx sdk.Tx) (result sdk | |||
} | |||
} | |||
|
|||
// consume block gas whether panic or not. |
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.
What would specifically panic again?
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 panic/recover logic still isn't quite right, see #2795 (comment). I'd echo @alexanderbez's question on the codec.
@cwgoes addressed the panic statement |
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.
Tested ACK
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 changes LGTM from an implementation perspective. I still think there is confusion on the consensus params used in the BaseApp and the one in the context and I think a simple godoc can help remove said confusion...even if it'll be removed soon.
@@ -220,6 +241,29 @@ func (app *BaseApp) setDeliverState(header abci.Header) { | |||
} | |||
} | |||
|
|||
// setConsensusParams memoizes the consensus params. |
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 think this further alludes to the statement above. I don't see the direct relationship between these params and the ones used via the context. I think at the very least the godoc should allude to what these consensus params are for.
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.
Good question. The types/Context consensus params were never used. We don't need them in the context for now, and even if we need them we'd want to modify them via a keeper, so for now will delete types/Context.ConsensusParams.
Reviewing... |
Co-Authored-By: jaekwon <[email protected]>
@cwgoes we need to store consensusParams because it's provided by InitChain, and never provided again, yet we need it for per-block max gas even upon app restart. |
LGTM now. |
// TODO move this in the future to baseapp param store on main store. | ||
consensusParams *abci.ConsensusParams | ||
|
||
// spam prevention |
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.
probably good to indicate that its local spam prevention, not consensus
Closes #2775
docs/
)PENDING.md
with issue #Files changed
in the github PR explorerFor Admin Use: