XRouter’s monetisation system: a design

XRouter, the first “blockchain router,” enables parties on one blockchain (or on no blockchain) to interact with virtually any blockchain in existence, without hosting a single chain locally, and without having to trust its peers or any intermediary. It does so via SPV proofs whose security assumptions are significantly different from typical SPV proofs.

This nifty interchain tool works rather well in its current state, but it would be advantageous if it could also support similarly decentralized (micro-) payments for various interactions. For example, perhaps a dapp would need to request computationally intensive chain data, or perhaps it needs to make a high volume of simple or cheap queries, the volume of which would be burdensome to its peers. Perhaps Bitcoin Core is effectively disabling support for SPV proofs and “light wallets,” and wallet developers are wondering how they might avoid trusting a central server. Or perhaps Bitcoin (or other networks) lack an incentive to run full nodes, the node count is shrinking, and a method of rewarding nodes would reverse the trend. XRouter permits a unique, inherently scalable, and monetisable approach to these problems, and by enabling off-chain proofs of chain state, it can help blockchain ecosystems to scale.

The interchain future, where full nodes thrive on SPV proofs.

Available mechanisms

Several mechanisms are available that appear amenable to use in XRouter, including ZK-starks, atomic swaps (specifically where one party swaps a digital good, not a coin), and payment channels. Payment channels appear particularly advantageous in this context for their speed, their relative simplicity, their support for micropayments and subscription-style services, and for the broad understanding of their nature on the part of developers and the crypto-leaning public (largely due to the mindshare of the lightning network).

Objective

Due to the above, this post is largely a design of payment channels to monetise XRouter requests, although in the next section I give consideration to areas where other mechanisms are required in order for XRouter to handle known use cases. This blog culminates in a protocol with scripts (unvalidated!) for Bitcoin and related coins.

To define the design objective, XRouter requires a mechanism to enable payments from consumers of a given interchain service to providers of that service; moreover, since the interchain is a p2p network of untrusted peers, this mechanism must be “trustless,” in the sense that it will not be required to trust one’s counterparty to act honestly in order to do business with them. This is especially desirable because a suitable mechanism would not only support doing business over the interchain, but in virtue of its trustlessness, I believe that it opens up radical new possibilities for doing business in general.

Sequence

Several behaviours and potential service types are possible over XRouter. What follows is a high-level sequence that maps the service types in which payment would feature — many of which are amenable to the use of payment channels.

A flow diagram is provided for clarity.

Steps:

1. XRouter client (henceforth, the “consumer” of a service) makes a request (e.g. xrSendTransaction ETH [tx hex]).
2. The service node(s) that execute the request (henceforth the “provider” of a service) sends its response to the consumer.

• a. Monetising a call is at the discretion of each service node. If it requires a payment, move to 2b.
• b. Some services cost nontrivial amounts and cannot be paid for in several micropayment steps. Other services involve nontrivial risk for other reasons (e.g. reveal of personal information or other data that cannot be re-concealed after revealing it). Such cases are better suited to an atomic swap transaction, since it removes counterparty risk.
• c. Services that do not carry the requirements in (2b) stand to benefit from the speed and low cost of payment channels, and may move to step 3.
• d. In the case of decentralized services (e.g services deliverable by any node on a p2p network), before requesting a service, the consumer will typically need to ascertain “trustlessly” whether the provider is honest or whether the provider truly offers the digital good it purports to offer. Interchain service providers may support this by enabling consumers to prove in zero knowledge the legitimacy of the service offered. This can be supplied to the consumer out of band.

3. Consumer and provider set up a payment channel.

• The channel is required to be funded by some number of coins. This amount can be expected to vary from service to service (and from service node to service node). XRouter should aim to remain agnostic as to specific requirements. I suggest implementing a channelFundAmount request, made during channel setup, and a subsequent check on-chain.

4. Consumer and provider create an update transaction (see the Protocol section below) committing funds to the provider.

• a. Depending on the context, this may be payment in full for the service, or an initial, smaller, “deposit” commitment.
• b. Depending on the context, this may be before or after the service is delivered.
• c. Where the service is delivered after payment (e.g. where the provider is a traditional company using XCloud to deliver its service, and is vulnerable to tarnishing its reputation if it fails to deliver), then consumers can reasonably be expected to trust it to behave honestly and can thus make payment in advance.
• d. Where the provider first delivers the service, and then requests payment afterwards (e.g. if its business model is a subscription service that involves repeated payments), its business is not put at risk by offering to deliver before receiving payment, because the consumer only derives value from the service by using it repeatedly. As such, providing a service before payment amounts to a “try before you buy” sales strategy. The provider may thus safely request payment in many stages, delivering before payment at each stage.
• e. Where the service is delivered before payment and its delivery is not locally provable by the consumer (e.g. committing a transaction to some chain not hosted locally), the consumer may first check, before making payment, the provider’s on-chain execution of the service by querying other service nodes and constructing an SPV proof from their responses.
• e-i. In some cases (e.g. for computationally expensive requests), service nodes may require payment for this, in which case a further payment channel may be required.

5. Consumer and provider close the channel as per the Protocol.

Rationale for the protocol in the next section

Design criteria

• While payment channels retain the traditional (i.e. trust-laden) property that if one party receives their counterparty’s goods (or money) before releasing its own, then it may costlessly grief the counterparty. However, with payment channels, the potential for griefing can be limited, by design, to a trivial number of coins (depending on use case, this could vary considerably, e.g. $0.0001 < x < ~$3) because the party who parts with goods or coins first need only risk the smallest value increment, after which both parties may proceed with the exchange in similarly tiny increments, essentially partitioning risk into harmlessly small segments.
• I have no direct concern for developing a scalability solution, because this is not a blockchain engineering context. (We just want trustless micropayments.)
• No cross-channel settlement (e.g. Lightning) is required, since in interchain contexts, there is an unknown number of chains, so it is not possible to discover all the IOUs (and potential liquidity bottlenecks). As such, if one were to support cross-channel settlement, users would be exposed to an unquantifiable and unmitigated risk of locking up funds.
• Desirable properties are: speed, minimal collateral requirements, low cost, predictable settlement behaviour, very broad interoperability (e.g. no novel opcodes).

Significant properties of various channel designs

• CLTV channels: parties trustlessly agree to modify an unbroadcast CLTV transaction prior to nlocktime maturation.
• Poon-Dryja channels: parties trustlessly agree to modify an unbroadcast segwit 2-of-2 multisig transaction.
• Decker-Wattenhofer channels: parties agree to create new, unbroadcast “invalidation” transactions which modify the amount in an output funding either of a pair of channels, and which invalidate a prior invalidation transaction by having a lower nSequence value. Trust is eliminated through each party possessing a signed, unbroadcast “kickoff” transaction that commits to waiting until nSequence maturation.
• Eltoo channels: parties agree both to new, unbroadcast “update” transactions and new “settlement” transactions (which are spent by the new update transaction). Any new update transaction may spend any earlier update transaction, making it pointless to broadcast earlier ones.
• Ethereum state channels: R&D on Ethereum, led by Magmo and Counterfactual, has converged on a generalised state channel design with semantics akin to CLTV channels. This effort is called the State Channels Project. The code is available at https://github.com/statechannels. It seems to be good work, with sound engineering of the setup, messaging, and UX of state channels.

Known limitations

CLTV channels have

• a finite lifetime, requiring both extra messaging for each setup sequence,
• and that suitable checks be built to close channels prior to nlocktime.
• XRouter services that would continue past nlocktime require the additional complexity of closing the old channel and opening a new channel.
• Finally, in the event of dispute, funds can only be settled after nlocktime maturation, a ‘punishment” not necessary in some other designs.

Poon-Dryja channels are:

• limited to chains that support segwit.
• like CLTV channels, they require a punishment branch in the commitment transaction.

Decker-Wattenhofer channels (see also this related paper):

• impose a significant “punishment” in the event of dispute: a long wait time if a channel is closed by one party rather than both parties.
• Additionally, they are complex, requiring the creation — and potentially the broadcasting — of many transactions.

Eltoo channels:

• require the SIGHASH_ANYPREVOUT and/or ANYPREVOUTANYSCRIPT opcodes, which have yet to be introduced to Bitcoin (and elsewhere)
• This is expected to ship soon, along with the taproot update.
• No other coins will support this, at least initially (though adoption can be expected, as with SegWit). In practice, general support for new opcodes across the blockchain ecosystem takes several years.

(Partial) overview of known failure modes of the various channel designs, to ensure that XRouter isn’t limited in ways significant to any of its anticipated use-cases.

CLTV channels:

• Depending on implementation, either the consumer (snode client) is able to evade paying for the first tranche of data provided by the provider (snode), or the snode is able to receive payment without providing data.
• In both the above cases, the exploit comes at the cost of locking up the consumer’s funds until nlocktime.
• The reason for still considering the feasibility of a channel-based approach is that there is only the potential for a very small loss of coins and/or unpaid service, while, in contrast, the provider loses a repeat customer (on the assumption that opening a channel is essentially like signing up to a subscription service).
• If a provider goes offline before and during nlocktime maturation, the consumer can claim back their funds.

Poon-Dryja channels:

• Accidentally using old state results in loss of funds

Decker-Wattenhofer channels:

• Accidentally using old state results in loss of funds
• Wait times in the event of dispute are long (potentially blocking certain use cases)

Eltoo channels

• No relevant failure modes were found, provided one uses SIGHASH_ANYPREVOUT rather than the NOINPUT opcode originally specified.

Outcome

A CLTV-type payment channel is recommended, for its broad interoperability, its relative simplicity, and the absence of known unworkable shortcomings.

Protocol

For Bitcoin and related coins

In the following protocol sequence, a Blocknet service node is the service provider and an XRouter client (e.g. Blocknet wallet or standalone XRouter library) is the service consumer.

Script suggestions are provided. Note: scripts have not been validated, so do not count on their security or correctness.

1. Consumer creates a public key (K1) from private key P1, and requests a public key from the Provider (K2), derived from private key P2.
2. Provider sends K2 to Consumer.
3. Consumer creates and signs but does not broadcast a bail-in transaction (T1) that sets up a payment that, in order to be spent, requires signatures from both P1 and P2. Alternatively, T1 may be spent after a timelock expires by signing using P1.
   ##output should be a P2SH transaction to a hash of a serialised version of the following:

OP_IF
[timelock block height] CHECKLOCKTIMEVERIFY OP_DROP OP_DUP
OP_HASH160 [Hash160(pubkey K1)]
OP_EQUALVERIFY OP_CHECKSIG

OP_ELSE
OP_2 [Hash160(pubkey K1)] [Hash160(pubkey K2)] OP_2
OP_CHECKMULTISIG
OP_ENDIF
4. Consumer creates a refund transaction (T2) that spends T1 back to itself. Due to T1’s timelock, it is unspendable for some time (e.g. 3 hours), but the Consumer may broadcast this at any time after the timelock expires and have the network accept it as valid.
   ## scriptsig
OP_1 [signature from P1] [pubkey K1] OP_1 {serialized script of T1}
5. The Consumer broadcasts T1. This commits the Consumer’s coins to the channel.
6. The Consumer then creates an update transaction (T3) which spends T1 upon signature by both Consumer and Provider. It has two outputs, K1 and K2. The Consumer signs T3 and provides the transaction and signature to the Provider.
   ##prevoutscript
OP_HASH160 [HASH160 of serialised T1] OP_EQUAL

##scriptsig
[signature from P1] [signature from P2] OP_2 [pubkey K1] [pubkey K2] OP_2 OP_CHECKMULTISIG {serialised script of T1}
7. The Provider verifies the output to K2 is of the expected size, verifies the client’s provided signature is correct, signs T3 and sends it to the Consumer.
   This process iterates, so that T3 may go through several unbroadcast versions. Its starting version allocates all coins to K1 (that is, it is like T2 except that it is not time locked), and progressively allocates more coins to K2.)
   Version updates to T3 continue to be made until either service delivery is complete, or until the timelock is near. In either case, either party may broadcast its most recent validly-signed version of T3, closing the channel.
   In the event that the Provider disappears or ceases providing its service early, then the Consumer may sign and broadcast T2 after the timelock expires and receive all its coins back.

For Ethereum

No (low-level) work appears to be required. One may simply use https://github.com/statechannels/monorepo

Documentation is available at https://protocol.statechannels.org/docs/state-channels/overview