Minimal Viable Wallet Layer #43
Conversation
| return $ if predicate then Just out else Nothing | ||
|
|
||
| forMaybe :: Monad m => [a] -> (a -> m (Maybe b)) -> m [b] | ||
| forMaybe xs = fmap catMaybes . for xs |
KtorZ
force-pushed
the
KtorZ/#20/wallet-layer
branch
from
9776d23
to
7b1cf62
Compare
| , binary | ||
| , bytestring | ||
| , cborg | ||
| , containers | ||
| , cryptonite | ||
| , deepseq | ||
| , digest | ||
| , fmt |
There was a problem hiding this comment.
I bet there are some strong argument in favor of using fmt vs formatting?
There was a problem hiding this comment.
There are some arguments. See #sl-core (I'll send you a link in PM)
| -- License: MIT | ||
| -- | ||
| -- Here we find the "business logic" to manage a Cardano wallet. This is a | ||
| -- direct implementation of the model from the [Formal Specification for a Cardano Wallet](https://github.com/input-output-hk/cardano-wallet/blob/master/specifications/wallet/formal-specification-for-a-cardano-wallet.pdf) |
There was a problem hiding this comment.
don't we want to split it into two lines?
There was a problem hiding this comment.
I wish but we can't split the link :(
| -- k = 2160 is currently hard-coded here. In the short-long run, we do | ||
| -- want to get that as an argument or, leave that decision to the caller | ||
| -- though it is not trivial at all. If it shrinks, it's okay because we | ||
| -- have enough checkpoints, but if it does increase, then we have |
There was a problem hiding this comment.
you mean the problematic situation would be: the caller has an ability to set k in applyBlocks? and the wallet persists the state and then is called with higher k at some point, and for some period it misses checkpoints to be compliant with new k parameter. And then rollback comes that has depth covering those missing checkpoints? Maybe in that case k->k' , where k'>k some kind of "restotration" should take place to compensate it....
There was a problem hiding this comment.
That's what I meant yes. So, there are different way to deal with this indeed, but it's not trivial, hence the warning.
|
|
||
| -- | A polymorphic wrapper type with a custom show instance to display data | ||
| -- through 'Buildable' instances. | ||
| newtype ShowFmt a = ShowFmt a |
There was a problem hiding this comment.
this one is because we do not want to deliver separate instances of Show for Utxo, Adresses, Block,... Instead we wrap them in ShowFmt and in one go use any type's Buildable instance?
There was a problem hiding this comment.
This one is because we do not want to write custom show instances in practice. Though, because of the way QuickCheck, HSpec and some other libraries work, they use Show to output results and counterexamples which is very unpractical to read for some types (like the UTxO). For those, we may opt-in for a ShowFmt wrapper around a type to get a nice output. Though, we don't want to be changing the stock Show instance for those types.
test/unit/Cardano/WalletSpec.hs
Outdated
| {------------------------------------------------------------------------------- | ||
| Basic Model - See Wallet Specification, section 3 | ||
|
|
||
| Our implementation of 'applyBlock' is a bit more complexe than the basic |
| prefilterBlock b (Wallet !utxo _ !s) = | ||
| let | ||
| txs = transactions b | ||
| (ourOuts, s') = txOutsOurs txs s |
There was a problem hiding this comment.
in the previous code prefiltering acted on the whole set of transactions. now we make sure we intersect only on those belonging to us. Nice!
| {------------------------------------------------------------------------------- | ||
| Test Data | ||
|
|
||
| In practice, we may want to generate arbitrary valid sequences of block. |
There was a problem hiding this comment.
maybe block sequences instead of sequences of block
KtorZ
force-pushed
the
KtorZ/#20/wallet-layer
branch
from
7b1cf62
to
d4573c7
Compare
KtorZ
force-pushed
the
KtorZ/#20/wallet-layer
branch
from
d4573c7
to
f912702
Compare
Issue Number
#20
Overview
Showinstances (like the UTxO, cf comments)applyBlockand compare it to a basic model.Comments
UTxO through
Buildablelooks like the following: