Minimum Viable Consensus Algorithms with Object Capabilities

State channels avoid the consensus problem by requiring unanimous consent of its members.

A smart contract can be composed that is willing to accept messages signed in a form of object capabilities. These “ocaps” are off-chain messages, or intents, that describe conditions under which the contract is willing to send a given internal message.

One popular example of a signed intent is the MetaTransaction concept, wherein a user signs a transaction that is intended to be submitted by another user, but with the strict condition that the user may only submit a transaction message that was already signed by the account owner.

These ocaps can describe terms for a subscription, a spending limit delegated to another key, or even the minting of a digital asset, and those capabilities can in turn be delegated, as is the definition of an object capability.

One object capability message could say “I will send a tx signed by both of these people after a challenge delay of X”. That’s easy. And so, a state channel can be expressed as an ocap.

A message can also say “I will send a message signed by 2/3+ of this list of validators, but with a withdraw period of Y”, and so Plasma can also be modeled as a capability.

Since these can both be modeled as capabilities, this means that capabilities can allow ad-hoc parallel protocols to update their rules in real time, without touching back to the main network.

What of rolling keys forward? Being off-chain, capabilities can be constantly updated without an on-chain update, and so if the quorum is live and responsive, they should be willing to sign an update that rolls your key forward.

Additionally, the permission to sign an update could itself be a capability, and so any person with permission to sign state updates should also be able to delegate that state updating permission to another key, and so in addition to the possibility of key-rolling, there is also the possibility for key-delegation, entirely off-chain, with no on-chain transactions until a withdraw.

A validator could even sign their object capability to delegate their validation power to another consensus group. Again, with no on-chain transaction except in the case of withdraw of dispute resolution.

With the knowledge that capabilities can model extensible consensus algorithms without any on-chain updates, we are free to re-evaluate state channels and all layer-two scaling strategies from the lens of minimum viable consensus.

What is the least consensus required for a given interaction? For very small interactions, like a two-way exchange, a state channel may remain ideal. But even in those cases, when would the two parties be willing to delegate their state updates to a third party, reducing the consensus requirements from 2 signers to 1?

One very heavy-handed answer is to have a fully collateralized counterparty, the way the Connext network or SpankChain does for their state channels, but fully collateralizing exchange means all possible liquidity is cut in half. This is the cost of full distrust. It’s powerful, but expensive!

On the other side of the trust spectrum, we know if we fully trusted a third party, we wouldn’t need a blockchain or cryptoeconomics in the first place. But we can actually do better: We can leverage cryptoeconomics to allow fully or partially socially collateralized consensus algorithms.

The economics of social collateral teach us that individuals can estimate a limit that they trust a friend to not betray them up to, and this value can be treated as a sort of virtual, or social collateral. This means if you had a friends list that was privately accompanied by a personal estimation of how much you believe your relationship is worth to them, safely and strictly erring on the side of too low, you can have a perfectly secure system that leverages these numbers, and even a graph of these numbers:

Let’s say Alice and Bob want to transact rapidly, each depositing $100, but not run a state channel validator. They want the cheapest possible validator they can get. They perform a search of their mutual social graph for someone who runs a validating computer, and propose Claire. Alice trusts Claire up to $1000, and Bob doesn’t trust Claire at all.

The two parties then sign a new ocap that delegates permission to sign updates to Claire, who does not need to post any collateral for Alice (who trusts Claire), but fully collateralizes Bob’s channel, with a challenge period, so if Alice or Claire tries to close the channel in an early state, they can withdraw, and Bob could still have a challenge period during which he’s fully insured.

If Bob instead trusted Claire only up to $50, Claire might only need to post $50 of collateral, meaning in case of a final challenge, Bob might have only up to $50 of insurance, but the lower cost of capital from locking up the collateral should lead to a cheaper transaction fee from the validator.

This gives us a model for nominating validators or sets of validators not only on the distribution of public coins, but also on the degrees to which the concerned parties can have their interests partially socially collateralized by the validators, leveraging real-world trust to minimize the costs of doing business.

This is not a prescriptive set of models, but is instead a set of highly composible primitives that allow people to opt into the kind of digital consensus systems that make sense for them.

One benefit I’m very excited about regarding this kind of highly dynamic off-chain consensus model is the ability for groups of people to break off the main network to less-connected regions and still maintain effective crypto-economic arrangements, allowing patterns of highly dynamic blockchain-pegged trust systems far beyond the main chain.

That’s all for now, thanks for reading!