This was written in mid 2016. My views, and technology, have crystallised considerably since. I will leave this page as is, other than to add this disclaimer. The core ideas, and why it necessarily has nothing to do with BFT, are more valid than ever.
Concordata is a smart distributed ledger platform. It does not depend on blockchain though it does use components of it and, as any observer or commentator of distributed ledger technology will appreciate, we are constantly learning about and reviewing our position on this complex and rapidly developing subject. Concordata is a fully functioning architecture based on a relational model, as oppose to blockchain’s transactional requirements.
Concordata’s principal goals are ones of functionality and access. How the hell do you do this stuff that everyone is talking about, and how do we build things that can work in real life. There are two important issues that we are tackling. Privacy, which is an accepted and serious issue within blockchain contracts, and concurrency. Concurrency is a a paradigm shift from the blockchain transactional model.
The developers come from two disparate computing backgrounds. One from the heart of the insurance industry having spent their working life confronted by issues of trust and interoperability of financial systems, and one from a systems development background, especially in publishing and an open source culture. Both of us have strongly held views about access and empowerment. One driven by these issues of trust, the other through a need to give as much work to other people as he can.
3TC – A Provable, Immutable and Private Consensus Strategy
The transport, validation and publication mechanism within Concordata is called Three Tier Consensus, or 3TC. It is not a blockchain derivative. It employs a method of network saturation of signed request and acknowledgement messages, including an elegant but uncontroversial technique for applying a non blocking network wide record lock when required. As such it is not scalable with respect to the number of parties to a contract as the number of messages is proportional to the square of the number of parties to a contract. But for a small number of parties to any specific contract, the system is perfectly effective.
Using standard cryptographic techniques and secure, publicly maintained libraries and platforms, such as for two way authentication and Merkle trees, it is a trivial task to build a system which is immune from any unauthorised addition without needing to corroborate with any external system. i.e if we have the correct keys we can verify that any record has been signed correctly by foreign parties. You can also guarantee against deletion by verification of a Merkle tree, apart from the latest transactions, without reference to an external source. i.e. even if we are offline, all an intruder can do is roll back time.
To guarantee against deletion from the head of the transaction stream, the systems need to corroborate with each other as to what the root of their Merkle tree is. But there is sufficient proof as just discussed that any discrepancy can be proved by the external system. i.e I can prove that I have a more recent hash as I can show you all the signatures to prove it’s genuine.
In short, Concordata is provably immutable – immune from any unauthorised deletion or addition, provided at least one participant has not been corrupted, and totally immune from any historical tampering irrespective of a network wide security failure and without any recourse to the other parties computers to prove it.
As such, Concordata is not dependent on a development of the blockchain consensus algorithm, and is subsequently not concerned about having to prove that any such changes will work and be secure when scaled. This lower level synchronisation is the first of the 3 tiers.
Empowerment Through Access
Much like spreadsheets in the 80’s enabled accountants to develop applications that would have previously required a software engineer, Concordata allows those who understand the logic of the business process to program their systems as much as possible. The world has changed much and the industry has enveloped almost everything in the last 3 decades. Any sophisticated user has an understanding of basic relational concepts. We need to be enabling these lead users to become business analysts, and business analysts to become software architects.
Open and Equitable Negotiation of a Contract
An important principle and design goal of Concordata is to move as much of the specification of systems to the users themselves. The user decides what fields we have and what they are called, what sub records or blocks belong to a contract, i.e the contracts structure, and what rules need to be applied to updates of a running system. Concordata does not define journal transaction types and the like, this is the users job. The entire process of the development of a contract is equitable, in that everyone has to agree what the rules are before we apply them. This process, and the details of how contention and collisions are resolved, is the 2nd tier of 3TC.
The architecture, developed on a comprehensive stack of contemporary Object Relational Mapping and Model View Controller technologies on Node.JS, is extensible. More complex rules and triggers can be programmed by engineers and applications developed at a lower level. But the ethos is to drive as much of this decision making onto the client/Client.
The web stack architecture itself is called Gemini and was developed as part of an open mapping project. It is reactive, meaning that if you change the database, any client looking at that part of the database will automatically refresh. This is employed from the base of the Object Relational Mapper, and throughout the Gemini stack. Your models will by default automatically be instantiated within Gemini’s data model hierarchy, and will automatically fetch if the database changes.
Privacy Is Paramount
It is impossible to verify the execution of an arbitrary program without knowing the input data. There’s no known way of magically scrambling everything up and letting blockchain nodes verify an execution of a program without knowing the data they need to work with. And while there’s some exotic stuff being dreamt up, unless it’s plain obvious and provable, which it isn’t going to be because the mathematicians have told us you can’t actually do it, we are going to have to wait to see if it stands up to public scrutiny and attack. If you have data that needs to be private but is required to validate an event on your smart contract, you have an issue.
See Ethereum technical blog post – Privacy on the Blockchain. The first paragraph of the Taking A Step Down section in Vitalik’s superb article is essentially what we are doing, with N==M. If N is say 2, and both companies have simultaneously allowed themselves to be hacked, we have a problem. Everyone has to agree, else we have an assertion failure. This is a fundamental part of how 3TC works. It’s not a system where 80% of the group can force the rest to yield. If one of the parties wants to turn off their computer and do a runner, then you have to call the lawyers. This isn’t something to allow anonymous transactions, it’s a business to business architecture for use in the real world, where companies know who they are trading with. Note that you have a lot of proof to show the judge if someone reneges, though exactly how much notice the judiciary will take is well beyond my scope.
The Hyperledger manifesto Next Consensus Architecture Proposal outlines the same approach again. Neither of these systems currently support this, thought they doubtless will do eventually. But you are still left needing to implement a negotiation mechanism if you want an equitably agreed contract. So that rather brutal approach illustrated by my pentagram animation, is what you are going to end up with. There’s no clever way out of that. So using blockchain as a transport mechanism doesn’t achieve anything.
And you can still do enforced payment using 3TC. We can post, as part of 3TC’s 3rd tier, minimalist or specific contract rules, and keep as much of the data off the blockchain as possible. In this model, you are using Concordata to arbitrate and settle your contract details, equitably, mutually and with trust and privacy, but are then going a traditional blockchain route for settlement. A participant can block the contract by simply disconnecting from the network. i.e everyone has a power of veto. There’s simply no way round that while keeping things private. Sorry.
It’s More Than a Record
The contract definition is an arbitrary tree or hierarchy of elements or fields. You can have as many of these as you like, and this nesting can be as deep as you like. You can then perform specific copy or duplicate operations of these blocks or sub-trees when the contract has moved to a live state. e.g. you define what a claim block should look like on an insurance contract and then when live the operator in effect creates an assignable copy of the claim definition. In essence, you can create instances of a given sub-model that you have designed. So the user gets to design a database schema for a particular contract model. It can be as complex as they require, and can contain as much data as they desire.
We will be developing this concept to enable generation of normalised API end points using the users own model definitions. This could be especially useful in integrating Concordata systems with existing infrastructure, and also simplifying 3rd party client integration. In short, without any programming whatsoever, the system can be configured to up and download data from an existing data system’s model. If that system is capable of listening to notification requests (Sockets.IO) then this interaction can be made reactive. Such systems need not be aware of the nature or even existence of 3TC. A naive client would not be able to participate in the negotiation and approval mechanism, but if they just want to write to fields that are indeed exclusively writeable by the host party, they not need know that the record is being replicated and validated elsewhere. They will still be notified, if they are capable of subscribing to such events, of updates by the remote party or any other client on this host. A native application (using a library to access a local database as oppose to making REST calls over the internet), can also access the ORM interface without being aware of 3TC, i.e. use Sequelize to make and update entities and not direct SQL when accessing your database and it all gets magically copied to everybody)
Why can’t you just do this with an RDBMS replication system ?
Well its all about this immutability stuff you see. You can’t trust anybody these days. Standard replication software is not concerned with issues of trust, it assumes you own the machines you are replicating to and from and can trust them. That’s a perfectly valid position, until bitcoin introduced (to the masses, and amongst a whole load of other stuff) the concept of being able to be utterly certain that I cannot possibly add, or subtract, from a data set without the consent of all parties/systems. And the realisation that we can get corporations to trust each other and rationalise effort.
Also, we need a dynamic network, i.e. we need to be able to drop and add nodes/parties to a contract at will. This would mean all kinds of reconfiguration and initiation and possibly locking the database.
There is also the issue of the network wide non blocking record lock required to publish/change the rule set, which itself is part of the record. For some patterns you need to change your contract rules, as long as we are all agreed, mid-flight. The way 3TC works, we needed to be able to do this at least once. Being able to evolve the rules to your contract is a more natural way of tackling many problems than having to serialise everything into blockchain transactions. e.g. a core group of participants need to initially negotiate what rules to apply to second tier members and indeed who they are, then when the next level of users join everyone needs to agree on some “final” state of the contract edit before being made “live”, which is just another phase or rule publication.
All this needs to be done on a per record/contract basis.
3TC protocol ensures, in an asynchronous non-blocking manner, that not only was the request to perform some action on a remote DB accepted and executed, but what the resultant state of the DB was, with signatures from all parties to that effect. This is an important point. As such there is no issue of Byzantine Fault Tolerance to be tackled. We simply aren’t tolerating anything. All the systems have to, eventually (i.e. its non blocking) come up with the right answer, else we wont be able to proceed to the next level of consensus. Brewer’s theorem is abided by to the letter, in that 3TC is completely intolerant of partitions.
If you are addressing value transfer on some trigger, go see Hyperledger and Ethereum, and for more general blockchain usage we like MultiChain, in particular its streams concept and support, and there are many others. 3TC is distinct from them all.
So no, it’s not just an RDBMS replication tool. And it’s not a cryptocurrency, so you don’t need to worry about trying to work out how that helps you. 3TC is a business to business infrastructure with allows architects to deploy cross company applications in a distributed manner (i.e. there’s not some fat makemycontract.com thing in the middle). Blockchain is a transactional database. 3TC is a relational database (interface) to which you can submit, via the ORM layer, your own constraints regarding access privileges and bounds conditions etc.. The transaction models are created by the users themselves in the contract definition, they are merely sub records to a contract which are regulated or validated by the constraints set up by the user.
The Elemental Model – The Core of Codeless Applications
There is a generic model of an element or field. This is an extensible model which will handle the design patterns of everything we’ve analysed so far. But of course such is life, someone is going to turn up with a fundamental concept that we hadn’t come across or thought about that means we need to tweak, or maybe radically rethink our generic contract model. 3TC will replicate any schema because it works, with the wonders of ORM, at a transactional level on the tables themselves. The underlying transport mechanism remains completely unchanged and thus we can migrate or support multiple core schemas.
Whenever a block or contract are created, they automatically become part of the element library on that system. An important core concept is the ability to be able to take any element already defined, copy it and amend it if required.
Workflow definition through conditional triggers and 3rd tier consensus
The third tier of consensus is when a region or a whole contract has consensus of all its component elements. All fields, or elements as they are called for clarity, have this capacity to call a trigger, but consensus is also aggregated to block level. These triggers are limited in scope, all you can do is apply a set of rules and/or cause a block to be replicated. It’s becoming apparent that we can tackle a very significant proportion of the pattern sets required for solving a wide array of insurance applications.
The Corporate Internet
We have codeless contracts, applications in effect, which are shared securely and with trust over a corporate network. Whenever a new contract is joined, all the members on it will automatically now have all components of that contract in their local element library. In such an ecosystem it is likely that social consensus across the corporate world can establish standards and share these applications not just within industries, but throughout the corporate world. All without having to talk to any computer programmers to get it done.
Here’s an amusing video we’ve put together to explain some of whats going on