This is a draft for implementing another step of #4358, particularly the transactions query system.
As discussed previously this is an optional endpoint useful for implementers of services/abstraction apis that can be enabled with the already available STACKS_TRANSACTION_LOG environment variable.
The current transaction log system is based on storing each transaction in the "transactions" table of the index db. Each row contains the txid, the index_block_hash and the hex encoded body of the transaction. It means in the current form it requires a lot of storage and lot of transactions are basically orphaned ones.
The patch covers the first issue related to "testability", as the TRANSACTION_LOG value holding the status of the STACKS_TRANSACTION_LOG env var is a static per-process one. When in test mode TRANSACTION_LOG become a thread_local (instead of lazy_static) with the idea of each test requiring it calls borrow_mut() for setting it.
There is a bit of refactoring in the TRANSACTION_LOG check as now it is overlayed by an is_transaction_log_enabled() function. Should not be an issue as this will be inlined when in non-test mode.
It is not necessarily "the best" solution but only a surgical way for not thrashing the current code.
It is important that every test using it restores the original condition, so i have used a Drop-trait structure for keeping the state (i do not know how much rust-idiomatic it is honestly).
The user queries by txid, so one of the main task of the endpoint is to check for the txid with a valid index_block_hash. Right now the implementation is just a placeholder as I need to manage forks too by allowing the user to specify an optional tip (and check for it too in the MARF).
TODO:
makes the system fork-friendly
early-exit in the endpoint if transaction_log is not enabled
Applicable issues
fixes #4358
Additional info (benefits, drawbacks, caveats)
Currently the body of the transaction is extracted from the nakamoto staging db instead of the transactions table. This is definitely inefficient but i did it with the idea that probably we could remove the tx body itself from the transactions table (drastically reducing the size required for it, especially because i am really doubtful it will be useful to query invalid/orphaned transactions and the query of the mempool is already exposed by the /unconfirmed endpoint)
As an additional point, we could even reduce the impact of the patch by just returning the index_block_hash in the endpoint output instead of the whole body of the transaction (the tx body extraction can happen with an additional /v3/blocks query). Right now a json with the index_block_hash and the body is returned.
Checklist
[ ] Test coverage for new or modified code paths
[ ] Changelog is updated
[ ] Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
[ ] New clarity functions have corresponding PR in clarity-benchmarking repo
[ ] New integration test(s) added to bitcoin-tests.yml
Description
This is a draft for implementing another step of #4358, particularly the transactions query system.
As discussed previously this is an optional endpoint useful for implementers of services/abstraction apis that can be enabled with the already available STACKS_TRANSACTION_LOG environment variable.
The current transaction log system is based on storing each transaction in the "transactions" table of the index db. Each row contains the txid, the index_block_hash and the hex encoded body of the transaction. It means in the current form it requires a lot of storage and lot of transactions are basically orphaned ones.
The patch covers the first issue related to "testability", as the TRANSACTION_LOG value holding the status of the STACKS_TRANSACTION_LOG env var is a static per-process one. When in test mode TRANSACTION_LOG become a thread_local (instead of lazy_static) with the idea of each test requiring it calls borrow_mut() for setting it.
There is a bit of refactoring in the TRANSACTION_LOG check as now it is overlayed by an is_transaction_log_enabled() function. Should not be an issue as this will be inlined when in non-test mode.
It is not necessarily "the best" solution but only a surgical way for not thrashing the current code.
It is important that every test using it restores the original condition, so i have used a Drop-trait structure for keeping the state (i do not know how much rust-idiomatic it is honestly).
The user queries by txid, so one of the main task of the endpoint is to check for the txid with a valid index_block_hash. Right now the implementation is just a placeholder as I need to manage forks too by allowing the user to specify an optional tip (and check for it too in the MARF).
TODO:
Applicable issues
Additional info (benefits, drawbacks, caveats)
Currently the body of the transaction is extracted from the nakamoto staging db instead of the transactions table. This is definitely inefficient but i did it with the idea that probably we could remove the tx body itself from the transactions table (drastically reducing the size required for it, especially because i am really doubtful it will be useful to query invalid/orphaned transactions and the query of the mempool is already exposed by the /unconfirmed endpoint)
As an additional point, we could even reduce the impact of the patch by just returning the index_block_hash in the endpoint output instead of the whole body of the transaction (the tx body extraction can happen with an additional /v3/blocks query). Right now a json with the index_block_hash and the body is returned.
Checklist
docs/rpc/openapi.yamlandrpc-endpoints.mdfor v2 endpoints,event-dispatcher.mdfor new events)clarity-benchmarkingrepobitcoin-tests.yml