kms: Rename contracts

Author: kvinwang

docs/deployment.md

@@ -57,31 +57,31 @@ rm -f dstack-${DSTACK_VERSION}.tar.gz
 ./dstack-vmm -c vmm.toml
 ```
 
-## Deploy the KmsAuth contract
+## Deploy the DstackKms contract
 
-A KMS node requires a KMSAuth contract to be deployed on the Ethereum-compatible network.
+A KMS node requires a DstackKms contract to be deployed on the Ethereum-compatible network.
 
 ```bash
 cd dstack/kms/auth-eth
 npm install
 npx hardhat compile
 PRIVATE_KEY=<your-private-key> npx hardhat kms:deploy --with-app-impl --network phala
 ```
-It will deploy both the AppAuth implementation and KmsAuth contract to the Phala network and print the contract addresses:
+It will deploy both the DstackApp implementation and DstackKms contract to the Phala network and print the contract addresses:
 
 ```
-Step 1: Deploying AppAuth implementation...
-✅ AppAuth implementation deployed to: 0x5FbDB2315678afecb367f032d93F642f64180aa3
-Step 2: Deploying KmsAuth...
+Step 1: Deploying DstackApp implementation...
+✅ DstackApp implementation deployed to: 0x5FbDB2315678afecb367f032d93F642f64180aa3
+Step 2: Deploying DstackKms...
 Deploying proxy...
 Waiting for deployment...
-KmsAuth Proxy deployed to: 0xFE6C45aE66344CAEF5E5D7e2cbD476286D651875
+DstackKms Proxy deployed to: 0xFE6C45aE66344CAEF5E5D7e2cbD476286D651875
 Implementation deployed to: 0x9fE46736679d2D9a65F0992F2272dE9f3c7fa6e0
 Deployment completed successfully
 Transaction hash: 0xd413d01a0640b6193048b0e98afb7c173abe58c74d9cf01f368166bc53f4fefe
 ✅ Complete KMS setup deployed successfully!
-- AppAuth implementation: 0x5FbDB2315678afecb367f032d93F642f64180aa3
-- KmsAuth proxy: 0xFE6C45aE66344CAEF5E5D7e2cbD476286D651875
+- DstackApp implementation: 0x5FbDB2315678afecb367f032d93F642f64180aa3
+- DstackKms proxy: 0xFE6C45aE66344CAEF5E5D7e2cbD476286D651875
 🚀 Ready for factory app deployments!
 ```
 
@@ -93,7 +93,7 @@ cd dstack/kms/dstack-app/
 ./deploy-to-vmm.sh
 ```
 It will create a template `.env` file. Edit the `.env` file and set the required variables.
-Especially the `KMS_CONTRACT_ADDR` variable set to the address of the KmsAuth Proxy contract deployed in the previous step.
+Especially the `KMS_CONTRACT_ADDR` variable set to the address of the DstackKms Proxy contract deployed in the previous step.
 The `IMAGE_DOWNLOAD_URL` variable should be set to the URL of the dstack OS image used to verify the os_image_hash.
 ```
 # .env
@@ -169,19 +169,19 @@ npx hardhat kms:add-image --network phala --mr <os-image-hash>
 ```
 
 ### Register dstack-gateway in KMS
-As a normal dstack app, it requires the app to be registered in the KmsAuth contract first.
+As a normal dstack app, it requires the app to be registered in the DstackKms contract first.
 
 ```bash
 cd dstack/kms/auth-eth
 npx hardhat app:deploy --network phala
 ```
 
-This will deploy an AppAuth contract in the KmsAuth contract and print the app ID:
+This will deploy an DstackApp contract in the DstackKms contract and print the app ID:
 
 ```
 Deploying proxy...
 Waiting for deployment...
-AppAuth Proxy deployed to: 0x539D0d59D1742780De41b85b2c3674b24369e292
+DstackApp Proxy deployed to: 0x539D0d59D1742780De41b85b2c3674b24369e292
 Implementation deployed to: 0x5aC1671E1Df54994D023F0B05806821d6D84e086
 Deployment completed successfully
 Transaction hash: 0xceac2ac6d56a40fef903b947d3a05df42ccce66da7f356c5d54afda68277f9a9
@@ -212,7 +212,7 @@ SRV_DOMAIN=test2.dstack.phala.network
 # Public IP address
 PUBLIC_IP=$(curl -s ifconfig.me)
 
-# Gateway application ID. Register the app in KmsAuth first to get the app ID.
+# Gateway application ID. Register the app in DstackKms first to get the app ID.
 GATEWAY_APP_ID=0x31884c4b7775affe4c99735f6c2aff7d7bc6cfcd
 
 # Whether to use ACME staging (yes/no)
@@ -262,7 +262,7 @@ GUEST_AGENT_ADDR: 127.0.0.1:9206
 Continue? [y/N]
 ```
 
-Don't press `y` yet. We need to add the compose hash to the AppAuth contract first. Go back to the `kms/auth-eth` directory and run the following command:
+Don't press `y` yet. We need to add the compose hash to the DstackApp contract first. Go back to the `kms/auth-eth` directory and run the following command:
 
 ```bash
 npx hardhat app:add-hash --network phala --app-id 0x31884c4b7775affe4c99735f6c2aff7d7bc6cfcd 0x700a50336df7c07c82457b116e144f526c29f6d8f4a0946b3e88065c9beba0f4
@@ -294,8 +294,8 @@ After the dstack-vmm is ready, you can deploy an app on it following the steps b
 
 The on-chain registration process includes two steps:
 
-1. Deploy an App's control contract AppAuth. Developers can develop their own or choose the reference contract from the Dstack repository. Custom contracts need to implement the IAppAuth interface.
-2. Call KmsAuth.registerApp(appAuthAddress) to register the contract.
+1. Deploy an App's control contract DstackApp. Developers can develop their own or choose the reference contract from the Dstack repository. Custom contracts need to implement the IAppAuth interface.
+2. Call DstackKms.registerApp(appContractAddress) to register the contract.
 
 The Dstack repository provides scripts to complete these two steps:
 
@@ -320,10 +320,10 @@ Command output:
 Deploying with account: 0x8626f6940E2eb28930eFb4CeF49B2d1F2C9C1199
 Account balance: 9999.995278992293365404
 App ID: 0xA35b434eE853fdf9c2Bf48Fa1583Ac1332d50255
-Starting AppAuth deployment process...
+Starting DstackApp deployment process...
 Deploying proxy...
 Waiting for deployment...
-AppAuth deployed to: 0xD4a546B1C7e63CD4CeD314b2C90108e49191A915
+DstackApp deployed to: 0xD4a546B1C7e63CD4CeD314b2C90108e49191A915
 Implementation deployed to: 0x5aC1671E1Df54994D023F0B05806821d6D84e086
 Deployment completed successfully
 Transaction hash: 0xceac2ac6d56a40fef903b947d3a05df42ccce66da7f356c5d54afda68277f9a9
@@ -348,7 +348,7 @@ If you need to upgrade the contract in the future, please backup the `.openzeppe
 
 Build app-compose.json and calculate its sha256 to get compose-hash. The compose hash can also be previewed in the dstack-vmm UI.
 
-Call the hardhat command to add it to the whitelist (using AppAuth as an example here; custom AppAuth follows its own custom permission control logic).
+Call the hardhat command to add it to the whitelist (using DstackApp as an example here; custom DstackApp follows its own custom permission control logic).
 
 ```bash
 export PRIVATE_KEY=<your eth private key here>
@@ -360,7 +360,7 @@ npx hardhat app:add-hash --network phala --app-id 0xA35b434eE853fdf9c2Bf48Fa1583
 ![app deploy](assets/app-deploy.png)
 - Select image `dstack-0.4.2`
 - Fill in the AppId applied in the contract during deployment
-- Currently, test KmsAuth has set a whitelist for Base image, requiring instance memory to be `≥ 3G` or exactly `= 2G`
+- Currently, test DstackKms has set a whitelist for Base image, requiring instance memory to be `≥ 3G` or exactly `= 2G`
 
 After the app starts normally, click [Board] to access.
 

gateway/dstack-app/deploy-to-vmm.sh

@@ -52,7 +52,7 @@ else
 # Public IP address
 PUBLIC_IP=$(curl -s4 ifconfig.me)
 
-# The dstack-gateway application ID. Register the app in KmsAuth first to get the app ID.
+# The dstack-gateway application ID. Register the app in DstackKms first to get the app ID.
 # GATEWAY_APP_ID=31884c4b7775affe4c99735f6c2aff7d7bc6cfcd
 
 # Whether to use ACME staging (yes/no)

kms/README.md

@@ -46,13 +46,13 @@ CVMs running in dstack support three boot modes:
      2. App control contract check
 
 3. **Authorization Contracts**
-   - `KmsAuth.sol`
+   - `DstackKms.sol`
       - Maintains a registry for all Applications
       - Maintains the allowed KMS Instance MRs
       - Maintains the allowed OS Images
       - Registers KMS root keys
-   - `AppAuth.sol`
-      - Apps can have either a dedicated `AppAuth` contract or share one with multiple apps
+   - `DstackApp.sol`
+      - Apps can have either a dedicated `DstackApp` contract or share one with multiple apps
       - Controls permissions for individual apps
       - Maintains the allowed compose hashes for each app
 
@@ -93,19 +93,19 @@ During bootstrapping, the KMS node generates two root keys:
 1. CA root key: Used to issue x509 certificates for Apps, enabling HTTPS traffic
 2. K256 root key: Used to derive Ethereum-compatible keys for Apps
 
-After generating the root keys, their public portions can be obtained along with the corresponding TDX quote and registered in the KmsAuth contract.
+After generating the root keys, their public portions can be obtained along with the corresponding TDX quote and registered in the DstackKms contract.
 
 #### KMS Self Replication
 When deploying a new KMS instance (`B`) using an existing instance (`A`), the process follows these steps:
 
 1. **Prerequisites**
-   - Register allowed MRs of instance `B` in the KmsAuth contract
+   - Register allowed MRs of instance `B` in the DstackKms contract
 
 2. **Replication Flow**
    - Configure instance `B` with the URL of existing instance `A`
    - Instance `B` sends replication request to instance `A` via RA-TLS based RPC
    - Instance `A` validates instance `B`'s TDX quote
-   - Instance `A` checks KmsAuth contract for permissions
+   - Instance `A` checks DstackKms contract for permissions
    - If approved, instance `A` transfers root keys to instance `B`
 
 After the replication is complete, the KMS node becomes a fully functional KMS node.
@@ -117,7 +117,7 @@ Once onboarded, the KMS node begins listening for app key provisioning requests.
 
 When a KMS node receives a key provisioning request, it:
 1. Validates the TDX quote of the requesting App
-2. Queries the KmsAuth contract for provisioning allowance
+2. Queries the DstackKms contract for provisioning allowance
 3. If allowed, generates and sends the keys to the App
 
 ### Attestation
@@ -134,7 +134,7 @@ As a simpler approach, an App can verify the signature chain using the KMS root
 
 For example, given a message `M` signed by an App with signature `Sm`, the chain of trust works as follows:
 
-1. The KMS maintains the root key `sK0`, with its corresponding public key `pK0` registered in the KmsAuth contract
+1. The KMS maintains the root key `sK0`, with its corresponding public key `pK0` registered in the DstackKms contract
 2. The App receives an app-key `sK1` from the KMS, along with signature `S1` (signed by `sK0`)
 3. The App derives a purpose-specific key `sK2` from `sK1`, with signature `S2` (signed by `sK1`)
 4. The App uses `sK2` to sign message `M`, producing signature `Sm`
@@ -146,7 +146,7 @@ The verification process follows these steps:
 1. Recover `pK2` from `Sm` and `M`
 2. Recover `pK1` from `S2` and `pK2` + `<purpose-id>`
 3. Recover `pK0` from `S1` and `pK1` + `<app-id>`
-4. Compare the recovered `pK0` with the registered `pK0` in the KmsAuth contract
+4. Compare the recovered `pK0` with the registered `pK0` in the DstackKms contract
 
 ## The RPC Interface