Could this be addressed with cryptography, digital ids and signatures? Imagine it were possible to add a signature that proves that I own some "human" identity (like a national id), or that I possess some scarce resource (like a github account with some level of activity) and that today I sent no more that 20 emails. If I want to conceal my identity, I can use zero knowledge proofs. If you don't sign this way, or if your daily email counter exceeds 100, your mail ends up as spam.
yeah, hashcash is a very neat idea! but had problems like: how do you determine the threshold for the amount of work to be proven? there are values that makes it too expensive for a well intentioned human, and not enough for a bad intentioned spammer... moreover, it would induce economies of scale like it happens in bitcoin mining (spammers would invest in ASICs etc.) Signatures, on the other hand, allow to cheaply leverage other forms of "capital" (digital identity, github activity)
Farcaster is doing it (allowing posting, upvoting etc) with a pragmatic architecture with different degrees of decentralization (identity onchain, posts on a p2p storage à la bittorrent), and it's going pretty fine... https://warpcast.com/
ether, Ethereum's native token, is required to pay for computation on a computer with peculiar properties (publicly visible, unmodifiable, unstoppable code, uncensorable interaction). If somebody finds that useful, he will need ethers, and you will be able to sell them yours. How would he be a (greater) fool?
Digital scarcity seems like a fundamental concept also in the digital realm. Consider games: if you only have a certain number of weapons, lives, or limited time, isn't that digital scarcity? If you play capture the flag, the fact that there is only one flag, and only one team can "own" it at any one time, isn't that digital scarcity? Aren't the points you get from sweating arbitrarily "scarce"? Or isn't the first position a ranking "scarce"? It seems to me that scarcity is at the heart of many fundamental social mechanics, be they physical or digital.
Couldn't blockchains offer some new tools to tackle the problem? Imagine for instance wanting to create some incentives by distributing the value of correctly tracking an item to the actors of the supply chain, with some rule like "once the item is sold, part of the revenue gets distributed to all the actors that contributed to the tracking". Wouldn't smart contracts render this simpler to implement, since code is visible by all actors and guaranteed to be executed?
I got my start trading for one of the big commodity shops. The problem isn’t incentive. Markets create natural incentives. The problem is authority. Who decides what’s right? Who decides what constitutes “solved”?
Blockchain or smart contracts have no way to solve this without abandoning the decentralized and permissionless aspects, at which point you’re giving up loads of efficiency for none of the benefits.
This is the problem that every large non speculation based blockchain problem has encountered: any system will be reduced to its weakest link. Any problem that requires crossing off chain into the real world will necessarily lose many of any benefits blockchain can provide.
Blockchain really only solves a few specific problems in a few specific domains. There’s a reason that a decade on, all we’ve managed to build are massive casinos that can’t be shut down by authorities
I doubt it. The only place where I see blockchains in significant practical use is in very low-trust cases. But supply-chain relationships already involve a fair bit of trust. Cryptocurrencies are also attempts to solve problems of financial interaction, but these people already have financial relationships.
Moreover, I think one of the big problems with "blockchain [jazz hands]" is what you're doing here: a solution looking for a problem. The right way to build something is to start with actual problems actual people have and then find the most economically efficient technology that best fits the solution. When approached from that perspective, I still haven't heard of a case where a blockchain turned out to be the right answer.
William, while I agree the problem at hand is mainly an organizational one, you ignore that even with a trusted environment you still need safeguards for internal fraud. A distributed ledger can ensure that protection and easily verifiable audits. The distributed ledger solves this real problem, but with the caveat that as you noted that is a fairly small part of the overall picture.
I agree that a distributed ledger could under very specific circumstances protect against some very specific types of internal fraud. But again, that's the wrong way to look at it. The way to do it is to look at actual fraud problems that businesses are actually having and then see what measures, technological and otherwise, best mitigate the problem.
Even if the fraud in question was of the very specific type where somebody fiddles records after the initial write (as opposed to fiddling them before, or on output, or making offsetting transactions, or any of the many other ways to hide internal fraud) I still wouldn't try to set up some sort of multi-organizational distributed blockchain ledger. I'd just write a regular ledger to some immutable medium. E.g., AWS's WORM solution. [1] That would not only be simpler, clearer, cheaper, and more thoroughly vetted, it would also be very easy to prove compliance with the sorts of standards used to prevent fraud.
The issue isn't one of trust in the general sense. Blockchain would "solve" the issue of transparency about when and who signed for what shipment where and when. The problem that can't be solved is that you have to completely trust that the blockchain reflects actually physical reality. A blockchain signature doesn't mean it is actually where it says it is. Even if you have some digital "fob" device, how do you know that it is on the right pallet of good. A digital signature can't prove anything in the real world. Blockchain is only useful in the pyramid scheme world of coins.
Is that a goal that anyone involved actually wants to implement? Does the code being visible really add any value? The problem isn’t in executing the contract among people who agreed to it.
I think the smart contract part of blockchain doesn't offer much value.
But I think the core value proposition of blockchain to supply-chain like situations is to solve the problem of "who's version of the database do we trust", without needing to resort to escrow or other 3rd parties. It won't completely solve the problems of parties being in disagreement - lawyers will still be needed, but it might address a subset of problems.
"Whose records do we trust" is a problem that's thousands of years old. [1] In practice, the answer is "we both keep records and compare when there's a problem". It's not clear to me that having a single shared database solves more problems than it creates.
Not at all. A blockchain requires a shared model. Everybody has to agree on what's stored. But the way it normally works is that each entity gets to do its own thing. E.g., if company A sends a package received by company B via shipper C, each one is going to keep their own records of what's going on. They don't have to agree at all on what gets kept when. There are specific, limited points of interaction. It's only if some problem occurs that everybody compares their individual records and reconciles them.
That looks like waste to the "blockchain [jazz hands]" crowd. But it prevents other wastes. Like trying to get a whole industry to come to consensus on ontology and process. Or trying to comply with systems build around that fantasy process when local needs differ from the standards.
Any single centralised database performs that function though, since supply chains are emphatically not trustless and there's no more guarantee updates to a blockchain corresponds to actual changes to the physical goods. "What if the party that manages the database reverts data entered?" is really quite low on the list of risks involved in transferring goods of value between multiple independent parties, ensuring all contractual and legal requirements have been met and paying separately, and anyone given read access to a centralised database can identify edits anyway.
While it is true that blockchains themselves cannot guarantee that they're synchronized with the physical world, they provide an irrevocable digital trail that can be used to punish bad actors, one that is relatively immune to tampering. A lot of the world operates this way—simply signing something under penalty of perjury does not guarantee that it is true, but it can be taken to court if it is later found that you're lying.
A blockchain (not proof-of-work, but permissioned/BFT-based) is pretty clearly the optimal way to have an irrevocable digital trail.
Sure, I'm not disputing that they can fulfil a role, I'm noting that [i] they're not remotely close to being a solution to the sort of problems parties use escrow for (except where the goods are digital to the extent fulfilment can be encoded into some sort of smart contract) and [ii] a distributed ledger only has value over and above a non-distributed one if other parties worry about the centralised database manager tampering with records [without leaving obvious evidence behind], which has got to be so far down the list of potential issues with most supply chains (even with respect to record keeping) it's barely a consideration. Another vendor's good old fashioned cloud datastore might be equally suitable as far as parties not being able to update records without leaving an audit trail goes, and quite possibly with a shinier front end and easier to use API.
> they're not remotely close to being a solution to the sort of problems parties use escrow for
But you can encode fulfilment into a smart contract for physical goods, assuming that those physical goods have some digital representation on-chain. Discrepancies between the chain and the real world continue to be resolved through the court systems in various jurisdictions, but on-chain activity is just strong evidence that any court can rely on.
> a distributed ledger only has value over and above a non-distributed one if other parties worry about the centralised database manager tampering with records
An alternative viewpoint is that a centralized database manager can be seen as a potential risk. One of the general ways we progress in society is when we reduce sources of risk, and a permissioned blockchain where you need 2/3rds of a cabal to collude is a pretty clear reduction of risk compared to a centralized DB. (I mean, how would you keep track of whether a central DB has been tampered with? You'd probably maintain your own copy, reconcile the two periodically, and flag discrepancies if and when they happen. That's exactly what a blockchain is.)
To be clear, I'm pretty skeptical about blockchains in general, but this seems like a very compelling use case.
> But you can encode fulfilment into a smart contract for physical goods, assuming that those physical goods have some digital representation on-chain.
But why would I want to? Unlike a smart contract for some verifiable code-based outcome it doesn't offer any guarantees I get paid, which I still rely on the courts for, it just adds complexity and unfamiliar risk.
> An alternative viewpoint is that a centralized database manager can be seen as a potential risk
Sure, in theory it can be. But relative to all the other potential supply chain risks, the ERP cloud vendor colluding with a part of the supply chain to remove records from or silently update a datastore is pretty near the bottom of the list in terms of likelihood, expected cost and chances of it not being glaringly obvious to other parties and used as evidence of bad faith on their part in court.
To be clear, I'm not saying blockchain can't be used as a datastore, I'm saying that overall its about as useful for mitigating supply chain risk as insurance against your spouse committing identity fraud is for mitigating potential problems with marriage.
Well, the assumption is that unfamiliarity risk goes down as people get more familiar with the technology. There's certainly some added complexity but a blockchain is not that complex, it's just a git repo with some added functionality to repel hostile actors.
Doesn't a permissioned blockchain require a trusted central authority to manage the permissions? How is it better than having that central authority manage the database?
You have, say, 50 entities that are part of the cabal, not all of whose interests are aligned (this is the important bit, you want a diversity of interests), and you need a 2/3 vote to add a new one.
Could you give some examples of current commercial relationships that let, say, 50 entities have a binding majority vote? I agree it's in theory possible, but I've never heard of such a thing.
Sidechains have different security properties. You probably know xdai (https://www.xdaichain.com/), where you can transact tokens that "wrap" dais from Ethereum mainnet. The sidechain is secured by a proof of authority consensus, where you require a fraction of validators to behave honestly. If a certain number of validators collude, they can do nasty things, such as censoring transactions from a certain address, or keeping the chain from making progress. This is not possible in a rollup, either optimistic or zk, because any single user can always commit a batch or report fraud on L1, so you just need a single honest actor for things to work.
