Consensus mechanisms validate and authenticate the transactions of a distributed ledger without the need to trust or rely on a central authority. They are the centerpiece of any cryptocurrency.
Current consensus mechanisms, such as the Proof-of-Work in Bitcoin, consume unimaginable amounts of electricity. If VISA were to use this technology, world power consumption would double. On top of that, every so-called full client has to store the entire blockcain, which also leads to unimaginable data traffic, resource consumption and redundancy.
In this presentation, I will introduce a consensus mechanism that not only requires no energy but also no other resources and also stores the data of the blockchain in so-called blockchain trees without redundancy. The ideas presented are part of a project called Co-op Money Infrastructure. In the white paper of the project further details are presented.
Legal consensus mechanism
Consensus mechanisms, such as the proof-of-work are technical solutions to the underlying problem.
Through the newly developed legal consensus mechanism not only money, but all rights and obligations might be turned into digital bearer instruments that have been signed by the senders and can only be read and processed by the legitimate recipients.
The signed data of a contract, together with all the rights and obligations arising from the contract, are distributed in a complementary and redundancy-free manner only to the contracting parties and with the result that a party who manipulates his data would destroy his own rights and yet would have to fulfil his obligations under the contract. Manipulating your own data would be even worse than burning your own money in your pocket. – All own rights in the system would be burned.
To prevent manipulation and disaster, a user works only on a copy of his data. The original database only exists as a backup of the log files, from which a copy of the original database can be restored if necessary.
The legal consensus mechanism links rights and data inextricably, such as are rights and paper in securities. The rights from the data follow the rights to the data. The power of control over the data is ensured by cryptographic methods and possession.
The correct content of the data is also legally secured through the complementary interests of the parties: The right of the creditor to claim a particular performance refers to the identical performance that the debtor has to provide.
For example, a contract signed by the seller certifies the rights of the buyer and the obligations of the seller. This unique data is stored in the buyer’s blockchain. As a result, only he can actually and legally dispose of these data. The buyer cannot manipulate these data because the seller signed them. And without these data, the buyer cannot assert his rights against the seller and the seller is under no obligation to perform.
And vice versa, the contract signed by the buyer certifies the rights of the seller and the obligations of the buyer. This unique data is stored in the seller’s blockchain and only he can actually and legally dispose of these data.
The legal consensus mechanism causes users to not manipulate their data; otherwise their own rights would be destroyed. Therefore, the data must be protected only from accidental and third party manipulations, hardware failures and software errors. To prevent such incidents, there are several redundant protection mechanisms installed that can be supplemented by the user himself, if he wishes to do so.
“Proof of Work” is currently the consensus mechanism in the most popular crypto currencies, such as Bitcoin. At the beginning of September 2018, Bitcoin’s estimated power consumption was 73 TWh per year and will reach 125 TWh per year by the end of 2018. Thus, this power consumption is higher than that of 15 million respectively 25 million four-person households in Germany.
In the money infrastructure, this tremendous energy consumption is not required and is replaced by a single paragraph in the terms of use and the legal consensus mechanism in combination with the so-called blockchain trees. In addition, this much simpler solution achieves more than the “Proof of Work” mechanism: the scaling of the system is independent of the number of users and the transactions can be executed in real time.
Blockchain
The term blockchain is used in two very different ways.
In the proper sense, a blockchain is a continuously growing list of records, called blocks, which are chained together and secured using cryptography. Each block typically contains a cryptographic hash of the previous block, a timestamp and payload data. By design, a blockchain is inherently resistant to modification of the data whose integrity can be checked very efficiently. These features are the reason to use blockchain technology.
The application of this technology to certain cryptocurrencies led to the second meaning: A blockchain is a decentralized, public digital ledger of transactions that can not be manipulated due to cryptographic methods.
Here the term blockchain is used in the first sense and the second meaning is called a blockchain application. The term blockchain tree used in the following is also a blockchain application, which however differs substantially from the previous use in cryptocurrencies.
A blockchain tree consists of independent blockchains linked by a rooted tree structure. The root and leave nodes of the tree contain blockchains. The first block in a leave blockchain contains as the first entry the hash of the first block of the root blockchain and the path.
Identity blockchain tree
Identity services are important whenever people become interactive. They are particularly important in situations where people no longer meet in person and legal relationships are involved. If the identity of a business partner is unknown, significant disadvantages can arise if rights are claimed and the debtor does not want to fulfill his obligations. If in such situations the identity of the debtor is unknown, a claim can not be asserted in court.
Identity services are the bridge between the computer-generated virtual world and real people. Technically speaking, an identity in the sense used here is an object in the sense of object-oriented programming. That means an identity has attributes and a behavior that is governed by the represented real person.
Storing and managing identities is the job of the distributed identity server cluster. The data of the identities are stored in a graph database management system that implements a blockchain tree. The Identity Server Cluster is a common component of the money infrastructure and runs on particularly suitable user hardware. The motivation for users to provide resources for an Identity Server is the ability to earn money and to process their own transactions faster.
Since the rights, duties and legal dispositions of a natural or legal person are documented and inextricable linked to data in the money infrastructure, a one-to-one connection to the person concerned is indispensable. A person is represented in the system by a virtual identity and can act through that identity in the system. All rights, duties and legal acts that are assigned to an identity are directly attributed to the person concerned.
In the legal sense, there are two types of persons. Natural persons refer to humans. Legal persons refer to all other legal subjects, e.g. companies or institutions.
A legal person acts through the identity of another identity that occupies one or more roles within that legal entity. In this way, as in reality, chains of representations can emerge, at the ends of which a natural person stands.
A role gives an identity certain rights, obligations and powers on behalf and by authority of the represented legal subject.
Informational self-determination is a basic principle of the money infrastructure. Therefore, a person decides which data they want to make accessible to whom. In turn, this decision determines a person’s rights and possibilities in the system.
An identity and its data may be confirmed to varying degrees: fake, unconfirmed, confirmed by other IDs, certified, etc. If an identity is recognized as fake, then it is banned from the system.
For example, a person in a developed country could only conclude a loan agreement within the money infrastructure if it has an officially confirmed identity whose data is made available to the contracting party. This restriction makes the money infrastructure compliant with legal requirements and prevents a person from evading their duties.
However, in regions where government structures are poorly developed, it should be possible to obtain loans based on identities verified by counterparties or by personal inspection.
For both cases, mechanisms are available that promote and, if necessary, enforce sanctity of contracts. One mechanism is called the compliance index and the other is implemented through so-called recommended, standardized and balanced contracts.
The profile of an identity and the changes are stored in its own blockchain. The first block contains all the necessary data to identify a person and a video in which the person expressly commits to comply with the rules of the money infrastructure. This declaration of commitment is a specific sentence that must be repeated.
When setting requirements, recommendations from international standards, such as ISO / IEC 24760, should be considered.
The first block contains encrypted all necessary data for the identification of a person and a video in which the person expressly commits himself to comply with the rules of the money infrastructure.
The individual data and the video are used to calculate hash values, which are summarized in a Merkle tree.
The second block contains public or business partner released profile data and published certificates. The Merkle tree over the profile data is used to check whether the published profile data matches the encrypted profile data.
The other blocks contain additions and changes to the profile data.
Due to their general importance, the identity service of the money infrastructure should also be available to other applications. In this case, one could consider whether the sponsor organisation of the money infrastructure becomes an official certification authority and controls the identity server cluster.
The identity blockchain of a person is the root of an user data blockchain tree.
User data blockchain tree
A user data blockchain tree might be viewed as a general tamper-proof database and might be used wherever appropriate. The structure of the payload data within a blockchain can be chosen as required.
All rights and obligations and all contracts of a person might be stored in a user’s data blockchain tree. This data is encrypted by the owner of the tree so that only he has access to the data.
At least three copies of this encrypted data are stored as backups by other users. A user can make requirements on the quality of the backup resources, but on which server the backups are ultimately stored will be decided by the system at random and quality requirements. Backup storage providers do not know who they are backing up and can not do anything with the data because they are encrypted.
If a backup server does not meet the promised characteristics, then the data is automatically saved to another server if the requested quality is not reached. This ensures that at least the required odd number of backups are available when needed.
The blockchains are used as accounts or as storage for contracts or other data. A blockchain evolves from the transactions in the case of an account or from the performances provided under a contract.
An account can either store a right as a digital bearer instrument or the right will only be documented. In the second case, the owner may need to prove his ownership by additional other means.
By default, rights are stored as digital bearer instruments. This means that the right is inextricably linked to unique signed data and only the owner and possessor of that data can in fact and legally transfer or assert such right. This applies, for example to the money accounts provided by the co-op money infrastructure.
However, this close connection between rights and data is not mandatory and in many cases not possible or desired. This applies, for example, to otherwise securitized rights or if land is registered in an official Land Register. This also applies to all accounts that are managed by banks and for which the customer receives a bank statement.
The proof of a single or multiple similar rights can be stored in an account:
- A single right, such as a certain real estate right.
- A quantity of similar rights that can be individually identified. For example, ownership of notebooks identified by a serial number.
- An amount of fungible rights that are treated alike, such as money, claims to money or the ownership of a fungible commodity.
The identity blockchain tree together with the user data blockchain trees can be considered as one large tree spanning across the internet in which each right has a globally unique address. The first part of the path uniquely identifies the legal owner of a right and the second part leads to the right itself.
In that sense, the money infrastructure creates an Internet of Rights and, indirectly, an Internet of Things because things depend on the right, not the other way around.
Redundancy is part of the architecture of the consensus mechanism in the proof of work. A full client must store the entire blockchain, even if it has only a few bitcoins. In the proof of work, the blockchain data is not distributed among the users, but each full client must store the complete blockchain. Like mining, this architecture leads to an unimaginable waste of resources and also significantly slows down overall system performance.
The legal consensus mechanism has no architectural redundancy.
Theoretically, the money infrastructure could be built without redundancy. But this would require 100% secure and error-free hardware and software. Redundancy is needed only to the extent necessary to intercept hardware and software errors as well as willful destruction. In addition, redundancy can be used to boost performance.
In the profile of an account, additional metadata can be stored, such as: Cost centers so that the organizational structure of a company can be mapped.
To prevent bookkeeping in a company from being done twice, all posting-relevant business transactions can be documented in the company’s blockchain tree. In this way, the blockchain tree can be used as a particularly tamper-proof database for accounting.
Each blockchain ends with the hash of the last block. These hash values are summarized in a Merkle tree. The first two hash values come from the first and last block of the root blockchain.
The Merkle root is used to prove the integrity of all data in the blockchain tree.
When a user starts a money infrastructure application, it checks in the background whether the Merkle root of the local blockchain tree matches the backed up Merkle root on the identity server and on a backup. If there are deviations, then the local blockchain tree database is restored based on the majority of the backups. Normally, all backups are the same.
The data from the backups and the identity blockchains tree are leading in determining the integrity of the data. In this way, the user data blockchain tree is replaced if it has been accidentally or intentionally corrupted.
To successfully manipulate a user data blockchain tree, the following barriers would have to be overcome.
- The identity server cluster would have to be hacked to find the cluster server containing the backup information for a particular blockchain tree.
- This specific identity server would need to be hacked to find out on which backup servers the backups of a particular blockchain tree are stored. That alone should be very difficult with a redundant server cluster with a distributed database in which the servers control each other.
- One of the backup server must be hacked to steal the backup.
- The correct private key must be stolen from the attacked user to decrypt the backup.
- The data backup must be manipulated in the desired way and the affected hash values recalculated. This manipulation is extremely difficult, because the database transaction log is backed up and not the individual tables.
- Since most of the relevant data was signed by a third party, the signature would also need to be rebuilt using the private key of the signer. These private keys would have to be stolen beforehand.
- Then the majority of backup servers must be hacked and the backups replaced.
- So that when comparing the Merkle roots the manipulation is not noticeable, all changes would have to be made on the server of the attacked user too. The manipulation would be completely different, because not the log files, but the tables would have to be manipulated.
- If digital bearer instruments are transferred such as payments, points 1. – 8. would have to be made for each transfer along the entire chain. For payments, there would also arise a difference between the total amount of the cash accounts in the system and the external escrow account. At the latest here, the manipulation would be noticed and could be traced back to the origin.
- All break-ins and manipulations would have to be done in a very tight time frame, because the normal use of the system could permanently change the blockchain involved. While an attacker manipulated a particular blockchain backup, the original blockchain could be updated and the backups moved to completely different backup servers.
Even if some barriers can be taken, it is very unlikely to overcome all obstacles as required. On the one hand, the security concept is based on cryptographic methods, and on the other hand, the effort to manipulate is set to an extreme disproportion to the potential yield. In addition, every user can choose to protect their data according to their own needs and options. Shared data is hosted only on servers that provide high security.
The attacker would also have to pass unnoticed at the permanent internal security checks.
However, the Achilles heel is the protection of private keys. Anyone who has access to a user’s private keys and hardware could make dispositions attributed to the owner of the private keys. This vulnerability can only be reduced by additional security measures, such as the integration of biometric procedures. Additional safety precautions can be determined by the user according to their own needs.
To protect the integrity of the entire system, traffic is encrypted among the servers and applications and each transaction is embedded in a three-phase commit protocol.