Add BlockSummary type and related changes

[HeinrichApfelmus]

Issue number

ADP-1422, ADP-1425

Overview

Light-mode (Epic ADP-1422) aims to make synchronisation to the blockchain faster by trusting an off-chain source of aggregated blockchain data.

In this pull request, we add the BlockSummary type that represents transaction data contained in a contiguous sequence of blocks. Instead of storing a sequence of Block directly, the BlockSummary gives us a (monadic) query that can be used to obtain transaction data for specific addresses within that sequence.

data BlockSummary m addr txs = BlockSummary
    { from  :: !BlockHeader
    , to    :: !BlockHeader
    , query :: addr -> m txs
    }

The idea is that the query will eventually call out to the off-chain source of aggregated blockchain data. The from and to fields are necessary to preserve the sequential way of how cardano-wallet currently consumes blockchain data.

This pull request mainly adds and rearranges types, and matches lightSync with the MaybeLight type class. However, the implementation of production or consumption of BlockSummary will be tackled in later pull requests.

Details

• We add a field lightSync to the NetworkLayer. This field will eventually provide the BlockSummary to a ChainFollower. It is set to Nothing for now.
• We add a type class MaybeLight s which indicates whether a wallet state supports address and transaction discovery with BlockSummary. All instances are currently set to Nothing.
• We instantiate the BlockSummary type with …
  • … addr = Either Address RewardAccount. In other words, we can either get transaction data pertaining to a single Address, or delegation information pertaining to a RewardAccount.
  • … and txs = ChainEvents, which is a sequence of BlockEvents. In turn, the type BlockEvents contains transactions and delegations that appear within a single block; this can be the full block, or a subset of interest.
• Even in light-mode, we expect to work with sequences of blocks, so the type BlockData tags whether we are consuming a sequence of Block, or a BlockSummary. In the case of a summary, we include information from the MaybeLight class in order to facilitate consumption.

Comments

• Later on, transaction data will be consumed by adapting applyBlockToUTxO to work with BlockEvents instead of Block.

[HeinrichApfelmus]

bors try

[iohk-bors]

try

Build succeeded:

• ci/hydra-build:required
• buildkite/cardano-wallet

[HeinrichApfelmus]

bors try

[iohk-bors]

try

Build failed:

• ci/hydra-build:required

[paweljakubas]

in next installements we will extend that and allow discovery of other things, like stake keys, policy keys, certificates, etc. Right?

[HeinrichApfelmus]

All things that we need in order to do address discovery, indeed.

The type BlockSummary is actually polymorphic in the addr type, and I felt that it would be easier to understand if I kept calling it "address".

In the LightSummary type, we currently instantiate this to addr = Either Address RewardAccount — as this is all the information currently required by applyBlocks.

[paweljakubas]

would be good to include some examples here, just to better explain what to expect from mergeOn. I wonder if there is no function like that in Data.List or Data.List.Extra...maybe we can use zipWith inside?

[HeinrichApfelmus]

Fair enough. mergeOn is very similar to a merging function that one would use in a mergesort implementation. I'll add more documentation / an example.

[paweljakubas]

this (is. ==) will be needed to generalize later as it only survives non-script case. For scripts we will need isShared, here maybe we should sneek isOurs, even at this moment. What do you think?

[HeinrichApfelmus]

Well, the thing is that in light-mode, we cannot use the isOurs functions anymore — the blockchain data source will provide us with a query addr -> m txs (instantiated to e.g. (Either Address RewardAccount) -> m ChainEvents). Then, address discovery will have to put several addr into this query rather than considering full blocks from the chain and filtering them.

The summarizeOnTxOut and filterBlock functions are intended for testing only. The plan is to test light-mode by comparing two paths:

• list of blocks → filter into query → light-mode address discovery
• list of blocks → node-mode address discovery

These functions help with the first →.

[paweljakubas]

yes, I see it. in light mode we use query and it is up to caller using BlockSummary how query looks like. So it is upt to caller, ie. consumer of this abstraction, do deal with address management. It is the caller's responsibility

[HeinrichApfelmus]

Yes, exactly. Hence no isOurs here.

[paweljakubas]

very nice abstractions introduced, I like always sorted by slot ChainEvents being monoid, BlockSummary as we discussed. I wonder if isRelevantTx should not be already powered by using isOurs instead of == and prepared to accomodate isShared later. I am waiting for models' applyBlocks impl and first integration test/setup in next PRs of this series

[HeinrichApfelmus]

bors merge

[iohk-bors]

Build succeeded:

• buildkite/cardano-wallet
• ci/hydra-build:required