Warning
Internal Breaking-Change
This release internally reworks the output_reference
column of the inputs
table.
There's no direct upgrade from an existing index since this requires additional information not present in the database; the only possible migration is therefore to drop the entire index and force a resync from scratch.
Added
-
📌 #25 - New pattern format to match results by transaction id or by output reference. Also added two new HTTP query parameters for filtering matches:
transaction_id
&output_index
. See more information in the 📖 API Reference.See syntax
┏━━━━━━━━━━━━━━┓ ╭───╮ ┏━━━━━━━━━━━━━━━━┓ ╾─┫ OUTPUT_INDEX ┣─┤ @ ├─┫ TRANSACTION_ID ┣─╼ ┗━━━━━━━━━━━━━━┛ ╰───╯ ┗━━━━━━━━━━━━━━━━┛
Note
Filtering is done by scanning linearly over all results, whereas matching is much faster and leverages the database's internal indexes. One can however combine filters and matches in all kind of ways. -
📌 #56 (💡 @1000101) - New pattern format to match results by policy id or asset id. Also added two new HTTP query parameters for filtering matches:
policy_id
&asset_name
. See more information in the 📖 API Reference.See syntax
┏━━━━━━━━━━━┓ ╭───╮ ┏━━━━━━━━━━━━┓ ╾─┫ POLICY_ID ┣─┤ . ├─┫ ASSET_NAME ┣─╼ ┗━━━━━━━━━━━┛ ╰───╯ ┗━━━━━━━━━━━━┛
Note
Filtering is done by scanning linearly over all results, whereas matching is much faster and leverages the database's internal indexes. One can however combine filters and matches in all kind of ways. -
📌 #51 (💡 @everestada, 💬 @bakon11) - New endpoint to retrieve transaction metadata by slot number, possibly filtered by transaction id or output reference.
GET /metadata/{slot-no}
→ 📖 API Reference
-
📌 #63 (🔨 @sorki) - Prometheus-compatible format can now be returned by
GET /health
. This occurs whenAccept: text/plain
is provided as request header. Otherwise, it defaults toapplication/json
as before. -
📌 #65 (💡 @1000101) - Added
transaction_index
to each result, referring to the index in the block of the transaction carrying the matched output. -
📌 #72 (💡 @Quantumplation) - Clients can now bulk-add many patterns at once.
PUT /patterns
→ 📖 API Reference
-
New command-line flag
--defer-db-indexes
to be given during the very first synchronization to postpone the creation of some non-essential database indexes. Non-essential refers to indexes that are needed to speed up some queries (e.g. querying by payment credentials) but that do not play a role in synchronization. In fact, maintaining such indexes during synchronizations (millions of blocks) adds a lot of unnecessary overhead. Indexes can be created after the facts in a couple of minutes on a standard laptop. This flag therefore comes in handy to speed up an initial synchronization. Once synchronized, the server can be restarted without the flag to automatically create the necessary indexes. -
The server now makes use of an internal resource pool when it comes to database connections. This pool can be configured using a new command-line option
--max-concurrency
. Users running an instance of Kupo on a capable machine (e.g. 32-cores) may want to increase the default of 50.
Changed
-
📌 #65 (💡 @1000101) - Results are now ordered by descending slots, transaction index and output index by default. They used to be ordered by descending slot number only; and then arbitrarily ordered from within a same slot. The order is now fully stable.
-
📌 #58 (💡 @nielstron) - Improved performances of query by payment credentials from linear times to logarithmic times. Most patterns now benefits from database indexes and are blazing fast.
-
(🔨 @mmahut, @1000101) Tuned various runtime and internal parameters to optimize query performances. The indexer now makes better use of available machine resources -- in particular CPU.
-
Request log messages of the HTTP servers have been split in two; the server is now logging request and responses independently with the time taken to process the response as part of the log message.
-
The server now returns an error
503 Service Unavailable
when too many requests are pilling up. Note that the server can handle a relatively heavy load for most patterns but, for large addresses (such as the contract addresses of big marketplaces or DEXes), a single query can take a few seconds. If the server has exhausted all its available resources to serve additional requests, it'll fail gracefully with an error503
and let the client handle requeuing of the request if necessary.
Removed
-
stack
is no longer supported as a development tool / build option. -
(🐛 @Quantumplation) A bug in the
PUT /patterns/{pattern-fragment}
endpoint which would cause the server to take a very long time to reply when already synchronized. Adding a pattern is now instantenous when connected through Ogmios and effective as soon as a next block is visible when connected through cardano-node.
Benchmarks
See benchmarks.
Snapshots
In the release artifacts, you can find two snapshots (kupo.sqlite3-{testnet, mainnet}.tar.gz
). These snapshots were obtained from the following options:
--match *
--since origin
--prune-utxo
They can be used as starting points to get started quickly. Note that the mainnet archive is split in two parts; the original archive can be recovered as such:
❯ cat kupo.sqlite3-mainnet.tar.gz.part_* > kupo.sqlite3-mainnet.tar.gz
Then, verify the archive's integrity using md5
, it should match the checksum below:
❯ md5 kupo.sqlite3-mainnet.tar.gz
MD5 (kupo.sqlite3-mainnet.tar.gz) = a869ce18da5e028d80d9ad6d40f20897
Dependencies
Dependency | Tested With |
---|---|
cardano-node | 1.35.x |
ogmios | v5.5.x |