[RFC] Bytecode repository and deployment pipeline modernization

Protocol Development
1

Motivation

Over the past year, the number of new markets across multiple chains has increased and now stands in the dozens. Moreover, there are more markets to be deployed, more markets to be re-deployed—with new parameters or new collaterals, or with protocol enhancements. As a good example, the ongoing development of the partial liquidation solution will require the upgrade of a row of Comet implementations across several chains.

And so, it raises several cornerstones:

  1. With the increased demand for new markets, it becomes crucial to implement a seamless deployment process that reduces the time and effort required by both developers and the community.
  2. The deployment process should include the trustless verification of deployed smart contracts. As the development of new solutions became a more continuous process, it became essential to ensure a safer way for deploying and upgrading new markets. And, as a key point, without additional consumption of the efforts from trusted security providers, but without any losses in security
  3. While more markets are deployed on more chains, the ecosystem will require a version control system as well, since all implementations should be categorized for tracking of where upgrades should be applied.

Focusing on each cornerstone:

Simplified and seamless deployment process

Currently, deploying new Comets requires preparing a customized deployment script in the repository. Upon deployment, it is also crucial to validate the bytecode of deployed smart contracts - to confirm that it corresponds to the last audited version. As DAO proposes a new market, it depends on the developers how they deploy the Comet smart contracts. Since the bytecode is customarily deployed each time, this procedure consumes the time of developers, auditors, and the community. Although the bytecode remains the same for each new market, this procedure is necessary to ensure the security of the deployment pipeline. Therefore, this process requires time and accuracy from both the development and auditing teams. While such an approach works fine, it might become more problematic, e.g., in the case of simultaneous upgrade of a large number (if not all) of markets with the new feature requested by the community. There is a demand for the simplification of the procedure - but with conservation of the same security of the process.

Trustless verification of deployed smart contracts

As discussed in the previous point, the developers decide on how to deploy the new market requested by the DAO, and thus, it creates a necessity to have the validation by auditors each time (to ensure that the same version is deployed each time). So, it creates 3 bottlenecks:

  1. The deployment is performed by trusted developers only, as it reduces the chances of deviation in deployed contracts / upgraded markets. It is also possible to update the configuration of Comets using Configurator and CometFactory smart contracts, thereby bounding the new implementation deployment process (of the same bytecode with different initialization parameters) to the same issues as those for the new market.
  2. The deployment requires prior authorization by auditors, which may take time, as it depends on the auditors’ schedules.
  3. The proposal usually includes the whole bytecode of the contract, so the DAO can ensure that both developers and auditors do their jobs right and no changes were made to the code during the process. And so each change will require a change to the proposal (which is especially painful in the case of crosschain deployments)

Each bottleneck clearly shows a lack of a trustless deployment process, which is why it requires a lot of extra or duplicate steps.

Version control

With each new comet deployed, the issue of versioning becomes more pressing. The most trivial example - new enhancement should be applied to all markets in the ecosystem, therefore the community (both DAO, devs and auditors) will require a tool to track which markets are already upgraded, and which are not. Obviously, while the number of markets is relatively small, we can rely on internal registries that the developers have, or public tracking in UI or in other tools. But it becomes harder to track in case there are several dozen markets, a hundred markets, or if there are 2-5-10 enhancements in development progress, or if there is a need to upgrade dozens of pricefeeds (e.g., in case of big enhancements like OEV or CAPO pricefeed). The task becomes even more complex if there is a need to support a separate version of Comet for a specific chain or asset, and the chance of having an alternative solution (and so the alternative version) increases with each new feature/chain/asset.

We in Woof! reflected on those points (especially after the deployment of more than 16 markets with more in the pipeline) to develop the solution which will cover those key points, make the deployment process simpler, leave it seamless and secure, and enhance the ecosystem with a powerful tool for future expansions.

Solution

To address all the mentioned issues, we are currently working on the Bytecode Repository, a unified solution for upgrading the deployment pipeline.

The solution includes

  1. Version Controller
  2. DeployManager L1
  3. DeployManager L2
  4. New Factories for markets, price feeds, and related peripheral contracts
  5. Enhancement of the market deployment, configuration update, and market upgrade processes.

Version Controller

It is the main smart contract in the system, responsible for transparency of the deployment and upgrade process of new smart contracts. It holds core storage and functionality:

  1. Access control
    • List of registered developers
    • List of registered auditors

Both lists are managed and curated by the Governance. Developers are responsible for managing the bytecodes repo, and auditors are responsible for the verification of the bytecode.

  1. Bytecode repo

The contract maintains a list of smart contract types registered in the system (e.g., Comet, Price Feed, Version Controller itself, and factories for each contract type) and the respective bytecodes for each contract type. Taking the Comet market as an example, the Version Controller stores the last validated bytecode together with the signature from the auditors (which serves as a validation) and the version of the bytecode.

  1. Version

Each registered bytecode will have a version assigned, in a standard format: “major release”.”minor release”.”patch”.”alternative release prefix”

In such a way the community will be able to track which market has which version, and what market requires the upgrade and which requires an alternative release.

  1. Backlink to the registry

Each deployed market should have the onchain mark indicating which version it has. While we cannot include the version into the bytecode itself (due to size limitations), we will have an onchain registry. We are currently exploring options on having the markets registry in Version Controller, or in a separate contract or integrated with the ENS.

There will be only one instance of the Version Controller deployed on Ethereum, as a single source of truth among chains.

New Factories

The solution requires new factories to be developed for each contract type - so that they will be able to work with the Version Controller in order to get the requested bytecode. And, since Factories are also smart contracts within the same Compound ecosystem, their bytecodes will also be registered in the Version Controller, and each Factory will be deployed by the same pipeline as each market.

Deploy Managers

The Compound ecosystem is crosschain based; thus, there should be a way to deliver registered bytecodes throughout the ecosystem. And that is the purpose of Deploy Managers - to allow assigned developers to deploy verified contracts on other chains. So L1 Manager (deployed on ETH) will serve as a hub connected to the Version Controller, and L2 Managers will be deployed on each Compound chain. Their purpose is to receive the bytecode from the L1 Manager and cache it. In such a way, each foreign chain will have a copy of the latest verified and registered bytecode, thus ensuring that Factories will deploy it in a trustless manner.

Deployment flow enhancement

All components in the solution aim to solve all issues described in the first section, so that the deployment flow will be enhanced:

  1. The Governance can now manage the list of developers and auditors on-chain.
  2. Assigned developers will be able to register bytecodes of all types of smart contracts in the Compound ecosystem, including new types of contracts and major/minor versions for existing bytecodes (not only markets - but also price feeds, factories, and other types of contracts)..
  3. All bytecodes will have versions assigned, and each bytecode will have a signature from auditors stored onchain as well and processed via proposal as a proof of validity.
  4. All bytecodes will be stored in the Version Controller, so anyone will be able to verify from which implementation the contract was deployed fully on-chain as well.
  5. When deploying new contracts, developers will now use bytecodes stored on-chain without using locally compiled smart contracts, which increases safety and transparency for the community.
  6. Now Factories fetch the requested version from the Version Controller, and anyone can trigger the deployment in a trustless manner: by the moment of deployment, the bytecode is registered in Version Controller by the assigned Developer, has a version, has a signature from the assigned auditor, and is verified by the Governance. Thus each copy of such bytecode can be trusted and requires no additional time and efforts from developers and auditors
  7. To ensure that no malicious contracts will enter the Compound ecosystem, each contract deployed in this pipeline (from the Version Controller) is deployed in a paused state and is later activated via the proposal.

So, before the process took a lot of extra steps in the zero-trust environment: developers prepare a customized deployment script, prepare the bytecode (the same copy as already deployed), require auditors to verify already verified bytecode, pack it into the proposal and verify it again.

And now the process is seamless: the assigned developer registers the bytecode, gets the signature from auditors, gets the verification from Governance, and now the same code can be deployed any number of times in a trustless environment. Thus, if the market was already previously deployed, and we need to deploy its exact copy, the assigned developer just triggers the factory, which fetches the registered, audited, and verified bytecode and deploys it. And Governance only processes the activation proposal (basically the unpause proposal). And the whole process can be united in a single proposal with no extra steps.

Furthermore, the solution will now enable the update of implementations of existing smart contracts, a feature that was not previously supported. And the same applies to deployments on other chains, as it works as seamlessly as on the main chain: the developer uses the L1 and L2 Deploy Managers to fetch the registered bytecode from the Version Controller and store it on the target chain. After that, it can be deployed via a local factory any number of times in a trustless manner, requiring only an activation proposal after that.

While the mechanics of the croscchain operations and the restrictions are still under internal review, the mechanism in general is ready for development:

  1. The solution will support all the existing chains.
  2. The solution will not introduce complexities into the existing Governance system but simplify the structure of the proposals.
  3. The solution will provide a simplified approach for new comet deployments in a trustless environment.
  4. The solution will allow a clear on-chain validation of deployed bytecodes for auditors and the community.
  5. The solution will introduce clear version control over the deployed markets and other contracts.
  6. The solution will simplify the process of implementation, upgrade, and specifically, the process of parameter updates in the market.

Typical flow

  1. Governance registers developers and auditors - in a regular workflow, it is done just once per year or even rarely.

1600×497 44 KB

  1. The developer registers new bytecode (either new type of contract, or new enhanced version of the market, etc) and Governance verifies it with the auditors signature. In a regular flow it is done once per quarter or so.

1600×970 106 KB

  1. New bytecode can be used for markets’ upgrades, or for parameter changes, or for new market deployments - all in a trustless manner and with a simple activation from the Governance.

1600×691 91.8 KB

The version control approach opens a possibility for both Governance and the community to deploy new instances of smart contracts while not diving in the technical details, operating in a trustless environment with audited and verified bytecodes - for all types of contracts in the system. And that will especially become handy for market parameters upgrades, simplifying the process to the minimal number of steps.

Next steps

The Woof! team has already started the implementation of the Version Controller within the scope of the bytecode repository and deployment pipeline enhancement. Though it is the first early step for such a big improvement of the Compound ecosystem infrastructure. So as for the next steps:

  • We continue to work on the Version Controller, with another post planned in 2 weeks with the progress report and with more posts on the details of the enhancements.
  • Finalization of the technical details of the solution and specifications for new factories and deploy managers, unification of the crosschain approach, continuous development of the system and internal audits.
  • Gathering the version info on all existing markets, having the initial version assigned as 3.1.0 for all existing markets - with exceptions for few alternatives. This info will be the first in the future registry.
  • Preparation of the developed contracts for the external audit.
  • Preparation of specific guidelines with a full description of the deployment pipelines.

And after that, we will work on the adoption of the system, initial deployments of utility contracts, and first bytecodes registering, with a full adoption of the system with optimistic plans by the end of the summer.

1 Like