Fast USDC transactions (operational) dashboard #10598
Comments
This was referenced Dec 14, 2024
Merged
mergify bot
added a commit
that referenced
this issue
Dec 17, 2024
refs: #10598 ## Description The dashboard will requires data for each transaction. In the course of designing that we explored how to design the storage node paths without creating too much cost in IAVL. (The data in HEAD carry a burden of magnitude O(k+v) for all network nodes (including non-validators) into perpetuity.) Examining [the trade-offs](https://alpha.decidedly.co/d/b27cbb6a-df71-4136-aa27-3e947015e84b/view) we arrived at: - store one node per transaction - push all changes through it - rely on indexer to demux - delete on demand - when we have [an API for block-safe deletion](#7405) it can delete in the operation - until then keep track of what to delete - a core-eval can be run to cull data whenever necessary ### Security Considerations none ### Scaling Considerations One storage path per transaction, which persists until the deletion job is called. One entry in a set to keep track of transactions to delete. ### Documentation Considerations Not developer facing ### Testing Considerations CI ### Upgrade Considerations not yet deployed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the Problem Being Solved?
Users of the Fast USDC product need to be able to see the state of transactions.
Description of the Design
Users:
Requires an indexing server
Tasks
Security Considerations
Scaling Considerations
Test Plan
Upgrade Considerations
The text was updated successfully, but these errors were encountered: