[CSL-24] Move local MPC data from Acidic storage

[jagajaga]

@Gromak

--I propose to use structure similar to the one used by TxStorage: i. e. store local data only for the current version and global data for all versions. When rollback happens, we filter local data to make sure that it's valid.--

I doesn't make much sense to store local MPC data on disk. Size of it will be limited, because size of block will be limited (for example, I think block must fit into RAM). It means that we should move local MPC data from GtStorage. It also means that we need to move getLocalSscData from SscStorageClass. As well as sscProcessMessage. Good question is where to move it :)

I propose to create SscLocalDataClass type class, as well as SscLocalData type family in Ssc. SscLocalDataClass will contain:
• sscNewLocalData :: MonadIO m => m (LocalData ssc)
• sscDestroyLocalData :: MonadIO m => LocalData ssc -> m ()
• sscProcessMessage :: MonadIO m => SscPayload ssc -> SscMessage ssc -> LocalData ssc -> m () -- first argument is global payload which is taken from main persistent storage
• sscGetLocalPayload :: MonadIO m => SlotId -> LocalData ssc -> m (SscPayload ssc) -- maybe should take global payload too
Note: it's pseudocode.
It can be implemented as IORef, for example.
I want @neongreen to comment this solution, maybe it won't work for some reason.
Regarding atomicity: I don't see any fatal problems. We must be careful though, because, for example, when we pass global payload to sscProcessMessage it may happen that global payload changes. But actually we just need to check local payload before adding it to block, that's all.

[jagajaga]

@georgeee

Local data is not to be stored in ACID

[jagajaga]

@Gromak

Yes, we must move local data into memory state. It doesn't make much sense to do refactoring which moves local data from version as a separate task. It will be more efficient to move local data into memory state at once.

That's why I have updated this issue.

[jagajaga]

@Gromak

And now 12h estimation is reasonable :)

[jagajaga]

@neongreen

Looks okay to me. Where LocalData ssc (which is going to be an IORef, right?) would be stored?

[jagajaga]

@Gromak

@neongreen good question. It should be stored on very high level, higher than Worker or Server, because it's needed for both Worker and Server.
I think we can do it in the same way as we deal with NodeState (MonadDB). I will call it MonadSscLocalData, but it's not the best name. Then sscProcessMessage and sscGetLocalPayload will require MonadSscLocalData constraint (instead of taking LocalData as argument) and we can implement MonadSscLocalData in the same place where we implement MonadDB.
Does it make sense?

[jagajaga]

@Gromak

Btw, we also need to add something like processBlock to SscLocalDataClass, because we need to remove local data which appears in blocks.

[jagajaga]

@Gromak

Regarding atomicity: I don't see any fatal problems. We must be careful though, because, for example, when we pass global payload to sscProcessMessage it may happen that global payload changes. But actually we just need to check local payload before adding it to block, that's all.

This part is not implemented, I have created issue about it: CSL-155.

[jagajaga]

@Gromak

In general we have finished this issue, but there are some improvements to be done: CSL-154, CSL-155 and CSL-153.