You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The BlockStorage backend that handles persistence of synced blocks (and is used to provide orphaned blocks during re-orgs) is very tightly coupled to Data API validation. It includes (in addition to block persistence) hash persistence (transaction hash duplicate checks) and balance tracking.
To support automated Construction API testing, we also need to make use of a block persistence layer but don't want or need any of the additional balance tracking logic. We may also want to add more modules to the block syncing loop and don't want to continue overloading this extraction (like tracking UTXOs).
Describe the solution you'd like
I propose:
greatly simplifying the BlockStorage interface (just to handle the storage/retrieval of blocks and keeping track of sync progress across restarts)
adding a new package called StatefulSyncer that exposes the same Handler interface as the syncer package (except that BlockRemoved returns the actual block removed instead of just the identifier)
adding a new BalanceStorage backend that contains all balance tracking logic formerly in BlockStorage
adding a new tx querying functionality that allows for querying for the existence of certain hashes (and hashes at a certain depth)
adding a utils.go file that contains all common encoding/decoding logic in /internal/storage
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The
BlockStorage
backend that handles persistence of synced blocks (and is used to provide orphaned blocks during re-orgs) is very tightly coupled toData API
validation. It includes (in addition to block persistence) hash persistence (transaction hash duplicate checks) and balance tracking.To support automated
Construction API
testing, we also need to make use of a block persistence layer but don't want or need any of the additional balance tracking logic. We may also want to add more modules to the block syncing loop and don't want to continue overloading this extraction (like trackingUTXOs
).Describe the solution you'd like
I propose:
BlockStorage
interface (just to handle the storage/retrieval of blocks and keeping track of sync progress across restarts)StatefulSyncer
that exposes the sameHandler
interface as thesyncer
package (except thatBlockRemoved
returns the actual block removed instead of just the identifier)BalanceStorage
backend that contains all balance tracking logic formerly inBlockStorage
utils.go
file that contains all common encoding/decoding logic in/internal/storage
The text was updated successfully, but these errors were encountered: