| | | |
|---|
| Detail of what needs to be done |
| If we offer the channel hash, we can query the produces for the COMM events What if a user wants an event that was never in a checkpoint?
|
| Data in the log | | Take the COMM events from the trace log, and subtract the consumes and produces that appear in the trace log. We need to have a richer hash, so we can retrieve that information. In the trie these are stored as gnat - it contains all the stuff, the channel, pattern, data at the continuation, channel hash. Looked up via the channel's hash. Make the trace log slightly richer by including the hash of the channels.
|
| Trie Merges | | 2 blocks, both with the same parent. Contain no conflicting COMM events. We would like to apply the diff to another state hash (Trie Merge) Eventually we will want to start slowly optimizing when the entire trace doesn't need to be run in order to come to the desired state.
|
| What will be done | | Channel Hash Arrange such that if there is a message on the channel, send the data. If you want to know about a particular event on a channel, you will need to send a replay request. (request for intermediate information) Get information from the Trie and seeing if the data is still there, hot in the store.
|
| Client Experience | | Users will subscribe to a channel, part of the subscription will have to include a destination. Need to dig into the gRPC api and see how the data exchange would operate. Pair of blockhash and replay data.
|