🎣Deterministic resolution
Deterministically resolving an entity instance, including particular versions
To enable persistent resolution of nodes by address, we need to define an algorithm for deterministically traversing the graph. This definition is described assuming little more than functional Sidetree nodes able to find state at given commits, and the implementation of a resolver will differ depending on the practical applications used.
For resolution, we use both the node ID
and the version Commit
. Both are unique persistent identifiers by Sidetree definition, and uniquely resolvable due to how Sidetree deterministically resolves conflicts and cryptographically ensures document update ordering.
Some of the resolution steps laid out below linear in size complexity, while they may well be more or less constant time given a properly maintained index.
This section talks about protocol-native addressing, which something like dPID can use for resolution. This is not necessarily the same thing, depending on how dPID chooses to structure addressing.
Resolution cases
These cases define one step of addressing, grouped by type of target. However, a link is ideally done directly to a particular version of a node. This means using the unique ID and commit of an attestation to resolve that node, instead of addressing it relative to its target. This way of addressing allows for, more or less, instant lookups where relative addressing can contain multiple resolution steps to resolve.
Root node
Addressing the latest state of some node N
:
Query network for status of node
N
Particular version
Addressing a particular commit C
of a node N
:
Query network for status of node
N
at commitC
Particular time
Addressing the state of a node N
as of time T
:
Query network for update history of node
N
Find the newest commit
C
that was anchored before or at timeT
Resolve node
N
at commitC
Particular version index
Addressing a particular version k
of a node N
:
Query network for update history of node
N
Select commit
C
at indexk
in update historyResolve node
N
at commitC
Outgoing edge
Addressing of an outgoing edge from a node N
made against some other node:
Resolve
N
Get value
R
from reference fieldResolve node
R
Versioned outgoing edge
Addressing a versioned outgoing edge from a node N
made against some other node:
Query network for status of node
N
Get value of reference field
R
and version fieldC
Resolve node
R
at commitC
Incoming edges
Addressing of an incoming edge to node N
, from some node N2
of entity type T
:
Query network for all nodes of type
T
Find node
N2
withReference field set to
N1
Resolve
N2
An example of this is components or annotations pointing to a research object, and we address it from the perspective of the research object.
Versioned incoming edges
Addressing of an incoming edge to node N
as of version C
, from some node N2
of entity type T
:
Query network for all nodes of type
T
Query network for update history
U
of nodeN
Find versions
V
of nodeN2
withReference field set to
N
Version field value in
U
before versionC
Resolve
N2
, consideringV
the update history while targetingN
atC
An example of this is addressing all attestations made up until a certain point for a particular research object.
Versioned data DAG paths
Addressing a DAG node through UnixFS path P
, in research object N
as of version C
:
Resolve
N
at versionC
Get value
DAG
in manifest CID fieldWhile
P
not emptyPop first segment
S
fromP
Set
DAG' = lookup(S, DAG)
Loop with
DAG'
asDAG
DAG
is now the addressed node or leaf
Data DAG path addresses should always specify a particular research object version.
Last updated