-
Notifications
You must be signed in to change notification settings - Fork 126
fix: reject duplicate accounts between static keys and ALT #564
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
Merged
+130
−4
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back 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.
Are we sure
SimulationFailureis the correct error here? What if simulation is disabled? (skip_preflight = true)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 success, and the transaction is not executing at this point. We could introduce a new enum but it seems overkill.
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 I'm saying I think to better match with what a node would return, if
skip_preflight = truewe return anExecutionFailure- because we're not simulating the node would (I believe) return with the same error but while actually executing the transaction. Vs ifskip_preflight = false, on a real node you'd be simulating and you'd return aSimulationFailureThere 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 check is pre-execution / pre-simulation, and since the transaction is not executed (0 CU), simulation seems to be the least worst to me.
Neither of these variant are semantically correct: with the approach you're suggesting (
ExecutionFailure), if we use the simulation rpc endpoint and hit that code-path, we'd be returning anexecutionerror.I honestly don't think it's a big deal as this enum is not exposed anyway in the RPC response.
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's not true. The
send_transactionRPC method recives thisTransactionStatusEventand reacts differently according to the variant.VerificationFailurehas no data on the final error and just has a message.SimulationErrorreturns aRpcSimulateTransactionResulton the data of the error.ExecutionFailureis completely ignored - it's processed by the VM and the user would need to fetch the transaction by signature to see the error.So perhaps your point is shining light on that we're further deviating from how mainnet would actually handle - if you skip the simulation on mainnet do you get the same error contents ("Account loaded twice") but during execution? Why isn't LiteSVM returning the correct error in the first place.
This is feeling more like a bandaid rather than a fix -perhaps this should be at the LiteSVM level.
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.
Agreed - what I'm saying is that on mainnet this check isn't pre-execution/pre-simulation - so how can we have surfpool either behave the same way or appear to behave the same way
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.
Wdym? it has nothing to do with mainnet / devnet, it's a client implementation detail.
With this patch, behavior Agave and Surfpool are identical - as explained in the description, the PR was built with a test vector Surfpool / Agave.
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 just noticed this in the PR description:
Would fixing that root cause allow LiteSVM to return the correct 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.
LiteSVM should not be involved at all.