SIP-102: Support SNX on L2 with Optimism

Author
StatusImplemented
TypeGovernance
ImplementorTBD
ReleaseTBD
Discussions-Tohttps://research.synthetix.io/t/sip-102-support-snx-on-l2-ovm/240
Created2020-12-09

Simple Summary

Enable SNX to be used on layer 2 (L2) via Optimism

Abstract

Integrate with Optimism to enable the staking of SNX on L2 - an environment with faster transaction throughput and much cheaper gas costs.

Motivation

As most users are aware, Ethereum has a major issue with scalability. The recent DeFi summer of 2020 caused gas prices to surge, pricing out a large number of holders who could not justify spending so much of their Ether to transact. Eth 2.0 is coming, and with it, a rollup-centric approach to scaling:

the Ethereum ecosystem is likely to be all-in on rollups (plus some plasma and channels) as a scaling strategy for the near and mid-term future. - Vitalik Buterin

After investigating the various options, and considering the trajectory of Eth 2.0, Optimism was deemed to be the best fit for Synthetix's needs. In short, Optimism's Virtual Machine (the OVM) allows contract code from L1 to be ported to L2 wholesale, with only minor modifications. For more details on the choice of L2 provider, please see the blog post Why Optimism?

In order to tease out any challenges integrating with a new layer 2 technology, a testnet trial has been underway on the Goerli testnet since late September. This trial has tested connecting a custom L2 deployment of Synthetix to one on Goerli, and supported deposits, withdrawals and staking. After a couple of months working closely with the Optimism team, the code is ready to be released on mainnet.

Specification

Note: This SIP proposes using L2 for staking only. Future proposals may well introduce support for exchanging as well.

Overview

The creation of two new contracts - a deposit contract for L1 and withdrawal for L2.

  1. A bridge contract on L1: SynthetixBridgeToOptimism that supports the following:

    • When invoked by a user for a deposit of SNX, will hold the SNX as a deposit, will burn any escrowed L1 SNX and send a message to L2 representing the deposited SNX and escrow entries
    • When distributed with SNX rewards, will hold the SNX as a deposit, and send a message to L2 representing the SNX to be distributed as rewards to L2
    • When invoked with a relayed message of withdrawal from L2, will relinquish the SNX to the account
  2. A bridge contract on L2: SynthetixBridgeToBase that supports the following:

    • When invoked by a user for a withdrawal of SNX, will burn the SNX on L2 and send a message to L1 representing the SNX to withdraw
    • When invoked with a relayed message of deposit from L1, will mint the SNX to the user on L2 and populate escrow entries matching what was previously on L1
    • When invoked with a relayed message of SNX rewards from L1, will mint this SNX right into the RewardsDistribution contrat for the upcoming claim period

Further, a polymorphic approach to existing contracts needs to be considered (see Limitations of the OVM below). By utilizing polymorphism and the contract labeling within the Synthetix protocol, we can allow for different implementations of key contracts. These include:

  • EtherCollateral replaced with an empty shell (no native Ether support)
  • SupplySchedule replaced with a FixedSupplySchedule that allows for a fixed amount at construction time (as SNX on L2 will purely be a representation of the SNX in the L1 deposit contract and have no monetary policy)
  • Synthetix replaced with MintableSynthetix to allow for the minting and burning of SNX on L2 due to messages from the L2 bridge (as regular SNX cannot be minted outside the regular supply schedule)
  • DebtCache replaced with RealtimeDebtCache to ignore debt caching in L2
  • RewardEscrowV2 replaced with ImportableRewardEscrowV2 allow escrow entries on L2 to be imported from L1 (coming with SIP-60)

Rationale

In essence Optimism is a virtual blockchain, connected to and supported by L1. In order for state to enter L2, it needs to be passed in by a transaction to L1. These transactions include ERC20 deposits, as well as more sophisticated payloads of structured data.

In order for existing users to utilize L2, their L1 SNX needs to find its way to L2. To this end, this SIP proposes creating an ERC20 deposit contract for SNX with custom features to migrate escrow entries.

Limitations of the OVM

Due to the nature of on-chain fraud proofs, certain limitations are in place to enable trustless verification of state transitions within the EVM.

  • Contract size limits: in order to run in the OVM, contracts must be transpiled using the ovm transpiler, adding wrapping bytecode to contracts and expanding size. This only affects contracts near to the 24KB limit of EIP-170. Mitigation: switch to subclass of the contract with stubs for unused L2 functionality.
  • Contract deployment limits: contracts and the construction code need to fit within approximately 7.5m, as to be instantiated within the fraud proofs execution manager. Mitigation: the overhaul and removal of complex constructor logic in SIP-100
  • No native Ether: the OVM uses wETH instead of ETH for all payments. Mitigation: removal of unused EtherCollateral and Depot contrats from L2 deploy.
  • No self-destruct: the OVM transpiler does not allow the use of selfdestruct. As this opcode is problematic in Ethereum in general, the mitigation is to remove support for this feature altogether in all Synthetix contracts.
  • Compiler safety checks: when a contract's constructor arguments are read as potential opcodes, dangerous pairings can occur, proventing their instantiation in the execution manager for fraud proofs. Mitigation: on deployment, prevent contract creation with dangerous opcodes in the address (by analyzing after creation).

Technical Specification

interface ISynthetixBridgeToOptimism {
    // invoked by users on L1
    function deposit(uint amount) external;

    // invoked by users that want to also migrate their escrow
    function depositAndMigrateEscrow(uint256 depositAmount, uint256[] calldata entryIDs) external;

    // invoked by a generous L1 user (the synthetixDAO)
    function rewardDeposit(uint amount) external;

    // implementation of RewardsDistributionRecipient (for potential future use)
    function notifyRewardAmount(uint256 amount) external;

    // invoked by the relayer on L1
    function completeWithdrawal(address account, uint amount) external;

    // restricted owner function to migrate to a new bridge
    function migrateBridge(address newBridge) external;


}

interface ISynthetixBridgeToBase {
    // invoked by users on L2
    function initiateWithdrawal(uint amount) external;

    // invoked by the relayer on L2
    function mintSecondaryFromDeposit(address account, uint amount) external;

    // invoked by the relayer on L2
    function mintSecondaryFromDepositForRewards(uint amount) external;

    // invoked by the relayer on L2
    function importVestingEntries(
        address account,
        uint256 escrowedAmount,
        VestingEntry[] calldata vestingEntries
    ) external;
}

Note: in order to connect these bridge contracts to the Optimism messengers, a proposal to add to the AddressResolver is as follows:

For the external Optimism messenger contracts, the ext:Messenger label be imported to that layer's AddressResolver. These can be configured at deploy time.

For each bridge to indicate the other as a message recipient, the target layer can act as a prefix. I.e. the L1 bridge needs to know about ovm:SynthetixBridgeToBase and the L2 bridge needs to know about its counterpart, the base:SynthetixBridgeToOptimism. As these dependencies are circular, they can be configured soon after deployment of the protocol on both layers.

Test Cases

TBD

Configurable Values (Via SCCP)

As this SIP only proposes supporting SNX staking on L2, there will be no trading rewards to claim on L2. Thus only SNX rewards are relevant here, and those will only exist if they are sent to L2 by a benevolent holder - such as the synthetixDAO.

Copyright and related rights waived via CC0.