Sidetree protocol – Massivly Scalable Decentralized Identifiers – DEEP DIVE
From IIW
Sidetree Protocol: Scalable DIDs
Tuesday 2F
Convener: Daniel Buchner
Notes-taker(s): Karyl Fowler
Tags for the session - technology discussed/ideas considered:
DID, scalability solution, blockchain-agnostic, Bitcoin, Ethereum
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
- Raiden on ETH & Lightening Network on Bitcoin are the only [channel-based] scalability solutions for transactions on blockchain protocols to date; this is not sufficient for most applications.
- Scalability Trilemma: decentralization, scalability & security
- “Scale of identity” - humans are just tip of the iceberg (7.5 Billion but devices are far more and rapidly growing)
- We need protocols that are generic.
- Requirements for DPKI: 1) global, immutable, append only logs, 2) no central providers or authorities and 3) censor/tamper resistant
- Key realization is that identity doesn’t have the same double spend issue as money.
- Although this opened a larger discussion around the nuanced challenges specific to ID.
- Sidetree technical assumptions: 1) no secondary consensus required 2) no conflicting states are allowed and [to achieve this, we anchor to layer 1] 3)ID states are siloed and do not affect each other
- “Sidetree uses blockchains as an oracle of time.” – Daniel
- Like timestamping, in that any writing node can collect operations, Sidetree protocol lets you send your operations off to another node (that say, Microsoft or another service provider is running) to avoid you paying those costs.
- Optional: Holding batch files and anchor files [vs only holding one] = enormous difference in node size for holding both vs holding only anchors
- Why would a company retain your batch data? to retrieve/parse fast for their customers.
- But, you don’t need to rely on this; you can persist this data yourself on your own node.
- Sidetree has differential capabilities, so you can have a node that only replicates your own operations or specified types of operations (e.g. financial transactions, DID attestations/authorizations, etc.)
- Sidetree relies on the layer 1 consensus model to verify DIDs
- Sidetree is 95% of a DID method; it becomes whole when applied to a chain and configured to support a chain-specific method
- Audience Question: How do you know how to resolve certain payloads on certain chains if you’re not running a node specific to a chain? Ask Orie re: what is url for DID methods we use/why we consider Sidetree a DID method [for sales]
- If I am not running a node myself, I only need one of the nodes in the network to be honest [because I will always be able to deterministically compare/check their work]; very strong property of Sidetree Protocol
- Follow On Question: Is it possible to collapse Sidetree such that all layer 1 protocols can be supported under it. Answer: Longterm, we will have libraries to reference. Other responses included:
- Perhaps “time” is confusing as a term for a premise; let’s call it “order”[of events]
- if there is no consensus on layer 2, then first hash always wins.
- The protocol is based on “first seen,” so for cross chain/interchain applications, you will need to find a way to determine first seen across chains.
- Transmute’s Element Implementation (Sidetree on Ethereum):
- Demo video: https://www.youtube.com/watch?v=KY_dt2tKQxw
- Get started: https://github.com/decentralized-identity/sidetree-ethereum
- Audience debate: some IoT devices cannot support/handle certain hashing functions, so what about the case where a device generates the DID and key?
- Further context: DID documents decouple the hashing function from the identity; some are concerned that Sidetree recouple these things in a limiting way.
- Some Answers included: The IoT device doesn’t necessarily have to know its DID in the Sidetree context
- or a Sidetree compatible DID can be generated by the protocol on behalf of the IoT
- OR you can just change the hashing method Sidetree uses when you implement it