Motoko Rechain (Blockchain Middleware - ICRC-3 related)

This Motoko library serves as a middleware framework enabling the integration of blockchain functionalities directly into dApps on the IC. It aims to abstract the complexities involved in blockchain operations, such as block creation, transaction management, hashing, certification and archival processes, allowing developers to incorporate ledger functionalities with minimal overhead.

Core Components and Functionalities:

Reducer Pattern for State Management: Employs a reducer pattern to manage state transitions based on actions. This approach allows for a more structured and predictable state management process, crucial for maintaining the consistency of blockchain states. It will allow easy replaying of state.

Has a modified stable memory version of the Sliding Window Buffer (by Research AG) https://github.com/infu/swb

Modularity and Extensibility: Designed with modularity at its core, the library allows developers to define custom actions, errors, and reducer functions.

Reducer Libraries: Developers can publish their reducers as libraries, enabling others to incorporate these libraries into their canisters for efficient remote state synchronization. This process involves tracking a remote ledger’s transaction log and reconstructing the required state segments in their canisters. This mechanism facilitates the development of dApps that can in certain cases do remotely atomic synchronous operations within asynchronous environments, similar to the DeVeFi Ledger Middleware’s capabilities.

Example 1 - Simple

https://github.com/Neutrinomic/rechain_example/blob/main/src/example.mo

The provided example illustrates the use of the library in a token transfer system. It showcases the definition of actions for token transfers and minting, error handling mechanisms, and the implementation of reducer functions to manage the application’s state.

Example 2 - Advanced - Ledger with ICRC1, ICRC3, ICRC4

https://github.com/Neutrinomic/minimalistic_ledger

Middleware (Alpha | POC | Untested):

https://mops.one/rechain

https://github.com/Neutrinomic/rechain

TODO:

  • Compliance with ICRC3
  • Certification
  • Creating & communicating with archive canisters
  • Replay state
  • Tests

ICRC-3 problems

  • (not using) Generic Values are hard to use and probably prone to errors. Our reducers will have to reduce Generic Values if we want to replay state. Motoko CDK could add support for these that won’t result in bloated code at some point in the future. These also need a schema. Sounds like what Candid is supposed to do ICRC-3 Draft v2 and Next Steps - #3 by infu

  • (currently using) Storing app specific blocks as Candid binary allows custom schema. Hashing Candid binary format has other problems, but these can be fixed by making Candid produce the same binary on different platforms or ignored if we restrict hash verification only to Motoko canisters ICRC-3 Draft v2 and Next Steps - #6 by chenyan

Related: @skilesare @dieter.sommer @mariop @timo

Note: It appears for better ergonomic ICRC-3 Transaction should be something like this, where Payload can be custom, but the rest are fixed and provide deduplication and transaction related meta. Maybe even add expires_at. We have taken spender down to the root and every transaction has caller, it makes more sense.

    public type Transaction = {
        caller: Principal;
        created_at_time: ?Nat64;
        memo: ?Blob;
        timestamp: Nat64;
        phash: Blob;
        payload: Payload;
    };
4 Likes

We started a schema at one point. This library probably needs #Map changed to the Value type for Map to be compatible with Candy v0.3.0, but it should be a superset of the ICRC3 value and work if we can get the simple refactoring in. Not sure what @ZhenyaUsenko is up to, but it should be a simple addition/update.

Are you talking about motoko-candy-utils GitHub - ZhenyaUsenko/motoko-candy-utils ?

It currently uses Candy v2, therefore the Map version is v7 (to be compatible with Candy v2).

I haven’t been tracking Candy updates. Does v3 use Map v9?

So I guess you mean we need to update candy-utils to use Candy v3 and Map v9… Is it what you were suggesting?

We will have to use it if it’s in ICRC-3. Actually, the whole type system won’t work for us if we try to select values independently. Perhaps we need a library that does GenericValue → Record and Record → GenericValue. I guess the second one has to convert the Record to candid and then parse the candid and convert it to GenericValue. So we don’t have to write mapping for each one. Probably using this https://mops.one/serde @tomijaga or we just use CBOR

In Candy v0.2.0 we had #Map(Candy, Candy). We changed that to #ValueMap and added a #Map(Text, Candy) so that it would be a superset of Value in ICRC3. So we just need those pathways added for the Candy and CandyShared.

And yes, I use Map 9 now.

You can see the basics of what I did in this commit: Initial 0.3.0 commit · icdevsorg/candy_library@d67fc25 · GitHub

I hadn’t seen serde. Looks like it is a wrap-up of @Gekctek 's candid and cbor into one library. Nice.

We should be able to write something pretty generic with that, although computationally it may be faster to parse each schema.

1 Like

I’ll look into it and update CandyUtils at the weekends

1 Like

Candy Utils was updated to v0.7.0 and now works with Candy v3 and Map v9

It was also published to mops

https://mops.one/candy-utils

1 Like