-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to deal with finality on rootchain #36
Comments
how to includes deposit tx into the sidechain state? who do it ? |
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. |
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 |
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. |
@AdityaSripal I think the only difference between using a daemon and polling in say, My main concern with using |
@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. |
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. |
@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 |
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! |
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? |
1.) Deposits entirely represented on the rootchain and exited/finalized separately from transactions 2.) Removed BytesUtil 3.) txBytes include deposit nonce 4.) Confirm signatures are presents and tests provide good coverage. More will be added to cover require branches. 5.) General refactors in the contract and libraries fixes #57 fixes #36
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.
The text was updated successfully, but these errors were encountered: