Zero Downtime Devnet Deployment

[hugocaillard]

Context

The Devnet allows to start a local or hosted Stacks network. Started from a Clarinet project, the Devnet will deploy all of the projects smart contracts, along with the project requirements (smart contracts dependencies from Mainnet or Tesnet).
By nature, a Devnet is quite temporary (as opposed to the Mainnet and primary Tesnet that run indefinitely) and can be restarted evertyime the project is updated, with the latest version of the smart contracts.

Problem

Spinning up a Devnet and re-deploying all of the contracts takes time. Especially in the context of Nakamoto, because it takes many blocks for the stacks-node to reach epoch 3.0 and deploy the contracts.
When performing a small (or big) change in a contract, it's not productive to wait for several minutes to have it ready in a Devnet.

Solution

Zero Downtime Devnet Deployment proposes a way to continously re-deploy new versions of the contracts on an already-running Devnet as they are updated. For each re-deployment, a uniq hash is generated and included in the contracts name. Along with #1474, it would be possible to transparently call the latest version of the deployed contract, without having to specify the hash.

Scenario

A project has two contracts

counter-trait.clar
counter-v1.clar

On the first start, the devnet is spinning up and the contracts are deployed once the devnet is ready:

clarinet devnet start

The contracts are deployed twice, without the hash for "normal" use, and with the hash

counter-trait.clar
counter.clar
counter-trait-b0b67bc.clar
counter-b0b67bc.clar

At this point, the automatically generated JS client can be used to call the latest, hashed version of the contract

// this is pseudo code, function names and wording is not relevant
network = STACKS_DEVNET;
protocol = protocolClient(network)
tx = protocol.counter.add(2)

client.broadcast(tx)
// calls '<deployer>.counter-b0b67bc add 2
protocol.counter.getDataVar('counter') // == 2

When the contracts are updated, the user can manually redeploy the contracts and regenerate the JS client. It can also be done automatically by the CLI, VScode extension, or the platform.
Two new contracts are then deployed:

counter-trait-7ec8f7a.clar
counter-7ec8f7a.clar

// the protocol lib has been re-generated
tx = protocol.counter.add(2)
client.broadcast(tx)
// calls '<deployer>.counter-7ec8f7a add 2
protocol.counter.getDataVar('counter') // == 2

Notes

• This is not contract versionning, and this strategy only applies on private and transient testnets.
• Although not necassry, it would still pair well with contracts versionning practices