IBM is quietly brushing its Watson mess under the carpet and now they’re trying to focus on blockchain. However this is just as substanceless and full of marketing fluff as Watson was.
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.
IBM really seems stuck in their old systems / and at some level doesn't understand what to do with new systems.
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.
I hate to defend IBM (I used to work there and have nothing good to say) but its likely they were using the "Private Cloud" which is exactly what you say, co-location in the IBM Datacenter. Its just marketing rubbish.
"IBM Cloud Private" - it's a fascinating product that can be summed up as "We package kubernetes for you, and you pay us 2 million dollars. If you are a huge customer, we'll discount that to 1.6 million dollars."
Trying to keep from maniacal laughing during their sales pitches is always a fun game.
>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.
Well, the spin up is instant, but the multiple forms and stakeholder sign offs aren't :-)
One of my close family friends (an endocrinologist) participated in a Watson study at Yale New Haven Hospital. Apparently the amount of effort required to input the patient medical history from paper/other EMR into Watson's system was astronomical compared to just doing the analysis themselves. It sounded like it was mainly a UX issue but that's indicative of IBM's understanding of their market.
I got the impression from other articles that there was a bit of a constant process inputting data, formatting, reformatting and etc to get Watson to digest it for any given problem. Not necessarily a game breaking flaw, but it certainly meant that you would not use Watson for any .... issue that you already could solve with what I'll call "medium" effort. It had to be a really big issue, really big payoff before all that time made sense.
How many servers were they spinning up? My understanding (which could easily be wrong) is most of 'IBM Cloud' is really SoftLayer rebranded. Softlayer has virtual machines they can spin up for you within minutes, and they can spin up a small number of servers pretty quickly if you don't spec the hardware too weird, but if you want like 50-100+ servers with different specs than they usually do, they often have to order or cross ship parts to the datacenters you want them in. Waiting a few weeks seems out of the norm though.
I don't recall the specifics. Their organization was what I'd call a mid-sized organization so it wasn't small. They were under the impression they could get it on demand from other providers, but IBM did not do that.... but they already chose IBM so there they were.
It is entirely possible they asked for something(s) weird.
As I understand it, a blockchain is a decentralized database which does not require the individual instances to have perfect connectivity and perfect trust all the time.
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.
> does not require the individual instances to have perfect connectivity and perfect trust all the time.
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.
There is no such thing as "an item" moving through the food chain.
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...).
With an "IBM hosted MySQL store" you would need every party to have write privileges on the database, and make realtime connections to exactly this one database instance.
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.
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.
But since it's working with legal liability there's no need for blockchain. That can be done through standard contracts and having companies certify that their items are authentic. You still need such a contract with a blockchain, all the blockchain adds is some complexity.
I mean the question is if the complexity is needless.
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.
As you stated, blockchains can be quite useful in a low trust environment. Thus currently most of its use cases are by criminals or transactions that can't be easily adjudicated, like international money transfers. I hope that the cryptocurrency craze is more just a standard get-rich-quick ponzi scheme in action than a sign that the West's hard won high trust culture is changing to a low trust one.
> I think large business definitely has incentive to minimize liability through something like this.
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".
Can a block chain be poisoned by malicious actors easily? I hope not. I guess if there is a gate that prevents malicious actors from entering/participating in a block chain network... but how does identity verification on block chain work? Digital signatures of block chain content?
I'm not sure how to answer this as it would require more context in regarding to what you consider a malicious actor and I would need more details regarding the blockchain in question.
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.
No, you can't verify the food itself. But you can verify that a digital signature owned by the company in question signed the chain of custody for that food item, and using the blockchain, you can verify that that signature was made at a certain, retroactively immutable point in time.
Well, this is still an improvement over having no information about your produce, and a blockchain would provide a reliable ledger to sue deceptive food sources.
> As I understand it, a blockchain is a decentralized database which does not require the individual instances to have perfect connectivity and perfect trust all the time.
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.
Actually it does. IBM is spearheading the Hyperledger projects, so I'd suspect they're using Fabric. Fabric allows you to run chaincode on all transactions, which has to succeed for all parties of the secure ledger before the transaction is committed to the log. I think this tech makes a lot of sense for the use case.
Plus, I'm excited to see IBM do something new, if it works we all benefit.
I agree. The append-only nature of blocks chained together using hashes can build the most tamper-proof transaction log i can imagine. Even without mining/consensus algorithm and with it only being centrally host (but still published), i can upload a file to e.g. some government agency, see the file hash appear in the block and save the block hash. As long as that same block hash is used to continue the chain, upcoming block hashes would have to change to remove my entry from that chain-log.
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
I believe the case of network partition only matters in case of an attack on the system, i.e. someone entering conflicting information.
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.
But everyone involved is entering the information into the same IBM software front-end ("Food Trust")... So all players involved are using the same front-end and the same back-end, and only Walmart & IBM have the ability to change anything. How does a blockchain benefit anyone (other than IBM) in this situation?
Just guessing, but if appending to the chain requires signatures from IBM / Walmart, then all you need is to get the blockchain from somewhere, and you can verify it. With in-build non-repudiation.
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.
It doesn't preclude it, sure, but what stinky613 said does mean that a blockchain does not offer particular advantages over a more traditional datastore (regardless of how that datastore is accessed). I believe that was their point: that in this situation, a blockchain requires more effort for no additional benefit.
Putting data into a blockchain is something different from making a TCP/IP connection to the internet.
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.
My phone's Instagram app lets me "publish" images without a data connection. It queues them up, then POSTs them off to Facebook's API once I'm back online.
None of this requires - or even benefits from - a blockchain.
Yes, but your phone will eventually get back to the internet. An endpoint on a farm may potentially never be able to connect on its own.
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.
This is an important insight. A key characteristic of a "supply chain" is that no one company really "owns" it, and so integration to centralized systems is frequently unattractive. If a blockchain provides a decentralized repository for data, and the data that is stored can be effectively masked, then it gains real value. If it is just decentralized supply chain dropbox, then it doesn't do much.
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 is the biggest factor in why a "centralized" database or even a distributed one for that matter doesn't adequately provide the same value that IBM is bringing here.
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.
> blockchain is a decentralized database which does not require the individual instances to have perfect connectivity
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.
The fact that there is a fork is a inconsistency per se. The log must be a linear chain of blocks, that's enforced by the protocol. If there's a fork, eventually all the diverging subchains but one (the longest) will disappear.
Watching there "Blockchain" commercial was infuriating to me. I saw absolutely no way that the "Blockchain" was solving any meaningful problem. Unless each plant can be uniquely and irrevocably tagged from the time it's planted to the time it's in my bowl, this whole thing is useless.
The very point is that you can't tag the plant from the original producer to the individual consumer all the time. For one thing, you'd need to collect a whole lot of tags and carry them on. That would be the traditional solution.
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.
> Point is: There is useful information even if certain steps can't be perfectly traced.
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.
And it doesn't really prevent bad food entering the food supply chain; at best it just documents where it originated. So the next time someone is sicknened headlines reading "The IBM food chain (TM) failed to protect consumers" seem inevitable. Seems like a big reputational liability for marginal upside.
I don't think so. I think the actual headline (after IBM's pr machine gets involved) will be, "IBM successfully limits spinach e coli outbreak to only 56 people across seven states."
I’m glad to hear more people slicing through the bullshit on this. I’m building a company that aims to build a centralized and impartial means to trace food through the supply chain. Every time I pitch this to people the first thing they’ll do is cock their heads and say... “so is this going to be blockchain?!” and I have to explain in layman’s terms why that’s not necessary nor beneficial.
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.
The playground is all about running critical systems with databases that are ACID compliance for the past two months, instead of 23 years. After all, obviously you need webscale, and something that is working successfully in the industry for so long must be outdated by now as structured data is antiquated by definition (even though immutability sounds cool). lol
Salespeople better know what problems a blockchain solves that could not be solved with previous methods. Because this is something that customers will ask.
Not necessarily. The company I work for has a number of customers asking for blockchain but they don't know what it is. They just want it because it's the new cool thing and it will make them look up to date.
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.
Help me out here, I really don't see how a traditional database could solve the problem today.
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.
> sharing data between those actors is still a heavy duty process.
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.
> Everything is HARDER TO DO when done through a blockchain
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.
> There’s nothing being done here that couldn’t or shouldn’t just be handled with a traditional database.
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.
Perhaps, but there are far easier ways to solve that problem. Digital signing of data to protect against alteration has been around for ages and doesn’t require “blockchain.”
If the article was talking about Walmart using PKI with business partners, this thread would be grousing about how dumb CAs are.
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.
No, we wouldn’t be talking about it at all, because that’s exactly how we expect this problem to be solved. There would be no media, there would be no discussion, and there would be no publicity for IBM. And that’s exactly why they called in the blockchain. It’s a fad.
> If the article was talking about Walmart using PKI with business partners, this thread would be grousing about how dumb CAs are.
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.
The PKI model is awesome for less dynamic environments. Factories and suppliers are a great example of that.
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.
Surely legally speaking they have to do a minimum amount of vetting for their suppliers. They also probably need to negotiate prices and quantities at the very least. Sending the supplier a certificate in the process doesn't seem particularly complex (especially since it's easily fully automated and no more complicated than setting up a blockchain "account", however that works).
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.
The digital good is the chain of custody and timeline associated with the physical good. Money has always been a proxy for physical goods -- if you look at the Best Buy annual report, they don't tell you how many TVs are in stock, they tell you the value of inventory.
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.
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
It occurred to me also that you’d have to include trust, a la digital signatures as part of the solution also or the whole discussion wouldn’t make sense. If the block chain network actors aren’t trusted it leaves too much room for malicious behavior on the block chain itself.
I also wonder how efficient it is to “query the block chain”?
What's amazing to me is that, in this case, that's completely obvious to anyone technical. Lots of people know only a little bit about AI, even if they're computer programmers; I think most people can appreciate the idea of a distributed database.
Nope, a blockchain would serve a good purpose to have disparate entities share immutable data with event history, as today most companies are not giving each other access to their respective databases.
So why doesn’t someone do that — or create a centralized Walmart database of food transactions hosted by IBM, like in a MySQL store with a CRUD front end. There I just saved everyone millions and tons of energy.
Does it matter ? Walmart is saying "jump" to 1,000 small suppliers, and next year they will say "jump" to 100,000 suppliers
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.
Decentralization is critical to cryptocurrencies, but that's just one use case on top of an entire blockchain ecosystem. Not all blockchains need to be decentralized, and not all blockchains are cryptocurrencies.
This specific instance grants assurance that neither Walmart or anyone in-between is tampering with the database.
>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 fine with anybody using PGP and sha256sum labeling their product as a blockchain”
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.
> 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.
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.
You're right but again, blockchain is not needed for that part either. Just have wallmart publish their signed database publicly at regular intervals this way if they cheat and try to modify existing records anybody with an old dump could prove that something weird happened (since the database is signed simply showing a conflicting entry with a valid signature would be enough to demonstrate that either Wall-Mart did something fishy or that they got compromised. You wouldn't have to trust the whistle blower).
Sure, but they could also prevent tampering by just running a database themselves and not providing APIs that allow data to be tampered with. If they want to be able to prove it for external auditors, create a write-only audit trail the same way banks have been doing it for decades.
Is Wal-Mart really the threat in this case? I thought the threat was farmers too cheap to give their workers restroom breaks. This system will catch those farmers, and limit the sale of their produce. Wal-Mart doesn't actually want to sell dangerous lettuce.
I didn't mean to say that Wal-Mart was a threat. If the data is held internally, then it's up to the public to trust Wal-Mart's data. This is more a comment about a blockchain being moot than calling Wal-Mart a bad actor, but I can see how it goes the other way as well.
There are other possible solutions to auditing a database.
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.
> Not all blockchains need to be decentralized, and not all blockchains are cryptocurrencies.
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.
Since so many comments on this thread are so absolutely negative, I will try to play devil's advocate here.
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.
I really wish I could remember where I read this so I could give proper credit --
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.)
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.
Supply chains aren't really owned by a single entity, right? Walmart may be the biggest actor and driver of requirements but they don't own anything beyond the specific services they are paying for. Its a complicated system of actors - which is where something like a DLT or blockchain can help bring together in a more cohesive way.
The problem is that we've mostly exhausted technical discussions surrounding the blockchain. Everybody who cares about them (on either side of the fence) know how they work and what they do and don't do. But that's not even the point anymore.
>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.
> Is a given blockchain a more efficient database?
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.
Though, for the sake of argument, even in SQL databases people are increasingly moving toward append-only tables where you never physically update or delete existing records, you just insert a new one that supersedes the old one. The same approach would work for a blockchain.
Decentralized? No, it's "IBM Food Trust". So how is this any better or different from hosting a database on IBM's server? Secured by a PoW? Doubt it.
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.
If it's not intended to be a decentralized system in the first place, the "blockchain" aspect is useless and turns from being a clever hack that allows to generate a certain level of trust from distributed participants, thus enabling the decentralization in the first place, to a marketing ploy that, if not just being lip-service but actually implemented, is a huge resource hog and severely reduces scalability and maintainability of the system without offering any benefits whatsoever.
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? ;-)
What if the biggest feature about using the blockchain isn't that it's an open ledger that resists tampering from untrustworthy agents but that it has lots of hype?
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"
Make no mistake -- this is nothing but a minimally-cloaked attack on federal food safety regulations. The word "blockchain" is only a distraction / misdirection.
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.
Unnecessary rubbish. The article even mentions that larger growers already have a similar(one can assume non-blockchain) system in place. This is the product of excited executives listening to buzzwords and the always shameless IBM ready to play along.
Alternate solution: do not announce small foodbourne illness outbreaks.
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
The reason only 250 get sick is because of the notification. Traffic accidents aren’t contagious. Comparing a static risk and a dynamic risk is inappropriate.
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.
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?
Sorry, I misquoted: it's 75 million cases of food borne illness in general, and 5,000 deaths, using older statistics from smaller population sizes.
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.
It’s pretty hard to compare the value lost to the lettuce industry vs the illnesses and deaths.
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.
What does a blockchain offer in this case that submitting a line to some sort of B2B logging API where the logs are made public (like certificate transparency) doesn't?
I don't get that either. Absent proof-of-work (which is however terribly energetically wasteful), blockchain is just a public GIT repository where every commit is signed, no?
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?
Most of the security bonuses feel anemic when it's still humans entering data into a system to track food vs. how cryptocurrencies use blockchains to track transactions.
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.
I think there are two key points to making such a system work:
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]
Basically yeah. You probably aren't gonna be adding rebasing functionality to your supply chain git repo.
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.
Maybe I'm overly pessimistic, but isn't it quite likely that it will primarily be used as leverage against suppliers?
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.
> 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.
"As a tech person, the word 'blockchaing' is triggering, but the real story here is IBM and WalMart moving more surveillance and monitoring further down the food supply chain, to squeeze more out of farmers at the expense of everyone but them"
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.
Can't one solve the problem of tracking food contamination with a simple key value store that tracks supplier id and the food batch information? Whats the advantage of using blockchain here?
It's about tracking all steps, all parts that were used, whether all companies involved in the processing chain had appropriate ISO certificates, if sourcing didn't originate from sanctioned countries or countries with bad working practices etc. in order to "select" ones that fulfill given criteria, possibly marketing them in multiple layers with certificates (this one is pure Swiss, cows were fed grass 100% from Glarus canton, operated 100% German machinery, food assembled by a Dutch factory implementing ISO blahblah, so here you pay 175% price; or you can get a budget version containing traces of ground fingers of children from Uganda forced to work in a processing factory with high contamination of environment etc.)
Notice how this article never clearly states specifically how a block chain solves the supply chain problem, nor does it even clearly state the problem in the first place.
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.
> Notice how this article never clearly states specifically how a block chain solves the supply chain problem
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.
I'm aware of the latter justification, but can you elaborate further how a blockchain is more effective at preventing double spending than a centralized system?
Without focusing on the relevance of whether Blockchain is required in this situation, the thing that I find interesting is that this is Walmart and this news source is the WSJ.
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 ...
I feel like I’m yelling into the wind, the only time a blockchain is it all relevant is if you cannot trust a single party. You can trust IBM in this case, and are, which makes this just a database but harder.
To me great business innovations needs 2 equal forces: 1) The marketing and customer oriented drive 2) The scientific, technological and engineering side.
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' ....
I can only imagine how terrible it must have felt to work on this project as an engineer. So your manager tells you 'ok, we are gonna make distributed, blockchain enabled, smart contracts based system" and then you end up building your run-of-the-mill centralized database app. It really saddens me that we have to put up with this kind of BS to just make a living.
This essentially just feels like a PR push so that Walmart can claim 'better than the competition' food regulation, without actually opening up the system to be....regulated.
There's no wider benefit to the public from this unless the chain is publicly verifiable, imo.
We lack a good hash function for lettuce that allows one to eat it afterwards. This will limit the efficacy of blockchains in the supply chain space, but perhaps not their adoption...
Of course this was bound to happen, the entire point of a blockchain is supposed to be that joining it is voluntary based on a set of shared values that you wish to support by contributing resources to sustain the blockchain. Forcing someone to join the blockchain is nothing less than forcing them into a commercial racket, and completely renders irrelevant the fundamental value proposition of decentralization.
Many comments are saying here "it's just a database, you don't need blockchain for the public events log".
Private blockchain become more understandable when you dive into the level of corruption and data manipulation happening within big corporations.
It's just much more complex to change a row in blockchain than in good old SQL database, that's it.
Of course it will. Fads come and go. Remember when everything was going to be CORBA? Or when all user interfaces were done in Flash?
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.
The problem is that people don’t see a problem and go looking for solutions.
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.
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.