[Dev] Sidechain Spike

[pgebheim]

This is for Alex to take a look at what is needed for sharing OI and other information with sidechains like Matic.

[MicahZoltu]

Matic

Matic Phase 2 is (according to their own docs):

a research problem, and it will take time and effort to accomplish a breakthrough here.

Matic Phase 1 (from what I can gather from their docs) is not censorship resistant. In particular, block producers are voted in by stakeholders (there is a paper-style application process) and there is no way to force a withdraw if you are being censored on the Matic chain. This means once your funds are on the Matic chain, your ability to withdraw them is limited to whether the stakeholders (plutocracy) decides to let you withdraw or not. While Ethereum has a similar problem, the market cap of Ethereum is enough bigger than Augur's OI that we can safely ignore it. With Matic, I'm concerned that it would be significantly cheaper to takeover than Augur and thus provides an opportunity to censor (effectively burn) any arbitrary user's assets.

Arbitrum

Arbitrum Slow mode could work for Augur and it would reduce gas costs of all transactions to maybe 50,000 gas or less. Block time would still be Ethereum block time but users could use more competitive gas prices without having to break the bank due to the lower gas costs. Arbitrum slow mode is censorship resistant and cryptographically secure.

Arbitrum Fast mode requires "well known" validators. Specifically, you need some kind of mechanism for keeping trolls out of the validator pool by punishing bad actor validators out-of-band such as via public reputation loss. If we assume that no public figure will voluntarily run a validator, and if they did they are likely to be censored by state actors, then we cannot use Arbitrum in fast mode.

[atvanguard]

Hey @MicahZoltu,

First of all, our white paper is out-dated by far, so happy to answer all the questions you might have. We will be updating it or writing a blog post on our current architecture soon. We have changed the design a lot since and have implemented multiple epic features ✨.

block producers are voted in by stakeholders (there is a paper-style application process)

In our current design, block producers get selected after every 6400 child chain blocks. This duration is referred to as a span. We use a recent Ethereum block hash as a seed to select block producers in current span, but we are actively looking for an alternate mechanism to generate unpredictable, un-biasable and verifiable random seed which doesn’t introduce too much complexity in the system.

there is no way to force a withdraw if you are being censored on the Matic chain

This is incorrect. There is an option (and the most critical part of plasma safety) to exit with an in-flight tx. An in-flight tx means it was either censored or it was included but block data is unavailable. See startExit. It is possible to start an in-flight exit not only from a withdraw tx but also from erc20/721 transfers. See processExitTx.

In addition to this, we also have the in-flight exit functionality for atomic token swaps. See MarketplacePredicate.

The plasma predicate pattern allows one to add censorship resistance and fraud proof against custom state transition support to our Plasma design. The coolest thing about the "predicate" design pattern is that, a dapp developer can write their own contract to support in-flight exits from a particular type of tx that is essential to their dapp - See addPredicate which of course means we piggyback on Ethereum’s PoW security.

[MicahZoltu]

@atvanguard I would love to see tho docs updated, that would help a lot with evaluating Matic as a solution for Augur.

How does the system deal with data availability? Is the assumption that if clients cannot acquire the data then they should do an in-flight exit?

What happens if the client doesn't know their balance (due to data availability issues)? Is there a way to exit with "all of my token X"?

If a block is produced and sealed without its data being available and it never becomes available, what is the recovery process like? This would be a 66% attack where the attacker takes over the network, produces and signs a block, then walks away without sharing the block's data with anyone (so no one can do any merkle proofs for the current head block).

[atvanguard]

Yes, updating docs seems to be a task of paramount importance, it's just that we are moving at a staggering pace 😅

Is the assumption that if clients cannot acquire the data then they should do an in-flight exit?

Yes this is true. Would you happen to know another approach that works better than this?

What happens if the client doesn't know their balance (due to data availability issues)? Is there a way to exit with "all of my token X"?

Yes. We are an account based plasma flavour, so we provide a mechanism to do the same. Details below.

If a block is produced and sealed without its data being available and it never becomes available, what is the recovery process like? This would be a 66% attack where the attacker takes over the network, produces and signs a block, then walks away without sharing the block's data with anyone (so no one can do any merkle proofs for the current head block).

Assumption in plasma is to stop making any more txs if the data is unavailable or your last tx was censored. So let's say you made n (n >= 1)txs on the sidechain. These txs were included in the chain and no fraud occurred in the blocks where these were included. By this time you had t tokens of type X.

When you made n+1th tx, spending let's say T tokens of type X. The data became unavailable. In that case you'd reference nth tx, provide raw n+1th tx and start an exit with t - T tokens of type X on the main chain. This testcase and others in the same file will help.

This is our ethresear.ch post talking about our plasma design in detail.

[MicahZoltu]

Since this doesn't use UTXOs, how do you ensure that a malicious validator set doesn't "double-spend"?

1. Alice creates a transaction where she sends Bob 1 TOKEN and submits it to validators.
2. The 66% hostile malicious validator commits a block to Ethereum with that transaction in it, but does not share the block data.
3. Alice exits using the last committed block.
4. The malicious validator now makes the block available.
5. Bob exits using his balance as of the new last-committed block.

In this scenario either Alice, or Bob, or both may be colluding with the malicious validator. Can the system ensure that 2 TOKENs cannot be withdrawn by Alice & Bob in this scenario (they only had 1 TOKEN between them)?

[atvanguard]

So we also have periodic checkpointing.

1. If Alice is honest, she'll start an in-flight tx from the spent tx. If Bob is honest, he'll start an exit from the same incoming transfer. Bob exits with 1 TOKEN.

2. if Alice is dishonest but hasn't colluded with validators If she starts an exit from a stale state, she'll be challenged by showcasing her latest spend to Bob. Alice's bond will be seized and Bob exits with 1 TOKEN.

3. Alice is dishonest and colluded with validators (data is unavailable and checkpoints are not being made) If there hasn't been a checkpoint for x days (< 7 days), chain we will marked halted and no new checkpoints will be made. In that case, Bob would never be able to withdraw from Alice's spend. Alice exits with 1 TOKEN.

4. Alice is dishonest and colluded with validators (data is unavailable and checkpoints are still being made) Exits (all exits in general), are pushed into a priority queue where priority is the position of the referenced tx. (See referencing nth tx while exiting from n+1th tx case in my last comment). This is case of mass exiting where all users need to exit the chain within 7 days. When that plays out, valid funds will be withdrawn first; then Alice's exit of 1 TOKEN and plasma funds pool would be drained by the time Bob's exit even begins processing.

[MicahZoltu]

Ah, so users of the system need to "check in" once every 7 days to make sure data is available. If they don't, then they run the risk of someone exiting with their funds?

[atvanguard]

Yes! Exactly. The task of watching the chain can be given out to economically incentivised watch towers. Then they can send out a push notification to users, "Please exit with your funds" - This action will be a one touch action from our Matic compliant wallet.

[MicahZoltu]

@atvanguard Has the public documentation for Matic been updated yet to reflect the latest advances?

[joeykrug]

think the spike in the initial task was done w/ oi cash