Skip to content
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

[CORE-538] Apply dYdX patches to Cosmos SDK 0.50.1 fork #30

Merged
merged 10 commits into from
Dec 6, 2023

Conversation

lcwik
Copy link

@lcwik lcwik commented Dec 4, 2023

Description

Apply dYdX patches to Cosmos SDK 0.50.1 fork


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...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

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...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

Copy link

github-actions bot commented Dec 4, 2023

@lcwik your pull request is missing a changelog!

@lcwik lcwik force-pushed the lukecore538 branch 2 times, most recently from 5f8013b to 21e77b6 Compare December 4, 2023 20:27
@lcwik lcwik changed the title Apply dYdX patches to Cosmos SDK 0.50.1 fork [CORE-538] Apply dYdX patches to Cosmos SDK 0.50.1 fork Dec 4, 2023
Copy link

linear bot commented Dec 4, 2023

This change pushes the mutex that was in the local client to the top level of the ABCI methods and uses the unsynchronized local client. A future change is intended to reduce the critical sections of the various ABCI methods.

We also replace cometbft usage with dYdX fork.
@@ -184,6 +186,9 @@ type BaseApp struct {
// including the goroutine handling.This is experimental and must be enabled
// by developers.
optimisticExec *oe.OptimisticExecution

// Used to synchronize the application when using an unsynchronized ABCI++ client.
mtx sync.Mutex
Copy link

@teddyding teddyding Dec 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question on DeliverTx:

I see that on v0.47 fork we take the app.mtx lock

cosmos-sdk/baseapp/abci.go

Lines 418 to 429 in bdf96fd

func (app *BaseApp) DeliverTx(req abci.RequestDeliverTx) (res abci.ResponseDeliverTx) {
return app.DeliverTxShouldLock(req, true)
}
// DeliverTxShouldLock enables control of whether the lock should be acquired. The golang mutex
// is not reentrant so we enable conditional locking to prevent deadlock since cosmos-sdk/x/genutil.InitGenesis
// invokes DeliverTx from the ABCI++ InitGenesis method which already holds the lock.
func (app *BaseApp) DeliverTxShouldLock(req abci.RequestDeliverTx, needsLock bool) (res abci.ResponseDeliverTx) {
if needsLock {
app.mtx.Lock()
defer app.mtx.Unlock()
}
in DeliverTx. How has this changed in v0.50? This is the corresponding deliverTx function - is it intended to not take the lock?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cosmos was re-entrant when delivering txs during block commit which is why we needed the ability to selectively take the lock. CometBFT pushed down block commit logic of individually calling DeliverTx into FinalizeBlock which means that we could elevate the need for acquiring the lock to FinalizeBlock removing it from deliverTx which also meant that we didn't care any more that Cosmos was re-entrant for this method or not.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the explanation. I see from here tha BeginBlock, DeliverTx, and EndBlock are coalesced into FinalizeBlock

@@ -901,6 +937,9 @@ func (app *BaseApp) checkHalt(height int64, time time.Time) error {
// against that height and gracefully halt if it matches the latest committed
// height.
func (app *BaseApp) Commit() (*abci.ResponseCommit, error) {
app.mtx.Lock()
defer app.mtx.Unlock()

header := app.finalizeBlockState.ctx.BlockHeader()
retainHeight := app.GetBlockRetentionHeight(header.Height)

Copy link

@teddyding teddyding Dec 6, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: do we still need the commiter logic from here? Or is that replaced by the prepareCheckStater below?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is replaced by prepareCheckStater which @prettymuchbryce pushed upstream as the replacement for the committer logic.


return gInfo, result, anteEvents, err
}

// runTx processes a transaction within a given execution mode, encoded transaction
// bytes, and the decoded transaction itself. All state transitions occur through
// a cached Context depending on the mode provided. State only gets persisted

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question for runTx() below: do we still need these checks?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, added it back and updated the [STAB-19] Reduce the size of the critical section commit to contain it to keep the history clean.

@teddyding
Copy link

To confirm, do we still need to port over these changes from the v0.47 fork?

@teddyding
Copy link

For my understanding, how do we plan to test the upgrade from v0.47 fork to v0.50 fork? Involves a lot of changes all over the places, and it seems easy to miss something to port over.

@lcwik
Copy link
Author

lcwik commented Dec 6, 2023

To confirm, do we still need to port over these changes from the v0.47 fork?

Just added these now to this PR.

@lcwik
Copy link
Author

lcwik commented Dec 6, 2023

For my understanding, how do we plan to test the upgrade from v0.47 fork to v0.50 fork? Involves a lot of changes all over the places, and it seems easy to miss something to port over.

This is TBD, my thoughts around this are:

  • ensure existing unit tests pass
  • deploy to dev to ensure it continues to run
  • perform upgrade testing (either using the upgrade test framework if it exists or performing upgrades in a persistent environment (dev/staging/testnet))

lcwik and others added 3 commits December 6, 2023 09:49
This change makes a copy of `runTx` and does the following:
* moves transaction descoding and tx validation before lock acquisition
* moves creation of the response after releasing the lock
* removes support for the post handler (unused by dYdX) and extracts out the only code that is executed in `runMsgs` allowing us to avoid the creation of the `runMsgCtx` and its associated `MultiStore`
* removes `consumeBlockGas` since it is only executed during `deliverTx`
@lcwik
Copy link
Author

lcwik commented Dec 6, 2023

I was able to add the last of the remaining commits.

I flattened these two commits together (5402055, b95c66d).

And the CLOB-930 commit was able to be simplified a bunch because of changes that were released in 0.50 (cosmos#15041).

@lcwik lcwik merged commit 2768f92 into dydx-fork-v0.50.1 Dec 6, 2023
38 of 40 checks passed
@lcwik lcwik deleted the lukecore538 branch December 6, 2023 19:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants