Add provisory blockhash lifetime helpers #519
Open
Conversation
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
🦋 Changeset detectedLatest commit: 2df5868 The changes in this PR will be included in the next version bump. This PR includes changesets to release 40 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
BundleMonFiles updated (4)
Unchanged files (123)
Total files change +629B +0.18% Final result: ✅ View report in BundleMon website ➡️ |
lorisleiva
requested review from
steveluscher and
mcintyre94
and removed request for
steveluscher
|
Documentation Preview: https://kit-docs-me4rb4en8-anza-tech.vercel.app |
steveluscher
requested changes
Jun 5, 2025
There was a problem hiding this comment.
Provisory. Such a British word to use. I love it.
So, hang on, instead of introducing the concept of a placeholder lifetime, isn't the right thing to do to relax the requirements of functions that don't really require one?
getComputeUnitEstimateForTransactionMessagecould stop requiring the message to satisfyTransactionMessageWithLifetimecompileTransactionMessagecould add an overload that:- produces
CompiledTransactionwhen the input message does not satisfyTransactionMessageWithLifetime - produces
CompiledTransaction & CompiledTransactionWithLifetimewhen the input message satisfiesTransactionMessageWithLifetime
- produces
Rpc::simulateTransactioncould continue not to care, because it just takes inBase58EncodedBytescompileTransactioncould continue requiring as input the more strictCompilableTransactionMessage & TransactionMessageWithLifetimebecause there's still no good use case for marrying a transaction message that has no valid lifetime with a signature.
|
@steveluscher That is a good point. The only thing is the whole instruction plan machinery relies on the |
|
Show me a short example; I bet I can make it work. |
|
Hmm extracting a small example of this API is tricky but essentially
I believe we can change all of these to use a looser |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR adds the following items to the
transaction-messagespackage:PROVISORY_BLOCKHASH_LIFETIME_CONSTRAINTconstant. It defines an invalid but temporary blockhash lifetime constraint that can be used for a variety of applications such as: simulating a transaction before setting its actual blockhash, calculating the size of the transaction message, etc.setTransactionMessageLifetimeUsingProvisoryBlockhashfunction that simply sets the blockhash lifetime constraint using thePROVISORY_BLOCKHASH_LIFETIME_CONSTRAINT.fillMissingTransactionMessageLifetimeUsingProvisoryBlockhashfunction that only sets the provisory blockhash if and only if the provided transaction message does not already have a set lifetime constraint.Note that this is currently used by the Compute Budget client and will be required for Instruction Plans.