Open euonymos opened 1 week ago
Blocks L2 effect, which is now represented as a new set of utxos to be put in the ledger (utxosActive), can be optimized too. Though this can be done separately, it seems reasonable to piggyback it onto the copy-on-write implementation.
Yup. Here's the update rule for a block's L2 effect on utxosActiveConfirmed
:
utxosActiveConfirmed <-
(utxosActiveConfirmed ∪ utxosAddedTxs ∪ utxosDeposited) \
(utxosSpentTxs ∪ utxosWithdrawn)
Invariant (since every L2 genesis event comes after its block's eventsValid
):
∅ = utxosDeposited ∩ (utxosSpentTxs ∪ utxosWithdrawn)
So we can also write:
utxosActiveConfirmed <- utxosDeposited ∪
( (utxosActiveConfirmed ∪ utxosAddedTxs) \
(utxosSpentTxs ∪ utxosWithdrawn)
)
Instead of cloning L2 ledger for block creation/validation purposes, "copy on write" optimization looks appealing. The idea is described by @GeorgeFlerovsky here.
Blocks L2 effect, which is now represented as a new set of utxos to be put in the ledger (
utxosActive
), can be optimized too. Though this can be done separately, it seems reasonable to piggyback it onto the copy-on-write implementation.