[Alex3917]

> This is fairly niche, perhaps 1% of all interorganizational database applications, but there are certainly cases where it is the right solution.

So I personally think DLT is going to be one of those multi-quadrillion dollar technologies that come around every few hundred years. The real benefit of DLT is that it enables new types of human relationships. So thinking about it in terms of what percentage of your existing databases should be replaced by it isn't going to give an especially impressive result, because by definition your existing databases are going to model your existing relationships.

Think about what percentage of the stuff in your house you would own without the invention of double entry accounting. Unless you happen to have some veggies from the farmer's market or a sweater one of your relatives knit you, the answer is probably 0.00%. It simply isn't possible to manufacture things like the iPhone without double entry accounting, because without double entry it would be impossible to form the sorts of human relationships needed to produce such a complex product. And if we asked someone to take a look at all the stuff in their house a couple hundred years from now, I'm guessing that a similar 0.00 percentage of the stuff they own will have not have been created as the result of DLT.

The fact is that once DLT becomes ubiquitous it will no longer be cost competitive to manufacture and distribute products using only the sorts of relationships and techniques enabled by double entry accounting. And if anyone even tries it's going to be like bringing a knife to a gunfight.

[Jakawao]

I can’t tell if you are being sarcastic or not, so I assume this is a serious comment.

Can you share some examples of use cases where DLT is going to be transformative?

[Alex3917]

I mean a good example of the need for DLT is the fact that no one in the country can buy romaine lettuce right now. Does it really make any sense whatsoever that no one in the country can eat lettuce for the next couple months just because one farm got contaminated with E. coli?

[chipotle_coyote]

You seem to be suggesting that a distributed ledger would have made it possible for regulators or buyers to track the specific source of the contamination and pull it out of the food system. DLTs are starting to be used for that level of tracking for diamonds, but key to that system is the ability to establish a "fingerprint" for each diamond that involves a laser-inscribed serial number on each diamond.

So to apply that, wouldn't we have to somehow register each individual head of lettuce with a tamperproof fingerprint? Just registering the bags the lettuce came in isn't good enough; the "farm" selling you their romaine might actually be selling you romaine from somewhere else that they've repackaged. (If that wasn't the case, we wouldn't be having this lettuce problem to start with.) And this is setting aside the possibility that lettuce might be leaved/shredded before packing and shipping, because now we have to put that tamperproof fingerprint on each and every leaf.

Oh, also there's the thing about all the leaves actually being in contact with one another as they're shipped, so by the time the consumer actually eats the leaf and gets sick, the best you could possibly do is say "we think it's from one of these packagers."

Maybe you're envisioning some other way entirely for Distributed Lettuce Technology* to solve this problem, I dunno. But I have trouble seeing it.

*I'm sorry, but cut me some slack, the joke is RIGHT THERE

[Alex3917]

> the "farm" selling you their romaine might actually be selling you romaine from somewhere else that they've repackaged.

Think about it from a game theory perspective. Under the status quo, each party in the supply chain maximizes their profit by lying about where their supplies came from. Whereas with DLT, each party maximizes their profit by being honest about where their supplies came from.

As an example, let's say you hijack you a truck and swap out expensive lettuce for cheap lettuce in a way that circumvents whatever tamper proofing technology has been applied. Stuff like this happens all the time currently, and is wildly profitable. (That's why if you go to a sushi restaurant and get a bunch of assorted sushi pieces or rolls, there is roughly a 0% chance that your meal will actually consist of what you ordered.)

With DLT though this is no longer profitable, because if you sell the cheap lettuce as expensive lettuce then you now have to sell the expensive lettuce as cheap lettuce, because each head or crate or whatever still needs to be traceable back to the source. This means that your total profit from the transaction is just whatever you would have made without cheating, plus your costs of hijacking the truck. So all in all, a substantial net loss.

[lalaland1125]

Doesn't this require you to trust the source? And if you trust the source, there is no need for a blockchain?

[atq2119]

Well, even if you trust the source, you still need to be able to access the transaction records.

You don't really need a distributed ledger for that,a centralised database run by an industry clearinghouse could serve the purpose just fine.

But maybe there are cases where a distributed ledger is easier or cheaper to establish than such a clearinghouse.

[Alex3917]

> Doesn't this require you to trust the source?

It allows you to know the source, which enables you to make a data-informed decision about whether or not you trust the source.

As opposed to the current status quo, where you can never even know the source so trust doesn't even come into the picture.

[simonw]

Could you talk me through how a blockchain solution would help avoid this in a bit more detail?

I've seen lots of vague "blockchain for supply chains is a great idea" pronouncements but I don't get how it would actually work.

[Alex3917]

Sure, so each party in the supply chain registers their private key with a PKI by going to the PKI's website (e.g. GoDaddy) and sticking their USB fob into their computer. The PKI associates the private key with an identity, and allows private keys to be voided and replaced if they get lost or whatever.

Then as each head of lettuce is picked, it goes into a crate that's securely sealed and then signed with the farmer's private key in a way that originates that crate of produce on the ledger. When the farmer sells their produce to the middleman that transaction is also recorded, and so on, all the way to the end consumer who buys the produce in a grocery store or in a restaurant. (And consumers would just use their phones or credit cards for this, rather than using any sort of external fob.)

Then when the first person gets sick they report their illness as per usual. Nothing happens at this stage, because there's no way to narrow down what made the person sick. By by the time the second person gets sick (with E. coli of the same genetic signature), now you can find the furthest place back in the supply chain where both people's purchases intercept. So you can now see if e.g. the contamination came from a single farm, and if so only recall lettuce from that farm rather than all romaine lettuce produced worldwide.

Because the database is open anyone can download a copy, and there is no risk of a single entity imposing a 30% Apple tax on each head of lettuce or whatever. And each person benefits from participating, because it's a pareto improvement in terms of their profitability. (Now their products only get recalled when they are at fault, rather than their products getting recalled when anyone is at fault.)

[beefield]

How about the types of products that can't be stored in a secure package from producer to consumer through the supply chain but need somehow be processed within the supply chain? You know, at least something like 99.9999% of the products...

[tim333]

I'm not sure secure sealing is done or necessary. If you get ecoli then just asking who the lettuce supplier was is probably enough. The government inspectors can then go check them.

[seibelj]

Suppliers at every step of the chain enter data into a blockchain. Every organization runs a node. Therefore they can’t lie later and tamper with records when something goes wrong. Investigators can trace provenance easier. That’s it really. An append-only cryptographically secure database would do that same thing, but that’s just another name for a blockchain, which is a rebranding of a specific type of distributed database that has enhanced trust properties.

[tomrod]

Blockchain requires distribution for trustless implementation though, which is the duplicated expense (versus an append-only secure database).

[Alex3917]

> Blockchain requires distribution for trustless implementation though, which is the duplicated expense

Trust scales with something like Metcalfe's Law. E.g. a consortium of ten independent banks is probably 99% less likely to steal my money than just Wells Fargo. The idea that we need millions of independent entities to get substantially better security than the status quo is just propaganda that gets spread by Bitcoin maximalists.

There is a cost of duplication, but at the level of duplication you actually need the cost isn't that much compared to the benefit.

[asynchrony]

Putting lies into a blockchain doesn't make them true. Lettuce can still kill you in a post-blockchain society.

[seibelj]

No, but it isn’t about lying as a matter of business, that would easily be detected and caught in most cases, and a large amount of work to continually lie effectively. If you have employees and machines writing lots of data it’s infeasible to tamper with it in real-time.

The tampering comes after the fact when a legal issue arises. The immutable nature of the ledger makes it an improvement over the past by preventing later tampering.

[asynchrony]

So why not use a central database and allow all stakeholders to replicate and keep their own logs of edits. It would be far more efficient. It would lack a certain buzzword though.

[seibelj]

A blockchain is a database optimized for that use case. Your desire to avoid the word blockchain is because you don’t like the connotations.