This article is part of a series of publications that will be uploaded to this site soon that shine on a light on real-world applicability in the blockchain space.
DID (Decentralized Identifiers as they are called) refers to a decentralized identity document that can be used within some sort of authentication scheme / protocol.
Obviously, the big pull here is that blockchain (a stateless, 'relational' database of sorts can be used as the backbone of such a process to facilitate an immutable, never-ending [in theory] refernce that can be used to almost empirically pin down somebody's identity).
More information can be found here: https://identity.foundation/
On the front page, one can find more information related to the integration of blockchain into this scheme:
Blockchain-Related DID Projects
There are numerous security-related projects underneath the blockchain umbrella of the DID project.
Specifically, they are (at the time of writing):
Universal Resolver = https://github.com/decentralized-identity/universal-resolver
Universal Registrar = https://github.com/decentralized-identity/universal-registrar
.well-known DID configuration = https://github.com/decentralized-identity/.well-known/
KERI (Key Event Receipt Infrastructure) = https://github.com/decentralized-identity/keri
Peer DID Method Specification = https://github.com/decentralized-identity/peer-did-method-spec
DID Spec Extensions = https://github.com/decentralized-identity/did-spec-extensions
Integration With Ethereum
Having a hard time conceptualizing how this works or understanding what the intuitive connection / link to blockchain is?
Well, you're in luck (if you were looking to learn more about this) because there is an open source sidetree protocol scheme that was drawn up for Ethereum a short while ago (in accordance with this effort) and published publicly for evaluation.
The best part being...it comes with a GUI.
Below are two links to the relevant repositories
A) Sidetree Specification = https://github.com/decentralized-identity/sidetree
B) Element (basically an implementation of the sidetree protocol within a GUI context) = https://github.com/decentralized-identity/element
More On Sidetree and Element
As noted in the original Sidetree Repo (not linked above because it was archived and replaced with the two repositories that we did name), the sidetree protocol:
"Is a REST API that supports anchoring of Sidetree Transactions to the Ethereum [and any other blockchain for which specification is built upon]..."
also
"A Sidetree Transaction is a JSON Document of the following format"
{
"transactionTime": 53,
"transactionTimeHash": "0xa6dd7120730ddccf4788a082b0b5607fd1f39dbb80ebc170678551878b90b835",
"transactionNumber": 15,
"anchorFileHash": "QmcModh3cTgSpr8A6m7jNHnwVZRGZsepWv3uaFtD5KhL2U"
}
"The anchorfilehash is a multihash content address for an anchor file of the following format"
{
"batchFileHash": "QmcModh3cTgSpr8A6m7jNHnwVZRGZsepWv3uaFtD5KhL3U",
"merkleRoot": "b6dd7120730ddccf4788a082b0b5607fd1f39dbb80ebc170678551878b90b836"
}
"The batchFileHash is a multihash content address for a batch file of the following format:"
{
"operations": [
"eyJzaWduaW5nS2V5SWQiOiJrZXkxIiwiY3JlYXRlUGF5bG9hZCI6ImV5SkFZMjl1ZEdWNGRDSTZJbWgwZEhCek9pOHZkek5wWkM1dmNtY3ZaR2xrTDNZeElpd2lhV1FpT2lKa2FXUTZjMmxrWlhSeVpXVTZhV2R1YjNKbFpDSXNJbkIxWW14cFkwdGxlU0k2VzNzaWFXUWlPaUpyWlhreElpd2lkSGx3WlNJNklsTmxZM0F5TlRack1WWmxjbWxtYVdOaGRHbHZia3RsZVRJd01UZ2lMQ0p3ZFdKc2FXTkxaWGxJWlhnaU9pSXdNamMyWXpJek5EZ3dNelU0TWpJeE9EZ3dPVFkwTlRWaU4yWXpaakprTlRaaE5HSmhZbVU0WkRka09UZGpZMlF5TmpnMVl6VXdZbVJpTXpVNFpHUmlOekVpZlN4N0ltbGtJam9pWkdsa09uTnBaR1YwY21WbE9tUnBaRkJ2Y25ScGIyNUpaMjV2Y21Wa0kydGxlVElpTENKMGVYQmxJam9pVW5OaFZtVnlhV1pwWTJGMGFXOXVTMlY1TWpBeE9DSXNJbTkzYm1WeUlqb2laR2xrT25OcFpHVjBjbVZsT21sbmJtOXlaV1JWYm14bGMzTlNaWE52YkhaaFlteGxJaXdpY0hWaWJHbGpTMlY1VUdWdElqb2lMUzB0TFMxQ1JVZEpUaUJRVlVKTVNVTWdTMFZaTGpJdVJVNUVJRkJWUWt4SlF5QkxSVmt0TFMwdExTSjlYU3dpYzJWeWRtbGpaU0k2VzNzaWRIbHdaU0k2SWtsa1pXNTBhWFI1U0hWaUlpd2ljSFZpYkdsalMyVjVJam9pWkdsa09uTnBaR1YwY21WbE9tbG5ibTl5WldRamEyVjVMVEVpTENKelpYSjJhV05sUlc1a2NHOXBiblFpT25zaVFHTnZiblJsZUhRaU9pSnpZMmhsYldFdWFXUmxiblJwZEhrdVptOTFibVJoZEdsdmJpOW9kV0lpTENKQWRIbHdaU0k2SWxWelpYSlRaWEoyYVdObFJXNWtjRzlwYm5RaUxDSnBibk4wWVc1alpYTWlPbHNpWkdsa09tSmhjam8wTlRZaUxDSmthV1E2ZW1GNk9qYzRPU0pkZlgxZGZRIiwic2lnbmF0dXJlIjoibnFTNDNLeTNYUjBmanRQTHFVaHpTRWhKLWlUbEJ0ZXdGdDl1dDN3YVhyMWhaRTRQSy1VcXZEYzlzVUtscTZNX0hDdHkxVkM1U1Fpa0FPVlRPN3JnRkEiLCJwcm9vZk9mV29yayI6InByb29mIG9mIHdvcmsifQ"
]
}
"The merkleroot is used [to] prove that a given operation is included in a batch."
Overall Gist of the Sidetree Protocol and its Relevance in a Blockchain Context
While we all look at blockchain explicitly within the context of sending / receiving money, the cryptographic aspect of it seems to get ignored (consistently, for whatever reason).
However, it is this property of blockchain that provides the most promise when coupled with the functionality of blockchain itself (i.e., specifically Proof of Work).
Proof of Work is the Glue That Makes This a Uniquely Effective Solution
While there are many things that we can critique about blockchain, one accepted concept is that the payments that are being made on the larger protocols (i.e., Bitcoin & Ethereum), are considered to be valid.
By 'valid', I mean that there isn't really anyone running around questioning whether the transactions on those protocol are "counterfeit" in any way.
And why should they?
The cryptography laden within these projects alongside the public chain of transactions the produce allows for:
Independent verification of the chain with the greatest 'Proof of Work'.
An objective definition for what qualifies as 'Proof of Work' (so that there can be no disagreement / difference of "opinion" on the network -- not that there can't be dissent in the network, but no disagreement of opinion).
Any attacker looking to compromise the network is still burdened to adhere to the Proof of Work specifications, so we end up in a circular situation where an attacker must essentially perform the same tasks that legitimate miners do in order to subvert the protocol (which means that it would more than likely be in the favor of a given attacker to simply mine honestly if they are able to 'compromise' the protocol in this manner ; this makes the Ethereum Classic situation a bit more interesting...but that's a different story).
What This All Means
In essence, the hashes that are stored within blocks (for each and every single transaction), can be leveraged within the context of an outside protocol as an 'anchor' for whatever information that the protocol is relying on (i.e., hash of someone's transaction, identification #, etc.)
Live Example
As promised, there is a live example / implementation of the DID sidetree protocol at https://element-did.com/
GitHub Repository: https://github.com/decentralized-identity/element
A Live Look at the Ethereum Sidetree Protocol Implementation
Scrolling down a bit further on the page, there is a 'Create Wallet' option as well as the tour that's taken.
Assuming that one has the Metamask wallet downloaded, they'll be me with the following text when they attempt to create a wallet on this 'sidetree protocol':
"Your keys are ready for use. If you wish to reuse these keys in another application, you must lock this keystore and then export it."
Best to Spin Up Your Own Node in Practice
That's just my personal opinion (take it with a grain of salt if you want) - but this is something that I would personally run off of my own node (versus a public one).
This obviously would not obfuscate anything that's going on, but it would prevent one from having their transactions aggregated and listed among the backdrop of other similar transactions as one can see below:
Wrapping Up
This is just a fresh take on blockchain that doesn't involve promoting a specific project / token / etc.
It seems that there's so much focus in this space to re-invent the wheel a million times over (for profit), that no one has taken the time to examine the solutions that have already been created (i.e., Ethereum).
This sidetree protocol also validly works for Bitcoin as well (again, why is no one considering this as a viable authentication / identity-based solution?)
Oldest comments (0)