Skip to content
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

Merged
merged 5 commits into from
Mar 4, 2022

Conversation

HeinrichApfelmus
Copy link
Contributor

@HeinrichApfelmus HeinrichApfelmus commented Feb 24, 2022

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

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.

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.

@HeinrichApfelmus HeinrichApfelmus force-pushed the HeinrichApfelmus/ADP-1043/DeltaUTxO branch from 45d68f8 to 1ad4225 Compare February 24, 2022 21:01
@HeinrichApfelmus HeinrichApfelmus force-pushed the HeinrichApfelmus/ADP-1043/DeltaUTxO branch 4 times, most recently from caf3ac8 to 7f28089 Compare February 25, 2022 14:17
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"]
Copy link
Contributor

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?

Copy link
Contributor Author

@HeinrichApfelmus HeinrichApfelmus Mar 3, 2022

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:

venn diagram

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.

Copy link
Contributor

@paweljakubas paweljakubas left a 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

@HeinrichApfelmus HeinrichApfelmus force-pushed the HeinrichApfelmus/ADP-1043/DeltaUTxO branch from b5c23ae to fe24a5d Compare March 3, 2022 13:15
@HeinrichApfelmus
Copy link
Contributor Author

bors merge

iohk-bors bot added a commit that referenced this pull request Mar 3, 2022
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]>
@iohk-bors
Copy link
Contributor

iohk-bors bot commented Mar 3, 2022

Build failed:

@HeinrichApfelmus HeinrichApfelmus force-pushed the HeinrichApfelmus/ADP-1043/DeltaUTxO branch from fe24a5d to 9394d3e Compare March 3, 2022 16:55
@HeinrichApfelmus
Copy link
Contributor Author

bors merge

@iohk-bors
Copy link
Contributor

iohk-bors bot commented Mar 4, 2022

Build succeeded:

@iohk-bors iohk-bors bot merged commit 6d7f705 into master Mar 4, 2022
@iohk-bors iohk-bors bot deleted the HeinrichApfelmus/ADP-1043/DeltaUTxO branch March 4, 2022 08:51
WilliamKingNoel-Bot pushed a commit that referenced this pull request Mar 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants