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
The integration work of the first version of UTxO-HD with db-sync was intended to avoid using tables and just carrying an EmptyMK ledger state all over the execution, with the full UTxO set inside, just as before UTxO-HD.
However, it turns out that our API is too restrictive as it requires ValuesMK for ticking and applying blocks, which will then be stowed. It is perfectly fine for Consensus' concerns but not for this db-sync integration as stowing/unstowing the full UTxO set duplicates the map on each step and therefore memory consumption explodes.
We should provide lower level alternatives to the tickThenReapply function that don't expect to have the tables unstowed, i.e.
Possibly this just means factoring out some of the things we do (the stowing and unstowing of values) into a separate function, something like tickThenReapplyWithTables or some such, to get:
db-sync has a half-working integration which uses ouroboros-network at ea8f657533b64ad3494d3695c945c8fb24c6a0f1.
I think we should just start a branch there and do whatever we need to do to provide this API, but even maybe only in the packages needed by db-sync, to not get into trouble fighting the tests, as this is exploratory integration work. In particular db-sync uses:
ouroboros-consensus
ouroboros-consensus-diffusion
ouroboros-consensus-protocol
ouroboros-consensus-byron
ouroboros-consensus-shelley
ouroboros-consensus-cardano
The text was updated successfully, but these errors were encountered:
The integration work of the first version of UTxO-HD with
db-sync
was intended to avoid using tables and just carrying an EmptyMK ledger state all over the execution, with the full UTxO set inside, just as before UTxO-HD.However, it turns out that our API is too restrictive as it requires
ValuesMK
for ticking and applying blocks, which will then be stowed. It is perfectly fine for Consensus' concerns but not for thisdb-sync
integration as stowing/unstowing the full UTxO set duplicates the map on each step and therefore memory consumption explodes.We should provide lower level alternatives to the
tickThenReapply
function that don't expect to have the tables unstowed, i.e.Possibly this just means factoring out some of the things we do (the stowing and unstowing of values) into a separate function, something like
tickThenReapplyWithTables
or some such, to get:(Probably with some
applyDiffs
in between).db-sync
has a half-working integration which usesouroboros-network
atea8f657533b64ad3494d3695c945c8fb24c6a0f1
.I think we should just start a branch there and do whatever we need to do to provide this API, but even maybe only in the packages needed by db-sync, to not get into trouble fighting the tests, as this is exploratory integration work. In particular
db-sync
uses:The text was updated successfully, but these errors were encountered: