Deployment
Request for Onchain Deployment Standard
Overview
There is currently no standard way to deploy Chopin-based apps. Each app hosts its own sequencer and must provide instructions for its community, if they want to run nodes themselves.
With an onchain deployment standard, we open up a new set of possibilities for the Chopin ecosystem.
The idea is simple: source code should be published onchain (Celestia) and anyone with knowledge solely of Chopin Framework, Celestia, and an App ID should be able to verify the current state of such an app.
This has a variety of benefits:
- Transparency for Users: instead of installing whatever binary is published to GitHub, users can run any app with just a Celestia node and Chopin client.
- Decentralized Infrastructure: instead of the app developer hosting their own sequencer on centralized infrastructure, this allows a decentralized marketplace to form around running sequencers.
- Trustless Updates: the criteria for publishing an update can be formally defined. Since the infrastructure can run on decentralized infrastructure, there is no longer a single point of failure. This allows decentralized (i.e. DAO) ownership of the development process.
- Enshrined Forking: this also formalizes the forking process, making it easy to permissionlessly modify an existing app while bringing along the existing state.
Basics
Here is the basic process for how it should work:
- Developers build their app.
- They publish their source code, including the IaC and any deployment logic to the DA layer.
- They include a Chopin config which instructs clients how to run, validate, and fork the app. The config can contain many other options as well, including registering a name in the Name Service.
Config
The file chopin.config.json is used to configure the app. In the future, a TypeScript version, i.e. chopin.config.ts, should be supported as well.
Let's walk through the fields that it should contain. This may not correspond exactly to the final field names or structure of the config:
| Field | Description |
|---|---|
domain | The domain of the app. i.e. "example.com" |
app-id | The unique ID of the app. This is used to identify the app onchain. |
version | The version of the app. |
config-version | The version of the config format. This is used to ensure that the config is compatible with the version of the Chopin client. |
forkOf | The ID of the app that this app is a fork of, if applicable. |
deployment | Information about how to deploy the app. |
deployment.type | Either "nextjs" or "docker". More types will likely be added in the future. |
deployment.options | Options specific to the deployment type. Details TBD. |
deployment.dockerfile | The Dockerfile to use for the deployment. Only used if deployment.type is "docker". |
env | Environment variables to set for the app. These are not secrets. |
commands | Commands to run on certain events in the app's lifecycle. |
commands.init | Command to run to initialize the app. This runs the first time the app is deployed. It does things like seed the database. When a new version is published, this can be used to run a migration. |
commands.can-update | Command to run to authorize an update. Users of an old version run this to check if they should upgrade to the next version. For example, this could check a signature to see if it was published by the dev team. |
commands.dump-state | Command to run to dump the state of the app. |
commands.get-state-commitment | Command to run to get the state commitment of the app. If not provided, this will be generated from the output of commands.dump-state. |
commands.dev | Command to run to start the app in development mode. Similar to npm run dev. |
services | A list of services that run alongside the app. |
da | Details about the data avialability layer. |
da.chain-id | The ID of the chain to use for the data availability layer. |
da.namespace | The namespace to use for the data availability layer. |
da.start-height | The height at which to start the app. |
Lifecycle
Running a node
Services
Services are third party processes used by the app, often times generating to a secret environment variable passed to the app at runtime. Some possible examples:
- A Postgres service could run a postgres instance and provide a connection string to the app.
- A Stripe service could require a Stripe API key and allow the app to use Stripe's API to accept fiat payments. As you can imagine, you would not want to expose your Stripe API key in the config file.
- A Bitcoin service could could run a full node and provide RPC endpoints allowing a trustless one-way bridge from Bitcoin to the app.
Some of these are more and less decentralized. They depend on the needs of the app developer. Chopin Framework will automatically be compatible with a default list of services. For example, apps will be able to provision databases without any third party dependencies or extra steps.
Hosting
Modular Cloud, the creators of Chopin Framework, will provide a service that watches app deployments on Celestia and automatically provisions them. This will have a free and paid tier, including an option for onchain payment via crypto.