Vision for Off-chain and Non-Custodial Smart Contract Networks
A few weeks ago I came across a quote by Satoshi Nakamoto:
The root problem with conventional currency is all the trust that’s required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts.
— Satoshi Nakamoto
The above illustrates the motivation for a global peer-to-peer-electronic cash system, Bitcoin, to upset the existing financial system. Nakamoto (alongside others) built a programmatic form of money that is completely publicly verifiable. Plus, we don’t need to trust any single entity to run it.
What is public verifiability and why is it important? In cryptography, it tends to mean an entire protocol’s execution transcript can be independently verified by anyone such that they are always convinced it was run correctly. Thanks to this single property, Bitcoin (and other cryptocurrencies) operate with the security paradigm: trust, but verify.
We can verify all transactions (and blocks) are valid, but there is still some element of trust in Bitcoin. While the system is set up to ensure financially invested actors (i.e. miners) compete with one another to mint blocks in return for in-band coins, we must trust miners not to collude and censor transactions (or worse, reverse transactions!).
It is up us, the community, to hold the miners accountable by verifying blocks and transactions in real-time.
The crux of holding the miners accountable has hindered the network’s scalability
There are generally two approaches for scaling on-chain transactions in a trust-less manner for cryptocurrencies:
- New consensus protocols. Strictly increase the network’s throughput, think Bitcoin-NG, ThunderCore, Phantom, etc.
- Shard and distribute the task of validation. Users only validate transactions that are relevant to them (i.e. train and hotel problem).
For now, let’s assume both approaches increase the network’s throughput to support 5,000 transactions per second and as a result transaction fees are super-low. This would truly be exciting. Potentially anyone can afford to transact on the network and thus cryptocurrencies may then be ready to compete as a global payment network.
However… it doesn’t come for free.
By strictly increasing the network’s throughput, we inevitably reduce the diversity of peers with the computational, bandwidth or storage resources to validate blocks and transactions in real-time.
If the community cannot hold the miners accountable, then cryptocurrencies are not truly publicly verifiable and thus we have lost the very thing that makes them both special and beautiful.
Can we scale while maintaining public verifiability?
At PISA Research, we are interested in an alternative scaling proposal, off-chain protocols, that simply aims to reduce the network’s load without compromising on public verifiability.
Off-chain is exciting. Users can transact locally amongst themselves instead of sending every transaction to the network. All off-chain transactions retain similar security guarantees as their on-chain counterparts, and the involved users can simply bypass the network’s fees and latency.
There are typically three stages for an off-chain protocol:
- Lock up. All users must deposit coins into the off-chain protocol.
- Progress off-chain. The group of users can transact / execute smart contracts locally amongst themselves.
- Release deposit. Once the users have finished, they can agree to unlock the deposit and send each user their respective new balance.
In this quirky world, the blockchain is re-purposed as a settlement and arbitration network. It is only responsible for resolving disputes that may arise amongst the off-chain users (i.e. one user stops responding).
Concretely, the blockchain enforces the following guarantees if the channel breaks down:
- Balance Security. All users get the coins they deserve.
- Application liveness. The application will always progress.
Thanks to the integrity guarantees provided by the blockchain, off-chain protocols are non-custodial by nature and they ensure an honest user is always protected against a full collusion of all other users.
Flavours of off-chain protocols? We have witnessed two styles of off-chain protocols emerge over the years:
- Off-chain Channels. All users deposit coins and authorise payments/smart contract execution via unanimous consent. Instant finality, rapid, and free.
- Operator-assisted Commit Chains. A non-custodial operator is responsible for co-ordinating payments amongst all users and periodically posting succinct (but binding) commitments of all payments. Eventual finality, rapid, financial motivation to run.
There are several protocols to implement off-chain channels including Spilman, DMC, Lightning, Sprites, Kitsune, Perun, Counterfactual, Magmo and several for operator-assisted commit chains including NOCUST, Plasma Cash, StarkPay.
Generally, the former is useful for small group (<10) of parties, whereas the latter is useful for a substantially large group (1m+) of parties.
Can off-chain protocols interact with each other?
It is easy to envision a world with thousands of channels and commit-chains, users transacting at lightning pace (and potentially for free), without the need to interact with a global blockchain.
What if all off-chain protocols could interact with each other in a trust-free and off-chain manner? Can we bootstrap an off-chain network? Yes!
The fundamental building block for an off-chain network is the humble conditional transfer. It looks pretty silly by itself, but bear with us for a bit.
Conditional transfer. We’ll consider hashed time-locked contracts, but this can be generalised to support ZKCP, Virtual Channels and FairSwap.
We have a sender and the receiver. The sender wants to purchase the pre-image of a hash from the receiver. To begin, the receiver computes h = H(R) and sends h to the sender.
The sender can now set up the conditional transfer:
“If the receiver reveals the pre-image of H before time t, the receiver can claim this 1 coin.”
Once the conditional transfer is set up. The receiver can make one of three decisions:
- No activity. The receiver may not reveal R. Maybe it is OK, the sender is refunded by time t.
- Co-operative. The receiver may share R with the sender off-chain. If all goes well- the condition is removed and receiver gets the 1 coin.
- Dispute. The sender may refuse to remove the condition after receiving R. That is OK, the receiver can simply publish the conditional transfer + R to the blockchain as a dispute. If the dispute is processed before time t, the receiver will get the coins.
The receiver is always guaranteed a payment for revealing the secret R unless they decide not to reveal it.
Synchronise across a path. Thanks to the humble conditional transfer, we can use the fair-exchange protocol to synchronise a single off-chain payment across a path of channels. Let’s consider the following path:
Alice -> Bob -> Caroline → Dave.
Alice wants to pay Dave, via Bob and Caroline in an off-chain and trust-free manner.
All parties participate in a two-step protocol:
- Step up transfer: Dave sends H(R) to Alice. All parties along the path set up conditional transfers.
- Finalise transfer: Dave reveals R to Caroline. All hops reveal R to the previous hop and both parties update their channel to confirm the transfer.
In the ideal case, hashed time-locked contracts are lightning fast, and it works because it achieves the core security property:
- No counter-party risk. For every hop along the route, the intermediary is always guaranteed to fetch coins from the next hop after sending the same quantity of coins to the previous hop.
But in the worst-case (as succinctly presented by Dan Robinson), the conditional transfer can be locked up for an extended period of time and eventually cancelled, for free.
Channel-based networks: probably not for many-to-one payments
Thanks to the humble conditional transfer, we can now build global, off-chain and non-custodial networks. This brings up the question how the respective off-chain protocols, channels and commit-chains, may interact with each other in the future.
Rise of channel-based networks. In 2018, we witnessed the rise of Bitcoin’s Lightning Network and at the time of writing it supports 30k channels.
Generally, there are three types of users on the network:
- Sinks: Users who mostly receive coins on the network.
- Spenders: Users who mostly spend coins on the network.
- Liquidity provider: Users who mostly facilitate bi-directional transfers on the network (and may provide routing duties).
There are little to no issues with spenders or liquidity providers on the network. However, while we envision a channel-based network like Lightning as the cornerstone of a global off-chain network, we claim its role will probably not involve payments for sinks.
Event sales problem. To illustrate the problem for sinks (and many-to-one payment scenarios) on the network, let’s consider an example of an event manager preparing to sell 200 tickets at 1 coin each.
Before the manager can advertise the event, they need to set up an off-chain channel with sufficient capacity (~200 coins) for the sale’s lifetime to accept payments. If the event manager selects BitRefill, it will cost approximately 3% (6 coins)* to open the channel.
*For a 16,000,000 satoshi channel, it costs 485,200 satoshi,~3%.
While the need to pre-allocate collateral and pay up-front before accepting payments is not convenient or natural for most users (especially if there is no guarantee all tickets will be sold), it isn’t the worse problem.
The success of any payment in a channel-based network depends on the customer finding a path to the event manager with sufficient capacity in the right direction.
Why? A hashed time-locked contract doesn’t actually move the coin across the path. It simply re-distributes the balance of every channel to mimic a payment.
Thus to send 1 coin across 4 channel path, the sender in each channel needs a balance of 1 coin to facilitate the payment.
The path-collateral problem has implications for path-finding which is already a well-known problem in the lightning community.
However it is important to consider the quality of the partner’s connection to the channel-based network. If the partner’s channel is not well-connected or continuously well-balanced, there is no guarantee the event manager’s channel can actually receive all 200 payments as the partner’s connection becomes a bottleneck.
Several arguments can be made about how to better support payments to sinks in channel-based networks:
- With better engineering and channel balancing protocols (like Revive and AMP), the partner’s channel will always have sufficient capital to support payments.
- Customers should carefully select their partners and open several smaller channels instead of one super-channel to avoid path-bottlenecks
- Purchasing collateral is reasonable and OK since channels may be long-lived to facilitate thousands of payments.
Instead of designing new protocols / configurations to help alleviate fundamental issues with channel-based networks, can the problems of pre-collateral lockup for the receiver/channel and the potential of a path-bottleneck partner just be eliminated altogether?
Operator-assisted commit-chains are super-promising!
To overcome the limitations posed by a channel-based network for many-to-one payments, we envision most users will rely upon operator-assisted commit chains for payments.
No collateral lock up for operator or receiver. As long as the sender has coins locked into the operator-assisted commit chain, they can send coins to another user in an off-chain manner.
Even better, the coin can virtually move from user A to user B via the operator.
There is also no requirement for the receiver’s signing key to be online to receive a payment and the operator doesn’t require any collateral lock up to operate this service.
It is easy to be afraid (and rightfully so) the network may evolve to some hub-and-spoke model, but we claim the dream of decentralisation is still alive and it is even stronger due to commit-chains.
At a technical level, it is clear anyone (and their dog) can run an operator-assisted commit-chain as their only role is to co-ordinate payments for a fee.
We envision thousands of non-custodial operators for commit chains, coming and going in a permissionless manner, competing to attract users by offering affordably low fees and the best user experience.
An observer may notice a new requirement in the operator model. The event manager and the sender must co-ordinate on which operator-assisted commit chain to use for the payment. Perhaps the event sales page has a list of approved operator, but what if the customer does not have coins with the approved operator?
Channel-based networks for re-balancing liquidity, not payments to sinks.
As we explained above, channel-based networks like Bitcoin’s lightning network are not ideal for many-to-one payments, but they shine and can potentially outcompete any other solution for low-latency re-balancing transfers.
We envision channel-based networks will provide rapid and non-custodial liquidity as coins are moved from one operator to another, and back again.
If a customer wants to move coins from Starkpay to Liquidity Network to Plasma, channel-based networks can accommodate the liquidity transfer at a lightning pace and without counter-party risk.
Off-chain and Non-Custodial Smart Contract Networks
We have only discussed the concept of a global, off-chain and non-custodial payment network, but wasn’t this blog post supposed to be geared towards off-chain and non-custodial smart contract networks?
As we presented at Advancing Bitcoin, non-expressive blockchains restrain our ability to build non-custodial and off-chain payment networks. In Bitcoin, we can’t build operator-assisted commit chains and the current design for lightning channels has caused plenty of problems for watch towers, paying network fees, crash recovery etc. (watch talk for more information)
Why can smart contracts help? At a high level, smart contracts are trusted third parties with public state and their expressiveness helps us build simpler off-chain protocols.
When designing a new protocol, we only need to be concerned with how to program the third party’s algorithm instead of fighting the underlying transaction model (and scripting facility) to force it to do something beyond its will.
While smart contracts provide super-exciting applications, for us it is all about building better and simpler non-custodial protocols.
Thus the pursuit of expressive smart contracts aligns with our goal to build a global, off-chain and non-custodial network.
Goals of PISA Research — What are we going to do?
This brings us back to the initial quote by Satoshi Nakamoto.
Why do we need to trust banks not to debase the currency, to transfer coins on our behalf, and not to run a fractional reserve?
We hope to continue and expand upon Nakamoto’s vision:
PISA Research’s mission is to build and protect global, privacy-preserving, non-custodial and self-enforcing smart contracts networks via off-chain protocols.
While there are several companies building operator-assisted commit chains and channel-based networks — which we hope to aid in development — our goal is to build the final piece of the off-chain vision.
Always online assumption. All off-chain protocols introduce a new assumption that users remain online and fully synchronised with the network to protect their coins:
- Off-chain channels: Users must watch out and respond to malice disputes.
- Operator-assisted commit chains: Users must issue challenges to prove checkpoints as invalid.
Interestingly, in the case of a zkSNARK/STARK commit-chain, while users no longer need to issue challenges for checkpoints, they must remain online to ensure the operator makes the off-chain ledger data publicly available.
Clearly it is unreasonable to assume users (and in most cases their signing key) will remain online to protect themselves.
Thus users can hire PISA, an accountable third party watcher, to help alleviate the always online assumption, for any off-chain protocol.
Is PISA only a single watcher? No.
We plan to build a distributed watching service where k-of-n watchers must agree to watch the off-chain protocol before the job is accepted. While our concrete architecture will be covered in a future blog post, more information about PISA can be found in our paper.
PISA can succeed without a network of watchers? Yes!
We hope a market of watchers will emerge to compete for a customer’s job, but this will only be achieved by the “snowball” effect:
- Watcher Snowball Effect. The first watcher for an off-chain network will win all the profit. A second watcher will eventually emerge and compete for a share of that profit. Eventually a competitive watching network will evolve.
PISA does not rely upon a network of watchers for its success.
We do not plan to build an elaborate commit-chain to facilitate hiring and paying for a watching network — it seems like an unnecessary engineering challenge for the task at hand.
Our goal is to build a reliable and straight-forward watcher for off-chain protocols in both Bitcoin and Ethereum.
PISA Token? We are not against the idea of a PISA token, but there are no plans for a token to help foster watching network.
Simply put, we have not discovered or found an existing token model that makes sense for us (and in general, third party watchers).
How to monetise PISA without a token? The old fashioned way.
PISA is hired by customers to watch off-chain protocols on their behalf. We can succinctly sum it up:
If off-chain networks truly take-off, can you imagine the revenue stream for a well-respected watching service protecting millions (if not billions) of users?
We hope this article sparks fundamental and profound discussions about the direction we are moving as a community.
This is what we, PISA Research, believe off-chain and non-custodial networks may look like in 5, 10 or 20 years.
It will truly be exciting to see what *will* actually emerge and we hope to help spearhead that movement towards real-world adoption.
Thanks to funding from the Ethereum Community Fund, Ethereum Foundation and the Research Institute, we are well-positioned to pursue the dream of non-custodial and off-chain smart contract networks.
After all, we are security-oriented researchers and engineers, we write papers and code.
Acknowledgements. Thanks to the PISA Team — Chris Buckland, Sergi Delgado Segura, Salvatore Ingala, PISA Contributors — Anthony Tsiopoulos and Ali Azam. As well, we thank Andrew Miller and Jeff Coleman for feedback on an early draft, and the collective Off-chain Reading & Research Group.
