Introducing OUTPACE: Off-Chain Unidirectional Trustless Payment Channels.

Back in 2018, we wrote about off-chain event aggregation, which was the backbone of the AdEx v3 protocol.

With the AdEx v4 protocol, we’re introducing OUTPACE: Off-chain Unidirectional Trustless PAyment ChannEls.

What are payment channels and why are they great for AdEx?

Payment channels refers to a set of techniques/methods for enabling multiple payments between parties without committing each payment to the blockchain.

Payment channels are one of the most popular and proven forms of Layer 2 scaling and are used in projects like the Lightning Network, Raiden, Connext, Spankchain and Funfair, just to name a few.

For AdEx, using payment channels has a few important benefits.

Firstly, it allows us to minimize the number of on-chain transactions, and that’s is a huge UX improvement. In the v4 version of our protocol, the only on-chain transactions that you need are opening a campaign (as an advertiser) and withdrawing your earnings (as a publisher).

Secondly, because making payments does not incur any extra fees, we can use micropayments for each individual impression (or any other type of payable event).

This means publishers have a guarantee they can withdraw their revenue at any given time, unlike traditional systems where you can only withdraw your earnings for set, usually long periods, and/or only if you reach a certain threshold.

But most importantly, since the payments are per impression, this eliminates any possibility that an advertiser would cheat a publisher out of their earnings.

What are the benefits of OUTPACE?

OUTPACE is inspired by previous research, such as the Lightning Network and Perun, however it’s different in two major ways:

1. It’s strictly unidirectional, which eliminates the need for watchtowers and complex exit strategies; and
2. It allows multiple parties to be paid from a single channel (one-to-many).

No challenge periods or watchtowers

In bidirectional payment channels, if Alice sends 1 ETH to Bob, but Bob sends 0.5 ETH back, Bob can cheat by broadcasting an older version of the state (balance sheet) to the blockchain, in which he still has the whole 1 ETH.

To eliminate this issue, you usually need something called a challenge period. In practice, this means that if Bob submitted the older version of the state, he wouldn’t be able to withdraw immediately, but rather after the challenge period has ended. In this period, Alice can submit the newer state (where Bob has 0.5 ETH less). Each state is sequentially numbered, so that the on-chain contract can know whether the state is actually newer.

Another caveat to this is that it requires the so-called “watchtowers”: software systems that have to be constantly online and watch for fraud attempts. While this usually works, a watchtower going offline could have disastrous consequences.

Now, imagine a channel in which Alice can send funds to Bob, but Bob can’t send funds back to Alice. There is one possible state transition: Alice’s balance decreases, and Bob’s increases.

If Bob broadcasts an older state, they will only hurt themselves. But wait, can’t Alice broadcast an older state and therefore pay Bob less?

In OUTPACE, Alice’s funds are locked up until the channel expires. Once this happens, they can get their remaining funds back.

However, Bob can withdraw at any time using any state, as many times as they want. This is OK, since at every withdraw, we just need to subtract the amount they previously withdrew.

To recap, the unidirectional property in OUTPACE allows earning parties to withdraw immediately at any time, and a lot of the implementation complexity of regular payment channels is avoided, therefore helping the reliability/stability of the system.

The trust model in a one-to-many setup

In OUTPACE, rather than having one recipient of the funds, we have many. This is achieved by using a merkle tree of all of the balances (we often call it a balance tree).

However, the traditional trust model of payment channels dictates that funds are locked up on-chain by a 2/2 multisig controlled by the two participating parties.

Since the receiving parties in OUTPACE are not defined at the time of the channel creation, we can’t use the same model. We have a separate concept of “validators”, which are the parties that control the on-chain multisig.

Usually, this works by having a “leader” validator, who should be the same entity that funded the channel, and will propose new states, and a “follower” validator, who’s responsibility is signing new proposed states as long as they adhere to the unidirectionality rules.

There is additional trust implied in this: if you’re a receiving party, you need to be confident that the follower will act in your interest. This works perfectly for AdEx, where the leader is the advertiser-side platform and the follower is the publisher-side platform.

It’s important to point out that the “follower” validator is not a custodian: at any point, every receiving party has access to the latest signed state that guarantees they will be able to withdraw their earnings on-chain.

You can read more about this in the “Trust implications” section of the AdEx protocol documentation.

The advantages of one-to-many

If we used a 1–to-1 setup, each advertiser would have to open a payment channel to each and every publisher they want to interact with. Keep in mind that opening a channel means locking up funds on-chain; this leads to a significantly worse user experience, and requires more on-chain transactions that would lock up funds.

Alternatively, they’d use hubs, but this just shifts the same issues on to the hub itself. Plus, for this to work, there have to be proper incentives to operate a hub — which might mean adding considerable fees to the system.

A one-to-many system mitigates all of those issues and makes improves UX: the advertiser only needs to open a channel when they open a campaign, and never worry about it again.

Also, since we’re talking about funds that they are locking up anyway, they don’t even need to know what’s happening under the hood: they are just depositing their campaign funds into the platform, and they don’t even need to know what a payment channel or a blockchain is.

Finally, this allows any publisher to jump on board and start earning at any time — again, without even having to know what a payment channel is!

Is this only for Ethereum?

Absolutely not! OUTPACE was designed to be blockchain-agnostic, and you can implement it on pretty much any blockchain that supports smart contracts, or even a bitcoin-style UTXO/scripts model.

Currently, there are implementations for Ethereum and Substrate/Polkadot.

Is this only useful for AdEx?

Again: absolutely not! While OUTPACE is a great fit for AdEx, we believe it can be used for any other use case that requires micropayments and can benefit from a unidirectional one-to-many interaction.

For example, OUTPACE can be very useful for a bounty network, where one entity would continuously distribute bounties to various other parties.

It’s also possible to interleave several OUTPACE channels together (also called “netting”) in a way that a micropayment will be atomic across a few channels, allowing more complex use cases, for example a DEX (pun intended).

Additional reading

There is more documentation available here: https://github.com/AmbireTech/adex-protocol

Furthermore, we’ve already rolled out the AdEx validator stack, which is the first implementation of the off-chain parts of OUTPACE.

There are going to be follow up posts as well, going into more detail and looking into potential use cases.

Interested in AdEx? Follow us:
X (Twitter) | Telegram | Reddit | Facebook | LinkedIn | Discord