Use custom JSON value type with Rc inside. It cannot be edited, but producing new values based on child element is very cheap.
This new type is used exclusively in AquaVM internals. Interface APIs use serde_json's Value or JSON strings, as before.
---------
Co-authored-by: raftedproc <71657594+raftedproc@users.noreply.github.com>
* Hide `Rc` inside `CID` type, making it cheap to clone.
* Introduce `CidRef` type that abstracts on `CID`'s inner type.
This change makes code cleaner, makes memory more optimal (single allocation vs two allocations) and makes it easier to change CID's internal representation from string to binary.
Refactored stream and stream generation a lot, it introduces the following changes:
- no generation in data anymore, AquaVM relies on generation inside data to stay valid and places value accordingly to it
- stream is internally divided into previous, current, and new values, before, it was one array for all of them
- recursive streams cursors are refactored and rely on new generation values instead
- the Generation enum was refactored and now contains the source of the generation
A peer signs the multiset of call results and canon results it has produced.
New field signatures, a map from peer public key to signature, is added to the interpreter data.
Signatures verification is yet to be done.
* `ValueAggregate` refactoring
0. Service results, canon results and literals are constructed as
separate types that are further wrapped with `ValueAggregate`.
1. `ValueAggregate` is enum that contains all the provenance info.
2. Construction methods get provenance information as well.
* Rename CID state field
Prepare to adding a canon CID field: rename `canon_tracker`/`canon_store`
to `canon_element_tracker`/`canon_element_store`.
* Add canon result store/tracker
* Rename some structs that have CIDs inside
Reflect explicitly that they contain CIDs inside:
`CanonResultAggregate` -> `CanonResultCidAggregate`
`ServiceResultAggregate` -> `ServiceResultCidAggregate`
---------
Co-authored-by: Mike Voronov <michail.vms@gmail.com>
BREAKING CHANGE:
1. Call values in the trace have CID references to structures that have call arguments' hash and CID references to values and tetraplets.
2. If call value is unused, it is serialized with `Unused` variant, and CID references are not stored.
Previous data scheme was (Scalar as an example, other cases are similar):
```
Scalar(CID<JValue>) ---<value_store>----> JValue
```
New data scheme is much more sophisticated:
```
Scalar(CID<ServiceResultAggregate>) ---+
|
+----<service_result_store>----------+
|
+-------> ServiceResultAggregate:
value_cid ------------<value_store>----> JValue
tetraplet_cid --------<tetraplet_store>----> SecurityTetraplet
argument_hash: String
```
`Stream` variant is similar, however, `Unused` is different: it has value CID only, but the value is not stored into the `value_store`:
```
Unused(Rc<CID<JValue>>) ---> X
```
Co-authored-by: Mike Voronov <michail.vms@gmail.com>
* Use CID values for tetraplets and `canon` vectors.
* Rename `cid_store` to `value_store`
It is consistent with the new `tetraplet_store` and `canon_store`
fields.
* Make canon data more typeful
The `CanonResult` doesn't take a JSON value anymore that is further
deserialized elsewhere, but is a struct that has all data deserialized.
* Typeful `CID` type
The `CID` type has a phantom type paramter defining its value's type.
* Group cid stores and trackers
Group cid stores into `CidInfo` struct, and trackers into `ExecutionCidState` struct.
