Implementing Deposit Blocks

[colin-axner]

The child chain is responsible for taking note of deposit blocks on the rootchain. Here's one way I think we could do this.

Treat deposits like regular SpendMsg's as we do now. Let them go to the mempool, but in the mempool create a custom prioritization, giving messages formed as a deposit message top priority (might not be necessary if the core can quickly search the mempool). Tendermint core would then search for the correct deposit to propose as the next block (as ordered by the root chain).

This implementation would require adding a geth node to interact with tendermint core as well as adding in logic to handle when/how to form a deposit block. We would somehow need to add functionality for our ante handler to also check the root contract if it receives a deposit message.

Thoughts?

[legengliu]

Would we need to fork Tendermint Core to be able to do this?

Sunny mentioned that "choosing which tx from mempool to use is currently just first in first out, but it can be modified to take them in order of highest fee". I suppose in this case, instead of modifying priority to highest fee, we do as you say and give deposit messages top priority. On that note, what incentive would a Tendermint validator have to give top priority to deposit messages when there are other Txs in the mempool with higher fees? Would deposit messages also require a fee then?

[colin-axner]

Yes I believe we would need to fork tendermint to do this.

Good question. Including a fee for deposit will probably be a use case specific design and I would suggest letting whoever uses our child chain add that implementation. One incentive for submitting a deposit block is otherwise the child chain would be out of sync with the root chain and users would think the validator is trying to be malicious. Not including a depsosit block may actually be rejected by other validators in non PoA.

Another way of doing this that I thought of was allowing validators to process only non deposit blocks. This would work fine with the implementation I suggested in issue #10 . However, the height of a block on a child chain and on the root chain would be different. We could probably implement some hacky trick (incrementing height by say 1000 and allowing deposit blocks to be the values in between) like omisego did.

[legengliu]

I see. If we only have a single validator running PoA, that validator would have to submit deposit blocks in order to be in sync with the root chain.

But if we have multiple validators running Tendermint consensus, in which one block is proposed by a single validator in each round, selected in a deterministic round-robin fashion, how should deposit blocks be handled in that case?

[AdityaSripal]

Decided we are not doing this. Instead validators will simply create and propagate validator submitted blocks in increments of 1000. The root chain will insert blocks between 1-999. To validate a spend from a deposit, validator must check rootchain to see if user deposited claimed denomination in claimed position. If so, add position to a store of spent deposits, and then process spend msg as normal.