SIP-127: Minimal Proxies for Virtual Synths

Simple Summary

Deploy a ERC-1167 Minimal Proxy instead of a full Virtual Synth contract when new Virtual Synths are created.

Abstract

This SIP proposes to optimize the creation of new Virtual Synths by deploying ERC-1167 Minimal Proxies instead of the full SIP-89 Virtual Synth contract on each exchange outputting a Virtual Synth.

Motivation

This SIP is motivated in two parts: users and code size limits (development headache).

Users benefit from this optimization because ERC-1167 proxies are tiny. They are generally regarded as the cheapest way to deploy a copy of a contract and there are many copies of Virtual Synths needed (currently, a new one is deployed for the majority of exchanges on L1). Users should expect the gas cost of each exchange outputting Virtual Synths to fall to 800k gas (50% cheaper than current).

Secondly, adopting ERC-1167 proxies reduces the code size of factory contracts that deploy contract copies, e.g. ExchangerWithVirtualSynth. A number of other such contracts in Synthetix are at or near the 24kb code size limit established in EIP-170, hampering development as developers must struggle with optimizing new and existing code or significantly refactoring functionality to comply with the limit when any part of the dependency tree leading up to the factory is touched (e.g. SIP-120). Taking ExchangerWithVirtualSynth as an example, its code size will be reduced by 5kb, giving more wiggle room to fit SIP-120 and future changes in.

Initially, only VirtualSynths are proposed to be deployed in this way as they represent the largest gas opportunity for users. In the future, other components such as binary options could also be updated.

Specification

Overview

The ExchangerWithVirtual contract will be modified to:

1. Deploy an ERC-1167 proxy pointing to an "base" Virtual Synth contract instead of a full Virtual Synth contract.
2. Resolve the address of the base Virtual Synth contract through the AddressResolver.

To allow such deployments, the deployed "base" VirtualSynth contract will require changes:

1. Migrate the current constructor to an initialize function, as proxies do not run constructors.
2. A new constructor that "disables" the contract from being initialized. This step is not strictly necessary, but preferable to avoid possible future confusion.

This base contract will be deployed through the normal deployment process, being registered in the AddressResolver as VirtualSynthMastercopy.

Rationale

ERC-1167 proxies are no-frills and delegate all logic to the underlying base contract specified at deploy time. They were specifically designed to be a cheap way to clone functionality rather than fully re-deploy a full contract many times.

No assumptions regarding interaction or security should change for users or developers, outside of a small gas overhead on interactions and UX friction for proxies on explorers like Etherscan.

Technical Specification

No interface changes are required.

A new internal contract to handle ERC-1167 proxy deployments will be created as an internal abstraction to make such changes easier in the future.

Test Cases

Included with implementation. For the purposes of this SIP, exhaustive tests for the ERC-1167 proxy are not included and can be referenced from the reference implementation.

Configurable Values (Via SCCP)

None.

Copyright

Copyright and related rights waived via CC0.