Hacker News Reader

Comment by pythonaut_16 | Hacker News Reader

I think perhaps one effective use by a central entity is to have trust centralized but proof of work is distributed.

An example would be that I, as the central entity, know which public keys/key pairs I want to trust, and the proof of work is the owner of said key signing a given block with it. So as the central authority I can't unilaterally rewrite history, but I can unilaterally decide whether the chain is valid.

E.g. Alice wants to deliver a package to Dan by means of Bob and Carlos as couriers. So Alice signs the initial block using her public key and gives the package+signed block to Bob, who signs and gives to Carlos, who signs and gives the package to Dan. Dan can independently verify his trust in Alice, Bob, and Carlos's public keys and then be sure that the package was passed along in the manner recorded in the blockchain.

View on HN

That reads to me as yet another scenario where blockchain is the stone in the soup.

If trusting Alice, Bob and Carlos's public keys is equivalent to trusting them, then I don't really need a blockchain to verify that they did what they said they did.

If it's not, then I don't trust the blockchain as a record of what happened, because there's no chain of trust between what they wrote in the blockchain and what they actually did.

The reason why this sort of thing works with cryptocurrency is because, with cryptocurrency, the blockchain is reality. If the blockchain says I have 1BTC, I have it. If it doesn't, I don't.

As soon as you try to apply it to something like supply chain management, though, that falls apart. The map is not the territory. So you have to add a whole bunch more stuff to the system to try and ensure that what's been recorded is accurate. Not entirely unlike how, in the story of the stone soup, people had to add a whole bunch more stuff besides the stone to the pot in order to make sure the soup was tasty and nutritious.

What would you suggest as an alternative where each step still independently verifies all previous steps?

I guess you could just store it in a database and store the hashes and signatures as columns but again, that seems more like implementing a blockchain strategy using a traditional RDBMS.

*After your edit: It seems like the blockchain is still useful in this case as a series of signed statements where it can be (generally) verified that each signature was made by a certain entity at a certain point in the chain.

I'm not a logistics guy, so maybe I'm missing something here, but I think I'd just not do it at all.

Why would I need to do such a thing? What, in practical terms, does it get me?

So looking back at your post, I think the big difference is trusting someone's key isn't equivalent to trusting them. Trusting Alice's key just means I can trust that a statement signed by Alice's key was indeed signed/made by Alice.

The value of the system is that Bob cannot modify what Alice has said and signed. So the only place where Bob could lie is in his own block. Additionally, once Carlos signs his block, Bob and Alice can no longer change their statement either, so we're partly relying on Carlos to verify that he receives the package in the condition described by Bob's block.

One vulnerability I see is Carlos could just cut out Bob and fork the chain with his own block coming right after Alice. To counter that you could have each sender sign off on who they entrusted the package to (i.e. Alice signs her block/creates a block saying she gave the package to Bob).

So essentially the idea is to set up a system of untrusted participants whose identities can be verified/trusted. Bob might have an incentive to lie about who he received the package from or what the condition of the was package when he received it, but he doesn't have much incentive to let other people sign messages using his key.

I'm not sure as a system whether there is actual value or benefits here over other simpler solutions, it's just a fun thought experiment I've been doing to try and figure out scenarios where blockchains could provide real benefits over other systems.

So I think that, here, the 2nd-to-last question bubble in the flow chart is the key one. Because the question you're circling around is, "How do we verify that records are written by specific people?"

If you can centralize the records management, then you don't have a problem deciding who should own the record store. At that point, good old-fashioned authentication will solve your problem.

If you can't centralize records management, then things get trickier. But I think the trickiest part would still be to come up with a non-contrived logistics scenario where there isn't an obvious custodian you can put in charge of a centralized record.

I was imagining a potentially offline scenario where the blocks are physically recorded (i.e printed) and attached to the package as some kind of barcode or QR code. I suppose you could also deal with a scenario where the digital record is primarily transported with the shipment as well.

A tamperproof log with certain commodity hardware might be easier than guaranteeing secure network access to every participant in the chain.

One example I've seen in the wild is Walmart investing in blockchain for food safety. This is me in a sense trying to reverse engineer that thought process/system to figure out what benefits it might bring.

Looks like the system I'm thinking of is roughly a Proof of Authority system (https://en.wikipedia.org/wiki/Proof-of-authority). Your point about blockchain being unnecessary here is one of the points brought up in the Wikipedia article under Comparisons.

Reply on news.ycombinator.com