Walmart Requires Lettuce, Spinach Suppliers to Join Blockchain
blogs.wsj.com
blogs.wsj.com
There’s nothing being done here that couldn’t or shouldn’t just be handled with a traditional database. Having IBM “run it” also sort of defeats the whole decentralized aspect of blockchain technologies.
You don’t need “blockchain” to track where your produce came from. This is just a marketing play through and though.
To nitpick a bit -- even this would not require a blockchain.
The blockchains record transactions. Where for example a batch of soy beans and a batch of wheat go into a batch of animal feed. Then a few batches of animal feed go into a pig (or rather multiple pigs). Then the individual piggy goes to the market. To trace back your food you need to know how the sausage is made, and trace back the transactions to find out where any particular problem is coming from.
Point is: There is useful information even if certain steps can't be perfectly traced. There is value in not having to connect to a central database all the time.
Yes (and no), but that's not what IBM is selling with their blockchain. They're selling trust, but only providing a digital trust solution while completely ignoring the physical and human side of trust.
> There is value in not having to connect to a central database all the time.
Problem here is IBM's blockchain is still a centrally maintained database. This literally provides any value. You still need to connect to a central database at some point.
I generally agree with you and if I had to implement the solution, I wouldn't do so with blockchain.
That said, if there's a concern about data manipulation from Walmart's side (that is, employees erasing or modifying the data), blockchain would help with that.
If you look at blockchain as something almost like a cousin of PGP in the sense that you distribute signing operations it’s actually an interesting and novel technology.
Fundamentally, you could use clipboards and wet signatures to get the same result. That doesn’t mean that this approach is flawed.
Would we? That seems like a perfectly reasonable solution to me. You have a clear central authority here who could be issuing certificates to trusted third parties. It's a perfect fit for a CA and a bad fit for a blockchain.
Produce is more dynamic and 100% cost driven.
You have multiple, unsophisticated suppliers that shift based on season, weather, etc. These folks are located in the middle of nowhere in many cases and may or may not have connectivity.
Carting the produce from these suppliers to distribution is performed by any number of trucking companies. Then you have the huge distributed enterprise of WalMart itself, with dozens/hundreds of DCs and an internal fleet of trucks and contractors who cart products to the store.
Bitcoin demonstrated that a large number of unknown parties can successfully store and transfer value. I don't see why this would be a bad fit.
I mean what are you proposing exactly, that anybody can stuff a bunch of Lettuce in a truck, send it to Wallmart while generating a wallet address on WallmartCoin? Where's the traceability there exactly? What stops me from lying about the quality of my product or even who I am? What if I just wait for a farmer in my area to send a delivery of lettuce and impersonate them on the blockchain, how can it resolve the issue and figure out who did what? What if I buy cheap product from abroad and resell it as organic locally grown lettuce?
>Bitcoin demonstrated that a large number of unknown parties can successfully store and transfer value.
No, a large number of unknown parties can successfully transfer purely digital goods. As long as lettuce doesn't grow on the blockchain you'll need some kind of third party oracle to actually keep track of physical goods.
I know nothing about what is actually happening here, I'm speaking to a high-level process.
It seems logical that a workflow might look like this:
- All parties must have a supported application.
- Supplier scans carton labels as they are palletized and loaded into the truck. (you have a singed attestation that pallet x was loaded on truck y at location z)
- Truck is scanned on arrival at cross-dock.
- Cartons are scanned as they are loaded into various trucks for delivery. (you know how long the cold-chain was broken for perishables and who supplied what store)
- Cartons are scanned on arrival and scanned when shelved.
- Cartons are scanned when pulled and stocked.
The problem that you are solving is that at every step of the process, the process is at least partially out of Wal-Mart's control and every contractor has an incentive to either not track things or lie. If there is an e. coli outbreak, WalMart may destroy $5M of lettuce from Arizona where in reality they only needed to destroy $500k of lettuce from farmer X.
Is it the best solution? I have no idea.
When you get to the heart of things, that's all blockchain is anyway. The "blockchain" part really just describes how it's organized - in a signed chain
I also wonder how efficient it is to “query the block chain”?
But the world of corporatism is just as susceptible to fads like every other subculture.
It's like execs are desperate to force blockchain on every problem because it's the hip new thing. Even though most problems don't need blockchains and there are far better and simpler solutions.
Similar to the nosql fad. Who needs ACID compliance? If things fail silently and we lose a few transactions here and there, what could go wrong? Get with the times. The cool kids are into nosql now.
This specific instance grants assurance that neither Walmart or anyone in-between is tampering with the database.
We've had this discussion a billion times before on HN so I'll avoid a huge wall of text but it always boils down to the same conclusion: blockchains (as in bitcoin) are about being completely decentralized and trustless. It's an "and" not an "or", if you remove one of these imperatives they're completely pointless. Detecting tampering can be achieved trivially using public key cryptography and a good hash function.
So you're either saying that what IBM is doing is not a true blockchain or you're fine with anybody using PGP and sha256sum labeling their product as a blockchain. In the latter case it means that bittorent, linux package managers and Windows Updates qualify as "blockchains".
At any rate this is obviously a huge marketing ploy to get free advertising, like "web 2.0" or "cloud computing" before. The problem here is that pumping the "blockchain technology" also means pumping the entire ecosystem of cryptocurrencies which is 90% scams at this point.
You're completely right, but I want to point out something subtle that I almost missed. For something to be considered a blockchain, it does not have to be distributed (as you noted). There can be a centralized entity (Wal-Mart) controlling the blockchain, but like you said, a controlling entity takes away trust. Without trust, Wal-Mart can still verify any tampering, but the public would still have to trust that Wal-Mart is coming forward with any discrepancies.
The entire point of blockchain is trustless. Otherwise a walmart database would be fine.
I like this. I’ve worked in orgs where PKI meant identity and identity proofing and expensive certs. Blockchain changes the pki from “this public key is definitely prepend” to “this public key means the holder of the private key did it.” This is because the “blockchain” either does consensus or has an authority on that key’s action being appropriate.
So being able to use pgp and sha256 as appropriate is a good thing in my book. Could this be done without blockchain with smarter it policy? Yes. But it didn’t, and now there’s some way of formally structuring how non-authoritative identities can perform functions.
So breaking pki out of the authentication world is pretty useful for me.
It feels like we're arguing about semantics here. Non decentralised, cryptocurrency-less blockchains have existed since before Bitcoin and were just called databases, event stores, public logs, etc. The true innovation behind Bitcoin was its consensus mechanism (which requires both decentralisation and currency). I'd argue that technology which was well established prior to Bitcoin (e.g. a centralised tamper resistant database system) does not deserve to be called a "blockchain". Unfortunately, that doesn't seem to be the prevailing opinion.
Yes they do, or you could use a traditional database.
>This specific instance grants assurance that neither Walmart or anyone in-between is tampering with the database.
Except IBM. Hope no one at IBM is greedy... I wont hold my breath.
I work on a product in this segment (food traceability) and from experience I expect walmart to encounter possible operational issues by adopting the complexity of the blockchain into their solution.
The first one is tech-literacy. Like the article says, and is usual in this segment, producers and distributors have to adhere to the program to continue to sell to walmart. Often they just see it as a burden and don't perceive any value add for them, so they resist using it as much as possible. Data input must be incredibly simple and fast (produce can't sit in stock for long). If there is some exotic problem regarding certificates, keys or anything more elaborate than filling simple forms, then the producer will not be able to move his product until it is resolved with risk of having his shipment returned.
Unless you do all the work to set up the client side of tech, which means generating all the keys for everyone (making the whole endeavor pointless), the UX will be a major obstacle.
The part of this that's hilarious is we already have verification mechanisms in place. We have logs, controlled access, and verification hashes. It would not be easy to bypass the controls we already have.
On top of all of this, most of our customers can't even figure out how to read their emails to click a password reset link.
If IBM wants to fleece people, more POWER to them.
I was talking to someone who was using the "IBM cloud". They went to spin up some servers and etc and IBM was all "that will take a few weeks, we have to install them". At least to me "cloud" includes the ability to spin stuff up on demand.... IBM was operating it like you were ordering from a very old co-location service or something.
Word has it Watson failed possibly because it was sold as a magic drop in solution where in reality careful data entry and a lot of work was required to get quality results requiring both the customer and IBM to be heavily involved. Maybe had they understood / sold it right and brought the customer's along and tried it in the right places they would have done better.... or at least had a better chance.
There seems to be a fundamental misunderstanding of how things work and thus how to sell / execute at IBM.
Trying to keep from maniacal laughing during their sales pitches is always a fun game.
Well, the spin up is instant, but the multiple forms and stakeholder sign offs aren't :-)
(I work for a SoftLayer customer)
It is entirely possible they asked for something(s) weird.
I can see why that would be something worth doing in a food chain. To trace, for example, a particular load of soy beans to a customer eating a steak, there are a couple of completely autonomous companies/sole proprietors involved. From the original soy farmer, through feed production (maybe multiple factories because the soy is processed and later mixed with other ingredients), feed distributors and transporters, to the cattle farm. Again the individual animal can change hands multiple times, for example a bull calf can be fed soy based milk exchangers at a dairy farm where it was born, then be sold to a farm that raises it to market (with pigs there can be three different farmers from piglet to market maturity), then to the slaughterhouse, the meat goes to food processors and then into a distribution channel.
Easily a dozen or two separate legal entities. I can see why it could be hard to connect each of them to a central database reliably may be tricky.
In a blockchain system, a particular piece of information has to eventually reach all interested parties, of course. But it can do so through a chain of potentially untrusted intermediaries, which also don't have to be connected through an internet connection. For example a truck servicing multiple farms or multiple stations on one farm, could collect new information packets, and pass on those he already has. Variations of the "Sneaker Net" pattern if you will.
Food chain information is not very time-sensitive. A POST request is, however, very much time sensitive.
None of this requires - or even benefits from - a blockchain.
Also, your phone is able to store the images. In IoT there is the problem that a lot of devices can only deal with very little disconnectivity before losing data. In those cases it's better to pass on the data to anyone rather than lose it, even if that someone isn't the central server.
And it'll use what to connect to the blockchain?
> In those cases it's better to pass on the data to anyone rather than lose it, even if that someone isn't the central server.
None of which requires a blockchain.
This is of course also possible with signed responses to queries. I think the advantage here is that the signatures are build into the data-store. This just simplifies verification and replication.
Specifically, perfect trust in the log itself. Blockchain gives you a guard against someone trying to retroactively tamper with the log. It doesn't give you a whole lot of help with the points where data enters the log in the first place.
e.g., the blockchain solution to, "there was a network partition when you tried to enter that transaction, and you entered it on the smaller partition" is to declare that that transaction never happened. I can't see how this is an acceptable solution for logistics. With Bitcoin it's easy enough to say that the blockchain is reality, but with supply chain management, it doesn't matter that the blockchain says your kumquats are in a warehouse in LA; if they're on a train bound for Chicago, they're on a train bound for Chicago.
Plus, I'm excited to see IBM do something new, if it works we all benefit.
I would love such cryptographically safe systems actually being used, especially whenever we don't trust the db operator. E.g. for Reddit admins it might lessen the appeal to alter posts again :D
That would be somewhat obvious, and you'd have to go after that actor. But as long as that doesn't happen, and even if it would happen, most transactions will actually be valid enough to trace the food chain.
The blockchain does not solve the trust issue in this scenario.
Blockchains only work there is a verify unit entirely enclosed in the system - including the origins of any "unit" on the system.
* Bitcoin/Ethereum/etc - "coins" are a completely digital concept fully enclosed by the system. "coins" are generated in a predictable, consensus based manner with consensus based means of exchanging their value.
* Distributed Filesharing - "files" are stored in encrypted in a verifiable manner. I have an identity (or multiple identities) on the system which I can use to verify the source. Trust does become a factor in something like Civil where credibility is attached to a trust that an author actually published something.
* Food - involves a physical good that cannot be verified by the "blockchain". I can verify that SOME item went through a certain set of checkpoints. I can possibly verify that the SAME item went through a certain set of checkpoints. I cannot however verify the authenticity of any item before entering into the system. I have to rely on a middle-man (e.g. Walmart, Kroger, Whole Foods, etc) to verify authenticity at the origin point. They also have to implement safe guards that ensure goods cannot be tampered with between checkpoints. That relies on trusting the middleman to have appropriate safeguards in place.
Though here is another perspective I thought of. What the usage of blockchain would allow is a chain of liability to exist among different companies in the supply chain. If you are signing off on a product, you are verifying the authenticity of the item, and if it arrives defective at the next location you assume liability. As a customer, what you would really leverage, is the incentive of every individual company to not be liable for any issues to the next company in the supply chain. You would still be required to some degree to verify the direct transaction of the item to yourself, but if ubiquitously applied, it should offer some higher level of trust simply due to the transparency offered.
If this is needed in current society or will be implemented is another question, but I think large business definitely has incentive to minimize liability through something like this.
Blockchain generally forces some level of standardization or there will be rejection, as well as being incredibly easy to audit.
In a well functioning system, there is little benefit, but I would say that a blockchain based system elevates the floor of a functioning system due to its nature.
I agree. I think that's one of my big problems with this.
It seems like it's going to be a way for [Walmart] to point the blame at some supplier. They can say "look we implemented the blockchain. X supplier said they did THING and they didn't. Not our fault".
But in regards to identity verification, you are correct that it would be through digital signatures controlled by private keys. In order for malicious actors to masquerade as legitimate ones, they would have to steal these private keys. That can both be easy and hard, but that is probably going to have a relatively strict correlation to how much is at stake.
In the EU we have a somewhat traditional system for cattle, created after the BSE crisis. Each animal has two ear tags which contain a unique ID. This ID will be carried through to the table if necessary. But it has to be "copied" along, for example when the animal is processed.
The idea behind block chains in food processing is to record the transactions between individual parties. The blockchain does not verify the food, but rather the belief that they passed on a certain product. A malicious party will now have much more problems creating, vanishing or forging material. It also doesn't matter that much, because after a malicious transaction the following transactions are perfectly traceable again (if at least those are honest...).
This can be somewhat hidden by remote APIs, multi-datacenter protocols and the like. But probably you are quickly going to some form of custom, signed data packets with an eventually consistent system.
If only we could hash a potato...
We call it hashed browns.
User account security and role/employer based data masking across all companies and all data are the key requirement, lack of the central intermediary is table stakes.
This also quite obviously a DLT solution and not a blockchain...but it seems like a lot of people are missing that point in this thread.
Only because in the case of a fork it has a defined way to choose whose work to throw away.
You cannot meaningfully operate on a blockchain like bitcoin while disconnected from the majority. Each fork will be internally consistent, and you can continue to work on it if you like - you probably wouldn't even notice anything wrong, but at some point you'll connect to the longer chain and an arbitrary amount of history will be blown away.
If one were to deploy a non-blockchain version of such a thing, what would it actually look like?
At some point other businesses will say "if a freaking lettuce grower is putting their supply chain on the blockchain, why the hell aren't we?"
Somewhere there is a tipping point - and then logistics is done through dozens of "private" blockchains, which i will better is orders of magnitude simpler and more efficient than now.
Okay, I'll bite. A few questions that I think lead to the idea of a DLT system being an appropriate fit:
If it's a single
If you have various different, independent actors that operate in a shared environment but with distinct roles, how does traditional DBs help you do anything that isn't already being done today?
For example, sharing data between those actors is still a heavy duty process. Trusting the data coming to you from other actors is still a high risk area, even if they aren't intentionally acting maliciously. Determining actors who have acted in poor faith without trusted and transparent data sources is incredibly difficult as well. How do you overcome these issues and come to the point of a centralized DB either? Who's going to own that central DB and pay for everything going into and out of it?
So in that way, I don't see your point about how a traditional or central DB could solve these issues. I agree with all your other points, and I certainly agree the buzzword charm is heavy as always with this topic, but I don't buy that part.
Happy to hear otherwise. Full transparency, to me, it does seem like DLT has an enterprise value so I'm a bit more of a homer than most.
Utter nonsense. Everything is HARDER TO DO when done through a blockchain.
> Trusting the data coming to you from other actors is still a high risk area
Utter nonsense. Public / private key encryption solves this in the same way a blockchain would, because a blockchain uses public / private key encryption.
> Who's going to own that central DB and pay for everything going into and out of it?
Walmart. Or IBM. It would likely cost less than $50/month of AWS resources, including backups and redundancy.
Could you explain?
PKI is solves the issue of identity. It can't solve all the issues around accuracy, consistency, and provenance when it comes to data sharing.
Ignoring the idea that you think it's a cheap endeavor, my bigger point is that putting every single bit of the responsibility on a single entity is a tough challenge.
Is a given blockchain a more efficient database? Not efficient measured by percent of data stored in any given entry, which of course throughput and any other, "engineering metric," will suffer because of that. As an engineer, the idea of wasted energy, memory, space, etc., makes one cringe.
Efficient from the standpoint of preventing loss of human life or preventing sickness? Well, in the United States where likely most of us live, this is not as big of a problem, but likely in many other countries such as China, "food authenticity," is a problem. Let's keep in mind that Walmart has more stores and customers in China and more problems with food than the United States by orders of magnitude.
If I'm an actor within the food system in China which presumably has multiple middle-men, and I want to move one product up the supply chain through multiple, ultimately ending up on the shelves at Walmart, then I will not want to give away my source, because I want to get preferential pricing. However if I can convince my suppler upstream to use this tool (it doesn't matter if it's IBM, Google, Alibaba, or some startup or whatever, it's just a tech tool), to track and register when food was, "picked" or "harvested" then I don't have to give information to my buyer about the source, yet the database is all, "standardized," in terms of labeling. Keep in mind the alternative would be some kind of bar coding system which perhaps Walmart would have to impose. Well, I don't want my upstream partners knowing that this is going to Walmart either, otherwise they will jack up the pricing. If everyone is using some IBM tool, and assuming the IBM tool sees increasing adoption, then no one (hopefully) knows where or who a particular food is going to, yet any problem foods can be tracked back to their source by the end seller, without having to impose multiple types of key-value pair, bar-coding database systems, which - while technically easier to implement and run more smoothly from an engineering standpoint, perhaps do not take the entire use case into mind, because parties within the supply chain may be unwilling to share their source or destination due to pricing incentives.
Mind you, I am no food systems expert, I am just trying to talk hypotheticals here. I think the knee-jerk reaction on Hacker News within this thread is an almost Redditian "reaping karma" approach by putting down Blockchain, because many of us have had bad experiences working with corporate executives who have no idea how various types of technology work, and implementing non-technology buzzwords ends up being painful. That being said Blockchain at its heart, stripping away the history, is just a mathematical concept, and it's a math tool that can be used to point from one source to another. Calling it a, "mind disease," is losing sight of that.
Typically the types of discussions on hacker news that I enjoy reading are more angled toward how do you reverse engineer things, not just insulting an idea without backing up one's insult.
>That being said Blockchain at its heart, stripping away the history, is just a mathematical concept, and it's a math tool that can be used to point from one source to another.
Not anymore. Look at this thread, not everybody seems to agree about what a "blockchain" is. Is it a blockchain without PoW? Is it a blockchain if it's fully centralized? The word is so generic to begin with that people can overload it with whatever they want, like "cloud computing" and all these other buzzwords.
This is not a technical discussion because we're well past that point. This is not about technology, this is about marketing and banking on the hype. Cryptocurrency proponents are happy because it can be used to boast wider adoption, crypto haters (like me) dislike it for exactly the same reason.
Walmart has 10x as many stores in the US relative to China. It's 5,358 in the US¹ vs 426 in China².
Does Walmart have leverage in China to force this on growers? They do in the US.
1. https://corporate.walmart.com/our-story/locations/united-sta...
2. https://corporate.walmart.com/our-story/locations/china#/chi...
Somewhere I read a helpful way to rephrase "blockchain" that really helps cut to the heart of the issue when you're dealing with technical questions like this: A blockchain is just an ordered series of files, each of which contains a hash of the previous one in the series.
So, when you've got someone saying, "What if we use blockchain?", just mentally substitute the suggestion as, "What if we store the data as an ordered series of files, each of which contains a hash of the previous one in the series?" Any bits of the proposed system that aren't impacted by the decision to store the data as an ordered series of files, each of which contains a hash of the previous one in the series, also don't have anything to do with whether or not it needs to involve a blockchain.
(Yes, I realize there are additional questions around trust and proof of work and whatnot that come into play when you're talking about blockchain-as-in-cryptocurrency, but, as far as I can tell, it's a rare case that proposed use cases for blockchain in business are ones where anyone even wants trustlessness. See, for example, Walmart trying to use a centralized blockchain to manage their edible leaf supply chain.)
Mentioning the hash is an implementation detail -- it is what gives blockchains their immutability property.
So I'd say even simpler: a blockchain is merely an append-only register that can be used by multiple parties.
But it's also the defining characteristic - it's the essential thing that sets blockchains apart from all the many other ways you could create an append-only register that can be used by multiple parties.
The fact that the hash is both an implementation detail and the defining characteristic is exactly why, IMO, "blockchain" is an inappropriate word to use in most business plans. Implementation details as a headline feature of your elevator pitch is a classic characteristic of a solution in search of a problem.
As far as I'm aware, nobody was talking about peer-to-peer supply chain management before "blockchain" became a buzzword. Probably because you don't need peer-to-peer when you have a natural central authority. The organization whose supply chain it is in the first place, for example.
Agree with everything else you said.
One property of a database that may not exist on blockchain is deletion of records. You can not delete "records" on blockchain due to its immutable property.
Here's the closest I could find to technical info:
> IBM Food Trust's blockchain solution, on the other hand, is permissioned so invited members know exactly with whom they are transacting, similar to what happens between business partners today. Participants also determine what data is seen by whom, thereby providing information on a need-to-know basis. Smart contracts also run on our blockchain, allowing business logic to help solve disputes, automatically execute contracts, and build trust.
In any case, with a 'hash-linked-chain-of-blocks' attempted forks are really easy to prove.
Blockchain is a decentralised way to create trusted record without a trusted counterparty, i.e. centralised.
In this case, there is nothing decentralised, you need to go through IBM as with a regular system. Blockchain is only mentioned as marketing to convince you they are reliable. A bit how some hosting service tell you their are using S3 to convince you they are not going to lose your data.
edit: The problem is the title of the article that let you imagine there is some interesting blockchain tech being developed. Instead that's about as interesting as "Walmart uses SAP"
Because of this situation it is natural to assume that a blockchain-based system must either have a decentralization aspect to it, or that the architects of the system are incompetent. And we don't want to assume there's such gross incompetence at IBM, do we? ;-)
This article explains it well: https://berk.es/2018/09/19/the-private-blockchain-fallacy
FTA:
> Tests... have produced a more complete view of the food system than under current federal regulations, according to Nestlé SA, Dole Food Co., and other participants in the project. ["more complete" != "more accurate/accountable"]
> As investigators worked , 210 people got sick and five died, according to the Centers for Disease Control and Prevention. [implying blame lies with the regulatory body, not the industry]
> A directive for suppliers to use the Food Trust blockchain will help the industry create a more complete picture of the food system than is possible under current federal regulations, Mr. Yiannas said in an interview. [yet again federal regs are mentioned]
> “Today, the requirement for traceability by law is one step up and one step back. That doesn’t work any more,” he said. [really obvious here!]
> Early this year, as investigators worked to understand an outbreak of E. coli linked to romaine lettuce grown in the region of Yuma, Ariz., 210 people in 36 states got sick. Five people died, according to the Centers for Disease Control. [ditto blame shifting]
> Blockchain establishes authorship or ownership that experts say can’t be faked and eliminates costly middle layers because of its peer-to-peer structure. [if it can't be faked, obviously there's no need for regulators! Garbage in, perfection out! ::eyeroll::]
It's like claiming that ledgers written in pen make the SEC obsolete.
Sold my alts, kept my Bitcoin.
Im seriously starting to believe in the phrase Bitcoin not Blockchain.
In the article's example, 250 people got sick from a lettuce outbreak, and everyone stopped buying lettuce, hitting the whole industry. But 5 million people get sick from Norovirus alone in the US every year.
Leafy vegetables like lettuce are the most common source of food illness. Telling people about a minor outbreak is just letting them freak out for no good reason. We should be educating people better about foodbourne illness so they can respond without freaking out, and so they don't get sick so damn much. And the media should stop freaking people out.
250 people out of 350 million getting sick, and not even dying? It's a minor risk! 35,000 die in traffic every year, and these people are freaked out by some lettuce. Take a fuckin chance, would ya please? https://youtu.be/X29lF43mUlo
For example, I could argue so few people were affected because not many were eating lettuce, and then when news broke, nobody was eating lettuce.
I know more people that drive cars than eat lettuce.
If lettuce is contaminated with ecoli at the source and you don’t recall/stop people eating it, you will have much more adverse health events. Different outbreaks have different responses and sometimes that includes notifying the at risk population and the source of the risk. [0] (this list includes lots of norovirus outbreaks and the response for them)
We should also be educating people about food borne illness, but this isn’t exclusive to outbreak control.
[0] https://www.cdc.gov/foodsafety/outbreaks/multistate-outbreak...
73 million Americans are infected with E.coli every year and 5,000 die. Only 5 died in this outbreak. You think that number was significantly reduced because it was announced that there was a single small outbreak?
The outbreak was minor, but the effect on the economy and people's state of mind was overwhelmingly more powerful. It's fine to notify an at risk population if you can, but what do you gain if just a few less people get sick? What do you lose when people stop supporting an entire industry?
"CDC estimates that each year STEC [Shiga toxin-producing E. coli] causes 265,000 illness, 3,600 hospitalizations and 30 deaths in the United States."
Using your stats, this outbreak was responsible for 0.1% of e.coli illnesses and 1/6th the deaths. But it's also 1/300,000 of the overall food poisoning illnesses, and 0.1% of the deaths.
So it hit the lettuce industry significantly harder than normal, even though the actual effect on health was minimal compared to the norm.
Estimated annual number of episodes of illnesses caused by 31 pathogens transmitted commonly by food
Domestically acquired foodborne [1]
9,388,075 (6,641,440–12,745,709)
Deaths [2]
1,351 (712–2,268)
[1] https://www.cdc.gov/foodborneburden/pdfs/scallan-estimated-i...
[2] https://www.cdc.gov/foodborneburden/pdfs/scallan-estimated-h...
The EPA values a life at $7.4M for policy purposes [0]. So 1351x7.4M is about $10B. In 2015, the value of all US farm output was $136B. [1] So you could argue that you’d want to save more value from lives than from market impact, if you wanted to be purely utilitarian (that I hope no one in thread does).
But there’s a big impact from illness. I think many people underestimate the impact of food borne disease because they are young and healthy. I’m glad you pulled up the impact because it’s a big deal.
Hopefully as people better understand the danger, we’ll be able to avoid reductive math where we only worry about things when they are big, and way harder to fix.
[0] https://www.epa.gov/environmental-economics/mortality-risk-v...
[1] https://www.ers.usda.gov/data-products/ag-and-food-statistic...
Still a minor risk to the population, but a greater risk to brands like Walmart.
If the suppliers themselves enter every piece of information into what is essentially a living contract, any error or omission could be considered a breach of contract and can be leveraged.
If it was only about food safety and increased sales because of increased trust the solution you propose, maybe with some kind of basic digital signatures, would be fine, and probably much cheaper.
From what I've heard, Walmart seems to like moneh very much, hence doing something a more expensive way is likely to be intended to increase their bottom line in more ways than one.
but at least intuitively, a signed blockchain (in the true sense that each block contains a hash of the previous block) does seem to confer some additional security over a plain database.
A plain database would give you a log of events and who logged them, but security and trust resides in the database and how it's authenticated. Anyone with sufficient permissions could modify the database.
A signed block chain would give you a log of events where each party in the chain signs the new block (which includes a hash of the previous block) using their private key. The block can then be verified using each entities public key. To modify this system you would need to be able to breach the trust of the private keys.
{Lettuce from Farm A on date, <>}[Signed by farm A] => {Received lettuce on date, <Farm A block>}[Signed by shipping agent] => {Received lettuce on data, <Shipping agent block>}[Signed by Walmart store], etc
In theory then, Walmart would have a registry of the public keys of each agent in the chain, and upon receiving produce could verify the events of the whole block?
But now you've also raised the technical requirements and are betting the security on non-technical farmers and farm staff. Even if they have technical chops since farm equipment is more complex these days, they likely don't have security chops.
There's already 'country-of-origin' scams in international shipping, so it's not a far stretch to apply the same concept to farming supply chains. Throw a disposable proxy farm in front of your real farms and change the origin. When it's human-entered information, blockchain doesn't prevent someone being dishonest from the beginning, and it lures people into a false sense of security because of IBM's advertising.
I guess limiting fraud to the beginning of the supply chain is a step in the right direction though. I don't think blockchain solves chain-of-custody well though.
1. Packaging it in such a way that it's easy to use for non-technical users.
2. There still has to be a mechanism for establishing trust in the public keys registered in such a system.
For one I'd imagine that farmers are doing some amount of work to go from raw "lettuce in the ground" to "one unit of shipment". Once it's a unit of shipment it could have an ID/Bar/QRcode generated that is then scanned with a handheld scanner that has its own keypair. The scanners keypair would be registered with the farm and so the farm would either explicitly sign off on the package or implicitly have signed that scanners pair as trusted by the farm. So a farmer and farmstaff wouldn't need any technical know how beyond operating a scanner. Depending on the farm adding such a granular tracking system may or may not be easy to implement.
For two, I can see two options. Walmart could verify every step of the chain themselves and register/receive the public key for each step in the chain. (So a farm would register with Walmart as a verified producer, a shipping company would register, etc). Or each step of the change could make a binary decision to trust the step before it and apply pressure down chain to resolve issues, since theoretically each step could fabricate the entire chain before passing it off. In this scenario, Walmart would go to the shipping company and say "E. Coli was detected in Shipment X. We no longer want to be sourced produce from Producer Y. The shipping company then takes this into account when sourcing produce, or else Walmart discontinues business with them.
I think the big benefit is by having an associated public key, you can verify the claimed identity of any agent in the chain and build trust in that agent over time. You could keep popping up disposable proxy farms, but Walmart/Shipping provider/X doesn't have any reason to trust your proxy farm's shipments; you have to establish trust either directly with a buyer of your produce, or establish trust over time as a commodity provider. As you build trust you can probably get better prices.
I'm by no means a blockchain advocate or a supply chain manager of any kind, just doing a thought experiment of how blockchains might be effectively applied in such a scenario. There very well might be better solutions, but I think at the very least a blockchain presents an interesting or novel solution.
Just thinking through, you could also create a sort of "doubly linked list" and include who custody was given to as part of each block, so a farmer is signing a claim of who they gave their produce to. {Farm A produced unit of Lettuce X, Given to Shipper B, <no previous>}[Farm A signed]
But again, that's why I mentioned a blockchain in the true sense, as a chain of blocks containing a hash of previous blocks, because git is a blockchain by that definition.
And it’s any different on a private blockchain?
https://www.ibm.com/blogs/blockchain/2017/05/the-difference-...
> Consensus in a blockchain for business is not achieved through mining but through a process called “selective endorsement.” It is about being able to control exactly who verifies transactions, much in the same way that business happens today. [...] This is different from Bitcoin, where the whole network has to work to verify transactions.
> Bitcoin thrives due to anonymity. [...] On the other hand, businesses have KYC (know your customer) and AML (anti-money laundering) compliance requirements that require them to know exactly who they are dealing with. Participants in business networks require the polar opposite of anonymity: privacy.
So I actually think this is not such a bad idea. I mean, it allows IBM to take all the money from people who want to buy blockchain, but does not produce negative effects, like energy waste. Sure, I would call it "distributed event sourcing database", but if it has to be renamed for marketing reasons, this is OK too.
https://i1.wp.com/potdar.info/wp-content/uploads/2018/07/ima...
The link to the actual description is behind a register wall, but there is a bunch of marketing gibberish at:
https://www.ibm.com/blockchain/solutions/food-trust
There's no proof of work or similar and participants can limit who has access to the data they contribute, so it basically is just a data sharing system run by a central party.
A very common response to these block chain/supply chain stories is that "a block chain is just a database."
But even that statement is overly optimistic.
A block chain is a log file. It keeps a record of a sequence of state changes. All of the tamper-resistant properties we associate with Bitcoin come, not from the log file it uses, but from the economic incentives around changing the file.
So the choice isn't between a block chain and a database for these non-economically incentivized use cases such as IBM's supply chain projects. Rather, the choice is between a block chain and a dumb log file.
Oh, I noticed. In fact it's the first thing I go looking for in these articles about "blockchain solves problem X".
And then I read the words "IBM Hyperledger". I've tried to find out what Hyperledger is, but penetrating IBM's blizzard of marketing bullshit about it has so far proved beyond me. All I know it has some relationship to a think called a "permissioned blockchain".
From what I can gather (as it is also surrounded by a cloud of marketing hype) a permissioned blockchain doesn't use proof of work, proof of stake or anything related. Nor is there a race to append the block. (Thus is it prompted as solving bitcoin's energy "problem", and because it doesn't need time to accumulate the proof of work it's not limited in the number of transactions it can process). Instead a permissioned blockchain appoints (ie, gives permission to) some miners to process the blocks. I have no idea what happens next, but I'm guessing in practice there is only one miner who checks the incoming transactions and assembles then into a block, signs the block using a public key, and publishes it by appending it to the database where it remains unchanged forever more.
To me the word blockchain doesn't just mean "append only published database". If that was true every log file would qualify as a blockchain. It also involves a clever set of rules for appending to that database that have one clear goal: they ensure the log is append only by making alterations computationally expensive.
In doing that a blockchain makes the "trust" quantifiable, eg to rewrite an entry 24 hours old in the log you are going to have to expend roughly 100 G Watt hours. Then by using more magic (the consistency checks aren't just rules, they are computer programs that can include assertions on future events, and thus control what happens in the future), the assertions can extended into "I promise to do X in the future, and if I don't I loose Y", and the only way to undo that promise is to expend that 100 G Watt hours.
A permissioned blockchain shares none of those properties, so to me it isn't a blockchain name notwithstanding. What it does look like is the old fashioned titles office - if I want to transfer my house title I have to give a notice to the Titles Office, and when they give it their official stamp of approval and append it to their records, and it's done. In that case the currency is property, the transactions are record of change of ownership of that property (which always originate with the state owning the land), the blockchain database is the records of all changes of ownership (which happens to be public in this case), the single miner is the Titles Office.
The amount of trust you have in the system boils down to much you trust the Titles Office to do its job (are they easily fooled, can someone be bribed, could a fire destroy the chain, and so on). This is not easily quantifiable. As an example I live in Australia whose civil systems are about as strong as you can get, yet every few years we have a new headline of someones house being sold from under them (usually while they were on an extended overseas holiday) due to title fraud. There is no recourse when this happens - the transaction is as irreversible as a bitcoin transaction and the state have legislated to ensure they are not responsible for any losses. However unlike bitcoin, it's impossible to extend the trust you put in the Titles Office to other applications. Or to put it another way: they are not going to look after your Ethereum ICO's for you, whereas Ethereum could do a very good job of looking after titles.
So it isn't a blockchain. It looks to me like IBM is selling "Titles Office" software for other applications, given it the fancy name "Hyperledger" and added blockchain to marketing blurb for extra pizzazz. 10 points for marketing prowess I guess.
It does however sound like a reasonable way to track food supplies. The currency is the food with some certifications. The transaction are changes of ownership, the miner is someone appointed to collects the sad transactions, stamp them as official, and append them to the log, the database is public so everyone (including the state and consumers) can verify everyone has made the right promises on that strawberry they are eating so they can sue there arses off if it contains needles. And the entity doing the certification (IBM?) gets to make a bit of money for their efforts.
This application requires neither, and this implementation accomplishes neither.
That means executives from the world's largest companies are all reading this article and many will be having discussions with their management teams about blockchain.
Technology relevance discussions aside, moves like this are what turn fads and buzzwords into funded projects and business models.
And when a big company like Walmart makes a move like this, others follow ...
If you only have one of each, any success is surely fickle and will quickly dissolve.
If one force (Marketing in this case) overwhelms the other, then of course you have 'Blockchains' to track food. Not saying that there isn't a need for this, but it smells funny. I'm surprised there isn't a 'Deep Neural Network' used also to make things look even more 'cutting edge' ....
There's no wider benefit to the public from this unless the chain is publicly verifiable, imo.
And right now AI/ML is taking over from blockchain, and lots of it will be written by people who don't know what a linear regression is and once heard of p-hacking but couldn't make up an example of it.
Or in JS.
People see a technology and go looking for ways to apply it.
Sure, a blockchain can be used to solve this problem. But should it? Probably not. It’s hard to find technical information but it seems like the same could have been accomplished with an easier solution.