Blockchain and crypto are related yet distinct concepts. I was lining up for a PCR test in Thailand the other day, and it was a huge mess. The lack of streamlined systems between invoicing, identity verification, etc means very long queues, people running back and forth to get their documents printed. The testing scheme is private run but I assume it needs to interface with governmental departments (i.e. Immigration and the police) to initiate quarantine in case i'm positive, and change my eligibility status for travel outside the sandbox area if i'm negative, or to arrest me if i fail to take the test within the specified time.

I thought about why so many centralizsed systems failed, or failed to be built, for streamlining processes in the real world. I think that it's because typically such systems would be built on SQL databases and backend servers that are prone to hacks and downtimes, and the APIs built by different developers often cannot integrate with one another.

What if, instead of databases and custom APIs, a blockchain with smart contracts is used? What if we can also sign documents such as receipts with hashes that can be verified off-chain and off-line? We'd have a fault-tolerant, always-available systems, and also a "unified" protocol in which other systems can interface to.

Instead of having different databases and APIs that are hard to integrate with one another, a blockchain could be the central storage and transactions handler that different systems interface to.

The PCR test system would be something along the line of: - Booking through a smart contract, paying the PCR test fee, and obtaining a receipt signed by the contract in the form of a hash - Upon arrival in the test center, they check the validity of this signature offline by using a public key to verify your payment. - An identification service can keep a hashed version of your personal data on-chain. You can provide your name, DOB, place of birth etc, and this can be checked against the identification service by decoding the hashed data with a one-time key you generated

There's no DB that can be hacked or go corrupt, no BE servers that can be DDOS'd.

There are of course questions to be answered. But I see many use cases in my everyday life.

> Instead of having different databases and APIs that are hard to integrate with one another, a blockchain could be the central storage and transactions handler that different systems interface to.

That's a common refrain that seems to associate blockchains with standards and common APIs, it doesn't resist closer inspection. To take your example, I can easily design two PCR test systems completely incompatible with each other, and leaving no way for anyone else to implement a compatibility layer between these two, even if they both use the same blockchain.

There are various ERC20 tokens that should in theory implement the same interface, but turn out to be subtly incompatible with each other because of how imprecise the specification is. Standardization is hard, even when people try, and blockchain doesn't even enforce a modicum of effort in this direction.

Another way to see it: as a software development constraint, "the system has to live in a blockchain" is akin to "it has to be written in C" or "it has to use functional programming": maybe the end result will be more alike, maybe it'll be easier for a dev to understand one system based on the knowledge of the other, but that's pretty much it.

> There's no DB that can be hacked or go corrupt, no BE servers that can be DDOS'd.

Smart contracts can be vulnerable (and ensuring they are not is very expensive, if possible at all), private keys get lost and some external system has to update the smart contract (you can never really get rid of all external systems, something lives outside the blockchain, if only the human operators), transaction fees are high enough that getting protection from a DDOS mitigation service would be cheaper than using a blockchain in the first place.

I agree with you that not everything has to be done a certain way. Programs don't have to be written in C or functional programming for it to work well. But there are places where those excel in terms of performance and/or reducing complexity.

I am also not arguing that incompatible APIs will disappear with blockchain usage. But things like an EVM can be used as a template to build underlying blockchains to provide a common datastore and execution layer for multiple systems to work together. It is harder to achieve with traditional SQL databases, which shouldn't be publicly accessible.

Also an advantage I thought of is it would be harder in this case for corruption to take place in the PCR testing regime since all transactions are immutable, and transparency ensures that the public would be able to check against those if they so wish. A closed system would allow the government or participating platforms to manipulate data records for their benefit, with less chance of scrutiny.

I agree with your points about the vulnerability of smart contracts and private keys. These are challenges that I hope will continue to be addressed as we try to figure out how to make blockchains accessible for mass usage. I think that smart contracts auditing is still far from mature, but the immutable nature of contracts would allow audited contracts to remain secure, as opposed to some code running on some company's server.

In the end as with everything in life, there are trade offs. It's about picking the right tool for the right job, and to continue experimenting with potential improvements that new technologies can bring and to reduce their externalities.

> But things like an EVM can be used as a template to build underlying blockchains to provide a common datastore and execution layer for multiple systems to work together.

Substitute EVM for JVM and you end up with a similar statement that looks just as correct, but it's still not clear what the EVM brings that the JVM doesn't.

> it would be harder in this case for corruption to take place in the PCR testing regime since all transactions are immutable

In your system, the blockchain would replace the database, not everything around it. That's also something I keep seeing in these discussions: blockchain provides some guarantees, so you assume the system you'll build on top of it will inherit from these guarantees, without questioning the composability further. But the interfaces of the blockchain component of these systems you're trying to conceive are precisely where the guarantees break down.

To take your example, you'd basically replace a database (and just a database) with a smart contract, which would ensure immutability and transparency. But:

1. you don't need a blockchain to get these guarantees (e.g. https://en.wikipedia.org/wiki/Certificate_Transparency)[0]

2. using blockchains still imply that you're trusting the people holding the keys and interacting with the smart contract, so you haven't changed your trust model (the interface problem I mentioned above).

> the immutable nature of contracts would allow audited contracts to remain secure

The immutable nature of contracts is also what makes them unfit for evolving systems that have to be regularly updated to address new requirements.

[0]: to be clear, I'm talking about permissionless blockchains such as Ethereum

First of all, let me say that I understand where you're coming from. I too try not to use the latest fad just because of it. I use systemd instead of k8 when it's enough. I use plain JS instead of react when it's enough. I run cronjobs that updates jsons served by nginx instead of building graphql APIs.

But there's a good reason things like k8 and react become overused for everything these days, because they provide a standard that works for a relatively large spectrum of cases.

The argument of "you don't need X to do Y" is not wrong, but it doesn't make X absolutely useless. Your points are not really invalid imo, but i think you're missing the point of the continuum between centralised and decentralised systems

> i think you're missing the point of the continuum between centralised and decentralised systems

I'm mostly missing the point in this continuum where I can start listing pros instead of just cons. There are fundamental reasons why we haven't reached this point and may never reach it, as I (and many others) highlighted before, and these haven't changed for the past 5 years.

Or, the provider, namely the government, can write the code to orchestrate these API calls even if these APIs are managed by disparate entities.

It's not pretend like it's not a solved problem. It's just that you're trying to eliminate the central provider in this case and you want to replace that with a blockchain which is excruciatingly slow

A colleague of mine once disagreed to use git because it was easier for him to copy paste the project's folder every now and then to keep "versions" of his work.

There are trade offs, but having data and core business logic in an open and transparent network would allow for better interoperability imo. Not saying there aren't fundamental issues to be solved with using blockchains, but it's a new path to be explored.

The speed of the blockchain doesn't necessarily have to be slow. It depends on how decentralised and safe it needs to be. It's possible to create a "private" blockchain for some use cases. I don't see web3 as open in the sense of open to the whole world, but open to whoever the stakeholders are.

> Instead of having different databases and APIs that are hard to integrate with one another, a blockchain could be the central storage and transactions handler that different systems interface to.

Couldn't this be done with something like an enterprise service bus, without the blockchain?

> Booking through a smart contract [...] There's no DB that can be hacked or go corrupt

But you have moved the hacking problem to the smart contract instead, and last time I looked those seemed a lot harder to make secure.