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.
Preview 10 Release Notes
This Preview outlines a foundation for State Expiration on the Soroban platform.
XDR Changes
Significant changes have happened in the way that authorization trees are defined for contract invocations. This should be covered by transaction simulation, but you can view stellar/js-stellar-base#633 and stellar/js-stellar-base#634 for details and diffs around the changes.
Breaking Changes
Server.getContractData
method now takes an optional parameter of a new type,Durability
, representing the "keyspace" of the contract data. It should be set to eitherDurability.Persistent
(the default) orDurability.Temporary
, depending on the type of storage that backs this particular piece of data.Operation.invokeHostFunction
method now takes afunc
parameter that should be anxdr.HostFunction
instead of anargs
parameter.Operation.invokeHostFunctions
method has been removed because multiple host function invocations in a single operation are no longer supported.New Operations
Operation.bumpFootprintExpiration({ ledgersToExpire: number })
bumps the expiration all of the read and written ledger keys in the transaction'ssorobanData
by the specified number of ledgersOperation.restoreFootprint()
uses the transaction'ssorobanData
field to restore the entire footprintServer.prepareTransaction
now incorporates simulation results containing the newBumpFootprintExpirationOp
s andRestoreFootprintOp
s as part ofassembleTransaction
.New Features
We've made an effort to improve the abstractions around dealing with smart contract values (
xdr.ScVal
). There are a handful of new helpful interfaces to make dealing with them easier:Large Integers
"Large" integers (e.g. 64, 128, and 256-bit values) and their
ScVal
equivalents (for passing to rawOperation.invokeHostOperation
structures, toContract.call(...)
invocations, or as part of the authorization framework) can now easily be crafted fromstring
s orbigint
s.You should never need to deal with bitwise operations or endianness again!
This is accomplished via the following APIs:
The interfaces should be pretty self-explanatory, but you can refer to the documentation for details and example usage. To keep it simple, you can do:
Here,
scv
is anxdr.ScVal
with theU128
type. Similarly, you can get the integer back out:Native Conversions
There are also new abstractions to easily convert between native JavaScript types and
xdr.ScVal
s. Since they are new and very high-level, they try to make reasonable assumptions about what you hope to accomplish.You should never need to deal with converting basic (and nested basic) types to and from XDR smart contract values (
ScVal
s)!The APIs are:
The documentation has details on each conversion and what types of conversions you can force via options, but here's some simple examples:
It handles most of the
ScVal
types you will see in high-level contexts and even handles nested types.