THIS PAGE IS WORK IN PROGRESS

Usage scenario

User A wants to transfer REV from their vault to B's vault.

This scenario is covered by the script Vault Demo

Concepts

The main focus of the above scenario is the ability to observe the 2 balances A's vault balance and B's vault balance after the transfer.

To be able to reason about the above scenario basic concepts need to be covered.

DeployId is the unique identifier which is produced as the result of "deploy" RNode API.

A block is a list of deploys.

A deploy can be added to multiple blocks (similar to mempool).

A block can be either finalized or not. Finalization has a certain fault tolerance which dictates how stable the DAG above the finalization point is.

With a reasonable fault tolerance, a finalized block containing a particular deploy can be considered certain.

A finalized deploy will be removed from the "mempool".

Implementation

Setup step requires the users interested in observing a particular transfer need to connect to a WebSocket endpoint {{/ws/events}}.

During deploy of the transfer contract the owner of the vault A will receive a DeployId D1.

D1 will be included in blocks created and added by validators in the network.

This can be observed in the events produced by {{/ws/events}}.

At some point, a block B1 containing D1 will be finalized.

The hash of B1 can be used to compute the execution trace of D1 by using {{/reporting/trace?blockHash=B1hash}}.

This trace needs to be parsed to find the balances of A's vault and B's vault.

Generalization

In general, it is possible to trace all the changes that are happening on the chain by tracking the DAG {{/ws/events}} and the traces in finalized blocks {{/reporting/trace}} in an automatic fashion. This requires:

A) storage - which is obvious

B) parsing - the ability to gain insight about the interesting parts (e.g. vault balance) of the data stored on the chain. This requires additional resources but can be done offline and post-fact.

One aspect that has been omitted in the above scenario is the ability to catch up to the state of the network. A newcomer wants to be able to trace vault balances of all the users but is able to observe only the addition of new blocks via {{/ws/events}}. This concern is covered by "catch-up".

ws/events

reporting/trace

Catch-up

APIs that cover catching up are under development.