peaceBridge MVP launch

It’s been almost a year since the conception of peaceBridge. A few detours and hiccups have only made us better: we’re excited to announce the peaceBridge MVP launch on the Kovan (ETH) and Kotti (ETC) testnets. The top three reasons we’re excited about this:

1. This is the first cross-chain solution, to our knowledge, that incorporates the challenge functionality into the UI. This brings opaque security mechanisms to the front and centre of users’ consciousness, encouraging engaged and informed users. In future iterations, always-online watchtower services can also take on the role of automated challenging.
2. This solution takes a “decentralised centralisation” approach: meaning that even though it derives security guarantees from the incentives of a staked operator, anyone can choose be their own operator. Furthermore, every user provides their own liquidity and mints their own tokens, unlike the WETC TokenBridge.
3. No data availability issues: unlike relay-based bridges, there is no way for a single party to censor or withhold data about deposits, transfers, or withdraws happening on either chain. Transactions are fully logged on each respective chain. (Of course, this also means that gas costs apply as per usual — this is not a scalability solution.)

Cross-chain interoperability is a large and fascinating design space, and there is no one-size-fits-all approach. We invite you to test the peaceBridge, criticise it, break it, fork it, and make it better.

User flow: the happy case

Step 1: Mint (foreign chain)

We begin by minting a token on the foreign chain with a chosen denomination on the foreign chain. While it may seem counterintuitive to mint before collateralising, this prevents the attack vector where someone else prematurely claims your deposit (before you get the chance to mint).

Step 2: Deposit (home chain)

We then deposit the same amount in the native currency of the home chain, taking care to reference specifically the tokenId we had minted. Of course, somebody else could make a deposit for your token; but since you’d still own it on the foreign chain, and would be able to claim their stray deposit, that would be a very weird flex indeed.

Step 3: Transfers (foreign chain)

We can now proceed to transfer our token on the foreign chain as per usual. When accepting a token from someone, the recipient can easily verify that a corresponding deposit for that token exists on the home chain.

The operator is also required to sign off on each transfer. This prevents the cross-chain version of the double-spending attack, where:

• Alice transfers 10 ETCx to Bob on the foreign chain (Ethereum)
• Alice privately signs a transfer of 10 ETCx to Charlie, without publishing it to the foreign chain
• Charlie sends this fake transfer to the home chain, which doesn’t know any better

Here, if the operator had been required to sign both the real and fake transfers, then a double spend would have been easy to detect: there must not be more than one transfer signed by the operator at each nonce.

Step 4: Withdraw (foreign chain)

We sign a transaction indicating our desire to withdraw , and send it to the foreign chain. (We can also not publicly send it; really what’s important is that we sign it, and address it to the TokenContract ).

Step 5: Withdraw (home chain)

We start a withdraw on the home chain, making sure to submit with it our withdraw request on the foreign chain. This allows us to verify on the home chain that the person who is claiming custody of the token is the same one who is trying to withdraw it.

It is worth understanding the withdraw function in more detail. It requests the following transactions from the foreign chain:

• withdraw tx (as explained in Step 4);
• transfer tx, transferring custody of the token to whoever signed the foreign withdraw ; and
• operatorApprove tx, a signed message from the operator approving the transfer .

Essentially, this is a series of signature checks to make sure that the withdraw request is at least self-consistent. This makes it easy to later prove an external contradiction (i.e. double-sign).

Step 6: Claim (home chain)

If the withdraw was honest, or if nobody challenges it, then after the elapsed challenge period (currently set at 10 minutes), we can withdraw our deposit on the home chain.

Fraud and challenges

peaceBridge MVP is, to our knowledge, the first project to incorporate interactive challenge mechanisms into the UI. We realise that users cannot be always-online; however, we want users to transparently understand the processes underlying their security.

Note that all these challenges are happening on the home chain, because that’s where users must withdraw their deposits.

Type 1: Fraudulent withdrawal with past custody

Alice transfers 10 ETCx to Bob. Alice then fraudlently tries to withdraw 10 ETCx, even though she no longer owns it.

In response, Bob (or anyone) can successfully cancel this withdraw using challengeWithFutureCustody . Here, he provides a signed transfer from Alice to Bob at the next immediate nonce.

Type 2: Fraudulent withdrawal with future custody (i.e. “transfer out of nowhere”)

Alice colludes with the Custodian to sign a transfer of the token to her custody, at a nonce far in the future.

In response, anyone can initiateChallengeWithPastCustody by providing a transfer from the last proven nonce (from the home chain’s worldview, this is the transfer at nonce 0). The onus is then on Alice to prove a chain of custody from there to her claimed nonce.

Clearly, a griefing vector here would be to troll every withdraw attempt by requesting the withdrawer submit a chain of custody. That’s why we require the initiator of this challenge to put down a stake.

Future work

• Watchtowers: currently, users are alerted to fraudulent transfers and can initiate challenges via the UI. We want to also provide always-online subscription services that automate challenging for users.
• Defragmentation: currently, transfers must be made and signed by changing non-fungible token (NFT) ownership. We want to break down NFTs into arbitrary denominations and still retain the security of our signature scheme. We’re talking with Plasma Chamber to learn about their defragmentation solution.
• Cryptoeconomic adjustments: we’ve currently set stakes for challenges at just the “cost price” of successfully responding to the challenge. Though we love reasoning about cryptoeconomics, it is far from our expertise, and we would love to discuss better schemes with anyone interested.