Amazon Quantum Ledger Database (QLDB) as a blockchain database as a service

Nowadays, everybody talks about blockchain technologies but not many understand all the concepts behind it. Even less have any practical experience with these issues. Therefore here, we will try to put some light on it.

When in June our request for preview access to the QLDB service was approved, we all rubbed our hands together to test it ASAP.

But before we start with some practice, first let’s talk a bit about theory. Blockchain is a concept of implementation of nonrepudiation by means of chaining blocks of transactions. Each block contains data describing issued transactions and some additional data derived from the previous block (most often being the product of hash function). When the current block is completed, its stamp (hash value) is put to the next one. This way blocks form the consistent chain (being distributed transactions ledger) and this consistency could be easily verified by everyone using the previously mentioned function.

All the above is of course only the generic concept. As they say – the devil is in the details. And the details here are among others issues on:

• who calculates stamp of blocks,
• who confirms the correctness of the above calculations (how the consensus is achieved),
• how the stamps are calculated,
• how the whole ledger is distributed so everyone might check its consistency,
• who may join the ledger,
• how he is authenticated or authorized,
• is he authorized to see all transactions or only ones that concern him?

Start digging on the above topics leads us to the concepts of proof-of-work, proof-of-state, Byzantine Generals Problem, etc. It will turn out that the way of implementing all these concepts causes a number of problems on various levels:

• efficiency,
• scalability,
• security,
• privacy,
• legal regulations (e.g. GDPR).

All this means that the practical application of these technologies is often disputable and except for the cryptocurrency area, these technologies have not yet found a widespread and obvious application. But it is worth noting that separation of the concepts of block chaining (BC) and distributing ledger (DLT) is very much possible. Leaving the last one, things become simpler, but at the expense of the need to trust the central / trusted entity again.

This observation has led to the creation of such platforms as Corda, BigchainDB, and eventually Amazon Quantum Ledger Database from the AWS, which was first announced at AWS re:Invent 2018 and today available in production form in five AWS regions.

The concept of QLDB is based on chaining database log. QLDB maintains the so-called “current state” of data but also provides access to all the “historical states”, so it is possible to track all past data changes. It is not a typical SQL database but rather a document-oriented one (ION format), however, thanks to implementing PartiQL query language (since 10 September 2019), data can be queried, managed, and updated with SQL operators. It also provides an API that allows you to cryptographically verify that the history is accurate and legitimate. The QLDB is serverless what means it offered as a service and one needs not to worry about provisioning capacity or configuring read and write limits.

So, let’s start with a simple interactive example. First, we create a ledger.

The system is preparing the environment and in a few minutes (which turn out to be seconds) the ledger gets created.

Next, using the query editor we can create and populate simple database schema.

CREATE TABLE Book

CREATE INDEX ON Book (ISBN)

INSERT INTO Book
<< {
    'ISBN' : '978-0547928227',
    'Title' : 'The Hobbit',
    'Year' : '2012'
},
{
    'ISBN' : '978-0395489321',
    'Title' : 'The Lord of the Rings',
    'Year' : '1988'
},
{
    'ISBN' : '978-1328613042',
    'Title' : 'The Fall of Gondolin',
    'Year' : '2019'
} >>

Now, we can query our database.

We can also update some data.

update Book as b
set b.Title = 'The Fall of Gondolin!'
where b.ISBN = '978-1328613042'

And now we can query the modification history of a table or a specific document in a table, with the possibility to find modifications within a certain range and on a particular document. In our example, we ask for all records from the beginning of 2019 to now (as we don’t specify the second datetime).

select * from history(Book, `2019T`)

And we see that each transaction is tagged with a hash value that is a crucial part of the chainblock, and we can see all versions of a given document.

We can also verify the integrity of documents that are stored within out ledger’s journal, what has described in Verify a Document in a Ledger, and is a great example of the power (and value) of cryptographic verification. At any time we can get the digest of the transaction.

And at any time we can verify the ledger against the formerly downloaded digest.

Worth mentions that all the above-described operations can be performed using not only AWS Management Console but also AWS Command Line Interface (CLI), a CloudFormation template, or by making calls to the QLDB API.

As we see, the threshold to enter the world of blockchain is fairy-tale simple, isn’t it?

Another view angles

1. We have to pay attention that despite involving a subset of blockchain technologies the QLDB still implements nonrepudiation by means of trust in the central institution (in this case AWS corp).
2. Although QLDB is only available as a service, there are similar solutions that can be implemented as on-premises. In a case of such deployment scenarios, we must trust in entities who operate them.
3. Sometimes in case of institutional parties, it is only needed to build trust between parties (this is often scenario in banking) that are involved in a given transaction. Then Corda platform seems to be an ideal solution.