When I see something like this:
https://techcrunch.com/2018/09/24/walmart-is-betting-on-the-...
I just don't get it.
I understand the motivation behind them wanting this sort of broad supply-chain tracking, but I don't see what "blockchain" actually solves for them that can't be more readily/efficiently solved in other ways.
A trusted third party, with an immutable transaction ledger, and a simple to develop to set of APIs seems far superior from a product perspective in a case like this rather than those solutions that will simply build this same thing on "blockchain" software. The only gap is an API which is domain specific (like for food supply chain).
(And even this won't solve many of the trust issues in food supply chain, but it looks like it will offer the same useful traits of a blockchain only more simply).
[edit for clarity]
What does an industry with thousands of different major players have to gain by coming together to give a single company a monopoly over their entire industry? And in fact, one of the biggest strengths of blockchain is that it provides a viable alternative to monopolies for various industries.
It can be an interesting solution or vaporware depending on your level of interest. I personally think micro-transactions and blockchain do not go well together but reading debates about the tech is still interesting.
In your case, you're talking about no trusted actors in a very decentralized system. We're talking about walmart tracking supply chain and whatnot.
For a centralized ledger where you do have trusted actors, blockchain is a hilariously shitty solution.
That problem could potentially be mitigated by doing best-of-three or best-of-five with multiple trusted parties.
Amazon can claim it is both centralized and immutable, provided you trust Amazon.
> Also WTF is the point of a blockchain if you need to entrust your ledger data to a third party?
Maybe none? I might be willing to bet that 99% of blockchains in use today could in fact just use AQLD or similar.
And this is what it comes down to: most of us live in a world where trust can, and does, have to root out somewhere. So much of our society is built around this. Blockchains feel sort of alien in this world.
See RFC6962 Certificate Transparency logs and their consistency proofs for a widely used example.
The more I think about these things, the more I distrust cloud providers, and want my own hardware.
Do you really trust these companies enough to hand them the keys to all your data? Is there really any way to provide secrets to your app without trusting the hosting provider?
Also, for some purposes (legal) you are allowed to store the data regardless because you have to for other reasons.
Which is why you use it for specialised use cases and keep any PII out of there.
It would be possible to replay into a new ledger, filtering out the pieces of data to be deleted, but that goes against having an immutable log in the first place.
But you probably wouldn't store sensitive user data in this kind of database anyway. Not ever use case is well-suited for a ledger like this. In most applications, this would be pointless overhead.
> have an inventory list and supply chain
> want good audits of what happened when built into your database
I do like that they referred to it as a database rather than blockchain, as it more accurately captures the fact that it is a data store and I always felt like blockchain was more a reference to the way that the data is cryptographically linked together in the data store.
There's probably also an option for not keeping history for data that it doesn't make sense to have history for.
Having our own ledger means we can cheaply do internal transfers, micro rewards, and other incentives. Doing the bookkeeping correctly and in a tamper proof way is of course important for us, which is why we built our own ledger database to ensure we don't end up with corrupted data (either through bugs or malicious activity).
I use content hashes as the id that include the id of the previous ledger entry and the key data stored in each row. The core design is pretty easy (it's basically a linked list) but the devil is in the details with this stuff since you indeed need to worry about auditing and making sure you don't end up losing transactions.
Additional headaches include dealing with concurrent transactions and the fact that mysql does not do serializable transactions (at least not in sane way). Each row should only have 1 successor meaning that every new row involves looking up the previous row, and using it's id as a parent id. So we have a select and an insert happening in a transaction. We have a simple db constraint enforcing the parent is referred only once. We retry transactions when this constraint gets violated. This does actually happen when two concurrent transactions decide to use the same parent id. If transactions were serializable, this would not happen and the second transaction would end up using the id of the first.
Another of the gotchas is that data migrations are kind of hard/impossible in an immutable data store. The only way to do it would be to effectively recreate a new database with new content hashes. So there are some things that I'd like to change that I can't actually change because it would break the content hashes. But by and large, this design is working quite well for us so far.
So, in short, it's not rocket science but hard enough that having a well supported product that does this is worth having. We're actually considering open sourcing it at some point since it seems there are quite many projects out there that use a ledger primarily to have some tamper resistant immutable and auditable log of transactions.
But you are right, I have considered switching to cockroachdb since they advertise their support for serializable transactions.
The webpage says they use SHA256, but it doesn't go much more into detail than that.
Seeing 'quantum' in that acronym is so cringeworthy. I'd prefer Immutable Ledger Database, or a word that shares more with the technology than media hyperbole.
> Of a change, sudden or discrete, without intermediate stages.
- https://en.wiktionary.org/wiki/quantum#Adjective
It makes perfect sense if you know what the word means.
Like it or not, "quantum" has accumulated a) more connotations that make it less likely to be interpreted as "sudden or discrete" by most people, and b) an association with other pseudosciency buzzwords that don't have a very good reputation in product names.
Case in point, the whole reason I clicked through on this was becausei thought it might be some earlier quantum database.
If Quantum computers become a thing, then coining a new database 'QLDB', is a bad idea, despite what 'quantum' may mean in the dictionary.
IBM has spent a bit of money drumming up all things Quantum (while being at most moderately more successful at actual useful QC implementation), it would be ironic if some of the buzz (in people who think Quantum is the "next big thing" without knowing how actual current QC would benefit them) now transfers to something useful and real but not-QC
I accept that it may just a terrible choice of name that is not deliberately intended to confuse though.
ACM could leak your private keys.
EC2 hypervisor could have a 0day that allows China to steal all your data.
CloudTrail could drop audit logs.
At some point, you have to trust the company who's software you're using. Sure Amazon could easily drop the last N transactions, but what motivation do they have to do so? What behavior in the past makes you think this wuold happen?
