-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce types DeltaUTxO
and DeltaWallet
#3156
Conversation
45d68f8
to
1ad4225
Compare
caf3ac8
to
7f28089
Compare
where | ||
-- As the functions in 'DeltaUTxO' are implemented in terms of set | ||
-- operations, we only have to test a Venn diagram using few elements. | ||
utxo0 = mkUTxOs ["a0","a1","a2"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this manual example as it shows the case. One case. But what about also using proper arbitrary instances showing that deltaUTxO ops works properly for different overlapping of deltas? There are many possible cases here, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The beauty of elementary statements about sets is that they can be decided by looking at truth tables, which in turn corresponds to one universal example ("Venn diagram").
For example, in order to show that the equality (A ∩ B) ∪ C = (A ∪ C) ∩ (B ∪ C)
holds for all finite sets A,B,C, it is sufficient to show that it holds for the specific choice A = { "100", "110", "101", "111"}
, B = { "010", "110", "011", "111"}
, and C = { "001", "101", "011", "111"}
. Even though the elements like "010" seem very specific, they stand for an entire set of elements; here, "010" stands for all elements that are contained in B
, but not in A
or C
.
The associativity of DeltaUTxO
is a statement of this form, assuming that all operations are implemented in terms of set-theoretic operations like Set.intersect
, which they essentially are. Hence, we can decide its validity with a single, universal example — the one in the test. This example can be visualize as follows:
In this sense, "a2" represents an entire set of outputs (suggested by the colored dots), namely the set of outputs contained in utxo0
, not spent by delta1
, but spent by delta2
. Likewise, "a0" represents the set of outputs contained in utxo0
, not spent by delta1
, and not spent by delta2
. Due to the "no double-spending" constraint, not all cases are possible; the diagram shows all the possible cases.
EDIT: I have also added a comment in the source code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm! Maybe better generation of delta overlapping could be useful here
… but do not propagate them to `WalletState` yet.
b5c23ae
to
fe24a5d
Compare
bors merge |
3156: Introduce types `DeltaUTxO` and `DeltaWallet` r=HeinrichApfelmus a=HeinrichApfelmus ### Issue number ADP-1434 ### Overview Previous work in epic ADP-1043 introduced delta encodings, DBVars, and an embedding of the wallet state and its delta encodings into a database table. It's time to integrate these tools with the wallet code. To facilitate code review, the integration proceeds in a sequence of refactorings that do not change functionality and pass all unit tests. In this step, we finally introduce the type `DeltaUTxO` which represents a delta encoding of the `UTxO` set, i.e. a package of changes that can be applied to one `UTxO` set in order to obtain another one. The type `DeltaUTxO` is abstract, but internally, it is implemented as ```hs data DeltaUTxO = DeltaUTxO { excluded :: !(Set TxIn) -- ^ First exclude these inputs , received :: !UTxO -- ^ Then receive these additional outputs. } ``` i.e. it stores a set of `TxIn` that was spent, and a `UTxO` that was received. Building on this, we also introduce a delta encoding `DeltaWallet` for the wallet state `Wallet s`. The main change is that the `applyBlock` function now also computes and returns this delta encoding when computing the new `Wallet s` state. ```hs applyBlock :: (…) => Block -> Wallet s -> (FilteredBlock, (DeltaWallet s, Wallet s)) ``` However, this pull request does not yet integrate this type into the `WalletState` checkpoints; this will be the subject of an upcoming pull request. ### Details * `DeltaWallet s` currently uses the trivial delta encoding `Data.Delta.Replace` for the address discovery state. * As indicated, the delta encodings `DeltaWallet s` are not yet used with the `Checkpoint` mechanism. Instead, they are currently discarded. * Even though it is currently discarded, the `DeltaUTxO` type has suggested an optimization where a transaction that does not change the `UTxO` set can be discarded more quickly. This may already improve the wallet restoration benchmarks slightly. * I have smuggled in a small cleanup commit that removes the `Dom` type class, as it is no longer used. ### Comments * `@piotr-iohk` I'd be interested in the wallet restoration benchmark for this branch — I expect slight improvements for the `0.01-percent-seq` and `0.01-percent-rnd` benchmarks. Co-authored-by: Heinrich Apfelmus <[email protected]>
Build failed: |
* it was only instantiated for `UTxO` * after recent commits, it is only occurring in testing code
fe24a5d
to
9394d3e
Compare
bors merge |
Build succeeded: |
Issue number
ADP-1434
Overview
Previous work in epic ADP-1043 introduced delta encodings, DBVars, and an embedding of the wallet state and its delta encodings into a database table. It's time to integrate these tools with the wallet code. To facilitate code review, the integration proceeds in a sequence of refactorings that do not change functionality and pass all unit tests.
In this step, we finally introduce the type
DeltaUTxO
which represents a delta encoding of theUTxO
set, i.e. a package of changes that can be applied to oneUTxO
set in order to obtain another one. The typeDeltaUTxO
is abstract, but internally, it is implemented asi.e. it stores a set of
TxIn
that was spent, and aUTxO
that was received.Building on this, we also introduce a delta encoding
DeltaWallet
for the wallet stateWallet s
. The main change is that theapplyBlock
function now also computes and returns this delta encoding when computing the newWallet s
state.However, this pull request does not yet integrate this type into the
WalletState
checkpoints; this will be the subject of an upcoming pull request.Details
DeltaWallet s
currently uses the trivial delta encodingData.Delta.Replace
for the address discovery state.DeltaWallet s
are not yet used with theCheckpoint
mechanism. Instead, they are currently discarded.DeltaUTxO
type has suggested an optimization where a transaction that does not change theUTxO
set can be discarded more quickly. This may already improve the wallet restoration benchmarks slightly.Dom
type class, as it is no longer used.Comments
0.01-percent-seq
and0.01-percent-rnd
benchmarks.