What Is 3TC, and How Does It Relate To Blockchain
3TC isnt a blockchain in the opinion of its author, but it is in the view of some in the business. So if it’s not a blockchain then why not, and what is it. And if it is, what is similar.
Blockchain Does Not Have A Monopoly On Proof
You don’t need the universal ledger for one party to be able to digitally prove that another party said something, directly to them, in the past. You need public key 2 way authentication, and a certification authority. You use this all the time, it’s the stuff that puts the S in https://.
That of course doesn’t now mean we can make someone do what they promised to do just because we have irrefutable proof from a SHA256 digitally signed message, we need the magic of a Bitcoin with some extras to do that. No, not blockchain, a real Bitcoin, a traded crypto currency.
There’s two issues here
- What does the message actually mean ?, what are we promising to do, it’s just a string of 1s an 0s really.
- What can blockchain possibly make anyone do, its just a computer program. All bitcoin can force you to do, the only thing it controls, is it’s crypto-currency.
If you haven’t even got a crypto currency, if you arent actually triggering value transfer because you’ve ditched Bitcoin’s inconvenient and ecologically dirty secret called Proof of Work, then what the heck do we need a blockchain for ?. All a currency-less blockchain can do is provide evidence, set values in a database that say that someone owes you. You simply dont need a blockchain to be able to achieve this.
Blockchain isn’t private
Everything you stick onto a blockchain is there, and visible to the entire network, forever. You need to assess what potential cost to privacy you may be committing to.
Traffic analysis of static wallet addresses.
It is impossible to interact with any system in an identified or non-anonymous fashion, and be anonymous. That’s an obvious fact. Blockchain’s principal and overriding goal is to provide an incorruptible, universally ordered ledger. This is achieved at a price. If you interact with Bitcoin with the same wallet address repeatedly, your transaction patterns can be quite easily detected. Permissioned blockchains may mitigate against this to some extent by not affecting the wallet balances for pure data transfer, but activity is still detectable. With potentially massive quantities of transactions on static addresses, engraved for eternity on an immutable data store, any defense against this must be able to prove that it cannot ever be broken.
Almost all examples of blockchain usage, be they crypto-currency or privately maintained (and secured!), and which require either party to repeatedly interact with the same address or just from the same node, are liable to make their relationships in the network public. Any nefarious use of Bitcoin requires your wallet address to be regularly changed, and even then it’s far from certain your interactions will never be discovered. In a legitimate business environment that simply doesn’t make sense. You will require a consistent bank or data account address.
Detecting conspiracies in a network is clearly a highly technical issue. But it isnt simply the preserve of GCHQ and the CIA. Techniques for network analysis are in public use across the scientific community. This next point however is not up for discussion. It’s just plain fact.
Obfuscation of smart contract input data is impossible.
Everyone at Ethereum, Hyperledger & Eris is in agreement on this matter. The parametric data in your smart contract, the parameters for the rules which are embedded in your contract, have to be public if validated on a public network. There’s no clever way around that problem that is feasible that has yet been discovered.
The only way of keeping your validated private stuff private is to employ only the parties to the contract for validating a transaction. If this number is low then that will require total consensus. Everyone has to say yes, hence everyone has a power of veto. This is the declared solution to the matter from all of the above blockchain technologies, should they implement it.
We have now completely inverted the blockchain paradigm. Nobody can force anyone to do anything (even though all you can ever do anyway is force someone to spend some of your native currency). So you still have to call the lawyers to make people stick to the deal they signed, and yet we still have the potential of a thin cloud spread across the world watching our every move if we start rolling these interactions up in any way on a universal blockchain.
I haven’t moaned on yet about scalability. There are issues with Blockchain scalability, messy ones intrinsic to the architecture that nobody has a reasonable answer to yet.
There Exists A Solution
Given the inescapable issues listed above, the only possible solution is a mini blockchain, one per contract, with a simple universal consensus strategy involving only the parties on the contract. This is trivially achieved by a policy of network saturation. It is not scalable with respect to the number of parties on any one contract, it has to be say < 20. But is essentially unbounded on the total number of parties, and transactions, on this “other kind of blockchain”, because you arent actually all on one chain.
Everyone tells everyone else on the contract, and only those on the contract, about everything that happens, using little more than standard two way public key authentication. The nodes respond to each other with the current hash of the record. We are not just broadcasting a request and recording the remote acknowledgement. The remote has to reply with evidence of its current state, i.e we know that they have an identical contract in their database to the one you, and everyone else on the contract, is looking at. Any failure, whether through software error, or through malicious or faulty operation, will be discovered immediately.
We now have a very strong level of immutability already. You just cant add an invalid record to this store as it would need to be signed by all the parties and can always retrospectively be detected. We can now employ one of the core components of the blockchain architecture, the Merkle tree. This enables detection of the deletion of any item prior to the latest valid state of any of the participants. i.e we are all as good as the best secured system on the contract, we have all the correct records, no more or less, and in the right order. When you roll in the resilience of cloud based database systems, and with significant database corruption of each and all systems required to cause an undetected fraud, we now have a system which is cryptographically all but as secure as a blockchain, but doesn’t have the unfortunate side effects of telling everyone on the network who your clients are and what the relative strength of your relationship appears to be with them, or of being forced to obey a potentially faulty computer program.
Your smart contract now isn’t irrevocable. Anyone on the contract can just turn their computer off if they don’t like whats unfolding. That’s not the sci fi stuff that is being sold I know. Private and irrevocable smart contracts are not actually deliverable, and I don’t think you really want some magic box that could, and inevitably will become a monkey’s paw.
Is 3TC another kind of blockchain ?. My personal view is that you’ve lost being a blockchain the minute you drop proof of work and stop being a crypto currency. The whole point of blockchain is to make you change your wallet balance. If you havent got PoW then you dont have a crypto currency. That said, as the only solution to strict privacy is exactly what we are doing, then if you like we can call it a blockchain. But we’re missing the really novel part of the whole blockchain architecture, just so you know.
Let’s Start With A Contract
Rather than taking a crypto-currency and trying to work out how we bend it to our will, perhaps a better approach is to start with a contract and work out how we can smarten it up and bless it with some of the properties of the blockchain. As discussed above, we cant have irrevocable and private contracts in an honest world. What we can have is extremely high levels of immutability, or trust, between the parties, with total privacy.
Everyone on the contract has to co-operate for modifications to be accepted, but the history of agreement is extremely secure. Whether a SHA256 signature is sufficient to make a judge side with you is another issue, and as I understand it one you will lose. But making the Internet force you to do something while not telling everyone what that thing is, is neither an achievable target using existing technology nor a desirable one anyway . What is possible is a shared record that we can all trust.
What Is A Contract ?
A contract is a series of identical documents, one for each party in the contract, each document signed by all parties. Only the parties on the contract have copies. Indeed we don’t want anyone outside this group to even know of the contract’s existence. So what we want is some kind of database replication technology that has assurance comparable with blockchain, but with total privacy. It needs to share individual records/contracts over a dynamic network specified in the contract itself. i.e we can add new members at the start and also during the life cycle of a contract, and even remove them though they will always have a history up to the point they left.
Initially we merely wish for this document to be negotiable in a mutually consistent manner and for those edits to be first replicated to each party, and then in turn approved by each party. Note there are two stages here. The first is to replicate what is actually a proposed value for a field, this is tier 1, and then the parties have to manually (or automatically as will be discussed below) agree to that value, to vote yes, this is tier 2. However, we still then need a 3rd tier, to confirm the contract as a whole. e.g. we may have all agreed to what is on the contract so far, but one or more parties still want to add more before they sign the contract as complete.
These 3 tiers of the consensus strategy are what give the technology its name.
3TC – Three Tier Consensus
- Transport – the replication process
- Negotiation – agreement of individual fields
- Publication – agreement on the entire contract
Transport Layer – T1
So how does the stuff get about ?. Every entity instance in our 3TC database, i.e. a row in a table in the database, is replicated individually. There’s of course only 3 things you can do, CREATE, UPDATE or DELETE. These requests obviously have to be executed in the same order they were on the originating system , this is of course because we need any and all parent entities to exist before we insert the child. There are also issues about resolving primary keys. All tables need to have a universalId field for this. The originating entity simply broadcasts the request, including obviously the content of the record and also the hash of the entire contract at this state. Each remote party in turn re-broadcasts essentially the same request, but with the local system’s own hash. The hashes are stored in a dialogue table for each request and hence we can see if we have even hashes for a given transaction. The network is defined by the contract itself, with the ContractParty intersection table, or Crypt. So there’s some special behaviour needed for those tables. But all the others, and we are expanding the schema regularly, work the same way. We just define the table using the Sequelize model definition files developed as part of the Gemini project. The data is then not only automatically replicated, but is also magically instantiated in the client. The only thing left is to write some template code for the display of this entity using the ViewPoint system also developed in this project to work with Marionette.
Negotiation – T2
A principal problem in any database replication system is dealing with collisions where two of the nodes both want to write a different value to the same point in the database simultaneously. There are two simple techniques to get out of this
- Design the database so that everyone can have their own version to write to
- Lock the contract and then execute the command universally
During the live running of a contract the system is generally asynchronous throughout. Remote systems do not all have to be on line for contracts to have proposals submitted. This is because all the data you are submitting is to tables that belong to both the Contract and the Party tables. In short you all have your own version of things, you cant overwrite someone else’s Proposal, or Vote on someone else’s behalf. All this is within what is called the Negotiation or T2 tier.
Publication – T3
This only gets you so far. Eventually we need to be certain that we all have the same record. That we all are agreed on what we are agreeing on and that we can publish or at least mark this point in the contract’s history as an agreed point. For this the record has to be locked, we all have to stop changing it. All systems on the contract now have to turn up for work eventually. The architecture is resilient, they don’t all have to be on line simultaneously, but we can’t go anywhere with this contract until everyone has now signed off. This rubber stamping exercise is called the Publication or T3 tier and can for any contract be either automatic based on constraints set, or require each or some of the remote parties to manually sign or agree.
We can do this locking because we have a manageable number of nodes, all of which can reasonably be expected in a business environment to have reasonably available systems. You don’t need some special internet connection or even keep your databases online 24/7, but your systems do need to be reasonably available for a contract to be confirmed. The system is intended to work with under say 20 parties per contract. If you want greater numbers then one of the parties has to work as an aggregator. Note that each of these parties is going to be a company or institution that simply cannot store its data in some communal hub. 20 of them on the same contract is improbable. 20 of them on a secret contract is preposterous.
A contract consists of a potentially hierarchical tree of fields. Apart from providing some organization to large contracts by enabling blocks to be collapsed and expanded as required, a tree of fields enables us to perform duplication actions on blocks of fields. We call these fields Elements.
Elements have a relatively complex sub schema associated with them. They have votes as mentioned above for Tier 2, they can also have rules applied. These rule applications have modes, which in turn can be turned on and off. I have described this in previous posts as a “Generic Contract Model”. This is misleading, It’s a Generic Element Model. Contract structure is arbitrary and entirely controlled and developed by the end user community.
As we discover new distinct patterns or “features” if you like, this model can and is being expanded. But the T1 code never needs any changes as this schema is developed, we can just evolve our generic model. These new component entities may well have special properties, in particular resulting in base rules of the system being affected. These tasks and constraints are applied using the Object Relational Mapping technology discussed below. i.e. the tables just appear at the other end. if you need extra stuff going on, you add it using hooks for this entity.
While a contract is a list of fields which can have children or subfields, it’s perhaps better to think of it as a list of blocks or additional subforms that need completing. These subforms need defining, and then as part of the live state of the contract, replicating. The initial definition or template block for such a form is a called a prototype, and has an associated array of replicated elements (usually blocks), such as claims or endorsements on a contract. The user gets to define their own data models, their own tables and attributes basically.
What we now have is the capacity for end users to actually design their own data. Arbitrary groups of parties can develop and arbitrate not just the content but the very structure of their data. They can produce catalogues of form and contract types to be plugged in or used in full in a new contract. The ability to abstract these, to take a starting point and then add the extra stuff you need in this specific case, again from a drop down of blocks already defined, or by creating one and possibly naming it for future use, can have profound implications.
Not That Smart, But Selectively Constrained
Being told that you cant have the hippy trippy free love of the blockchain in the Insurance world, or almost any business context where we simply don’t want our association to be made public, may come as a disappointment. But I am now going to tell you that you don’t really want really smart contracts at all. You want totally transparent ones whose rules are simply constraints on what values can be and who can edit them. We want very solid simple and transparent logic that the users can see and control. Just by restricting who can edit what, and what they can submit, we have gone a long way.
In order to make this fly, we need to be able to set constraints such as “Field X must be greater than field Y”, or “Y+Z”, or “max(A,B,C)” or any standard mathematical expression. We want it so you cant even fill X in till we have a Y. And if Y changes and X now no longer works, X should be invalidated. We want fields to be able to have more than one constraint. And a referencing syntax to navigate this tree, and a common mathematical syntax. These features alone, while transparent and easily followed, give you most of what you need in an automated contract.
Triggers and Process Definition
We can take this a step further though, and still keep it simple, courtesy of the T2&3 concepts. When field, block or contract wide consensus is reached we can invoke a trigger. This isn’t an arbitrary piece of code, it is merely the automatic invocation of either a block copy, e.g. make a new claim form, and/or the application of a mode grouping of rules. This trigger is itself just a rule, with parameters specifying the block(s) to copy and or mode(s) to apply upon everyone accepting the value. This allows you to do things like, upon completion of some optional field, or even a specific value in a list, determine that a sub form now needs to be filled in. This allows the user to actually define a contract life cycle process.
One extended data type that I am currently implementing is to support arbitrary images or other documents. The files are stored separately by each party on their own storage system, whatever that might be (i.e you can all pick your own private cloud to put the stuff on). Only the hash of the file is stored in 3TC, any upload will create a new proposal for this field, and so we automatically have a history facility. Insertion will cause the remote nodes to request the file directly from the host using SFTP and a proxy via the uploading node.
We will be also able to do this with XLS files, allowing embedded spreadsheets as well as documents or image files. The cool thing we can then do is extend the referencing syntax so you can say MyXLFile.C1 or better still MyXLFile.MyLabelledCell, and then set constraints on other fields using this value. So if you have an existing process whereby a reasonably defined spreadsheet gets filled in first, we can load it and even derive values from it for use within the validation and control of the contract. We can even edit it inside the page and provide a history and rollback.
Sequelize – An Object Relational Mapper
3TC also implements a Sockets.IO strategy for all models and collections defined as children of a specific model. The entire exposed REST interface and the underlying database relations are transmitted via a call to the root API. In plain English, if you go to /api you will get a dump of the entire DB definition for use in the client in working out where things are, and what messages to listen to. The combination of all this results in a model being submitted on one screen on a remote node, producing a request on the remote to any clients looking at that part of the DB to fetch the now replicated value. Its a Reactive Immutable Distributed Ledger
My colleague sends me at least one “the future is blockchain” article a day. Admittedly we are now getting a weekly “blockchain might not be all what it’s cracked up to be”, and “blockchain took all my money” and “lots of money already spent on blockchain and nothing has actually turned up thats usable yet”. My favourite “blockchain will do everything” post of today included “Nuclear launch codes”. You can imagine my reaction to that one.
I am a coder. Things have to add up. I have solved your problems with what I believe, based on the interaction I have had with the Blockchain Illuminati, is logically the only way possible. But I have also done it using technology which comprises all the good stuff that has evolved over the last 5 to 10 years on how to build scalable reactive and highly complex applications. We now have the capacity to deploy here and now on use cases that make sense and can produce savings rapidly.
But what we have is so much deeper than that. Based on the vision of a simple transparent automated record, and the capacity for end users to design and refine their own data models and in effect applications, we can revolutionize how business is not just done, but how practices are developed. There are products you never even dreamed of waiting to be deployed using this technology. Ones where defining the process, let alone gaining consensus, just wouldn’t have been feasible without 3TC.
Do You Really Want To Be Disrupted ?
Do you have to endure centralized bodies wishing to enforce and control architecture, data standards and procedure ?. Is development and deployment of such systems and standards slow to non existent ?. Do these projects require you to commit to technologies that dont even exist yet ?. Wouldn’t you rather let your own business analysts just get on with things from the front line, and develop and forge these prototypes yourselves with partner groups that are motivated to explore these technologies .
Using a stack of existing and contemporary technology discussed above and including some of the core cryptographic components and publicly maintained code used by blockchain, we have a way of attacking the internal and inter-corporate IT impasses that exist in your industry now.
This has the potential to not just disrupt the entire landscape, but fundamentally change how your industry actually works.