Releases: stellar/go
Horizon v2.18.0
Upgrading to this version from <= v2.8.3 will trigger a state rebuild. During this process (which will take at least 10 minutes), Horizon will not ingest new ledgers.
New features
-
New Experimental Ingestion Filters Feature: Provide the ability to select which ledger transactions are accepted at ingestion time to be stored on horizon's historical databse.
Define filter rules through Admin API and the historical ingestion process will check the rules and only persist the ledger transactions that pass the filter rules. Initially, two filters and corresponding rules are possible:
The filters and their configuration are optional features and must be enabled with horizon command line parameters
admin-port=4200
andenable-ingestion-filtering=true
Once set, filter configurations and their rules are initially empty and the filters are disabled by default. To enable filters, update the configuration settings, refer to the Admin API Docs which are published on the Admin Port at http://localhost:<admin_port>/, follow details and examples for endpoints:
/ingestion/filters/account
/ingestion/filters/asset.
- Added
disable-path-finding
Horizon flag to disable the path finding endpoints. This flag should be enabled on ingesting Horizon instances which do not serve HTTP traffic (4399).
Performance improvements
- Querying claimable balances has been optimized (4385).
- Querying trade aggregations has been optimized (4389).
Fixes
- Postgres connections for non ingesting Horizon instances are now configured to timeout on long running queries / transactions (4390).
DB Schema Migration
The migration makes the following schema changes:
- adds new tables:
account_filter_rules
,asset_filter_rules
andtxsub_results
This migration will execute quickly.
Horizon v2.17.1
Performance tuning focused release.
- Querying claimable balances has been optimized (4385).
- Querying trade aggregations has been optimized (4389).
- Postgres connections for non ingesting Horizon instances are now configured to timeout on long running queries / transactions (4390).
- Added
disable-path-finding
Horizon flag to disable the path finding endpoints. This flag should be enabled on ingesting Horizon instances which do not serve HTTP traffic (4399).
Horizon v2.17.0
This is a promotion of the v2.17.0 release candidate with two additional changes. The following changelog summarizes changes since the last stable version, v2.16.1.
Upgrading to this version from <= v2.8.3 will trigger a state rebuild. During this process (which will take at least 10 minutes), Horizon will not ingest new ledgers.
New features
Support for Protocol 19 (4340):
- Account records can now contain two new, optional fields:
"sequence_ledger": 0, // uint32 ledger number
"sequence_time": "0" // uint64 unix time in seconds, as a string
The absence of these fields indicates that the account hasn't taken any actions since prior to the Protocol 19 release. Note that they'll either be both present or both absent.
- Transaction records can now contain the following optional object:
"preconditions": {
"timebounds": {
"min_time": "0", // uint64 unix time in seconds, as a string
"max_time": "0" // as above
},
"ledgerbounds": {
"min_ledger": 0, // uint32 ledger number
"max_ledger": 0 // as above
},
"min_account_sequence": "0", // int64 sequence number, as a string
"min_account_sequence_age": "0", // uint64 unix time in seconds, as a string
"min_account_sequence_ledger_gap": 0, // uint32 ledger count
"extra_signers": [] // list of signers as StrKeys
}
All of the top-level fields within this object are also optional. However, the "ledgerbounds" object will always have at least its min_ledger
field set.
Note that the existing "valid_before_time" and "valid_after_time" fields on the top-level object will be identical in value to the "preconditions.timebounds.min_time" and "preconditions.timebounds.min_time" fields, respectively, if those exist. The "valid_before_time" and "valid_after_time" fields are now considered deprecated and will be removed in Horizon v3.0.0.
DB Schema Migration
The migration makes the following schema changes:
- adds new, optional columns to the
history_transactions
table related to the new preconditions - adds new, optional columns to the
accounts
table related to the new account extension - amends the
signer
column of theaccounts_signers
table to allow signers of arbitrary length
This migration does not back-fill, so it should execute quickly.
Deprecations
The following fields on transaction records have been deprecated and will be removed in a future version:
"valid_before"
and"valid_after"
These fields are now represented by preconditions.timebounds.min_time
and preconditions.timebounds.max_time
as strings that are int64 UNIX timestamps in seconds.
Full Diff: horizon-v2.16.1...horizon-v2.17.0
Full Changelog: services/horizon/CHANGELOG.md
Horizon v2.17.0 Release Candidate
Upgrading to this version from <= v2.8.3 will trigger a state rebuild. During this process (which will take at least 10 minutes), Horizon will not ingest new ledgers.
This Horizon release includes support for the Stellar network's upcoming Protocol 19 (4340):
- Account records can now contain two new, optional fields:
"sequence_ledger": 0, // uint32 ledger number
"sequence_time": "0" // uint64 unix time in seconds, as a string
The absence of these fields indicates that the account hasn't taken any actions since prior to the Protocol 19 release. Note that they'll either be both present or both absent.
- Transaction records can now contain the following optional object:
"preconditions": {
"timebounds": {
"min_time": "0", // uint64 unix time in seconds, as a string
"max_time": "0" // as above
},
"ledgerbounds": {
"min_ledger": 0, // uint32 ledger number
"max_ledger": 0 // as above
},
"min_account_sequence": "0", // int64 sequence number, as a string
"min_account_sequence_age": "0", // uint64 unix time in seconds, as a string
"min_account_sequence_ledger_gap": 0, // uint32 ledger count
"extra_signers": [] // list of signers as StrKeys
}
All of the top-level fields within this object are also optional. However, the "ledgerbounds" object will always have its inner values set.
Note that the existing "valid_before_time" and "valid_after_time" fields on the top-level object will be identical to the "preconditions.timebounds.min_time" and "preconditions.timebounds.min_time" fields, respectively, if those exist. The "valid_before_time" and "valid_after_time" fields are now considered deprecated and will be removed in Horizon v3.0.0.
Full Diff: horizon-v2.16.1...horizon-v2.17.0-rc1
Full Changelog: services/horizon/CHANGELOG.md
horizonclient & txnbuild v10.0.0
v10.0.0 - 2022-04-18
horizonclient
This release adds support for Protocol 19:
- The library is updated to align with breaking changes to
txnbuild
.
txnbuild
Adds support for Protocol 19 transaction preconditions (CAP-21).
Breaking changes
- There are many new ways for a transaction to be (in)valid (see the new
Preconditions
structure), and the corresponding breaking change is in how transactions are built:
tx, err := NewTransaction(TransactionParams{
SourceAccount: someAccount,
// ... other parameters ...
- Timebounds: NewTimeout(5),
+ Preconditions: Preconditions{TimeBounds: NewTimeout(5)},
})
-
Timebounds
has been renamed toTimeBounds
, though a type alias remains. -
A
*TimeBounds
structure is no longer considered valid (viaValidate()
) if it'snil
. This further reinforces the fact that transactions need timebounds.
Horizon v2.16.1
- Use Golang 1.18.1 with security fixes for CVE-2022-24675, CVE-2022-28327 and CVE-2022-27536. (4333)
Horizon v2.16.0
Horizon v2.15.1
Upgrading to this version from <= v2.8.3 will trigger a state rebuild. During this process (which will take at least 10 minutes), Horizon will not ingest new ledgers.
Fixes
- Fixed a regression preventing running multiple concurrent captive-core ingestion instances. (4251)
Horizon v2.15.0
Upgrading to this version from <= v2.8.3 will trigger a state rebuild. During this process (which will take at least 10 minutes), Horizon will not ingest new ledgers.
DB Schema Migration
- DB migrations add columns to the
history_trades
table to enable filtering trades by "rounding slippage". This is very large table so migration may take a long time (depending on your DB hardware). Please test the migrations execution time on the copy of your production DB first.
Features
- New feature, enable captive core based ingestion to use remote db persistence rather than in-memory for ledger states. Essentially moves what would have been stored in RAM to the external db instead. Recent profiling on the two approaches shows an approximate space usgae of about 8GB for ledger states as of 02/2022 timeframe, but it will gradually continue to increase as more accounts/assets are added to network. Current horizon ingest behavior when configured for captive core usage will by default take this space from RAM, unless a new command line flag is specified
--captive-core-use-db=true
, which enables this space to be taken from the external db instead, and not RAM. The external db used is determined be settingDATABASE
parameter in the captive core cfg/.toml file. If no value is set, then by default it uses sqlite and the db file is stored in--captive-core-storage-path
- (4092)
Fixes
- Exclude trades with high "rounding slippage" from
/trade_aggregations
endpoint. (4178)- Note, to apply this change retroactively to existing data you will need to reingest starting from protocol 18 (ledger
38115806
).
- Note, to apply this change retroactively to existing data you will need to reingest starting from protocol 18 (ledger
- Release DB connection in
/paths
when no longer needed. (4228) - Fixed false positive warning during orderbook verification in the horizon log output whenever the in memory orderbook is inconsistent with the postgres liquidity pool and offers table. (4236)