Proof of work is overkill. Proof of stake and other solutions still use linear blockchains. Trust trees rely on a community of pseudo-anonymous participants, to build a truly distributed ledger network.
In August of 2015, I was learning about Peercoin and researching proof of stake technology. I eventually realized that the entire process of proof of work is overkill, and proof of stake and other technologies are problematic because they still rely on a single chain.
There is a much better way to solve the problem of distributed affirmation and consensus. I am calling this solution “Trust Trees”. Trust trees are independent collections of secure and proven transactions. Trust trees collect pseudo-anonymous signatures as evidence all transactions leading up to a leaf have been replicated and are conflict free.
In this post I explain how trust trees work, and how communities can build a network that supports a collection of diverse distributed cryptocurrencies. Trust trees are also highly performant and resilient.
The Community is Key: Pseudo-Anonymity
The essential ingredient here, is an active community of participants who have persistent identities within the community. We may not know who these people are in the real world, but within the community, they keep the same identity for a long time, and their history can be reviewed by anyone. This will be referred to as pseudo-anonymity. Pseudo anonymity takes advantage of public key cryptography to associate signatures and actions with an identity. The history of signatures performed using a particular key pair, shows that an associated party is trustworthy and reliable. This builds a community of active, reliable participants, who perform notarization to affirm transactions and resolve conflict.
Participants don’t need their identity associated with a real world identity, they don’t even need any transactions or balances associated with these identities. They just need to be consistent and reliable participants, who notarize transactions according to predetermined rules.
In this way, the participants can maintain real world anonymity, but the community benefits from participants who have a public history that keeps them mutually accountable. Most communities, whether online or in the real world, rely on mutual accountability. Cryptocurrency communities can benefit from this as well.
These participants perform two critical services: transaction replication, and conflict resolution.
Trust Trees Scale Their Effort to The Problem
Blockchains affirm transactions by publishing them in sequential, cryptographically “marked” blocks. This works, but it is an expensive preemptive strategy for addressing conflict. Proof of work is performed whether or not a conflict ever arises. Blockchains amortize this expense, but there is a tradeoff with performance, flexibility, and blocksize issues.
A trust tree can use minimal affirmation unless a conflict arises, at which point it relies on more and more of the community until it gets resolved. Before a conflict, it is only necessary to have sufficient replication, so that enough participants independently observe it is valid, and they can be certain a conflicting transaction has not yet been published.
Trust trees focus on two key steps to make sure transactions are secure.
- Avoid the conflict
- Resolve the conflict
Avoiding Conflict: Replication
A shady character is trying to double spend a coin. What’s the best way to stop him? Simply don’t accept it in the first place. This means there needs to be two steps to every transaction: the sender sends the transactions, and the recipient accepts.
But how do you know if it’s real or fake? In this case, how do you know there’s not a conflict or double spend? The basic idea is not complicated, you simply share the transaction with everyone else in the relevant community, and ask them if they have seen a conflict.
Cryptocurrencies already publicly replicate transaction information, so that part is nothing new. The only new thing we need to add is double signed transactions: the sender signs a transaction, it’s replicated, and then the recipient makes sure there’s no double spend or other conflict before they accept the transaction.
Double Signed Transactions: Initiate, Replicate, and Accept
Most cryptocurrencies require a sender to sign a transaction, but with trust trees, it’s critical that both sender and recipient sign transactions, at the least.
The attempt to make double spends cryptographically impossible preemptively creates a very difficult burden of proof, necessitating expensive algorithms like proof of work. In most cases, we expect people we transact with to be well behaved. But when double spends do arise, it is important that they get resolved consistently, in the favor of the valid transaction .
Resolve the Conflict: Everybody signs!
If a transaction is replicated to many independent participants, and later there is a double spend, then everyone who observed the original transaction will know it came first.
All those observers simply need to sign the valid transaction that was published and replicated first.
Based on the signatures, participants should be able to assess which fork is valid, and they will only interact with that branch in future transactions. One fork will thrive, while the other will be ignored. This process is proof of trust.
Note that this isn’t voting. There doesn’t need to be a fixed algorithm, though there needs to be a standard that guarantees eventual consistency throughout the community.
My “Trust Tree” Proof of Concept: Trust-Ledger
Since I first got the idea in 2015, I have been developing the concept of trust trees. I have been documenting details and ideas in a github repo named trust-ledger. A prototype version has been started, linked to from the main project, but for now, the concepts are more important.
While this is my effort to solve some important problems, at this point I am more interested in the process of learning and getting feedback from others so we can work together. I think there are a lot of new ideas that could improve cryptocurrencies and I want to share my efforts with the community.