Amazon Quantum Ledger Database
aws.amazon.com
aws.amazon.com
You need to at least have a collateralization of 150 %. If you fall below that, your collateral will be seized, the same amount of DAI that you own will be bought from the market and burned. The rest of your collateral minus 13 % liquidation fee will be send back to you.
At any time you can pay back your loan in DAI or add more collateral.
This mechanism keeps DAI stable at 1 USD.
The entire mechanism runs entirely on the Ethereum blockchain.
Know why is that cool?
1. You have a 100 % decentralized token that you can keep in any crypto wallet that supports ERC-20 token (Be your own bank)
2. You have a token that isn't volatile so it is safe to pay out salaries or buy groceries with it.
Stablecoins that are pegged to Fiat money like the USD still have one centralized aspect though. The currency that they are pegged to is still controlled by centralized organs (e.g FED, European Central Bank etc).
The cool thing is, this stuff is just getting started. MakerDAO is just a few month old and pegging to the USD is really just the beginning of a new era.
In the long term, imagine you have a stablecoin that is pegged to the purchasing power of North America or Europe or any other region of the world.
It's totally possible. The data feeds are the hardest part but there are solutions for that.
Imagine having a currency that is pegged to the purchasing power of your region without any governmental control. This is where we are heading.
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.
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.
This is overall great. QLDB is necessary for a lot of things, and it will be useful for a lot of the stupid 'blockchain' projects to be displaced by a better technical solution.
Now cryptocurrencies and blockchains are exactly what they are: a decentralized version of this. I believe that decentralization has some use cases that are extremely important. Now it can stand on its own, without being conflated with verifiable ledgers.
I expect that they will resolve to exclude such things.
The specific technology the Walmart group is working with is IBM's implementation of: https://www.hyperledger.org/about
There is a concerted effort from what we can see, and are getting some subtle hints that we need to be going down this path from some shared government customers. That is far from saying that this will be successful or that it will get past early stages, but they're definitely trying.
Having said all that, my understanding is this is more in line with a true blockchain effort rather than something like QLDB (though I hope I've misread on that count in case I do get stuck on dealing with this).
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 a number of your comments you talk about errors: the transaction processing technology being discussed will not address those issues be they mistakes, non-compliance, or anything other that rather naive cheating.
I think people hear about some of the attributes of blockchain, such as being distributed, and say, "hey, that solves some of the problem of getting disparate, unrelated parties transacting in a common data set."... along with a misunderstanding of trust model and its relationship to data integrity across that shared ledger... and they get all excited about blockchain.
You're right you don't need blockchain and a central database could do it. The harder parts are administrative around the many parties and then getting the parties to participate at all. I think the transnational immutability aspects are beneficial for food safety, I don't think the raw complexity of implementing a new blockchain to do it makes sense.
I do think with the right kind of industry focused solution on top of something like this Amazon product, can be that sort of single database, with some of the helpful parts that have appeal in regards to blockchain and without the complexity. There are still issues which I don't believe something like this Amazon product solves, but I do think it moves the needle.
Having a consolidated/consistent view of transactions from the full supply chain relative to tangible product could be genuinely helpful for reducing errors that could be consequential from a food safety perspective. It's unlikely to stop cheating since many of these food vendors will almost certain being humans entering transactions at keyboards (and then when you can get compliance with that transaction entry) and at those points all you can do is make cheating harder.
The challenge is how to get that consolidated/consistent view of the world across disparate parties, some of which don't know all of the other parties involved, in a secure enough manner, and in a way that the supply chain participants will be willing to take part in.
Larger players, like Walmart, can set the stage for some of that cooperation to happen just because of their relevance to the market. The government agencies that buy food also want that and also are pushing for it (that's where my clients are getting some pushes in that direction). None of that means the end goal will be achieved for any number of reasons, including many that are not technical in nature... "blockchain" just complicates those odds.
There are attributes of blockchain implementations which are desirable attributes to solve this problem, but they can exist outside of block chains.
In fact, it's part of why I find this Quantum product interesting for this... they seem to have those qualities that would be helpful without bring much of the other baggage.
The only thing that's not clear is how you handle authority (who says who can participate, for example). So I don't think this Amazon approach is the complete answer, but this sort of approach seems like a path which might bear more fruit than trying to implement blockchains for the problem.
A blockchain won’t solve the problem of creating a unique identifier for each banana and ensuring it was correctly scanned.
Also this isn’t a good example fundamentally because the banana is not immutable as in anyone can swap the barcode from one banana with another or it can fall off.
Blockchains really only work when everything is immutable.
Blockchain gives you security against bad actors. Here's a similar use case for a marijuana supply chain: https://www.nasdaq.com/article/leveraging-blockchains-to-tra...
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...
This is an incredibly strong assertion and not one that you have proven. Nor do I believe it is something that you, or anyone, could prove.
See RFC6962 Certificate Transparency logs and their consistency proofs for a widely used example.
That problem could potentially be mitigated by doing best-of-three or best-of-five with multiple trusted parties.
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.
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.
I'm currently working on this problem in application to blockchains. The plan ATM is to implement cryptographic snapshots of the data, where the old transactions are erased but their proof is available.
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.
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.
So sure. Voting. Wouldn't it be great to have an auditable trail?
But why would you then go and put all of that in one spot?
Wouldn't a better approach be reconfiguring the tech to work in a faster fashion?
I mean how hard is it? What are the real challenges?
Elsewhere they say something like "But it works like a database! You do queries and everything!"
Ok. So sign a database.
It's like they're expecting developers to not know a damned thing about blockchain, but know they want a secure database and something with cool buzzwords in the name and AWS has one for them as long as they have a credit card.
AWS needs to provide clear and compelling places where AWS is not the answer to everything. I am not hearing that, and it indicates to me a lack of appropriate executive direction. Yeah, sure, build a cult. But build a cult with guardrails.
I'm not sure that this is the "Make stuff people want" that I would be comfortable pumping to others. I don't know. I must be missing it.
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.
So it's an event store in that each write transaction is an event. But it's a relational DB in that it (at least the internal version did) schemas, multi-record updates, and transactions.
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.
Case in point, the whole reason I clicked through on this was becausei thought it might be some earlier quantum database.
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.
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.
If Quantum computers become a thing, then coining a new database 'QLDB', is a bad idea, despite what 'quantum' may mean in the dictionary.
Especially when it's the biggest cloud provider that many of us depend on.
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.