ApplyingBlocks Rollback After Decoupling Byron

ApplyingBlocks-Rollback-After-Decoupling (Byron era)

Executive summary We aim to cut off two wallet-node couplings that are present from the point of view of applying blocks and rollback (a) NodeStateAdaptor which brings the node state to the wallet's scope, and (b) shared state that allows the respective callbacks. We will utilize node-to-node mechanism of dissemination when it comes to new block application and rollback. As the wallet and diffusion layer components are bound to stay stitched together, these same ways of getting blocks and rollback as used in node-to-node communication can be used by wallet to realize block application and rollback

See Fig. 1 for high level view of how wallet and node decoupling looks like in Byron era. In Shelley era solution we can opt for direct talking with ouroboros-network layer of the node.

Fig. 1. Component view of the wallet and trusted node

The wallet component has diffusion layer component inside that is able to communicate with the trusted node. Trusted node engages in node-to-node communication with other nodes. The diffusion layer is utilized by the wallet to get blocks from the trusted node. Another needed by wallet information is to be delivered by node API. Downloading the blocks is realized by invoking two diffusion layer calls:

• getBlocks and requestTip. They have the following types:

-- Get all blocks from a set of checkpoints to a given tip.
-- The blocks come in oldest first, and form a chain (prev header of
-- {n}'th is the header of {n-1}th.
getBlocks
   :: NodeId
   -> HeaderHash
   -> [HeaderHash]
   -> m (OldestFirst [] Block)

-- This is needed because there's a security worker which will request
-- tip-of-chain from the network if it determines it's very far behind.
requestTip
    :: m (Map NodeId (m BlockHeader))

requestTip returns the tip-of-chain of the trusted node, which is afterwards used in getBlocks call.

The proposed mechanism is based on pull paradigm meaning the wallet assumes active role and takes responsibility for querrying periodically for the current block tip and subsequently request the missing blocks from the trusted node. The similar pull mechanism is used for submitting transaction - see Submission Layer (Byron era) for description.

The relation of active wallet layer with respect to the diffusion layer of both the wallet and trusted node presented as an action diagram is in Fig. 2.

Applying new blocks

As follows from the Fig. 2 tickDiffusionFunction is responsible for block header accounting, transforming the downloaded blocks into resolved blocks (needed in BListener methods) and calling applyBlocks and switchToFork of Cardano.Wallet.Kernel.BListener. The essence of the logic is presented in Fig. 3 in a number of figures where the wallet pulls the missing blocks from the trusted node.

Rollback

The rollback can also be accommodated as an extension of the logic of new blocks application presented above. The idea is presented in Fig. 4.