Exploration: on-chain “snap sync”

[yonadaaa]

Introduction

This issue explores introducing a new option for MUD applications that allows clients to quickly fetch the state of a Store directly from the blockchain, without relying on an off-chain indexer.

Existing approaches

There are two standard ways to sync MUD clients:

• Reconstruct the Store state locally by subscribing to events with a networking packages like Network with RECS.
• Fetch the current state from an off-chain indexer like MODE.

However, these approaches have drawbacks:

• Local syncing can take an unbounded amount of time, as the client has to process every event since the deployment of the Store (after a regular amount of activity, this takes minutes).
• Trusted services like MODE introduce a new point of failure that clients rely on, and it is important that they can retrieve the canonical state at all times (eg. #555). Besides, MODE still faces unbounded sync times when indexing a new Store.

In principle, clients should be able to fetch the current state of a Store directly from contract storage. However, there is no on-chain index of which records have been set, so this information is derived from past Store events.

On-chain "snap syncing"

I propose introducing a new maximally on-chain "snap sync" mode for MUD Stores (inspired by the option in Geth). This would install an index of keys on a Store by default, indicating which records have been set. With a modified networking library, clients sync directly from the chain by reading these keys, then values, from the Store. Once synced, they follow the event stream as normal.

The on-chain index could be implemented per table, using the KeysInTable module (#583), or with a single index that would be more gas-efficient but would require clients to check every key-table pair.

The sync logic could be implemented in a view function that clients call once; acting like an RPC batch request within MUD. Clients need to be mindful of chain finality and request the state starting a few blocks in the past.

Ephemeral tables

One drawback of this approach is that it would ignore past events from the upcoming Ephemeral tables (#665). However, these are usually only relevant at the time that the event was emitted (eg. for animating attacks), and once the client is synced they subscribe for any new events.

[smallbraingames]

On the issue of Ephemeral Tables–I don't think it is that large of an issue. This is because Ephemeral Tables will most likely be used to get context around component updates in the frontend (e.g. for animations), which only matters "going forward" in time.

In MUD v1 for example, the system call stream did not fetch historical system calls. Similarly, I think its fine if snap sync doesn't fetch ephemeral table events.

[yonadaaa]

Pseudocode for view function

This assumes the KeysInTable module supports composite keys, which is does not yet. getTables() represents some index of tables, I am not sure if we have something like that.

The Record struct is designed to match simple Store events that the client can easily parse, ie. StoreSetRecord(bytes32 table, bytes32[] key, bytes data)

Record {
    bytes32 table
    bytes32[] key
    bytes value
}

function snapSync() public view returns (Record[] memory records) {
    bytes32 tables = getTables();

    for (uint256 i; i < tables.length; i++) {
        bytes32[][] keys = getKeysInTable(table);

        for (uint256 j; j < keys.length; j++) {
            bytes32[] key = keys[j];
            bytes value = StoreSwitch.get(table, key, value);

            records.push(Record({table, key, value}));
    }
}

[alvrs]

in progress in #764