CIP-146: After - Discussion

Protocol CIP Discussions
1

Discussion for CIP-146: After

After

This CIP adds the ability to more closely determine the time after which an Init or Data Event was added to a Ceramic stream.

Currently, it is possible to determine the time before which a Data event was added by looking at the Time Event corresponding to the Data Event. However, it is not possible to determine a specific time after which the event was created.

Motivation

Time is a useful dimension in which to express interests.

There are various circumstances in which a node might be interested in the most recent events for a model. Because the nature of Recon is to synchronize sets of data, it is important that multiple nodes can agree upon an identical ordering of events. We can’t use anchor time as the mutual timestamp because anchor time can change and two nodes might not agree on the same anchor time at the beginning of the sync.

By introducing “after” timestamps, every event will have an immutable time that it is after.

For example, at the streaming layer:

  1. A node may be interested in subscribing to a Metrics model in order to populate some dashboard but only cares about events from the last 30 days. By using the “after” timestamp, the node can request only events that occurred after the current time minus 30 days by expressing an interest that filters on “after > (now - 30 days)”. This will allow the node to sync only the events that it is interested in. Despite the fact that the number of streams and events for the Metrics model grows without bounds, the node only needs to allocate enough resources to sync the events from the time range it is interested in.
  2. A node operator might choose to split out the task of archiving older data to a different node. By using the “after” timestamp, the node operator can determine which events are older than a certain time and synchronize them separately from recent events.
  3. If an application is using a Service Announcement model for service discovery, we can imagine that the announcements are only meaningful for a few hours before becoming irrelevant. This forces service providers to make announcements at least every few hours, or their announcements will expire.

An example at the aggregation layer could be for an aggregator to use the “after” timestamp to determine the order of events in a stream in a Last-Writer-Wins (LWW) fashion. Rather than the current default diff-stream behavior where the last writer is rejected during conflict resolution, an aggregator could use the “after” timestamp to permit the LWW strategy that is the default for most traditional data storage solutions, like filesystems and databases.

After Proof

“After” proofs are a new type of proof block proposed by this spec. An After proof proves that a Data Event happened after the timestamp of the Ethereum block whose block hash is included in the proof.

The header field of a Data Event shall include a new after field that points to an After proof or an Ordered proof:

{
    "data": {},
    "header": {
        "controllers": [
            "did:key:z6MkhvoSQhPDNwotybwX9o2scoSvkx5Syem3GiM9FV8h5YXG"
        ],
       "after": { "/": "bafyreidtsz24vstukaoxisgrpdjijgsof3u3ls5d22fcly2qcp6ksx4cfe" }
    }
}

This is an example of an After proof block:

{
  "chainId": "eip155:1",
  "blkHash": { "/": "bagiacgzapa6nljx6xyj5bcwa2wp2pztgja6v4r3fikzjncfg6c7mhuk75pka" }
}

These blocks are stored as DAG-CBOR but are represented here as DAG-JSON.

4 Likes