# Kintsugi - Decentralising ArcPay

## The Problem

ArcPay as described [here](https://ethresear.ch/t/arcpay-a-trustless-validium/16334) is a centralised payments validium. It achieves most of the properties associated with decentralisation such as censorship resistance and self custody, but it doesn't inherit robustness.

Decentralised systems are robust to outside pressure, including state level actors. If we want to build a system that ensures the financial rights of its users no matter who is in power, we have to make it robust as well. In practice, teams who try to implement ArcPay as described in the post above will probably run into legal issues, as the rights they offer users will conflict with financial regulations designed for an earlier era. In reality, those teams will be forced to weaken the guarantees in ArcPay's original design, and the effect of the project will be far less profound.

ArcPay's scalability, low fees, and instant transactions are quite tied into its centralised design. However, there may be a way to decentralise it such that all those properties are maintained.

## Kintsugi

ArcPay's innovation was figuring out how to keep user's funds safe even if the system breaks down and goes offline. We will consider a new system called Kintsugi consisting of shards, each of which is essentially an ArcPay operator. The shards are interoperable and work together as a whole, and using ArcPay's successor mechanism, can be put back together when one shard is broken.

### Disjointness

Each shard maintains a disjoint set of coins from the other shards. When a user wants to mint new coins on Katsugi, they specify the shard that will steward the coins, and send them to a smart contract which holds all the funds in all the shards.

A Katsugi shard must post a SNARKs to update its state, so we know that all the coins on the shard belong to their rightful owner. When a shard breaks, it it put back together again using the ArcPay claiming process, and some successor takes control of the shard.

This works fine on its own, but causes problems when we add interoperability between shards.

### Bridging

Suppose we have two shards and they contain disjoint coins. This actually works fine if the shards aren't interoperable - if there's a problem for one shard it doesn't affect the other. However, we want the shards to interoperate so that the network is robustly decentalised, scales with nodes added, and has a simple user experience.

To bridge funds we can send them to a special bridging address in the shard's Merkle tree. Suppose we have two shards and a user wants to send money from shard 1 to shard 2. The user will send the coins into the bridging address in shard 1 where the funds are destined for shard 2. Once the funds are in the bridging address they can't be moved on shard 1. Then the user can ask for an ownership proof showing that they control the funds in the 1->2 bridging address.

Then the user goes to shard 2 and proves that they have control over some funds in the 1->2 bridging address, and shard 2 is able to take control over those funds. Note, if the user controlled the coins `[1,5]` on shard 1 they would still control `[1,5]` on shard 2.

This bridging mechanism has the advantage of being able to be done completely offchain, while also being able to be forced onchain. It's worth noting that the user can bridge their funds between two shards even if neither shard is cooperating.

### Succession

Suppose shard 2 shuts down. Operators will bid to take control over the succession procedure, and users will provide their ownership proofs to a succesor or post them on L1.

However, once succession takes place, if we weren't able to recover the full state of shard 2, there is no guarantee that the shards are consistent. Perhaps shard 2 claims that it has stewardship over funds that actually belong to shard 1. Note, though, that shard 1 only takes stewardship over coins that it truly has the right to steward, since this has been guaranteed by SNARKs up until now. We say that shard 1 is in harmony with the L1.

### Harmony

If a shard is in harmony it can immediately process any withdrawals. However, if a shard is dissonant (not in harmony with L1), then any withdrawal must prove that no other shard stewards those same coins. To do this, the main data structure of each shard should be an accumulator that supports non-membership like an indexed Merkle tree. Also, to bridge funds from a dissonant shard to a harmonious shard, the user must prove that no other shard stewards those coins.

So what kind of ownership guarantees does a user have on a dissonant shard? Honest claimants have the same guarantees as on ArcPay - if you know that you didn't bridge your funds out of the shard before it shutdown, you know that no one else can claim to be the steward. However, if you receive funds on a dissonant shard, you don't know if you're actually the true owner until you see proof that there are no other stewards.

Consider the case where Alice has funds on shard 1, bridges them to shard 2, then shard 1 shuts down and she manages to claim them on shard 1 during the succession process. The true steward of Alice's funds is shard 1's, and anyone receiving payments from her there knows that they truly own the funds as shard 1 is in harmony. However, if Alice sends funds to Bob on shard 2, when Bob tries to withdraw them or move them to another shard he will fail, as he doesn't really own them.

### Retuning

A dissonant shard can retune and become harmonious again. It can do this all at once or leaf by leaf. We split each shard's Merkle tree into two parts, the harmonious and the dissonant. The funds can be retuned (moved from the dissonant to the. harmonious part) if it's proven that this shard is the true steward. Once a leaf is retuned, it can be withdrawn or bridged to another shard.

We can get these proofs trustlessly by forcing the other shards to return proofs of non-stewardship of particular coins onchain. The new operator of a shard has every incentive to retune their leaves, as they cannot earn fees on transactions otherwise. If the operator tries some kind of ransom attack, the user can do all the forcing themselves.

### Topology

Retuning could be expensive if there are many possible stewards. A shard that wants to guarantee that its users will be able to cheaply recover their funds in case of shutdown may want to limit the number of shards that it can bridge to.

## Very Sad Paths

### Failed Succession

In ArcPay, you could exit to L1 during shutdown, but in Katsugi, you can only withdraw if your funds are proven to be non-dissonant. What happens if no one takes up the responsibility of being the successor, and what happens if all shards fail?

If no one takes the successor role, the claiming process must happen onchain and, as usual we end up with a Merkle tree of the new owners. This new shard is now a stub - it won't process any more transactions. To withdraw or bridge from the stub you still have to prove that your funds are harmonious.

### Multi Failure

What if two shards fail and they both have stewarded the same funds but no other shards have. How can the others determine who the true steward is? We probably have to change the retuning test from "show that no harmonious shard claims stewardship over these coins" to “make sure that there is no demonstrated other harmonious steward, and that all other dissonant stweards rely on a later origin, where the origin is the last evidence of harmonious ownership.”

What happens if all shards fail and no acts as the successor? Can we do a shutdown procedure across all shards that can determine the true owners?