Introduction
Great advances have been made in blockchain in the past five years, but the barriers to mainstream adoption have yet to be broken or even fully defined. We believe that blockchain is about data and how it is managed, and that the most significant of these barriers is the blockchain data model. This article describes how we have taken inspiration from the most successful way of handling data in the non-blockchain world and created an entirely new blockchain paradigm which, we hope, can bring dapps to the mainstream. The relational model was a revolution in software development back in the 80s, and now we are bringing that revolution to the blockchain world. We call it relational blockchain.
Blockchains are great at being blockchains, but poor at being databases
Blockchain is essentially a kind of distributed database. The point of a blockchain is to ensure that every participant has a local copy of some data which is guaranteed to be the same as the copies held by all other participants. A blockchain system must be very strict when it comes to writing data because it lacks a center, or an authoritative master copy which can be referred to. Therefore it must validate the correctness of all input transactions. Is the transaction properly signed? Is the transaction valid against the current state of the ledger? This validation is typically coded in a special language. It might be in an embedded smart contract language, or a language such as Rust, Go, or Python.
A database must be able to add data in a secure way, but getting that data out again is equally important. This becomes even more relevant when we want to use the blockchain for complex business processes and applications which handle more than just account balances and transactions. Any application software needs a good way to find the data it is interested in. How much did company A send to company B in 2017? What is the average value of a transaction sent between the US and Europe? If the data is stored in a list of transactions, it will probably be necessary to write an application specifically to extract this information. It will likely be expedient to save that data in a more accessible form (a database) so that it can be reused efficiently.
We think that most implementations of blockchain will, after some time, adapt their architecture to read new transactions as they come in on the blockchain and save them in a database system so that they can be indexed and queried more easily. However, we argue that this approach introduces a risk of inconsistency by creating two parallel sources of truth. Before looking at how we might overcome this problem, let’s look at the current state of the art for storing, manipulating, and accessing complex data in the non-blockchain world.
Relational databases: best in class for efficiency, consistency, and reliability
Relational databases are at the heart of our modern information ecosystem. They are everywhere, behind every organisation, public or private. The core advantage of a database is the ability to structure and control your data. Relational databases structure data according to the relational model, which has a set of beneficial characteristics that support a high level of control:
- No redundancy. Each datum appears in only one place, which means there is only one thing to update if something changes.
- Reduced chance of inconsistency, because it is easier to enforce consistency rules.
- Data independence. Several applications might access the same data in different ways; data independence is the ability to change the way data is stored without affecting the applications which depend on it.
Making a relational blockchain
A relational database has a powerful declarative programming language that allows you to ensure data is valid by defining a data model. Features such as primary and foreign keys ensure that duplicate and inconsistent data is impossible - they need only be defined once and are forever enforced. Together, the features of a relational database management system give us a set of properties called ACID. This means that every transaction comes with the following guarantees:
- Atomicity. Complete execution or complete failure - no mixed states.
- Consistency. The database is never left in an invalid state after executing a transaction.
- Isolation. Concurrent transactions are executed in way that is consistent with sequentially executed transactions.
- Durability. Committed transactions stay committed, even in the event of service interruptions.
Postchain is the first relational blockchain
Postchain is the first relational blockchain. It is open-source software that takes advantage of the best existing implementations of relational databases. Some private blockchains have ‘backing databases’, but none are as deeply integrated as Postchain. It works by treating database transactions as deterministic state modifications, and using blockchain-style consensus to order those transactions in a distributed and fault tolerant way. This means that we can achieve extremely high transaction density, as complex logic can be offloaded to a Relational Database Management System (RDBMS) which is highly optimized for the task.
This gives us a blockchain system which is highly flexible and highly performant. We have validation of correctness using a declarative model founded on provable principles of logic and mathematics and improved over many decades. This gives us a powerful programming model in the form of stored procedures and structured queries. With Postchain we can easily perform computations and validations which are either impossible or prohibitively complex to implement on other platforms.
There are many advantages to this approach. It is built on a solid and mature codebase, as opposed to being an entirely novel system which is both highly complex and security critical. Many relational database systems have been around for decades and are trusted in production around the world. Further, RDBMSs abstract a lot of complex functionality in ways which make life much easier for developers. We aim to make it almost as easy to implement a relational blockchain project as it is to work with a conventional database.
Going public
Private blockchains are interesting. They are compelling for the right use cases, allowed us to hone our relational blockchain concept, and we intend to continue to serve that market in the future. That said, our interest in blockchain started with Bitcoin, and we have always had a belief in large scale, fully open, and radically transparent decentralized networks. Chromia is the culmination of years of work. With it, we have taken on the challenge of scaling decentralised software infrastructure to the point where it can actually deliver on the promises that we have heard so often in the past years.
Ethereum is the most prominent player in this area, and the biggest by several measures: users, dapps, and market cap. This is despite the fact that it has a small block size and a very limited transaction volume. Plans are under development to address this limitation in various ways, and other projects (which we will not list here) have managed to achieve thousands of transactions per second on their networks. “TPS” is an attractive measure; it is easy to benchmark and big numbers (more than Visa!) look good. Unfortunately, it is not a very meaningful way of understanding the real utility and user friendliness of a platform. Ultimately, a platform for dapps must offer a strong value proposition for developers and entrepreneurs. This is a much deeper and more complex problem than can be addressed with artificial benchmarks. It’s a little like measuring the quality of a game by the number of frames per second it runs at.
If we look at the top applications on dappradar.com it becomes clear that dapps are, for whatever reason, failing to achieve widespread adoption. Many seem to exist as little more than marketing material for the chain they run on rather than because they answer some kind of demand; dapps for the sake of dapps. Either there is no demand and the promise of dapps has been vastly overstated and buoyed by a crypto bubble, or the existing platforms have not yet unlocked the potential that exists. Given that we believe in the promise of dapps, we can only assume that the available technology is deficient in some way.
Gaining momentum
Any platform, whether centralized or not, depends on creators and users. Creators make things, users use the things creators create. They both do so because they stand to gain something. The range of incentives to create or use software is so great that it is not worth delving into here. What is important is that we acknowledge that:
- Creators come first. Users have no incentive to engage with a platform if it does not have any utility to them. Creators create that utility.
- Our platform exists in a crowded space full of alternatives, and the decision of any creator to invest their time and energy into a platform is a function of cost and value
- In order to achieve adoption, we need to maximise the value and minimise the cost for creators to build on Chromia.
- Platform inertia means that the value of a platform to a creator is strongly correlated with the number of users that it has.
- In order to achieve adoption, we need to maximise the value and minimise the cost for users to use Chromia.
Uncontroversial in theory, but complex and challenging in practice. There are many ways to stimulate or “bootstrap” an ecosystem of this kind. We intend to pursue a range of options, from funding promising projects to developing our own showcase dapps. At the core of our strategy is our belief that many of the usability issues of blockchain platforms, and thence the costs for creators, are a consequence of an unfortunate choice of data model.
Chromia is built on exactly the same principles as Postchain, but it has been extended to support decentralised governance, tokens, and internal incentive mechanisms. Further, with many team members who have been deeply involved in blockchain for a long time, we feel like we have a valuable perspective on how to avoid and preempt the issues we have observed in other projects. Essentially this means a more flexible system for implementing governance, greater heterogeneity of economic models, and ‘constructive’ forking support. These are large topics and will be addressed in other articles.
Complex on-chain logic
James Ferguson is the CEO of Fuel Games, the company behind the popular Ethereum based card game Gods Unchained. The game has attracted headlines because of the high prices some of the limited edition cards, issued as ERC 721 tokens, have commanded on the secondary market. The game is similar to Hearthstone, and is, as Ferguson puts it, “a really compelling game, which people would play regardless of it having anything to do with crypto”. We believe that this is key. Any dapp which depends solely on a buoyant token economy is highly vulnerable to shocks in that economy. Shocks are a likely occurrence as competitors enter and leave the field, and regulators catch up with all of the action. A dapp which delivers some kind of intrinsic value has a better chance of surviving, and by surviving, anchoring the value of the platform upon which it depends.
The promise of dapps is more than just collectible items. All of the game logic behind Gods Unchained (a relatively simple game) is executed “off-chain”, because “there’s pretty much no way you could put anything this complex on-chain”. While this secures those tradable cards, it means that the game itself is under the control of Fuel Games. As we detail in the white paper, apps of this kind can be described more as transparent apps (tapps) because they rely on centralized infrastructure to operate. I can trade my card, but I can only play with it if Fuel Games continues to operate their servers and distribute their software. The promise of dapps is something greater: it is software which executes in an open and public way. In order to realize this, we must support the execution of complex logic on-chain.
Relational blockchain for mainstream dapps
Fortunately, relational blockchain supports this. Because computation can be offloaded to the RDBMS, transactions can be extremely dense in terms of the actual I/O operations they are able to perform. We estimate that a Chromia dapp running on its own sidechain should support 10 000 cell updates per second. A cell update is not the same as a transaction, but it is a far more realistic measure of potential application performance. A cell can contain almost any kind of data. In this context, cells would contain information about currently active users, matchmaking, card properties, and active “battles”. It could well be that such a game, ported to Chromia, might continue to use ERC 721 tokens to offer the broadest possible p2p trading market for the cards. In our eyes, the remaining 99% of the game is just as important. Our argument for “public apps” is expounded in more detail here, and here. What is important is that a platform must support executing complex logic in a distributed way in order to fully realise the potential of decentralized platforms.
Conclusion
The biggest barrier to dapps of the kind promised by Ethereum is that the existing platforms make it difficult or downright impossible to develop complex, on-chain applications which can deliver real value outside of tokens and tokenized collectibles. We believe that this barrier can be significantly lowered by rewriting the data model at the heart of blockchain to make it compatible with the greatest revolution in data management of all time. The relational model is not sexy, but it is elegant and extremely functional and it works extremely well as a blockchain system.
Having proved this concept with Postchain, with Chromia we will provide a working implementation on a massive scale. With developer friendly tools, and a unique feature set, we can present a very attractive cost/value proposition to those with the vision to create that next generation of decentralised applications. We have been promised a new internet, and we are trying to make it a reality.