Niko’s Blog

I Looked Into 34 Top Real-World Blockchain Projects So You Don’t Have To

2022-07-30T04:21:46+00:00

TL;DR: The top #1 Google result for “blockchain production users” (and related queries) lists 34 individual “real world blockchain” projects. One would expect some actual functioning projects that have an impact on every-day consumers — outside of cryptocurrency & NFTs. Looking into all 34, I found that 13 are already dead (including one that has been killed by the SEC), 6 are only useful within the crypto & NFT ecosystems and not in the “real world” and 14 use Blockchain in a way where removing the blockchain would not impact functionality at all, or make the product better. The remaining project is Chainalysis, which has real-world impact by helping law enforcement de-anonymizing blockchain users.

Overview and Scope
The Dead, the Bad & the Ugly
Not The Real World
- Money Transfer Use Cases
  - Chain.io: Not Blockchain
  - Algorand, Gemini & Circle: Crypto only
- NFTs
  - Candy, Pixura, Dapper Labs [not real world, bad dlt]
And The Winner Is…
Closing Words

Overview and Scope

If you ask people without, or with limited background in tech about Blockchain (or Distributed Ledger Technology, “DLT”), the general understanding is that, even though the Cryptocurrency and NFT ecosystem is plagued by scams, Blockchain is the ‘Future of IT’. Deloitte compares it to the arrival of the postal services or the internet. “Forget Bitcoin: Blockchain is the Future” blogs Investopedia, “How Blockchain will change [everything]” writes Nasdaq. Even within the IT industry, plenty of people bought the hype:

“Blockchain will be as important to the next generation of internet applications as the public cloud, microservice architectures, and devops are to the current generation” [infoworld]

“Blockchain is ideal for delivering that information because it provides immediate, shared and completely transparent information stored on an immutable ledger that can be accessed only by permissioned network members.” [IBM]

But while the 13 years of blockchain’s existence certainly had no shortage of prototypes, promises and PR, outside of cryptocurrencies, darknet markets and money laundering use cases, it is hard to find news articles or an overview about real-world use cases of Blockchain technology. So I decided to dig myself.

The top search result for “blockchain real-world applications” on Google is this builtin.com article, titled “34 Blockchain Applications and Real-World Use Cases Disrupting the Status Quo“ (archived version). Quote:

We’ve rounded up 34 examples of real-world blockchain use cases for this pragmatic yet revolutionary technology. It’s far from an exhaustive list, but they’re already changing how we do business.

Apart from being the top #1 result, and a reasonably recent article, Builtin.com has 300+ employees (per linkedin), and is a company built around the tech startup community. Part of their business seems to be maintaining a database of startup companies, including the ones mentioned in the Blockchain article — so they have some business incentive for the data to be accurate.

Additionally, the majority of the following results did not list actual projects or products, but rather high-level ideas like “Supply chain management”, “Healthcare”, “Food Safety” etc. — usually with a 2-3 sentence high-level description, but no concrete examples¹.

So I figured the Builtin list would be a good starting point to find & check out some real-world use cases.

For the purposes of this article, I am making the assumptions that the projects should be

Not just crypto: As the point of this article is to find applications outside of cryptocurrency, I’m categorically excluding anything where the only effect of the application is in the user’s cryptocurrency wallet.
Not Dead: Projects should have had a sign of life in the last ~12 months or so.
Not Bad: Uses Blockchain, and in a way that makes sense
- They do use a Blockchain/DLT, and
- The DLT adds some form of value to the users, and
- The value add comes at reasonable tradeoffs: the product is still somewhat usable and does not cause (obvious) legal problems.

It turns out, these are sufficient to cross out 33 of the 34 projects from the list. I have listed those in the next section, in the order in which they appear in the original article.

The Dead, the Bad & the Ugly

Smart Contract Use Cases

Smart Contracts as a concept have their own set of problems, but luckily that doesn’t affect any of the projects Builtin listed in this category — because none seem to use them.

BurstIQ: Not Blockchain, Bad Blockchain, Prototype

Bad use of Blockchain, unfinished Prototype, and likely does not use DLT at all. The website is full of marketing buzzwords, and apparently they seem to have pivoted back and forth to IoT at some stage, and now to web3. Completely lacking is any technical description on how the system works, beyond a few high-level buzzword-filled boxes.

Their careers page mentions blockchain only in passing, nothing blockchain-related in the skills/qualifications sections for any engineering role — AWS & SQL everywhere, though.

The word “blockchain” appears only twice in their whitepaper, both times in the last sentence:

“The BurstIQ platform connects any data from any source in a global network of businesses, researchers and people, through a full end-to-end blockchain enablement system with blockchain-based big data management, consent and data sharing, cognitive computing, monetization and global data exchange.”.

This is also the only sentence describing the platform’s functionality in the whole whitepaper.

There is a “Tell me more” link to sign up for a 60-day free trial for BurstIQ. The link doesn’t work.

Mediachain: Dead

Dead: Acquired by Spotify in 2017. Website and Twitter last updated then. There has been no mention of any progress on Mediachain’s core proposition within Spotify ever since. In 2022 though, Spotify is recruiting people to work on early-stage Web3 projects — they are starting another prototype.

Propy Inc: Bad

In 5 years, they seem to have sold only 2 properties: One in Kyiv (2017) and one in Tampa, FL (2022). The article is somewhat ambiguous what rights you own with the NFT — it’s either “access to the paperwork” or some “ownership rights”. I reached out to Propy and asked what happens when you lose your keys. The answer was, in effect, “we’ll give you new login information”(!). In other words, you don’t actually own or manage the NFT, Propy does. All the advantages you are supposed to get with NFTs, access to the DeFi ecosystem for example, or easier transfers, obviously can’t happen in this case. What happens if Propy runs out of funding and shuts down? Do you still own your house? All Blockchain does here is muddy the waters w.r.t. legal responsibilities & adding more complexity to the purchase process.

Whereas earlier this year, “NFT” was all over their homepage, as of mid 2022, they seem to be pivoting away from NFTs — they seem to be focusing on being a real estate sales management platform, maybe a title and escrow company, neither of which has anything to do with blockchain; they also seem to be taking zillow (or similar) listings and offering to pay for the listings with cryptocurrency — which, in essence, makes them an exchange.

Internet of Things

The Blockchain is supposed to secure “everything from an Amazon Alexa to a smart thermostat.” by it’s “transparency and virtual incorruptibility”. This did not make sense to me in the first place, and apparently it did not make sense to Builtin’s featured projects either.

Filament: Dead

According to their website, they have pivoted to automotive. Their LinkedIn and Twitter have both been dead for 2+ years, and the only change their website has seen since 2019 is that the series A investors (Verizon Ventures, Bullpen Capital) have pulled out..

HYPR: Not Blockchain

The Builtin article claims that HYPR makes “IoT devices virtually unhackable” by “By taking passwords off a centralized server”. It is hard to find any references to IoT on their website, their Blog barely mentions IoT anymore — in fact, since Jan 2020, only one articlementions it — in passing.

Searching their website for “blockchain” yields only 8 results(of over a thousand pages). All of these are either only tangentially related “encyclopedia” articles, and/or updated 2017 or earlier. There is no indication that HYPR has used anything blockchain related for at least 4 years.

Xage Security: Not Blockchain

Not DLT: Last mention of “blockchain” on their site in September 2020. A partnership with the US Space Force, no less.

Similarly, their Twitter account — which tweets daily –- has last mentioned “blockchain” in July 2020.

They seem to be pivoting to “zero-trust”, away from blockchain. In fact that’s in the title of the main whitepapers at the time of writing, whereas any mention of Blockchain is completely absent.

Trying to access the actual whitepapers requires you to provide an abnormal amount of personal data — not a good look for a security-focused company to harvest PII. Most of the documents can be found with a filetype google search — also not a good look if it’s that easy to bypass their “security”.

Still, after downloading and going through the whitepapers, it remains fundamentally unclear what they were actually trying to do with their blockchain system — even high level information like “what kind of data is stored on the blockchain” is completely absent. . They keep talking about Xage being tamper-proof due to blockchain in virtually every document they reference blockchain in. This is plainly false, Blockchains are tamper-evident and maybe tamper-resistant, but not tamper-proof². Bad start.

The little information that is available raises way more questions than it answers. In their NIST Cybersecurity compliance analysis doc, they claim that their encryption scheme somewhat benefits from blockchain. There’s two, and both are messy:

Data stored in Xage Fabric is encrypted on a per publisher and subscriber basis end-to-end.

If all data between all participants on the network is end-to-end encrypted with per-channel keys, how exactly do you get a readable presentation in the audit log? Are the keys centrally managed? Clearly this encryption scheme is orthogonal to any blockchain use, but since we are using blockchain: What happens if the key material of one node gets compromised and you need to rotate the keys, how are you going to re-encrypt past entries without breaking the blockchain/merkle-tree?
Data stored in the Xage Fabric is encrypted using a threshold based encryption technique called Shamir Secret Sharing.

Compromises on Fabric will require simultaneous access to multiple (threshold) Xage Fabric nodes to provide their shares making data leaks substantially more difficult compared to central databases and not exploitable.

This makes no sense to me, whatsoever. The only interpretation that I can get out of this is that the data at rest (on disk) is encrypted with a secret-sharing scheme, and that each blockchain node holds a chunk of the key. You’d need M-out-of-N chunks to decrypt the data.

That sounds nice for 5 seconds, until you realize that there must be mechanisms for participants to read the data — for which the participant has a valid reason to contact those M nodes. At that point the participants obtain the “*simultaneous access” *to the key material. The encryption scheme offers protection only when some (less than M) database nodes are compromised, but not against compromise of any of the other (e.g. desktops, IoT) devices in the network.

Assuming this system makes sense, it can just as well be implemented without a blockchain, but with a central database and separated keyservers. It can be reasonably assumed that this would actually be more secure: Separating Database and Keyservers would mean that there is fewer software running on each node, which would mean fewer security concerns; and the key server code could be much smaller (compared to a node also containing the blockchain and database logic) and can be audited better.

Personal Identity

It should go without saying that putting anything ID-related on a public ledger is a privacy and GDPR nightmare³. I have talked extensively about the combination of DID and Blockchain in my previous article, which contains even more dead projects.

Ligero: Dead

The company was founded in 2018. Their website has no information on the platform, or on any activity. There doesn’t seem to be a twitter or a company Linkedin profile. I was unable to find the CEO on LinkedIn, the CTO has no mention of Ligero in their LinkedIn profile, and neither does the company president.

Illinois Blockchain: Dead

The “Final Report” was published to their website in 2018, and the “Illinois Department of Innovation & Technology” twitter account has not mentioned Blockchain since 2019

Civic: Bad

Doesn’t use DLT at all: This company provides ID verification and MFA login services, specifically targeted at blockchain and NFT companies — they don’t sell a product that utilizes blockchain itself.

Evernym: Bad

While the whitepaper from 2016 talk about a distributed ledger, none of the two case studies talk about their use of blockchain — in fact, the infographic in the former makes it pretty explicit that no blockchain is involved. The second one seems to use the same on-phone storage for credentials, without blockchain. I have discussed Sovrin, which is the creator of Evernym, in my previous article — I reached out to them, and apparently, for a single project, they write to a private Hyperledger instance — but their client doesn’t read from it. They did not clarify why that hyperledger is even there. They did mention that they are exploring non-blockchain solutions.

Ocular: Dead

The website ends with the registration form for the affiliate partnership program, which has the note “Please note this is in early beta stages and estimated to start high volume testing early September 2019.” The copyright is from 2020. There are no technical specs whatsoever. The Twitter account @ocularkyc has a Manowar profile picture, and limits its post to central-bank conspiracy theories.

Healthcare

As with identity, what was really missing from the healthcare system is that all that privacy sensitive data is on a publicly accessible ledger.

WholeCare: Bad, Likely Dead

There is virtually no information at all on their website. The most detailed technical facts are

“Resources to orient new caregivers”, “HIPAA-compliant record keeping”, “Integrated scheduling tools & alerts”, “Cross-device compatibility”.

That’s it.

There is no mention of blockchain or DLT on their website. Their twitter account retweets a WaPo article every few months.

Patientory: Bad, Likely Dead

The app seems to mainly be focused on tracking exercise, water, body photos — nothing that fitbit & co can’t do today. Hardly “requires blockchain”. There is some talk about storing patient data in the PTOY Blockchain (which seems to be the token associated with the chain). https://ptoy.org/ There’s a Whitepaper from 2017, which shows a wonderfully centralized architecture:

This graph could be stripped down to 3 nodes, with the same exact functionality, but less complex, cheaper, and more performant. It even explicitly says that all the storage work is done by a “HIPAA Compliant Database”, so blockchain doesn’t add anything here.

This is a classic 2017 ICO boom project that somehow manages to still occasionally write tweets.

Bonus: The “App Store” and “Play Store” links actually lead to a “subscribe” page, not an app store page. I doubt that is in compliance with Apple’s and Google’s respective policies. For example, the play store guidelines state: “Any online use of the badge must link to the Google Play store.“ The badge images are also clearly altered, prohibited by both Apple and Google’s TOS.

Pretty obvious trademark infringement on your homepage, for a company in a compliance-heavy industry – that bodes well.

Nebula Genomics: Bad

This company claims to allow people to buy their DNA sequencing kit anonymously via bitcoin. Which makes these pop-ups particularly fun:

Of course, the checkout process does not accept crypto at all.

There is some whitepaper that claims they can store and share genomics data in a privacy-preserving way. https://www.biorxiv.org/content/10.1101/799999v1. As dumb as the idea is in general, the whitepaper at least seems somewhat technically interesting. But that doesn’t really matter, because the data is sequenced in Hong Kong, or “in Europe”, so who knows who has copies of your data. And even if nobody stored the data: “However, under certain circumstances your genetic information may be subject to processing pursuant to laws, regulations or judicial or governmental orders, warrants or subpoenas. “ — in other words, whatever technical locks they have in place, Nebula has a master key. (Wikipedia)

Medicalchain: Dead

The Whitepaper is from 2018, the roadmap ends in 2021Q1. Their Twitter has been dead since March ‘21.

Logistics

Are logistics companies, and the businesses they work with, interested in broadcasting their business activity to their competitors — by putting reports, receipts & manifests on a public ledger?

… Let’s find out.

DHL: Dead

Dead and/or never left prototype phase: The last press release is from 2019, about a MvP they tested with Hewlett-Packard Enterprise. There is no technical description, no details, no further updates. They did provide an overview PR document, and it’s an entertaining read, especially section 2 ”Blockchain Examples across the Industry”: Every single example is “experimenting with”, has “built a prototype” or is “testing”. None deployed a prod product.

The exception is Powerledger where they claim to have deployed the product — but spot-checking a few of their 30 clients, all of those are either small-scale deployments (e.g. prototypes w/ 30 kWh) or in planning/prototyping stage.

Powerledger is an interesting one though, as it mixes both a fake blockchain approach (Per the whitepaper: private blockchain in section 5.3, off-chain channels in section 5.4, and an off-chain trading engine in section 5.5.) with what looks like a 2017 “ICO scam” ($POWR) — to build an energy market, which already has working real-world non-blockchain implementations.

Hewlett-Packard Enterprise’s Blockchain Solutions page has issued their last “News” in 2018.

Block Array: Dead

The link on the Builtin.com article links directly to their Facebook page, which hasn’t been updated since March 2018. Their actual website (blockarray.com) is gone.

Maersk: BadDead

Updated 2023-01-13: Maersk announced that they will be shutting down Tradelens in early 2023, as “need for full global industry collaboration has not been achieved”.

Bad DLT: I actually spent a serious amount of time looking at Maersk — this is a platform that actually seems to work, is used by customers, and they seem to be using a Hyperledger internally.

The problem arises when you look at what that blockchain actually does. Virtually every component in the system is gated by an IBM.com login, there are multiple disconnected blockchains with nodes operated by only a few participants, nodes can only be accessed through APIs hosted by IBM (ACL’d off, of course), data is (by necessity — GDPR) mutable, and not all data is shared by all participants.

The blockchain only seems to be used to store hashes, which you (if you have access) can then compare against a separately stored document (if you have it). This does, of course, not preclude existence of other, conflicting documents in the blockchain, nor does anything really stop the few node operators to collude and re-write history — for which there might be legal reasons, like GDPR, which one node might not even be at liberty to disclose to other parties.

In essence, this is a working system, with a blockchain slapped on the side for PR reasons. Blockchain integration probably does not make the system (much) worse – especially given that it seems to affect only a tiny part of a (presumably) massively complex shipping management system.

But it doesn’t add value either: At the end of the day, “trust in the data” is established through the IBM logo on the login screen⁴, not through the blockchain.

ShipChain: Extra Dead

Extra dead: https://web.archive.org/web/20210619020901/https://shipchain.io/settle.html

In the offer of settlement, ShipChain, Inc. offered, among other things, its payment to the SEC of $2,050,000 […] Unfortunately, ShipChain, Inc. is now without sufficient resources to continue its business. Consequently, ShipChain, Inc. has made the difficult decision to cease operations and is now in the process of closing its affairs.

It should be noted that this was in 2020, and it’s still listed when google searching for “blockchain production users”

Government

This is a category where, at least in theory, you’d expect the ‘everything is public’ aspect of the blockchain might add some transparency use cases. Unfortunately, in the projects listed, it doesn’t.

Voatz: Very, Very Bad

Bad DLT: Now, e-voting is obviously a really bad idea (EFF has tons of material,OpenPrivacy on Swiss elections ‘19, CCC on Germany 2020). There’s a principle in democracies that every person needs to be able to understand how the result was calculated, and why it is anonymous and secure. With that, I invite you to read the “Technology” on Wikipedia, in particular:

“The blockchain infrastructure of Voatz includes 32 identically arranged verifying servers that are distributed across Amazon’s AWS and Microsoft’s Azure.[16] Each server runs an identical copy of Hyperledger, an open source blockchain software.[17]

Once a user downloads the Voatz app, they verify their phone number, provide a photo ID, as well as a “selfie”. Facial recognition and voter rolls are used to verify identity and confirm a match between the picture and ID submitted. After the user is offered a secure token (activated through the use of a fingerprint) applicable to eligible elections, the user’s biometric information is removed from the Voatz system.[18] After all votes are submitted to Voatz, votes are printed on a paper ballot and fed into a machine.”

Also, the intro and “Security Assessment” and “FBI Investigation” sections are entertaining.

Now with that out of the way,

Voatz uses paper ballots as the source of truth. The votes are apparently printed out, fed into a machine, where they are then counted. Why is there a blockchain system in the middle, at all?
Voatz uses a replicated, permissioned hyperledger which (apparently) can only be accessed through their APIs. How does blockchain provide auditability here? So what exactly does the blockchain do here again?

A 2020 security review by researchers at MIT came to a similar conclusion:

We further find […] that the system’s use of the blockchain is unlikely to protect against server-side attacks (§5.2).

The whole article, but in particular Section 1, is downright scary. Particularly worth pointing out is that Voatz refuses to give a detailed description of how their election system works, citing IP concerns⁵. So much for the whole idea of “transparency”.

David Gerard has covered Voatz extensively.

State of Delaware: Dead

Dead: Via technically:

It’s been four years since that episode, and while corporations have the state’s authorization to use blockchain for record keeping, it’s unknown how many Delaware corporations are using it for stock ledgers.[…]

Technical.ly has reached out to the governor’s office and several individuals directly involved with the evolution of the initiative and has not yet received a response. It’s also unclear what came of the Symbiont proof-of-concept.

Follow My Vote: Very Bad, Almost Dead

Dead (-ish): Founded 2012. Virtually every article covering this project (from their ‘press’ section) was written in 2017 or earlier. Their Twitter account has not posted this year.

This seems to be mostly equivalent to Voatz, with the same privacy & security problems of the “one blockchain transaction per vote” approach. Sure, you may need to hop on a VPN, that you paid for anonymously, and you need to make sure that there’s no CCTV cameras watching you vote – otherwise people, corporations or governments could de-anonymize your vote. Small price to pay for a blockchain based system.

As with Voatz, there is basically no technical documentation. They have an infographic on how their cryptographic process works. Can an average person understand how this is secure & privacy-preserving?

In early 2021, they apparently scrapped the approach they have been working on, to build a new fundamental platform called “Pollaris”. A year later, they uploaded one commit to Github. There has been no activity since, nor was I able to find any documentation on this system. It is unclear whether the posts above refer to the pre-Pollaris, or the post-Pollaris system (but then again, it wouldn’t really matter either way).

Media

Per builtin:

“Blockchain’s strength in the media industry is its ability to prevent a digital asset, such as an mp3 file, from existing in multiple places”.

Wait what

MadHive: Bad & Mostly Dead.

The company’s core business (Adtech) actually looks alive — but not the Blockchain part. With the sparse information available, it looks like they had two previous attempts to do ‘something with blockchain’, AdLedger and MadNetwork.

The last post on AdLedgers’sMedium page is from 2019, so that’s almost certainly dead. The whitepaper assumes a permissioned Ethereum blockchain:

They do explain why this is required:

But they do not explain why using an immutable ledger, when you need to be able to delete, makes sense.

They then talk about the need for “real time updates”, without the need of a “blacklist”, and somehow the “distributed state machine” of a blockchain is a way to achieve that. They don’t actually explain why.

The other DLT attempt seems to have been a thing called “MadNetwork”.

“MadProduction’s MadNetwork will allow for the mining of MadBytes and minting of MadTokens which need to be managed through an accessible user interface.”.

The above quote is from a job posting that exited when I started researching for this article, but has since been pulled (cached version).

Assuming that this is the same as https://www.madnetwork.com/, their last big update — still featured prominently at the top of the page — is from 2020, announcing that they are working on a prototype with Verizon.

There is no indication that “MadNetwork” is anywhere close to even being in a prototype stage. It is unclear even whether this is supposed to be a distributed PKI, or a fraud-detection network for adtech. MadHive’s own “resources” section only lists documents from 2019.

Steem: Dead & Bad

Steem.it is a reddit-ish social media platform. It is very close to dead these days: Per dapp radar, its usage has dropped from 33k users / day to about 35, making this project 99.9% dead. Justin Sun took over the chain, and the community left for a project called Hive.io.

However, if you do consider the few remaining users as a “real world use case” (or include Hive), there’s plenty of bad DLT to go through here, too.

The big and obvious problem is how an “uncensorable” platform would deal with illegal content (CSAM is the obvious example). The answer is apparently: they don’t, they can’t, they just hope nobody will ever upload anything illegal.GDPR is of course a problem too. Steemit responds to legal requests by censoring the content in the app, apparently hoping that nobody will look into the Steem block-explorer — where the content remains. Social Media on Blockchain creates a worst of both worlds situation: You need a content moderation team, just like existing social media platforms — but they can’t actually delete the content form the database, so node operators are still broadcasting it.

SteemIt also has all the classic cryptocurrency traits: a history of stealing funds through soft & hard forks, threats of class-action lawsuits, hacks, and the earning model being a pyramid scheme (with the twist that early investors make money not only from later investors, but also from creators).

A similar project DTube, which is a youtube-esque social media platform, requires you to refresh the IPFS cache every few days to keep your videos alive: https://hive.blog/witness-update/@quochuy/your-previous-d-tube-videos-don-t-play-anymore-how-to-prevent-this-from-happening-again-without-technical-skills

Reddit exists, micropayments in social media have been tried over and over again before DLTs came around (Flattr,Google Contributor). Steemit does censorship internally, thus the key argument for “uncensorable posts and transactions” is not valid. Blockchain has no reason to be integrated here, and makes things worse.

Open Music Initiative: Dead

Dead: Last blog posts in 2018, most about hackathons, conference attendance, no actual products. Seemed to have tweeted about industry-related things until October 2020, and only tweeted twice since.

Not The Real World

Money Transfer Use Cases

Money transfer use-cases would fall directly in the category of “crypto-only”. For as long as Bitcoin has existed, this has been touted as a great use-case — but it never really materialized.

Chain.io: Not Blockchain

According to the Builtin article, Chain.io’s “cryptographic ledgers help financial institutions safely and efficiently handle the transfer of cryptocurrencies.” There is no mention of this on their homepage. It looks like they have now completely pivoted from being a blockchain-financials company to being a logistics-on-cloud platform. Their careers page summarizes their company as

Chain.io is a cloud based integrations platform that connects partners across the global supply chain.

The last mention of DLT in their blog is from 2018.

Algorand, Gemini & Circle: Crypto only

Not real-world projects. As discussed in the introduction, I am only discussing projects that have real-world effects outside of cryptocurrency balances. Gemini, Circle as exchanges, and Algorand as a Blockchain implementation, don’t qualify here – they don’t actually add real-world utility other than moving tokens around.

NFTs

Candy, Pixura, Dapper Labs [not real world, bad dlt]

As a whole, NFTs violate both the “real world” requirement, but they are also a really bad engineering solution for the “non fungibility”

In particular — see the Propy use-case above — when real-world ownership law meets stolen or lost keys, real-world wins. This also seems to be the case with the copyright law & Seth Green’s stolen ape — a stolen NFT is unlikely to give you rights. Ownership does, but that is not the same as possession. So the “NFTness” of the Ape doesn’t add any better management or transferability of ownership, the exact opposite is the case: it muddies the waters, adds another layer of complexity.

But not only are there complications unifying “ownership” with the real world and the crypto world; even within crypto “uniqueness” (and thus the “ownership over the thing”) is far from guaranteed.

If Ethereum forks (again), each NFT would be duplicated, and can be sold individually on each chain. Of course, OpenSea might just declare one of the two forks the canonical one, but other platforms might disagree. From a purely technical (“code is law”) perspective, both forks are equally valid.
It is of course possible to just clone the whole contract and plug the same images (or URIs) in. This exists as a service, e.g. with CloneMyNFT.com (“which allows you to keep a copy of your NFT in your wallet even after selling the original”),
It is of course also possible to just clone the NFT on a completely separate blockchain, like Candy does — they run on a DLT called Palm, which uses “proof of authority (PoA) consensus, with network validators being run by key stakeholders” — in other words, it’s completely centralized, and if the key stakeholders decide to take your ape, or a majority loses interest and shut down the chain, your stuff is gone and you can’t get it back — except with a hard fork, see problem (1.).

As Cointelegraph writes:

“Just as in the traditional art market, NFTs can be faked through Mimics. And just like in traditional art markets, this fact challenges users to take responsibility for tracing the provenance of what they’re buying. Identifying vulnerabilities is how infrastructure is strengthened.”

So, how does this improve on things then?

More generally, through labeling which NFT collection’s hash is the “true” BAYC, which fork of the blockchain is the “true” ETH fork, which collections can even be displayed and traded — OpenSea & co are the true gatekeepers and de-facto owners. If they want your ape to be gone, they can pull the plug. So again, you’re left with a central instance virtually controlling your apes, so the NFTs add practically nothing to the real world, other than a (very expensive) layer of indirection.

So I will be excluding this category as a whole, Candy & Dapper Labs are just generic NFT companies. Pixura deserves honorable mention for the phrase “[Pixura] helps non-technical users to create, track and exchange NFTs” — because what we really needed was to make it easier to create useless tokens.

And The Winner Is…

Chainalysis helps the government track down tax evasion,darknet markets and CSAM providers & consumers. You can make an argument that they fundamentally require cryptocurrencies to work, but the impact they are having extends far outside the crypto ecosystem into branches of law and tax enforcement.

They also provide mechanisms to automatically block transactions:

Use KYT to detect patterns of high risk activity and prevent transactions with addresses identified on OFAC’s sanction list, freeze deposits from hacks or ransomware, screen ETH accounts, and more

It is certainly ironic: The only live real-world Blockchain use case in this list, is an application that de-anonymizes and censors transactions in the context of ‘uncensorable’ & ‘anonymous’ cryptocurrencies.

Closing Words

There have been overly hyped tech products before — Cloud, Machine Learning, Internet — where people promised more than what the product actually delivered. But these products clearly delivered something. This is not the case with Blockchain technology.

The statements “Blockchain is the Future” and the more moderate “there are use-cases for Blockchain outside of cryptocurrency” seem to always fall apart when you look at any proposed use-case from an engineering, privacy and legal perspective.

Blockchain advocates have been spending 13 years convincing people of those statements, could they not have spent an hour or two to find facts to back them up?

Given how many investors and members of the general public lose time and money on this, I believe it is somewhat irresponsible that the software engineering community is not pushing back harder. As a member of this community, I also find it somewhat embarrassing.

In fact, the only other comparable list I could find was this one. Spot-checking some of the entries, it seems to suffer from exactly the same problems as the Builtin list. ↩
A tamper-proof system would be one where you could not, in any way, change the bytes. But that’s clearly false here, you can simply go into the underlying storage engine — for example, PostgreSQL or RocksDB for Hyperledger Iroha — and change the values there. Arguably, given that this is a private blockchain that has no external parties verifying the blocks, it would be hard to even call a private blockchain tamper-resistant. ↩
GDPRs right to erasure applies to pseudonymous data, too. Pseudonymous data is anything that can be linked to a single individual by someone who has additional data. There is good reason to believe that this includes even (hashed) public keys, i.e. bitcoin addresses, as well as transactions between them. As far as i know, this hasn’t been tested in court, because nobody has sued — yet. ↩
and a good old-fashioned centrally managed HTTPS connection ↩
In fact, large chunks of Voatz attempt to address the researchers’ criticismis based on the argument “We’re not telling anyone how our voting infrastructure works, so how could they possibly know. The remaining arguments are a mix of “oh we have fixed this a looong time ago, no we’re not going to tell you when that was” and inadvertently admitting that the situation is even worse — in Section 2.4, trying to address the fact that biometric information is sent to a third party, they admit that that data is additionally transmitted to Voatz for manual inspection. ↩

SSI-on-Blockchain is Objectively a Bad Thing

2022-07-08T02:21:46+00:00

Summary / TLDR: Blockchain (or “DLT”) adds no functionality to a SSI/Identity system that is not equally well, if not better, provided by a QR code on paper. None of the benefits Blockchain is supposed to bring hold up under mild scrutiny. Blockchain adds significant complexity and cost, as well as usability issues and serious privacy concerns. “Blockchain” in SSI exists for PR only, not for engineering reasons.

Note: I am only going to talk about the “blockchain” part of Self-sovereign Identity. Many things, good and bad, can be said about self-sovereign identity, but in order to keep the scope of this document manageable, I’ll leave the broader SSI-discussion to others.

Terminology
SSI and Blockchain
Put Your Engineering Hat On and Nothing Adds Up
- The Bad
- The Ugly
A Tour Through Literature & Projects
Parting Words

Terminology

Blockchain, or DLT (“Distributed Ledger Technology”), typically describes a database system (“ledger”) similar to the one cryptocurrencies, like Bitcoin, are built on. In theory, they are supposed to be permissionless (anyone can write and read the ledger), decentralized (no single authority controls the ledger). They are typically constructed as immutable, append-only structures - meaning you can never modify, even delete, data from it. (Certain optimizations exist that allow participants to phase out old data in some DLTs, but deletion cannot be enforced - i.e., it is insufficient, or at least a gray area, for GDPR purposes)
Self-Sovereign Identity (SSI) is the idea that, instead of having a central party (e.g. government, Google/Apple, …) issue you an ID, you issue your ID yourself and have the third parties notarize it. This is frequently sold as a “take the power back” approach from Big Tech (or Governments). The most well-known standards for digital identity are W3C’s Decentralized Identifiers (DID) and Verifiable Credentials (VC). These are heavily sponsored & driven by blockchain-based startups.

SSI and Blockchain

The intersection of Self-Sovereign Identity and Blockchain is a great example for how Blockchain technology does not live up to it’s hype. Government institutions, such as the EU, pump millions into research directly, as well as indirectly - the top 2 blockchain use-cases on the European Blockchain Services Infrastructure (EBSI) website are “Identity” and the SSI-based “Diploma”. The top Google result for “real world blockchain uses” prominently features Identity-startups.

But it’s certainly possible to use Digital Identity / VCs without any blockchain: The EU’s digital vaccination certificates use W3C’s VCs. The EU has managed to scale it up to 1.7 Billion certificates - but that’s after they got rid of all the blockchain stuff, which they unsuccessfully experimented with before. So if SSI works just fine without blockchain, the obvious question is, what value does Blockchain add to SSI?

It turns out, even proponents of the SSI-on-Blockchain idea don’t seem to have a clear narrative - everyone seems to claim something else. There are, however, 6 commonly touted benefits:

Blockchain increases trust in the digital identity credentials, e.g. your digital passport [e.g. IBM SSI Blog: “Why Blockchain”],
Blockchain increases trust in the issuers of the credentials [IBM SSI Blog: ‘Trusted Labels’, Forbes]
Blockchain makes fraud harder [e.g. Techtarget, Fintech News, TU Delft],
Blockchain allows trusted time-stamping, i.e. proofs that credentials were issued before some specific point in time [EU Blockchain Forum],
Blockchain avoids third parties for storage/access [IBM again]
Users have control over their data (found in virtually every blog on the subject, and even in academic papers, e.g. this or this)

All of these claims fall apart when even mild scrutiny is applied.

It is almost comical how every article or paper on this subject avoids describing, on a high level, the tradeoffs in terms of risk, or trust, or engineering.

In a problem space that deals exclusively with (chains, webs, direct, indirect) trust, you’d think someone would write a comparison of DLT and non-DLT, on “which third parties do I need to trust, and what happens when they fail, or they are malicious”. It seems like engineering 101 - yet such comparisons are completely absent from anything I encountered while researching this article.

It is somewhat mind-boggling how the “blockchain is the future”-assumption just keeps getting cargo-culted through the pitch decks - and even through scientific papers -, and nobody seems to fact-check that assumption, ever.

Put Your Engineering Hat On and Nothing Adds Up

The Bad

The following discusses the claimed common benefits mentioned before, and how blockchain adds - in the best case - no value, but frequently makes the problem area worse.

Your digital identity does not become more trusted. If everyone can write to the blockchain, the fact that “your identity is on the blockchain” doesn’t mean anything by itself. Therefore there is no difference in authenticity (or trustworthiness) of some “piece of data” whether it’s on a QR code on your smartphone, or in a public blockchain.

Authenticity is typically established through digital signatures, e.g. a federal agency would digitally sign a document stating “Taylor Swift is 21+ years old”. But that signature can be easily be embedded in a QR code too (and so can a “chain” of signatures and certificates, allowing for trust hierarchies). These systems exist, and work (see the vaccination passport example).
The identity issuers do not become more trusted. The previous point holds for the other side of the equation, the identity of the signature issuer (Certificate Authority), too. There are (by necessity) only going to be few trusted entities that can act as CAs - after all, for the verification to work, both issuer and subject need to trust the same CA. Coordinating this will by necessity only leave a few government agencies, or maybe (very large) trusted corporations (such as nationwide utilities, or some Big Tech companies).
1. If there are only few, and they are well-known - for example, a few government entities per country - then you can hard-code them in your app - which is exactly what’s being done today through your OS’ or browsers CA store.
2. If there are multiple smaller entities - for example, each landlord issuing digital keys, in every city, worldwide - you will need to delegate trust, typically through a hierarchy (the landlords are trusted by the city, which in turn are trusted by the federal government, or a national utility company - who’s certificates are hard-coded in your app). This is the exact structure (virtually) all internet encryption is based on. Additionally, the existing system - X509 - supports cross-signing, having credentials signed by multiple parties - despite claims to the opposite, this is not a unique feature of W3C VCs.
Detection of forgery or conflicting credentials is not made easier. A very common argument is that storing claims on a DLT would make it impossible for someone to show one certificate to person A and another to person B: The verifier could just look at the public ledger, and see the conflict! Variations of this claim include Sovrin’s “The blockchain can tell you which [certificate] is the most recent one”.

But this system requires the verifier to look up other credentials that match some identifying information - for example, they need to find all IDs named Angela Merkel. Being able to perform such lookups requires that the data on the blockchain is PII, and storing PII on an immutable ledger is a straight-forward GDPR (and generally, privacy) violation.

There are approaches that try to address this - e.g. using hashes, encryption, or zero-knowledge proofs, to obscure the data and make the problem a bit harder, but the fundamental problem remains the same - you need to be able to look things up for the forgery/conflict detection to work, and that lookup necessarily exposes PII.

Additionally, there might be valid reasons for a person to have conflicting versions of their IDs over time. People change names, change genders, typos happen etc. - applications need to be able to handle these. Consider someone in a witness protection program, where the existence of a conflicting ID would be outright life-threatening.
Verified timestamping adds no practical value, and can be dangerous. The publication timestamp is the only bit of verifiable data that a blockchain actually adds. In theory, this proves that a piece of data was created no later than a specific time T - i.e. that a document has not been “backdated”.

Now, this sounds like a useful feature to have, but, as before, it falls apart under closer inspection - mainly because there is no real-world situation where this is truly relevant: You’d need to construct a situation where you already trust the issuer to make true statements about everything that’s in the document (e.g. in a passport, Name, biometric data, issuance and expiry date), but you somehow don’t trust them that they issued (printed) the document in a timely manner.

This is simply not a problem anyone is having, but it gets worse:
- Even if this was an actual problem: Nothing stops the document issuer from simply issuing multiple entries at different timestamps. As in the previous point (“forgery”), this is impossible to detect for third parties.
- As above, there might be very valid use cases for having a document being backdated. Having an anomaly in the issuance timestamp can be anything from uncomfortable to outright dangerous.
- This only works when you trust your Blockchain API gateway - the “anchoring timestamp” is part of the block, not the statement, so an untrustworthy API gateway can simply change it.¹
Of course, timestamping services don’t actually require blockchain. RFC3161, the most popular timestamping standard, has existed since 2001 and can be reasonably decentralized. But even that standard is rarely used: a quick github search for RFC3161 finds only 28 repositories and 1k commits at the time of writing - compared to 29k repositories and tens of millions of commits for the search term “identity”. DKIM covers this usecase too, and is standard for most emails today.

You are relying on the same amount of third parties, but likely less trustworthy ones. There are two “third parties” to consider here: The cryptographic trustee, and the data provider. The trust model in the former is unchanged, as discussed in the first two points.

The latter third party stores the blockchain for you, and provides you with the data through some API. This is required if the DID-system is to scale to a large population, like a country or the EU: The blockchain would typically contain some entry for every DID or VC; whether that’s the document itself, a hashed/encrypted version, or an audit log entry. You would then end up with billions of entries, not something that will fit on an average phone, or that you’d want to keep updated day and night.

(A few projects, like Sovrin, store only a handful - maybe a few 100 - “root” DIDs in a private ledger. As only sovrin can add or revoke from the ledger, the “added third party” trust problem remains the same.)

Adding the dependency on a “blockchain API” is equivalent to adding a dependency on a Government or Big Tech, though in most of the existing examples the gateway is operated by a far smaller (and/or less reputable) company. What if they are offline? What if they get hacked? What if that company has financial incentives to not be honest at all times?
You actually give up control over your data, not gaining more. The “you own your data” claim is simply not true, the exact opposite is true. When you upload data to a blockchain, it stays there forever. Any Big Tech company that you tried to avoid by using DID can happily read along.

Some systems claim they provide the ability to delete data, but even if that were true - by necessity, you pushed the data onto a public system, you don’t know if all systems actually act on your deletion request. The NSA probably won’t.

The “control” argument also often seems rooted in some kind of encryption scheme, where only the user holds the private key. But this is orthogonal to blockchain - if the data is encrypted, you might as well store it at some Big Tech provider, even if you don’t trust them. At least then you have one entity to sue if your data gets mis-handled. From a privacy perspective, you’re almost certainly better off with that approach, too: Metadata analysis companies like Chainalysis make a living, and headlines, by correlating data that’s properly encrypted, but on a blockchain.

The idea that you gain control over your data by publicly posting it on the internet is so obviously stupid, it’s hard to understand why people insist on repeating it.

The Ugly

The “Engineering” section would not be complete without pointing out a few obvious additional drawbacks when using DLTs:

Additional complexity. Adding more moving parts in any IT system should always be done with caution, even more so when the system is exposed to the internet, and even more so when it is deployed on end-user devices you can’t control and thus can’t centrally coordinate. Complexity adds cost, slows development, and adds failure modes.
A dependency on an internet connection. You cannot get the most up-to-date state of the blockchain when you’re in a tunnel, in the mountains, or the connection is slow and unreliable at a festival where the 5G network is overloaded. This dependency of course also means higher latency independent of how good your connection is - if you need to pull additional data, things go slower.
Transaction cost. Distributed ledgers - virtually by design - can’t utilize economies of scale, making transactions computationally more expensive. In addition, all commonly used public ledgers charge fees (and private ledgers require you to trust an additional party).

None of these above would be deal breakers, of course, if they were offset by some additionally gained functionality. But there simply is nothing.

A Tour Through Literature & Projects

Obviously, thousands of blog posts, articles and papers have been written on the subject. I’ve tried to collect a representative sample from the most popular (per google ranking or citations) below:

Blogs & Articles

EBSI, the European Blockchain initiative, is advertising digital identity as one of their 4 usecases. Technically, 2 others - “Diploma verification” and “Health Insurance verification” are close enough to DID that it might count, too. They have documentation, but it too is devoid of any *actual *information what the blockchain actually does. Their documentation actually implies the opposite: All the usecases that they have envisioned so far seem to only write to the ledger. None of them actually read from it. Seriously, even the “verify credentials” use-case only writes an audit log to the ledger, which is apparently never read.

The IBM Blog mentioned earlier talks a lot about how they avoid trusted third parties, and establish trust through the blockchain. They conveniently ignore that all of IBMs blockchain products are based on their Hyperledger product, a private blockchain developed and typically hosted by IBM - a third party to the application. In the case of Maersk Tradelens, a product that had some success through being forced onto Maersk’s customers, all interaction with the blockchain requires an IBM.com account.

Wikipedia’s Self-Sovereign Identity article states that SSI is “verified using public-key cryptography anchored on a distributed ledger.”, but the term “anchored” is never defined.

The source for that statement is a document titled “Blockchain and Identity” from the EU Blockchain Observatory. The word “anchored” does not appear in it. Despite the title, this 27-page document discusses the “Blockchain” aspect on less than 1 ½ pages, in which they merely hint at possible options - with plenty “can”, “could”, “might”. Eventually, they identify ‘timestamped data for eIDAS [the EUs digital identity system]‘ as the only viable use case. As discussed above, this is infeasible in practice. They also mention plenty of problems around GDPR, and that they really don’t know whether digital signatures on a DLT hold any legal weight in the EU.

The Forbes article mentioned earlier claims that with DID, “In the future [online shopping] deliveries could be made to the person, wherever they may be at that time, rather than just relying on a home or office address.”. I was not aware that this was a problem of presenting an ID. According to that article, DIDs are “biometrically secure” (the author does not provide a reference for that claim).

In Academia

I went through the first 5 results on Google Scholar for the search query “self-sorvereign identity blockchain”.

The Title Self-Sovereign Identity Solutions: The Necessity of Blockchain Technology certainly sounds promising, but unfortunately, the abstract already lowers ones expectations:

We conclude that blockchain technology is not explicitly required for a Self-Sovereign Identity solution but it is a good foundation to build up on, due to various technical advantages that the blockchain has to offer.

The paper does not substantiate that claim - all they do is compare 9 Blockchain-based solutions with 2 non-Blockchain-based solutions.

The paper states that they only focus on self-sovereign identity, and have thus excluded some identity solutions, and then find that almost all the remaining ones use blockchain technology! How very convenient, even more convenient that they left out OpenID or PGP/GPG, arguably two large non-blockchain players in (or close) to the DID space.

Still they can’t seem to manage to create a convincing argument, resorting to statements like “Still it is more difficult to prove that there are no hidden algorithms when not using blockchain. So blockchain is definitely a better base for this property.“ In another spot they casually mention

“However, if a private key is lost it will be difficult to change or remove the data.”

- likely illegal under GDPR (because the existence of data that a private-key can change or delete implies that there is identifiable data on the blockchain - even public keys could be PII under GDPR).

In the parts of their comparison where the assumed blockchain solution is not in direct violation of privacy laws, they helpfully point out that either DLT or non-DLT would get the job done.

The big reference in the Wikipedia article is “In Search of Self-Sovereign Identity Leveraging Blockchain Technology”. Of its 21 pages, only 3 are actually dedicated to Blockchain, half of which defines terminology, the other half briefly presents 4 projects that they identify serious shortcomings with - but they claim *might *work in the future. They briefly sketch a few use-cases, noting that all of them would work without blockchain too, and conclude with “[…] In fact, there have been a few attempts in the form of different blockchain-based self-sovereign identity systems. However, as per our analysis, none of them satisfies all the properties of a self-sovereign identity system. […]”.

In the paper A Survey on Essential Components of a Self-Sovereign Identity, Section II, they claim that the Blockchain takes the place of “the registrar in a classic DID system”, without explaining what their job actually is. The key points though are

In order to accept the identity, the relying party needs to have a trustful relationship with the claim issuer. and The actual identity claim is stored in the user controlled storage, typically off-chain for privacy considerations. The relying party, also called claim-verifier, can then compare the publicely [sic] available identifier with the identifier in the claim that has been handed to him by the user. This makes zero sense at all. The user hands the claim-verifer the claim, the claim is signed by the issuer, the claim-verifier has a trusting relationship with the issuer. We’re done! There is no added benefit to comparing the ID to a database that anyone can write to.

Deployment of a Blockchain-Based Self-Sovereign Identity is actually reasonably well readable. They sketch some parts of how an on-blockchain system would work, a bit more in-depth than other papers, but at the expense of completely ignoring any privacy concerns - while they do come up with a sketch for (but not an actual description) of a zero-knowledge system to ~encrypt the claims, they fail to describe how the other claimed benefit, the audit log, would work with this: You can either publicly audit claims, or you can have privacy. Not both. The paper ignores this.

They do repeat frequently that the user has to be in “control” over what’s on the blockchain, but this can never be fully true - a blockchain is a one-way street, once published, you can’t “control” the data back out of it. They seem to be implying that a “personalized Blockchain” is required, a parallel blockchain akin to a branch in IOTAs Tangle (but neither would the desired level of control be available in the IOTA system, nor has IOTA ever created even a working (decentralized) prototype, also apparently IOTA is still a thing in 2022 lol).

They did, however, solve how to identify terrorists at the airport: You just need to write “Not a terrorist” on the Blockchain!

Lastly, in the worst case, some claims may require real-time proof of correctness (not being a terrorist when checking in to the airport).

The paper actually points out that a lot of this stuff would work without blockchain, too:

The claims do not require any blockchain to be evaluated and may be shared with other platforms.

They never actually specify why it is worth going through all that trouble with Blockchain. Instead, they refer to another paper:

The concept of using blockchains as vessels for identity has been explained by Zyskind et al. [5]

That paper, Decentralizing Privacy: Using Blockchain to Protect Personal Data, unsurprisingly, also fails to make an argument how blockchain is any better - as with all the papers above, it merely describes complexity that would need to be added to make something work at all:

One of the major contributions of this paper is demonstrating how to overcome the public nature of the blockchain.

The only explanation of benefits is a vague “Given this model, only the user has control over her data.” - based on ownership of the encryption key, orthogonal to the blockchain; and that an adversary cannot “corrupt the network”. Unfortunately, in the very next paragraph point out that adversaries can actually corrupt data, unless it is sufficiently replicated:

Note that while data integrity is not ensured in each node, since a single node can tamper with its local copy or act in a byzantine way, we can still in practice minimize the risk with sufficient distribution and replication of the data.

This is unfortunately as far as that section goes.

Finally, Towards Self-Sovereign Identity using Blockchain Technology looks like a Bachelor or Master thesis, and I’m not in the mood of trash-talking someone’s thesis. TL; DR is that It falls into the same traps as discussed above, although it looks a bit nicer.

Real-World implementations?

The article In Search of Self-Sovereign Identity Leveraging Blockchain Technology was from June 2019, so what happened to the 4 projects they mentioned?

Uport has shut down. It split into serto.id, which seems dead, as their twitter feed and blog stop in Oct ‘21 - and veramo.io, which pivoted to “A JavaScript framework for verifiable data”, and seems to have completely dropped anything “blockchain/DLT” - a google search only shows 3 pages on their site that mention those terms, all in passing.
Jolo, who’s homepage now prominently features a blog post titled “Self Sovereign Identity ≠ Blockchain”, containing “In the past two years, the SSI community has emancipated itself from Blockchain technology” and “Why you do not need a Blockchain for Self Sovereign Identities.”.
Blockcert seemed to have stopped their core work in 2017 - which is the date of the most recent blog post and most of the documentation - and their main product seems to not have left prototype phase: it hardcodes the wallet password to <empty> and seems to skip quite a few certificate verification steps [1], [2] (!!).

The FAQ, under the section ”Why use a blockchain instead of a PKI infrastructure?” claims that the blockchain provides tamper-proofs (in the presence of a trusted issuer key/identity, a problem solved since 1977). They do use the trusted timestamp argument, with a PoW chain, claiming that this avoids a trusted third party. According to their code they depend on the third parties blockchain.info, learningmachines.com and their own blockcerts.org website, the trust model for those is not discussed. Neither is discussed how trust with the certificate issuer is established. The FAQ refers to the wiki for further information, which is empty.
Sovrin, which is likely the biggest player in the space. Their paper “What goes on the ledger” explicitly states that ordinary users would never store identifiers on the DLT - in fact, only larger entities, such as governments or corporations, would write their “public DIDs” to the Blockchain. Ordinary people would keep their “private DIDs” to themselves, those work just fine without blockchain. But Sovrin doesn’t explain what the public DIDs gain from being on the blockchain. Also, the security of the current internet already has a very similar model of ~150 public government & corporate “Root CAs” - Sovrin doesn’t explain how their approach is fundamentally better (or even different, apart from “blockchain!”).

The architecture diagram and websitefor their (only?) real-world implementation, IATA Travel Pass, does not mention anything blockchain related. I reached out to them and asked whether they used blockchain at all; they confirmed that they do use hyperledger (a permissioned blockchain only they can write to), but that IATA, the main stakeholder, also keeps their own, separate list of trusted certificates - making it fundamentally unclear why Sovrin even bothers running their blockchain instance.

They also confirmed that Sovrin is moving away from a pure blockchain focus for their products.

Additionally, the “Necessity of Blockchain Technology” article mentioned

IDChainZ - at the time of writing, the images on the website don’t load, making it hard to evaluate the architecture. The “Download or Brochure” link 404s.
EverID - all their social media went dead in April ‘21.
LifeID, which is dead, because the author pivoted to a phone number-as-NFT project.
ShoCard, acquired by a company called Ping Identity in 2020. There is no indication that Ping’s PingOne Cloud Platform has anything to do with Blockchain.
SelfKey, whose website and Twitter just screams “2017 ICO scam”. That being said though, in their whitepaper, they seem almost excited about how they don’t use any DLT for SSI either, and somewhat argue that they shouldn’t. Their blockchain is only used to pay for attestations (i.e., pay a utility company to sign your credentials using their blockchain-based token).

It cannot be stressed enough that the only known wide-scale deployments of anything related to W3C’s DID concept are the QR-code-on-paper based EU vaccination certificate, and India’s equivalent “DIVOC” passport. The fact that EBSI & co. are waving around DID as a means to get grants, in 2022 (most of the projects above died years ago, the papers were mostly writen in ‘18/’19) is saddening.

Parting Words

A lot of Blockchain + SSI projects start with the goal “take the power back”. This is, at it’s core, a noble goal. But instead of solving the hard problems, like

how to do ID recovery,
how to ensure privacy and metadata resistance,
how to deal with identity theft,
how to ensure decentralization and interoperability,
how to make SSI work for tech-illiterate people

they instead burned all the funding on trying - unsuccessfully - to make Blockchain as useful as a piece of paper. Imagine how much further we would be in Digital Identity today, if a huge chunk of the funding would not have been burned on a fundamentally incompatible technology.

Blockchain adds a serious amount of complexity, drawbacks & costs to something that can demonstrably be done without. This is an “the emperor has no clothes” situation - many people have heavily invested in this. Nobody wants to admit they’re wrong. But the reality is: A QR code is the superior tech.

This could partially be mitigated using SPV-style verification, but this requires
- a PoW chain with reasonably high difficulty - unlikely for any practical application, and
- that the end-device is capable of tracking at least the block headers. Technically feasible for chains with long block intervals (e.g. Bitcoin) but still somewhat resource intensive).
Hardly a good selling point. ↩