How to deal with finality on rootchain

[AdityaSripal]

The sidechain must make a judgement on when a transaction is finalized on the rootchain before it includes it into the sidechain state.

Examples:
For a sidechain to spend a deposit it must first determine whether that deposit has been finalized on the rootchain
Potential Solution: Use a finality gadget on the rootchain that sidechain must defer to for finality judgement. If validator includes spend deposit that has not been checkpointed by finality gadget, it is considered malicious.

For a sidechain to delete UTXO as explained in #24 , it must determine when the startExit transaction gets finalized since if the transaction gets reorged, user may try to spend on sidechain instead of resubmitting transaction.
Potential Solution: In this case, it may be better to ignore finality. If validator sees startExit simply delete the UTXO. If transaction gets reorged, user has no recourse but to resubmit transaction.

[liwei00wade]

how to includes deposit tx into the sidechain state?

who do it ?
why ?

[AdityaSripal]

Hello,

Currently, we have not implemented this. The current idea is to not include deposit UTXO's into the sidechain state at all. Instead, if and when someone wants to spend a deposit, they submit a transaction spending Position [0, 0, 0, (deposit nonce)].

The antehandler will then query the rootchain to check that the user has deposited the claimed amount in the deposit nonce position in our deposit mapping and that the transaction is presumed final. If both checks are satisfied, the receiver(s) of the transaction will have new UTXO's included in the sidechain state.

To deal with finality, we will include the block number a deposit was entered and we will have some presumed finality bound (say 30). The antehandler checks that the deposit happened at least 30 blocks ago in this example.

[iantanwx]

Hey Aditya, we are also implementing Plasma with Tendermint. I have much the same thoughts as you on this matter; however, in my experiments, I have found it to generally be favourable to implement an Oracle that is updated with the root chain's state. This way, if you have seen my proposal for the ProposeTx ABCI method, we don't have to rely on any kind of asynchrony within the consensus routine at all; the daemon can simply be a go routine that polls the root chain, and decides (as you say, using a finality gadget), when to push the deposit block onto the queue.

[AdityaSripal]

Hey @iantanwx , I did see your ProposeTx proposal. It would definitely be a nice feature to have! Thanks for sharing your experience in dealing with this issue. Could you expand on why having a seperate Oracle daemon is preferrable to having the tm consensus routine poll the rootchain in your experience?

Are you guys planning to eventually support multiple validators? If so, how do you plan to deal with this issue in that context? Multiple validators running multiple oracle daemons may be monitoring different versions of the Ethereum blockchain and thus consensus would be temporarily broken until all oracle daemons converge on a single rootchain history.

[iantanwx]

@AdityaSripal I think the only difference between using a daemon and polling in say, BeginBlock, would be that BeginBlock wouldn't need to wait on the request to the Ethereum node. If all daemons rely on a single full node (say, one running behind an AWS EIP) for history, those Ethereum blocks can be pushed onto a buffered channel (one per validator), and popped off synchronously. In the event that the daemon cannot reach the Ethereum, then the channel is just empty and we can skip processing deposits for that block. That should not result in inconsistent root chain history, if all the validators have daemons running against only one node.

My main concern with using BeginBlock is inconsistent behaviour based on the network conditions at that particular point. I don't think it's a huge deal, but I would rather have this behaviour than resort to a time out or something along those lines. I don't think it changes the semantics at all, just ensures that none of the ABCI methods will ever be subject to the vagaries of a network request. That being said, I could be missing something, and I would love to hear more from you guys!

[AdityaSripal]

@iantanwx got it. IF every validator uses the same oracle node, then this isn't a problem. That would definitely work, and as you said, it would alleviate a lot of asynchronous headache.

The question then would be who owns and controls this oracle daemon, and whether they can be trusted. If instead of relying on an AWS geth full node, all the plasma validators could rely on peggy:

https://github.com/cosmos/peggy

Then, plasma validators would be relying on the Cosmos Hub validator set to act as an oracle for the Ethereum main chain along with getting a finality gadget for free. This would also solve the problem of a malicious oracle, because I personally think the Cosmos Hub validator set will be sufficiently incentivized to act honestly.

[colin-axner]

If the oracle node is acting as a finality gadget for deposits and exits, I don't see why it can't be its own chain with the purpose of coming to consensus on finalized deposits and exits. It would have the same validator set as the plasma sidechain. Since each validator on this oracle chain needs to run their own geth full node, coming to consensus on deposits and exits may take slightly longer as each validator would need queue up any deposits or exits they notice on the rootchain. Then any deposits and exits agreed upon would be signed by > 66% of validators and when a deposit or exit is included or referenced on the sidechain, all validators can reference a finalized block from the oracle chain that is signed by the same validators. The delay of finalizing deposits and exits are justified in my opinion, as it would avoid any issues with reorgs and entering and exiting a plasma chain already takes a bit of time.

Though I like the idea of using the Cosmos Hub as an oracle, I think it's best to provide alternative approaches so dapps are not forced to be dependent on an entirely different ecosystem.

[iantanwx]

@AdityaSripal @colin-axner great ideas, thanks for the help! I'm of the view that delaying the finalisation of deposits and exits (or, really, any other event that needs to be included in the sidechain) can be delayed in return for better guarantees as well.

I think what may be better is to develop an x/oracle type of thing, that provides an interface to different sources for blockchain history. I'm not very familiar with peggy, since the app seems to be under heavy development at the moment. It may not be necessary to use Cosmos Hub? It could be possible to simply run your own peggy oracle chain. I'll report back once I've actually attempted something like that. I love the idea of decentralising the oracle as well, though.

[AdityaSripal]

Seems like colin's idea is just running peggy with the plasma validator set rather than the Cosmos Hub validator set which works perfectly fine.

@iantanwx definitely keep us posted!

[colin-axner]

This is resolved in current implementation of PoA. For non PoA, since we are isolating notation of TM blocks and plasma blocks, we can add in deposit and exit msgs, that would update plasma store to reflect utxo existence. This would not increment plasma block number (don't wanna submit a header for acknowledging that a deposit occurred onchain). Basically we can integrate peggy into this chain instead of running two separate TM chains.

For PoA, this improvement would allow deposits to be processed without pinging the rootchain contract. Not sure we can say the same about exits since we might be required to always check for an ancestors exit?