123
stellar-core is the reference implementation for the peer to peer agent that manages the Stellar network
Events
Update for state-expiration XDR changes (#263)
Update for state-expiration XDR changes
Regenerate for https://github.com/stellar/stellar-xdr/pull/93
Update for state-expiration XDR changes
Regenerate for https://github.com/stellar/stellar-xdr/pull/93
services/horizon: Reenable SAC integration tests
I am blocked on this one, transferWithAmount() causes a function trap in the contract invocation submission which I don't know how to debug.
services/horizon: optionally add soroban-rpc to integration tests
This PR contains the additional infrastructural work I have had to do in order to make progress on https://github.com/stellar/go/pull/4891
services/horizon: Reenable SAC integration tests
Close #4883
guard my fee bump endpoint
[ANCHOR-311] Remove host_url and review usages of web_auth_domain
Reference Server Preview is available here:https://anchor-ref-pr918.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr918.previews.kube001.services.stellar-ops.com/
[ANCHOR-311] Remove host_url and review usages of web_auth_domain
Reference Server Preview is available here:https://anchor-ref-pr918.previews.kube001.services.stellar-ops.com/SEP Server Preview is available here:https://anchor-sep-pr918.previews.kube001.services.stellar-ops.com/
Make dealing with large `ScVal` integers easier.
A few notes:
-
BigIntegeris not the best naming choice because it resembles JS nativeBigInt. This may cause a confusion.ScInt,BigIntWrapper,GenericInt, or something similar might be a better option. - Automatic int size detection using
nearestInt()method will cause problems. Need to provide the int type explicitly in the constructor (preferably, as the first argument), otherwise there always will be confusion between signed/unsigned and size. E.g.sdk.BigInteger([1n, 1n])will always return ani64value if I don't provide the type. Again,hasSignedPartsdetection is wrong, lower parts of unsigned ints may be encoded with negative values (because of the u32->i32 overflow handling), for example,sdk.BigInteger([-1, 1])corresponds to a validu64value8589934591. -
MAX_64andMAX_128constants are wrong (especially,MAX_128, because it's in factMAX_28). They are different for signed/unsigned values. If you intend to use them only as masks for int parts conversion, then it's ok. But they shouldn't be used for any boundary checks without explicit sign specified. I, personally, like hex notation for such masks.0xffffffffffffffffffffffffffffffffnlooks much cleaner to me than(1n << 128n) - 1n, and it can be used directly, without precalculation and storing in theconstvariable. However, that's just personal preferences, not a hard requirement. - It would be nice to have several standard methods to simplify logging and manipulation.
valueOf() {return this.raw.valueOf()}
toString() {return this.raw.toString()}
toJSON() {return this.toString()}
graydon push stellar/wasmi
Move workflow files from "soroban-wasmi-v.16" branch over
Rename crate to reflect fork, update README, add Makefile
Capture and surface parsed custom sections in modules.
Access and reset fuel amounts
Add memory fuel metering
Add memory fuel metering
Access and set FuelCosts
State expiration (#93)
-
Adds support for state expiration
-
Cleanup and refactoring
-
Added rent fees and revert footprint changes
-
Get rid of floating point math for rent fees
-
Add changes for env
-
Adapt names to recent consensus on state expiration terminology
-
Add state expiration related entries to LedgerCloseMeta as v2
-
Move extension point to front of structure.
Co-authored-by: Graydon Hoare graydon@pobox.com Co-authored-by: Siddharth Suresh siddharth@stellar.org
