This is going to be a new series on The Chia Plot about what I see as the major hurdles to adoption for Chia, and for blockchain technology in general. This is not going to really touch too much on cryptocurrency and uses for the coins but for the underlying technologies and the promises being made. The focus here is what is standing in the way of general blockchain adoption.
The first of those hurdles is the system that a lot of blockchain predictions hope to replace. Public Key Infrastructure is the web of certificate authorities and certificates that enable secure email, web browsing and secure identification across the internet. The main tool of PKI is the x509 certificate, which is a versatile cryptographic format that enables asynchronous encryption – it uses a public and private key. In a lot of ways bitcoin is based on the PKI systems in place when Satoshi was developing it.
The main criticism to this is centralization, but that’s a poorly understood argument. PKI one of the least centralized services on the internet, with many providers offering overlapping coverage of services, and a strict – but fair – process on getting your PKI infrastructure trusted globally by the various stakeholders. Decisions are made through consensus between browser companies, operating system companies and the Certification Authorities. On top of that, the technology supports full decentralized trust where you can run your own root certification and only those who explicitly trust you will accept your certificates. They are also just as unforgeable as a cryptocurrency wallet.
The reason I bring all this up is because when judging the utility of a blockchain tool or use case the very first question you should ask yourself is “Can I do this with an x509 certificate?” You will find the answer is frequently yes. Almost all DID (decentralized identifiers) can be issued as certificates signed by the entity issuing the DID (the “Identity Provider” in federated identity jargon) and the entity consuming the DID (the “Service Provider”) could as easily trust the IDP’s root certificate instead of their smart contract address. You can even have cross signed certificates to enable real decentralized trust. This is in place right now in education-focused federation groups allowing for decentralized, shared identities.
Accordingly, a public ledger can be securely written and read from simply by using client authentication certificates. Almost all modern databases support per-record encryption keys, so there is nothing stopping a provider from leveraging this to create a securely encrypted, Merkle-tree signed database that has, for practical purposes, all the security of a blockchain without the immense work required for the adversarial validation system used in blockchains.
At a high level a cryptocurrency wallet private key and an x509 private key share many of the same advantages, disadvantages and general properties. So one of the ways you will know that blockchains are starting to come into their own is when they start taking over the utility of x509 certs. When I can secure the communication to my site on-chain like TLS; or network packets between two previously unconnected computers, like IPSec; or sign code for trust like Authenticode; or even log into my TV providers private systems or pay for a long distance call without an account like CableCard or SmartCard phone cards; that’s when I will know that blockchain tech has begun to mature to where it is the best choice for new services.
I wouldn’t be nearly so suspicious of the use cases being presented by the blockchain community in general if more effort was paid to explaining why the use case they have is better done with a blockchain than with traditional cryptography. Obviously TLS is good enough, the whole smart contract ecosystem fundamentally relies on it for bringing outside data on-chain securely. “Oracle” lookups are done via HTTPS API calls, that rely (hopefully) on strong TLS protections for the service being queried.
I think Chia has a good idea brewing with their CATs and how they will be used to federate data between different organizations. Its not over-complicated or aggressively fancy. What it is is a use case that might prove to be more simple than something I could build with a cross-signed PKI infrastructure, especially in terms of onboarding and offboarding database participants. I hope it is what I think it is, and not another fancy signed message service where nobody bothered asking “Can I do this with a certificate?”
