- provide efficient map and color change history access for the space clients.
- reliable
- no read bottleneck for clients
- easy to implement
- easy to run as server-less tasks
- low cost, but some gas fee seems OK
- all components are stateless
- use events for state management
- use ipfs for data storage
- NOT use ipfs dynamic name resolution facilities (for efficiency and reliability)
- snapper (run as aws lambda or in server)
- snapper-contract (run as smart contract)
- generate map snapshots and color change deltas
- store snapshot/delta into ipfs
- call snapper-contract to emit events about cache states
- get latest map snapshot from event/ipfs
- get color changes after latest snapshot
- apply changes to latest snapshot to generate new snapshot
- store snapshot to ipfs
- ask snapper-contract to emit snapshot info event
- get latest delta from event
- get color changes after latest delta
- generate new delta
- store new delta to ipfs
- ask snapper-contract to emit delta info event
note: color delta can be generated along with map snapshot if using the same interval.
- receive meta info from snapper and emit events
- png, 1000 x 1000, 8-bit/color rgb, no-filter, highest compression, non-interlaced
- not the smallest in size
- just a image (eg. people can simply open it in browser)
- support any color
- small enough (with random image at around 700k for theoretical upper limit, normally should be smaller than 350k)
316k fractal16.png
240k moutain16.png
104k panda16.png
688k random16.png
{
delta: [
{
bk_num: int, // block number for this delta
time: ISO8601 string, // real world time for this block
cs: [
{
i: int // pixel id
c: int // pixel color
},
...
]
},
...
],
prev_cid: string? // ipfs cid of previous delta, null for first delta
}
{
bk_num: int, // block number for this snapshot
cid: string // ipfs cid for this snapshot
}
{
bk_num: int, // block number for this delta
cid: string // ipfs cid for this delta
}