Amazon Quantum Ledger Database

I'm pretty sure this is what most people actually want when they say they want a blockchain, they just don't know it yet. It's got all the useful database features with none of the "well uh let's distribute it over people's computers and let people mine coins to support it" complexity, which adds nothing to 99% of usecases besides silly ICO potential.

AWS is spot on here. Stop using blockchain as a database if you just want the cryptographic verification and immutability of assets et al. That’s lieterally all 95% of corporate use cases for blockchain wanted all along. Stop the hype and insanity and focus on a tool that actually does what you need.

Huge props to AWS for being honest and not blockchain-washing.

Is it possible to comply with GDPR while using this to store data? Given that it operates like an append-only log, is it possible to actually remove data to comply with a GDPR request?

So is “Quantum“ pure buzzword hype? Or is there a reasonable connection to the product?

<a href="https:&#x2F;&#x2F;dilbert.com&#x2F;strip&#x2F;2018-11-26" rel="nofollow">https:&#x2F;&#x2F;dilbert.com&#x2F;strip&#x2F;2018-11-26</a>

Why are they using the word &quot;quantum&quot; here? With the advent of actual quantum computing this will just become increasingly confusing.

Under the guise of &quot;immutable ledger&quot; (basically just a honest scout promise by Amazon) Amazon gets into industrial provenance business. Genius. No sarcasm. Like that satellite ground station business yesterday. Basically &quot;own the platform of the future&quot; strategy the same way like spinning up the AWS 10 years ago. While companies like Google struggle to find any new business, Bezos just &quot;printing&quot; it non-stop (does he have a separate area in his brain labeled &quot;Bezos X&quot; ?).

Newbie here. Questions: 1) Can somebody go over use cases and target customers, where one would prefer this over more traditional DBs. 2) Since this is centralized, it is in theory possible to go back to a previous state of the ledger. Is that blocked simply because the product doesn&#x27;t support rolling back to a previous state?

Am I right in believing this looks like a competitor to Datomic?

This reminds me of temporal database [1] concepts. I&#x27;ve been thinking that besides the hashing aspect of it, otherwise, it&#x27;s actually basically the same as a temporal database, isn&#x27;t it?<p>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.<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Temporal_database" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Temporal_database</a>

Uhm... If some of my data is stored in one instance of that database and I then ask the owning company to delete such data in accordance to , say, GDPR... What happens ?

Amazon QLDB does solves some of the QDPR compliance shortfalls of blockchain, for example the physical location of the data could be guaranteed. But it doesn&#x27;t solve the big one: the right to full erasure, also known as the right to be forgotten. The tactics suggested by other users here, such as &#x27;losing&#x27; the key, do not fully qualify as full erasure, just pseudo-erasure. So far, to the best of my knowledge, nobody has as yet developed a GDPR-complaint, public-facing DAO application. It&#x27;s a grey area. I am working on a blockchain wallet that allows contractors and gig economy workers to request, own and administer their own employment references. The main problem we&#x27;re facing is to guarantee full erasure, and to guarantee the physical domicility of data (for example,in the EU region). I was excited about QLDB but I see many problems in its current state.

This is what I use protected git repo with a pgp signature for.

Interesting, I actually implemented a simple immutable ledger on top of mysql this year to track balance mutations of our InToken coin. The coin exists on Stellar as well but we track federated stellar accounts in our database for most of our users. This means that we represent them with a single stellar account. We allow users that clear our aml procedure to send&#x2F;receive tokens to stellar.<p>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&#x27;t end up with corrupted data (either through bugs or malicious activity).<p>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&#x27;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&#x27;t end up losing transactions.<p>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&#x27;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.<p>Another of the gotchas is that data migrations are kind of hard&#x2F;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&#x27;d like to change that I can&#x27;t actually change because it would break the content hashes. But by and large, this design is working quite well for us so far.<p>So, in short, it&#x27;s not rocket science but hard enough that having a well supported product that does this is worth having. We&#x27;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.

I wonder if this is just based on Kafka with some native tamper-proof functionality added to it?

Not sure why there&#x27;s so much hate on here. The article explicitly mentions that the database is <i>Owned by a central trusted authority</i>. This is distributed ledger technology within the AWS ecosystem, not decentralized blockchain technology

The promise and all the overhead of real distributed blockchains is that you should avoid any need to trust anyone, and if you&#x27;re really paranoid then you should not trust even your own database copy. All this could be hacked just as Amazon can. Power of real distributed ledger is that as long as less than 50% of the data copies (consensus) are not hacked, then database as whole can be trusted. Now if you can hack also consensus, then even blockchain is hackable. With the &quot;centralized ledger&quot; you don&#x27;t have the consensus protection level, therefore I see only marginal (if any) security improvement on top of just plain database with properly applied access control and auditing. You still have way more parties you need to blindly trust.

One thing I havent seen mentioned in the comments is talk about auditing challenges, how would journal auditing go? are there already tools for this? is it just another &quot;table&quot;?

This doesn’t explain how amazon has removed capability for themselves to mitm the whole process. Or perhaps I missed that part somewhere?

Did they just ship Trillian, or is this an AWS-exclusive design?<p>The webpage says they use SHA256, but it doesn&#x27;t go much more into detail than that.

Wow, this is exactly the sort of database I was dreaming about for a logging solution. I need to deep dive into pricing though.

QLDB = Quantum Ledger Database<p>Seeing &#x27;quantum&#x27; in that acronym is so cringeworthy. I&#x27;d prefer Immutable Ledger Database, or a word that shares more with the technology than media hyperbole.

Does the name suggest it has Quantum Computing + Distributed Ledger?

Looks like these guys were on a very similar path. <a href="https:&#x2F;&#x2F;m.youtube.com&#x2F;watch?feature=youtu.be&amp;v=3T2H4qO9_b0" rel="nofollow">https:&#x2F;&#x2F;m.youtube.com&#x2F;watch?feature=youtu.be&amp;v=3T2H4qO9_b0</a>

Do any immutable open source databases exist?

Why all of the Amazon spam? Three advertisements in 6 hours.

If centralized, why not just restrict the API to make history immutable? Lol

Does quantum mean its thread safe?

As they pointed out, this requires me to trust Amazon. But since that&#x27;s the case, what&#x27;s the point of it being auditable? Amazon can easily drop the last N transactions on your ledger and tell you the digest you provided was &quot;not found&quot;.

It seems to me the main reason people don&#x27;t go for such a Blockchain is because they don&#x27;t &#x27;trust&#x27; Amazon. Fair enough - why not then have a blockchain owned by several different competing companies with huge data centers: Google, Amazon, IBM etc. This solves the computation and scalability issue with blockchain while also making it less likely one company gets too powerful (any new transaction will need to be confirmed by all the parties (Amazon, Google) providing a self regulating mechanism).