Guarantees for clients

[domwoe]

I like the independence of Sidetree nodes a lot, but I'd be interested to read something about the guarantees a Sidetree node can provide to its clients.

As far as I understand the protocol it seems to me that if a client asks a Sidetree node to resolve a DID, the node is able to withhold deltas. Thus, I have to trust the node that it gives me all the information, i.e. the complete and current state of the DIDdoc or I need to ask a sample of nodes.

Is this view correct or are there any additional mechanisms that can provide better guarantees to clients?

Thanks a lot!

[csuwildcat]

You are correct in noting that without running a node yourself, the best you can get by asking one node what the state of a DID is would be to receive the latest state, deltas it is made up of, and proofs you could check against the underlying chain to verify presence of the deltas. However, an external node could always do things like exclude the last N number of deltas in a DID's history and you wouldn't know more existed beyond that false tip unless you ran a node yourself.

One way to make node-less clients calling in for resolution to external nodes a more trust process would be to do as you say: create a process where you query a random set of external nodes and use the protocol rules to validate and filter the returned results to ensure they are telling the truth. I have been thinking about ways to do this, but we are a ways off from starting work on it.

[domwoe]

Thanks Daniel for clarifying!
This is where a L1 Ledger based DID (can) have an advantage. For example with the Indy network, a read request to a node is replied with a state proof with a BLS multi-signature of the validators. Hence, the client needs only to keep track of the validator set.

However, in principle, some sidetree node operators could come together and provide such a service to clients.

Another approach could be something like https://slock.it/incubed/

From my perspective this issue can be closed.

[csuwildcat]

I'm not sure there's any real advantage to what you're alluding to, for the following reasons: 1. If one argues there is greater trust in an L1 DID ledger, there are two realities to consider: A) ultimately you're still just trusting the basis and level of immutability conferred by the L1's consensus mechanism, and B) you're just pushing all the data/load you would have had in the L2 system down to the L1. It then follows that maximum trustless operation would require running a full L1 node (at least to process and prune - which you can do with an L2 as well), so there's not a real difference in scalability/resource requirements between the two approaches. 2) But if you read point 1 above and think "But with some non-PoW L1s, I can get state proofs from operators without running a node", therein lies an implicit admission that your system is not based on a foundation of highly irreversible hardness: it's simply based on constantly trusting some set of trusted validators were not, and are not at this moment, lying to you. There's no magic bullet in PoW systems either: even if I snapped my fingers and tomorrow Bitcoin became a PoW-based DID L1, there would be two realities to contend with: A) to realize the far superior reversability hardness of PoW (because unlike trusted validator systems, you can't lie about past history after a few blocks), you'd still have to run the L1 to achieve maximum trustless operation, and B) similar to how trusted validator proofs are a mirage (given they boil down to "A group of authorities aren't lying"), having your cake and eating it too in a PoW system that claimed not to require running a node would effectively be a proclamation that you've solved fraud proofs, which most folks don't believe is even possible. What all this means in the end is that querying a sufficiently random set of nodes who operate a PoW-based L2 and provide verifiable inclusion proofs for each CRDT delta they used in assembly of the current DID Doc state is *at least* as good as a 'proof' from a trusted validator network. Why? Because while you're still not getting the superior hardness guarantee of running a node, at least the PoW inclusion proofs would come with a mathematical guarantee that the resolved DID deltas/state you received was not based on trust of the node query set alone, because you could verify they exist in a highly immutable history. In conclusion: run at least a light node that contains the full set of minimal proving data/history, or your guarantees are diminished regardless of the approach.

[kdenhartog]

For what it's worth, I believe things like satoshi audit trail and SPV could be used in sidetree to make it easier for a trustless lite client to be built. My thinking in #336 is a naive approach to achieve this.

[csuwildcat]

Copying over from #336:

@kdenhartog without at least running a light Sidetree node that stores all the anchor files, the only assurance you'd gain in a chain inclusion proof for op deltas is that whatever delta trail a node responded with was indeed present in the target chain, but there are many attacks possible - for example:

Say Alice has performed 5 ops against her DID. The last op was to remove a key she believed could have fallen into someone else's hands. A node could simply resolve the first 4 of her ops and omit the last one, and if all you had was proof of chain inclusion, you'd never realize it was a 'fake tip' of her total state. You must run a light node to avoid such attacks, or, for a lesser security assurance, query a larger randomized subset of nodes to probabilistically increase the chances you receive the correct current state.