4 ms·

I also want a writeup covering some examples of Bitcoin or Ethereum use that are relatable. This recent NYTimes piece takes that approach, though none of the e

• freemanon 5y ago
  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.
  • mohanmcgeek 5y ago
    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
    • freemanon 5y ago
      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.
  • hiq 5y ago
    > 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.