pub fn must_get_valid_record(
action_hash: HoloHash<Action>,
) -> Result<Record, WasmError>Expand description
MUST get a VALID Record at a given ActionHash.
The Record is guaranteed to be valid.
More accurately the Record is guarantee to be consistently reported as valid by the visible network.
The validity requirement makes this more complex but notably enables inductive validation of arbitrary graph structures.
For example “If this Record is valid, and its parent is valid, up to the root, then the whole tree of Records is valid”.
If at least one authority (1 of N trust) claims the Record is invalid then a conflict resolution/warranting round will be triggered.
In the case of a total eclipse (every visible authority is lying) then we cannot immediately detect an invalid Record.
Unlike must_get_entry and must_get_action we cannot simply inspect the cryptographic integrity to know this.
In theory we can run validation of the returned Record ourselves, which itself may be based on must_get_X calls.
If there is a large nested graph of must_get_valid_record calls this could be extremely heavy.
Note though that each “hop” in recursive validation is routed to a completely different set of authorities.
It does not take many hops to reach the point where an attacker needs to eclipse the entire network to lie about Record validity.
If you do not care about validity and simply want a pair of Action+Entry data, then use both must_get_action and must_get_entry together.
must_get_valid_record is available in contexts such as validation where both determinism and network access is desirable.
An Record will not be returned if:
- It is ABANDONED by ALL authorities due to failed validation
- If ANY authority (1 of N trust) OR ourselves (0 of N trust) believes it INVALID
- Nobody knows about it on the visible network
If an Record fails to be returned:
- Callbacks will return early with
UnresolvedDependencies - Zome calls will receive a
WasmErrorfrom the host