Abstract Layer POC

[boolafish]

Description

As a engineer, I want to get confidence on the Abstract Layer design before fully committed to implement it. So that I do not waste too much afterward.

Design doc: here

Some pseudo codes: here

Successful Criteria

• Have a prototype implementation of abstract layer design --> https://github.com/omisego/research/issues/80
• Have at least two types of tx running on top of that to see how multi-tx-types co-works together: --> https://github.com/omisego/research/issues/89
  • MoreVP with SE only (for future code re-use, and test functionality of the design. we know this is not secure)
  • Design and implement another random tx type
• Get metric on gas cost: --> https://github.com/omisego/research/issues/94
  • compare SE cost with original MoreVP
  • get general extra cost for calling external contract (get address from map + call ...)
  • key-value pair optimizations. Encode all required data to one "bytes" and safe that. Decoded when needed. See how much does this safe.
• Update the gas cost to design doc, and try to find out more limit of the design and document it.

[boolafish]

[Note]

1. from the SE & IFE interaction doc there is one case conflicting with the design. It is case 2: the current solution using standardExitId(txbytes, utxo_pos) for 2. Mallory does SE on input, finalized -> Mallory submits IFE would not work in this framework. It conflicts in that I want each Exit Game to be independent in logic. They should not know about how other decides exitId. To solve this, instead of blocking the IFE, we can just add nonCanicalChallenge with the condition of input finalized (to be seen as used). [edit: or an alternative is we make sure one ouput can only exit once in the processExit stage. We do not care the processExit to be triggered twice just the fund would not be moved. The decouples IFE and SE totally.] [edit2: that is not really an alternative, they are solving different interaction of SE and IFE]

2. Need to decide whether we want to keep token per priority queue or let the ExitProcessor to be able to ignore and move on wrong external contract implementation. (We can call the external function, see if any exception occurs, silence the exception if it is not from us) The two design kinda collide a bit (not much though) in the responsibility here. Ideally, PlasmaFramework should not know the "state" detail at all. Knowing "token" is sort of adding responsibility to the base layer. [eidt: we can use pull over push to solve this)

3. The current RLP contract code might have some issue migrate to solidity 0.5 (and some of the code is really weird....). Might want to try out this alternative repo instead.

[boolafish]

[Note] We probably would want to make decision do we want to support upgrade ExitGame, ExitProcessor, Predicate contracts with "version". Without this we can still upgrade by moving people to new tx type. I see a main benefit keeping version is for faster developing cycle. Bumping version is just easier for server code to handle than migrate to new tx type. We can test things faster in develop or staging.

I have a proposal to keep those function but add a function to lock the ability. So on prod, we deploy all the contract, move to a version we want to use, and lock the upgrade ability by version.

[boolafish]

[Side Note]

1. Regarding IFE, probably it might be better to enqueue per output while piggyback. If there is a large tx, it might run out of gas to process all the piggybacked input/output. (well...we don't have such scenario now actually XD)

The "start exit" would still be the beginning of the game, and the game would decide the "canonical flag". While piggyback the exit binded with an output would be enqueued. While processing the exit, it would go back and check the "canonical flag" true or not to decide exit-able or not.

I think this would/might make code more consistent between SE and IFE.

2. During POC, one thing I see as an anti-pattern on general code style is a global PlasmaStorage with public variables.

[boolafish]

[Note] Just figure out probably there is no need to do the proxy to exit game at all. Users can just call the exit game contract directly. They can first get the address of exit game from plasma framework and call the exit game contract directly. Nothing is really different. And the GeneralizedStorage would check if the writing is done by the latest version of exit game contract anyway, so calling old version of exit game is fine as well.

In fact, using proxy would cause a problem that msg.sender can only be the framework address. In other word, we cannot check msg.sender == user for exit.

[boolafish]

[NOTE] As finding out it is not necessary to proxy, also realized there is no need to put PlasmaFramework as a central entry. It is possible (might not better, just possible) to modular everything.

With modular design, it is possible to add new feature by adding new modules. This makes it possible to abstract wallet (eg. ETH wallet, ERC20 wallet, ....). This means user would call the, eg. ETH wallet directly instead of PlasmaFramework. The module would talk to other modules (eg. BlockController) afterward.

Put down my quick thought in the doc here. Currently probably better to start with monolithic cause we have more experience.

[boolafish]

we are in implementation phase (for a while) already. closing this.