Updating The Protocol

[setzeus]

Updating The sBTC Protocol (clarity contracts)

Overview

This discussion is meant to lay down the suggested / standard way of decoupling this protocol to make it more modular for future updates. There is an existing way of doing this that'll be mentioned below; this will be the how the contracts are first updated. Afterwards, we'll mention shortcomings with this method & mention alternative updates.

Standard Implementation

Currently, the sBTC protocol is made up of five contracts, each with distinct responsibilities that lay the ground for an upgradeable protocol:

1. sbtc-registry - holds the state of the protocol
2. sbtc-token - SIP10 fungible token contract
3. sbtc-deposit - contract for Emily API to complete deposits
4. sbtc-withdrawal - contract for Stacks principals to initial / complete withdrawals
5. sbtc-bootstrap-signers - pseudo-governance contract for the active signer set

While the protocol is currently not updateable, the responsibilities are structured in a way that makes it relatively easy to update three contracts: sbtc-deposit, sbtc-withdrawal, & sbtc-bootstrap-signers.

Modularization With Existing Setup

With the existing setup, we'll need the following steps:

1. Create three different flags for the updateable protocol contracts (signers/deposit/withdraw) in sbtc-registry (state)
2. Create a tuple for 'active-contracts' with a key/field for the active contract for the three types of interchangeable protocol contracts
3. Add checks for each writeable function in 'sbtc-registry', checking that it's the active contract
4. Adding a new 'update-protocol' function to 'sbtc-registry' for the signers to update

A draft of this can now be seen here that updates the 'deposit' contract: #1008

Alternate Form Of Updating Protocol

As discussed during our daily standups & now seen in a few upcoming/recent protocols, there's an alternate path here that involves creating traits & proxy contracts for each of the protocol contracts. Another consideration is whether this pattern will allow us to also update the sbtc-registry/state contract(?)

re: using traits & proxy contracts
My understanding is that traits are most effective when dynamically passing-in a contract that must adhered to abc standards. The most clear example of this is a dex/liquidity pool in which the protocol must support passing in infinite types of SIP10 contracts. Since no contracts are passed in dynamically, the benefits of making traits & proxy contracts for the three upgradeable types of contracts (signer/deposit/withdrawal) aren't very clear to me. If anything, defining traits now means we'd have less flexibility on how we update the three contracts.

re: updating state
Currently, the token & state (sbtc-registry) contract are not upgradeable. The token contract has built-in Clarity Values that make it basically impossible to upgrade; the state contract might be upgradeable with a more complicated structure the de-couples the 'state' from the 'active' contracts. But it's still unclear to me whether this behavior (updating state) is desireable.

[setzeus]

Pinging @hstove @hozzjss @MarvinJanssen @friedger & anyone else familiar with Clarity patterns for feedback here & in the accompanying draft PR. The main question in mind is: does the latest PR satisfy the requirements for making the sBTC protocol modular / upgradeable?

If not, what's the best alternative here? As mentioned above I can wrap my head around using traits/proxies but could use some context on pros/cons I'm not seeing.

[diwakergupta]

You've probably seen it already, but this PR and the discussion therein has tons of pointers: stacksgov/sips#176

[setzeus]

Ah, it had been a while since I read it top to bottom again, appreciate the reminder.

[friedger]

What is the governance model for sBTC? Maybe it is easy for the entities in power to upgrade.

[setzeus]

On the Clarity side governance is represented by the 'current-signer-principal' seen in 'sbtc-registry,' which is a multisig Stacks principal.

Only that principal would be able to update a protocol contract through the 'update-protocol-contract-wrapper' function seen in the 'sbtc-bootstrap-signers' contract (at least for this implementation linked above).

[friedger]

Isn't that dangerous?
Have signers enough to loose? Should sbtc holders be involved? Or a SIP and hard fork?

[setzeus]

It's the same amount of danger as trusting that multi-sig to complete deposit & process withdrawals no?

Hmmm, how would you suggest involving holders? Do you think we'd need a SIP/hard fork even if it's just to update the three feature contracts? (signers/deposit/withdraw)

[aldur]

+1 on @setzeus here.

[friedger]

One thing is to execute a process, the other is to define the process.

If we agree that signer set is the governance body, then let's continue like that. However, I think it makes the protocol weaker with this limited membership governance.

[MarvinJanssen]

In theory it should be possible for the signers to create a valid Stacks multisig address and do a deployment using it. Would it count as governance by virtue of such a transaction being mined successfully?

[aldur]

Based on this, I think that's how it works: #990 (reply in thread)

[MarvinJanssen]

A challenge with the approach is to atomically deploy and update multiple contracts. If the signer set sends out multiple transactions and these are not all picked up in the same block (or censored somehow) then the protocol will be a in weird state until resolved.

[MarvinJanssen]

Transaction bundles can solve that issue: stacks-network/stacks-core#4235

[setzeus]

Yeap. Initial comment is correct as 'governance' here is equal to the 'SM' multi-sig address that comes from existing signer set (found in registry).

Great point with bundles, though they could also be deployed in individual/sequential transactions? I think we'd only need to switch all three at once during a catastrophic event as opposed to a planned update.