Proceedings from SKAN Meetings: Jul 18/24
Currently as of v0.17.0 of Anoma, our implementation of snapshotting and our mnesia tables are laid out, leaves a lot to be desired.
Thus the focus of this proceeding was to tackle pain points in our architecture.
The Rough Plan
During the proceedings we came up with a proper way that our scry ought to work and how storage should interact with it:
This diagram describes a layout of a few things:
- key_A has 3 timestamps for which it’s been updated:
45,97and191. - We can do a logical read like
/123/key_Awhich should give the user/97/key_A - Further when we attempt to read at some random id like
[cf1409], the engine sending thescrywith receive a please wait until a please wait can be sent. - Further before a block is done and during the mid transactions we will have
half-done storagethat can be made permanent when we commit to a block.
Creating a Plan
In order to actualize our implementation strategy, we came up with a value map from what the user values, along with the supply chain of work that needs to be done.
The user will be calling scry directly and thus it’s the natural entry point that a consumer (Juvix, etc) cares about.
This particular map is made of two major sub components to get proper scry semantics:
- Proper timestamped storage
- A global data broker that can be found in this thread: Anoma Topics Meeting Digest: Global Data Brokers
The time-frame to attack this problem isn’t too bad. We estimate the work for the global data broker ought to take a week (with nominal delays let’s say 2 weeks) and then we shall use one the proceedings to implement 1. once we have 2. ready.
Further these plans also encompass the work to get parallel reads online.
Each of these nodes will be augmented by an issue to track the progress.