Blockchain: A Better Way to Track Pork Chops, Bonds, Bad Peanut Butter?
mobile.nytimes.com
mobile.nytimes.com
What is blockchain? It's a way to create a global ledger without trust.
What do you need to track your pork chops? A ledger.
What is IBM? A huge, trusted, corporation.
Does anyone think if IBM operated a bog standard database of pork chops that the users would not trust it?
Every few months I'm reading these articles about using blockchain, which is pretty clever, for something that doesn't require it.
Interesting. Do you have some pointers for more information on these efforts?
Take for instance the options contract market. Let's say you have a pool of 50 trusted brokerages and financial institutions that rapidly trade these contracts. The current solution is each entity has their own custom, internal tracking system along with either a centralized service that they all communicate with, or inter-party connections. In either case, this is fragile, highly expensive to build and maintain and is often slow.
The blockchain isn't a miracle technology like these articles portray it as, and IBM, JP Morgan, et al don't see it that way anyway. It is a convenience tool for a more robust ledger that will lower costs for trusted inter-party transactions.
If there is a benefit in using blockchain to track pork chops, and if all the pork chop companies know and kinda-trust each other already, a private blockchain could keep the hackers out and implement various security schemes, and maybe even have a board that could publicly organize a rollback to undo a "DAO-hack". (As seen with Ethereum, such a "board" exists implicitly anyway even in a public blockchain system).
But do you enjoy reading something like this [1]? Can you analyze blockchain code like that? Ideally before you know that there's a bug?
It's on Ethereum to show how to make things secure. The general level of software buggyness is inacceptable if you say "code is law".
[1] http://hackingdistributed.com/2016/06/18/analysis-of-the-dao...
1- The main advantage over something like Paxos or Raft is simplicity. There are also serious disadvantages, and normally I would still suggest grabbing a library that does Paxos or Raft instead of something blockchain-based. Still, it's not "no advantage".
You're right, from a technology point of view. But for this system to run, you need to convince a lot of people, from different cultures/backgrounds, to use it.
Maybe talking about the safety of the bitcoin network instead of a mathematical proof makes that marketing challenge easier ?
It's still a problem in the largest deployment. Does anyone have a "solution" to this?
In this specific case, it seems like what they really should do is have a set of trusted nodes for ledger replication.
W.r.t. having a set of trusted nodes, that's fine, however does the blockchain add anything in this situation?
Satoshi didn't coin the term blockchain and they existed for a long time before bitcoin so giving him sole claim to it because it paired it with a feature that isn't specifically required to have a blockchain seems silly.
That said I do agree that their are a lot of buzzword vultures using it at the moment for stupid business ideas though I think 99% of the bitcoin business ideas are poorly thought out and poor replacements for existing solutions("but with bitcoin!") so it's no surprise 99% of the blockchain ones are too.
The real reason behind techniques such as PoW instead of just Distributed Byzantine Fault Tolerance algorithms is scaling in terms of number of validators. Most of DBFTs (afaik Algorand is the only exception) don't really scale. Proof of Authority behaves similarly to PoW, since it also does not have that problem.
Go with DBFT unless you want to have huge number of validators.
In the original form though, it makes no sense to fire up your own bitcoin, because when it's small it's vulnerable to the attack you mention.
This creates a vast overhead as you can't secure a billion+ dollar market without massive and continuous investments.
But if you have some trusted party just use a DB.
Blockchain's also provide data redundancy and security between entities. It'd be way more effective way to communicate commodities, medical records, etc as the security, data model, and system API are all integrated into the blockchain model.
Having the "database" be the API would be great for those of us dealing with supply chain. Want information from your supplier in Shenzhen? Good luck with current systems! Paxos/raft do nothing to resolve data access and verification.
If you don't do that it's easy for your idea of what something is to morph into something sexy that's the best thing since sliced bread. Also it's a function of non technical people having a brainstorming session. They pat each other on the back for taking this thing to the next level, which is actually the previous level.
The problem is in the corporate world there is no trust. People seem to get the notion that if you use facts to show them their idea is bad that it is some sort of personal attack. Or worse, there are those in the corporate world that can spot a bad idea and not say anything -- only to watch it fail.
Even without that, its a confounding problem for me. Im always doing those things: asking questions either to genuinely learn or to ferret out possible mistakes, pointing out errors, sharing better methods/techniques, etc. I just cant help it, and while I try hard to word things in a constructive manner, to make sure it IS constructive, more often than not I think it is taken poorly.
I want the same criticism of my own work, but I still often have a difficult time with it myself, though I recognize the signs as the knee-jerk reactions that they usually are, and seem to get better at that every day.
The premise is that if your calculated reputation isn't above a certain score, servers can choose to disregard or throttle your requests. Servers can update your rep on the blockchain via a provided OTP, based on user behavior. The higher your rep, the less likely it is that actions interpreted as malicious will sever or throttle your connection.
The big technical challenges I see would be mitigating abuse from both malicious clients and servers. Visit a malicious server and your rep is harmed. Weighting all past scores could mitigate this issue. Combining a gradient descent algorithm for adjusting reputation with a "time-out" mechanism could possibly mitigate the incentive for botnets to farm good tokens to sell to malicious users. The other big challenge of course would be user adoption.
This could be a robust way of dealing with DDoS attacks and botnets in the increasingly anonymized web. It could create an accountable web of trust for anonymous authentication, as it would take time and effort to create and maintain more than a few trustworthy private tokens. Any blockchain experts care to chime in?
The fact that it's structured as a blockchain makes it worse, as there's no way to age out data.
To limit the granularity of data being stored, it would only be used at authentication endpoints, to create a private session. Once you've identified yourself as reputable with a OTP that doesn't reveal anything about your actual internal ID, you can transfer secrets and further authentication is not necessary.
The system would employ paranoid homomorphic encryption [0] and a fuzzy API. Hardly a worthwhile vector for analysis compared to the standard MitM attacks applied today by state agencies and ISPs.
If your "security models" don't recognize this as an issue, you need to change those models.
I literally put up something about this just this evening: https://davidgerard.co.uk/blockchain/business-bafflegab-but-...
Many blockchain schemes promise the magic of full availability of properly cleaned-up data. The actual problem in every case is cleaning up the data in the first place; the barrier that such efforts founder on, over and over, is that no industry’s players want to create such a new monopoly. The proponents’ business goal is usually to become the organisation effectively controlling the newly cleaned-up data, with a monopoly maintained by network effect.
If your big goal is cleaned-up data across multiple organisations, the approach that will get you there is creating a data schema that is so obviously and elegantly the right thing that everyone just adopts it themselves, and a regulator eventually says “hey, use this schema.” Note lack of blockchains. (This is the usual approach in computing, though even there companies routinely try to set themselves up in the role of central octopus.)
Supply chain provenance is a perennial proposed use case. e.g., Provenance, Inc. is a London startup who offer to put data about tuna catches on the Ethereum blockchain. They claim to offer supply chain transparency to all participants, and this will reveal illegal overfishing or fishing that involves human rights abuses. The actual problem turns out to be no agreement on what data to collect or what to do with it. The data would still be entered by local humans under the auspices of “trusted” local NGOs – who would be paying monthly for the necessary software – on the apparent assumption that commercial operations engaging in illegal overfishing or human rights abuses will certainly carefully document their human rights abuses in the blockchain and not have strong incentives to just lie or something, or bribe the “neutral” adjudicators, as already happens in current supply chain monitoring. The main byproduct of this sort of scheme is a monopoly for the traceability provider, i.e. Provenance.
As IBM found out after starting Hyperledger, all manner of businesses – financial institutions, beef industry, shoe brands, confectioners – don’t want to share data even with all participants in their blockchain, but only with the people the specific deal is actually with. Funnily enough. This was apparently news to them. It turns out that IBM set up an elaborate hammer design consortium without first finding out if there are nails.
The precise same considerations, goals and problems will apply in this case. In all these schemes I've seen to date (and let me assure you I've read horrible PDF whitepapers out to here), the aim of the scheme is to sell someone thousands of contracting hours by convincing them you can help them become the controlling octopus at the centre of their industry.