Adjust restoration loop to look for known certificate registrations

[KtorZ]

Context

With #898, certificate registrations will now be part of blocks normally processed by the wallet layer.

Decision

• Adjust restoration loop and keep track of certificates created by our wallet within already existing checkpoints.

Acceptance Criteria

1. The wallet engine must keep track of all certificates (modulo checkpoints) discovered on the chain as long as their date (as slot) of activation
2. The delegation status returned by the API must corresponds to the status maintained by the wallet engine (no certificate == not delegating, or, delegating according to the latest certificate).

---

Development plan

Generalization of existing discovery classes

PR: #1075

• Generalize the definition of the IsOurs type class so that it can be applied to more types of entities than Address.
• Add an IsOurs s ChimericAccount constraint to the Wallet type.

Adjust restoration loop to look for delegations from wallet's chimeric account

PR: #1050

• Add implementation of IsOurs (SeqState n k) ChimericAccount.
• Adjust the return type of applyBlock so that it references any stake delegation that has occurred on behalf of the specified wallet.
• Adjust the definition of restoreBlocks so that it correctly processes the registrations returned by applyBlocks.
• Fix atomiticity issue when inserting delegation certificates in a distinct transaction than checkpoints.

PRs

Number	Base
#1075	master
#1050	master

QA

PR: #1050

• Add tests to ensure that applyBlock does successfully discover delegations made by the wallet under test, and only that wallet. (STAKE_POOLS_JOIN_01)
• Add tests to ensure that a wallet's delegation status is correctly updated in the context of discovered delegations. (STAKE_POOLS_JOIN_01)

[jonathanknowles]

@KtorZ

Our current definition of Block in the wallet layer includes a set of delegations from ChimericAccount to PoolId:

data Block = Block
    { header  
        :: !BlockHeader   
    , transactions
        :: ![Tx]  
    , delegations 
        :: ![(ChimericAccount, PoolId)]   
    } deriving (Show, Eq, Ord, Generic)

The definition of applyBlock has access to a Wallet s, which implies an IsOurs s constraint, which in turns gives us the isOurs function:

class IsOurs s where  
    isOurs
        :: Address
        -> s  
        -> (Bool, s)  
        -- ^ Checks whether an address is ours or not. 

Of course, the above function gives us a way to recognize values of Address that are ours.

Question: how can we recognize values of ChimericAccount? Can values of ChimericAccount be treated as an Address (through unwrapping and rewrapping), or is there another function that we should be using here to translate?

[KtorZ]

Can values of ChimericAccount be treated as an Address (through unwrapping and rewrapping)

Definitely NO 😅

is there another function that we should be using here to translate?

We're going to need another function for that. Though, that function really is == :)
There's (by common agreement) a single chimeric account attached to a particular wallet. That chimeric account is known in advance so it's really a matter of finding it (or not) inside the list of certificates published in the current block or batch of blocks.

Additional reading here: https://github.com/input-output-hk/implementation-decisions/blob/e2d1bed5e617f0907bc5e12cf1c3f3302a4a7c42/text/1852-hd-chimeric.md

[jonathanknowles]

@KtorZ wrote:

There's (by common agreement) a single chimeric account attached to a particular wallet. That chimeric account is known in advance so it's really a matter of finding it (or not) inside the list of certificates published in the current block or batch of blocks.

The applyBlock function is currently responsible for scanning a block and finding things that are relevant to the current wallet:

applyBlock
    :: Block
    -> Wallet s
    -> ([(Tx, TxMeta)], Wallet s)

Given that applyBlock only has a Block and Wallet s available to it, we'd need to update the wallet abstraction so that it's possible to check whether a given ChimericAccount is owned by a wallet.

Questions:

1. Do you have any preference as to how we adjust the Wallet abstraction?

2. Since there's only ChimericAccount attached to a wallet, do we even need to depend on the type variable s?

Could we use an oracle function similar to this:

data Wallet s where                                                                                                                                                                   
    Wallet :: (IsOurs s, NFData s, Show s)                                                                                                                                            
        => UTxO -- Unspent tx outputs belonging to this wallet                                                                                                                        
        -> BlockHeader -- Header of the latest applied block (current tip)                                                                                                            
        -> s -- Address discovery state
        -> IsOurChimericAccount                                                                                                                                               
        -> BlockchainParameters                                                                                                                                                       
        -> Wallet s

type IsOurChimericAccount = ChimericAccount -> Bool

[jonathanknowles]

@KtorZ are you able to clarify the following:

Fix atomicity issue when inserting delegation certificates in a distinct transaction than checkpoints.

In particular, are you able to give a concrete set of reproduction steps for this issue? Thanks!

[KtorZ]

Ah! I forgot about this one, good I added a reminder ^.^ ... I'll explain in a PR, would be easier.

[jonathanknowles]

Ah! I forgot about this one, good I added a reminder ^.^ ... I'll explain in a PR, would be easier.

Great! I've moved this to the QA state.

[piotr-iohk]

lgtm.