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.
No it can't. The second it is hacked and somebody alters the ledger, it is no longer immutable. Centralized security models eventually all get hacked. What you could however say is that the application you need to have immutable isn't super mission critical, and thus you can afford a very low probability - but not 0% of getting hacked.
>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.
And this is where you might be a bit out of touch. From China hacking US IP, from Banks world wide manipulating markets, gold, Libor, frequent global election fraud, government mis-spending of funds, corporate & government accounting fraud, Fukushima lies, Fakenews etc. The trust people have in institutions and governments world wide is in an accelerated decline. We are constantly asked to trust, and we are constantly let down. Properly decentralized blockchains are 'Trust machines'. They aren't alone going to solve all the issues I mentioned, but they do have the potential to increase trust in many processes related to these various issues. The key requirement is decentralization though. A blockchain managed by a single entity is nothing more than a dumbed down over-marketed database with limited use cases.
Google: Decline in trust: https://www.google.com/search?ei=WEv_W6DfIe2x0PEPxe6AmA4&q=D...
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?
If your keys leaked, you'd probably have to assume you lost all of the data up to that point. To secure the data going forward, you'd need to generate a second key per user for all of the future data. Well, and hopefully shore up the security problems!
I agree, though, that an immutable ledger like this complicates things in a way that you-shouldn't-mutate-but-can datastores do not.
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.
1. Quantum computing, as in quantum physics.
2. Time quantum, as in the time slices a multitasking scheduler gives to threads.
3. Quantum Corporation, the disk/tape storage company.
Seems like there is room for one more meaning. They probably mean "quantum" as in "quantum leap" since this is a different paradigm for ledgers. It makes sense to me.
> 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.
My main interested was in use cases and the details of the integration with git.
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?
If the digest you provide is found, then you know the data hasn't been changed. Sure, that's the only bit of information you get, but in a lot of cases that's the only one you need.
It doesn't guarantee your data can't be changed, no. What guarantees that is your contact with Amazon.
