V5 contracts

[Ivshti]

Branch: v5-aggregate-channels

for @Ivshti:

• decide: validator registry; simple mapping (validator => pool) should suffice? stakingpool registers itself to the liquidator (note: what if it's not the first time? we should check)
• decide: court and assigning blame - implementation details when the court is NOT in place and when it is
• decide: are we shipping atomic multi-hop payments? conditional on a secret - decided not to do it cause it adds 1k per channel gas in it's naive impl (branch #v5-conditional)
• dev: implement SupplyController: mintIncentive/mintableIncentive hardcode ADX address
• deploy new SupplyController, set it
• dev: impl liquidator, single blame
• dev: StakingPool migration contract
• dev: StakingPool penalization
• dev: StakingPool unlocking ADX bug: V5: StakingPool unlocking logic #124

Added after v5 improvements for counterfactual deposits:

• decide: how will the validator verify deposits so that the worker does not allow overspend: validator should have periodic updating of total spendable balance by (channel, user) instead of the current submit/adapter scheme; set total available funds to deposited[channel][user] + balanceOf(magicDepositAddr) - perhaps 30 blocks back to ensure no reorgs

• dev: track lastStateRoot[channel] only if challenged; ensure we can call withdraw to update it even if there’s nothing to withdraw

• dev: track deposited[channel][user] rather than individual deposits; Guardian will use this to give the unspent funds back ; make sure any account can deposit under any user
• dev: Guardian: should be able to trigger challenges
• dev: Guardian: insurace to pivot to optionally giving out an additional fixed percentage on top of the remaining funds (eg 10%); percentage set by guardian owner
• dev: Guardian: if there is no lastStateRoot for the channel, allow return of full deposit
• dev: allow depositing even if channel is challenged: is there a solid reason why new deposits are not accepted during challenges? Originally it was to ensure all funds are distributed; but now we need that to make CREATE2 coutnerfacutal deposits work
• dev: create2 contract for counterfactual deposit, measure it's gas cost; 91k/46k to deposit to channel (first time vs second time)
• StakingPool/Guardian claim limits
• SPEC: validator should keep track of spent per (channel, spender) and include it in the balance tree in the way that it can't get spent in OUTPACE but it can be proven in Guardian (different leaf type)
• decide: design validator aggregation; version name: "Juan"
• dev: ensure there’s always a way to update lastStateRoot, even if there's nothing to withdraw
• NOTE: before depositing you have to ask for the validator to prove a spending node for you is included, then deposit; validator event ACK(depositor); otherwise you won't have a way to get your funds back with the Guardian in case the channel dies; note that if the channel was never used (no lastStateRoot), the spender can get their original deposit back without a leaf; but the leaf is absolutely needed cause the majority of cases are not gonna be new channels
• decide: figure out how to track channel solvency and when to trigger the sweeps; relayer? we can do it every time before withdraw if channel is insolvent (sum(balanceTree) > deposits); deposits also need to be sweeped during challenges - otherwise the depositor will not be able to get them back from Guardian

---

for @samparsky:

• re-enable identity tests and OUTPACE tests (copy TestAdExCore from v4/ and adapt in the same way that test/simulate was adapted)
• tests for StakingPool including claim()
• tests for the insurance pipeline (Guardian)
• update js libs
• check style guide again https://docs.soliditylang.org/en/v0.5.3/style-guide.html#order-of-layout, ensure everything is conforming to it