tokamak-network / plasma-evm-contracts Goto Github PK

This proposes that operator can limit total stakes to plasma chain (from operator and/or from delegator).

This motivates users to delegate their tokens to plasma chain with huge negative commission before total stake to the chain.

When RootChain applies request in rootchain, whether exit or enter, applyRequestInRootChain call may fail if msg.gas is insufficient.

In case of exit, this is so critical that prevents any exit request after it from being applied because current implementation remains checking result of applyRequestInRootChain as TODO.

https://github.com/Onther-Tech/plasma-evm-contracts/blob/aef56c95243efde3aae87592cc7be6f1abf7fbe8/test/stake/renouncePause.test.js#L495

test out with

await this.ton.renouncePauser(this.seigManager.address);

because authController has renouncePauser() function which can interact with other Pausable.sol contract.

Connected to SeigManager, gov contract can control below conditions with policy changes.

1. deposit amount
2. TON token contract address

The second also supports other ERC20 tokens to be used as a base currency in plasma network.

(about 3 days for contract dev/test, 2 days for test with other components.)

idea: MiniMeToken's parent token

fork plasma network at specific block(or cycle, epoch) and operates the forked plasma network (by another or same operator).

A hard-forked RootChain can be used as

1. add new features without changing previous canonical chain. (related: #26)
2. make a new duplicate network

The first case must handles requestable contract remapping (target requestable contract side and/or RootChain side)
The second case must abandon previous requestable contracts becuase they are already used by the original RootChain contract

We need more idea and discussion about scheme..

Depending on the redeposit order, Power may not change as intended by the user.

In the situation where a user deposits 100 tons of each of two operators, user may want to redeposit all tons to get power including seignioreages.

The results according to the redeposit order are as follows. Let's assume that the user have 150 power at first.

case 1:
behavior                        staking amount on op 1  staking amount on op 2  power
1.                              100                     100                     150
2. request withdraw 100 ton     0                       100                     50
3. redeposit 100 ton            100                     100                     150
4. request withdraw 100 ton     100                     0                       50
5. redeposit 100 ton            100                     100                     150

case 2:
behavior                        staking amount on op 1  staking amount on op 2  power
1.                              100                     100                     150
2. request withdraw 100 ton     0                       100                     50
3. request withdraw 100 ton     0                       0                       0
4. redeposit 100 ton            100                     0                       100
5. redeposit 100 ton            100                     100                     200

case 2 is intended result of the user. but case 1 can also happen. making a guide for this may be nice.

As OpenZeppelin/openzeppelin-contracts updates solidity 0.6.0, we can follow the update

migrate https://github.com/Onther-Tech/solEVM

using delegate-call proxy pattern, RootChain.sol, SeigManager.sol, PowerTON.sol can be upgradable with few changes of storage layout.

Whenever tried to make stake transaction which contains all the TON balance of operator, it reverted.

https://rinkeby.etherscan.io/tx/0xa8be665fd473754e25fb2647038d2c3dcefc0efb3bfaccba63c46b609db3236e

https://rinkeby.etherscan.io/tx/0xa6c2ef5ace2751c0a7ea3ae6cad52df8c129283025aeea11ababcfaa418c3ab5

https://rinkeby.etherscan.io/tx/0xc2cbdee9df8004c4f96a6b5cbf83aaadac10b7822cda66889300883c3d4496d1

#when 0x6ea443ad5430684f7b8353cd8ad50d1e97d886d1's TON balance is 1000
ubuntu@ip-172-31-29-177:~/plasma-evm$ build/bin/geth --nousb staking stake-ton 1000.0             --datadir ./operator             --rootchain.url wss://rinkeby.infura.io/ws/v3/d738213eecc341feb0bf0021390c75e4             --unlock 0x6ea443ad5430684f7b8353cd8ad50d1e97d886d1             --password pwd.pass             --rootchain.sender 0x6ea443ad5430684f7b8353cd8ad50d1e97d886d1             --rootchain.gasprice 10000000000
INFO [05-13|03:52:29.487] Maximum peer count                       ETH=50 LES=0 total=50
INFO [05-13|03:52:29.488] Smartcard socket not found, disabling    err="stat /run/pcscd/pcscd.comm: no such file or directory"
INFO [05-13|03:52:30.591] Set options for submitting a block       mingaspirce=1000000000 maxgasprice=100000000000 resubmit=0s
INFO [05-13|03:52:31.525] Unlocked account                         address=0x6ea443ad5430684f7b8353cD8Ad50D1e97d886d1INFO [05-13|03:52:31.525] Root chain transaction sender found      address=0x6ea443ad5430684f7b8353cD8Ad50D1e97d886d1INFO [05-13|03:52:32.145] Allocated cache and file handles         database=/home/ubuntu/plasma-evm/operator/geth/stakingdata cache=16.00MiB handles=16
INFO [05-13|03:52:32.160] Using manager contracts                  TON=0x3A4e4F7Da26fd2B19cE0e2634906A3BB83cfF3E9 WTON=0x981B2533528145e593C574fa20e54f9a55fbeee9 DepositManager=0x5EEd93B0a36b318A04825E326a0fa834E78fF74D RootChainRegistry=0x1d5F6Ac3aE4acB9c4e0C40E03D73B02b84427604 SeigManager=0x51b9E54A85F6ac61Bd281270aAc1Ce09Cc29554d PowerTON=0x63F2A55b025865DE4c647c40dA5EebD734b75F2a
Transaction reverted: 0xc2cbdee9df8004c4f96a6b5cbf83aaadac10b7822cda66889300883c3d4496d1

Reference: https://github.com/Onther-Tech/papers/blob/master/docs/tech-paper.pdf

A half of unstaked seigniorages are provided as PowerTON rewards. If few TONs are staked, the stakers have a lot of change to get huge reward.

https://github.com/Onther-Tech/plasma-evm-contracts/blob/650fce0e5002d0f81cd5f6c2cc427553e4d48817/contracts/stake/managers/SeigManager.sol#L102-L103

https://github.com/Onther-Tech/plasma-evm-contracts/blob/650fce0e5002d0f81cd5f6c2cc427553e4d48817/contracts/stake/managers/SeigManager.sol#L485

Possible solutions are

1. to make PowerTON reward in proportion to staked TON
   (e.g. At line 486, powertonSeig = powertonSeig * (stakedSeigs / totalSupply))
2. to define upper bound of PowerTON reward
   (e.g. At line 486, powertonSeig = MIN(powertonSeig, MAX_POWERTON_SEIG))
3. to control unstaked seigniorages with token distribution
   Large portion of TON will be held by team (for the dev team, reserve, marketing, and others). Those may be used to control the PowerTON reward upper bound.
4. to start first round of PowerTON when quite reasonable portion of TON are staked (and PowerTON reward are not so huge)

• The first two may reduce motivation of being staker at the early stage, which contradicts the purpose of PowerTON reward. They need a little changes of economic ecosystem design and rationales.
• The third may make token holders to feel antipathy toward the team because of unexpected change of tokens held by the team. It must be well announced to the public.
• The fourth cannot react when large portion of staked TON are withdrawn after PowerTOU round starts.

we calculate userDepoist amount with accStaked - accUnstaked. but when user calls redeposit function, accStaked amount increase. so that useDeposit amount and accStaked - accUnstaked amount will be unmatched.

ref: https://docs.google.com/spreadsheets/d/15CvTI5Li5XhJ14QppxXQ2ejCPS39I73PVkrC38BnVVY/edit#gid=0

function startEnter(
    address _to,
    bytes32 _trieKey,
    bytes32 _trieValue
  )
    public
    payable
    returns (bool success)
  {
    uint requestId;
    uint weiAmount = msg.value;
    requestId = _storeRequest(EROs, ORBs, _to, weiAmount, _trieKey, _trieValue, false, false);
    numEnterForORB += 1;

    Data.Fork storage fork = forks[currentFork];

    emit RequestApplied(requestId, false);
    emit RequestCreated(requestId, msg.sender, _to, weiAmount, _trieKey, _trieValue, false, false);
    return true;
  }

There is no need of payable modifier in RootChain.startEnter() anymore because User who wants enter to Child chain have to enter with EtherToken to make PETH in Child chain.

Stakes going to be withdrawn are in-pending if WITHDRAWAL_DELAY blocks are not mined. We may give stakers new choice to re-deposit the pending stakes, not just wait until withdrawal is possible.

accStaked amount increases when user deposits tokens and accUnstaked amount increases when user requests token withdrawal.

(1) we calculate user's delegated amount using accStaked - accUnstaked. but accUnstaked amount that users can withdraw always can be changed by seigniorage.

eg.
delegate = 100

• accStaked = 100
• accUnstaked = 0
• seig = 0
• coinage = 100
• accStaked - accUnstaked = 100

(...over time, gave user 40 seig)

• accStaked = 100
• accUnstaked = 0
• seig = 40
• coinage = 140
• accStaked - accUnstaked = 100

case 1) wihdraw: 140

• accStaked = 100
• accUnstaked = 140
• seig = 40
• coinage = 0
• accStaked - accUnstaked = -40
  -> in this case, display 0(in dashboard) if accUnstaked amount is more than accStaked.

case 2) withdraw = 80 => accStaked = 100, accUnstaked = 80

• stake = 140 - 80 = 60
• deposit = 20

(2) since TON's decimal is wey and WTON's decimal is ray, a very small amount can be discarded in the delegating TON and withdrawing WTON.

eg. delegated = 999999999999999999999049957000 (expected: 1000000000000000000000000000000)

Is it possible to integrate your solution with my wallet?

Current apply functions only takes enter and exit request. They should be extended to support escape and undo request.

function applyRequestInRootChain(
    bool isExit,
    uint256 requestId,
    address requestor,
    bytes32 trieKey,
    bytes trieValue
) external returns (bool success);

function applyRequestInChildChain(
    bool isExit,
    uint256 requestId,
    address requestor,
    bytes32 trieKey,
    bytes trieValue
) external returns (bool success);

apply functions should be divided into request types, not chains.

function startEnter(
    bool isRootChain,
    uint256 requestId,
    address requestor,
    bytes32 trieKey,
    bytes trieValue
) external returns (bool success);

function startExit(
    bool isRootChain,
    uint256 requestId,
    address requestor,
    bytes32 trieKey,
    bytes trieValue
) external returns (bool success);

function startEscape(
    bool isRootChain,
    uint256 requestId,
    address requestor,
    bytes32 trieKey,
    bytes trieValue
) external returns (bool success);

function startUndo(
    bool isRootChain,
    uint256 requestId,
    address requestor,
    bytes32 trieKey,
    bytes trieValue
) external returns (bool success);

DepositManager.requestWithdrawal fails when below conditions are satisfied.

1. when 2+ root chains are deployed with commission rate over 0.5, and 2 users deposit equally to all root chains.
2. when the amount of stakes from the first takes 95% of total stakes (the second user deposits 5% of total stakes)
3. after 10+ root chain blocks mined(and after 100+ seconds)
4. when the first user tries to withdraw his stakes from all root chains.

If operator set commission rate, some of seigniorages for delegators is given to operator. We may support opposite direction of seigniorage distribution, giveaway from seigniorages for operator.

When the first and only request is enter request, a request epoch that expect to include the request does not prepared.

If there is 2 more enter request or at least 1 exit request, request epoch is always prepared so that request(s) can be processed in plasma chain.