Motoko VeRoniCa retrospective

[ggreif]

Observations

Generally a pleasant experience, but I’ve been programming in a mostly functional paradigm.

Compact code.

• Mutual actor types are super helpful
• Leakage of internal types into the Candid interface
• group missing from Array, List (maybe as *Utils.mo modules)

Storing the transactions as an immutable reverse temporal sequence is a nice way to
implement the blockchain metaphor.

I have a helper class (Deduplicate) that holds a Set of visited credit Ids.

Time series DB wins with transparency vs. a mutable DB.

Pluggable exchanges

These are actor classes. Currently only VRC/fUSD trading pairs, with a very limited feature set.
Plans are

• hard: real bank account access (HTTP outcalls)
• easy: VRC/ICP, VRC/ckBTC, VRC/ckETH, VRC/stablecoin
  Hopefully only one routine needs to be changed

Exact interfaces to be determined.

Using:

• Cascaded queries
• system canister upgrades
• massive use of functional record extension

Scaling is needed

Using long linked lists is a no-no! There are no guarantees for tail-recursion elimination in Motoko, so the stack may overflow.

Sharing

• Restore after upgrade (post-upgrade hook)
• Bundles of 1000s of transactions as (stable) arrays (keep only a recent 100-prefix of linked list)
• Indices: describe relevant CreditIds and TransactionIds in the metadata of the bundle
• Use stable memory or spin out secondary storage canisters?

Future

We’ll need blob[0] (can be emulated by iterator: blob.vals().next())
switch could progressively specialise the scrutinee type
SHA2 (and subtypes) are common in the blockchain world, we should export those interfaces