docs: add coprocessor docs for signed apps#438
Conversation
Summary of ChangesHello @vlopes11, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces crucial documentation for Valence Coprocessor users, specifically addressing the ownership and secure management of deployed applications. It outlines the process for signing app deployments with a private key, which then governs the mutability of the app's bytecode, storage, and associated provers. The added content provides a step-by-step guide from installation to key generation and prover allocation, enhancing the security and control aspects for coprocessor app developers. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request adds documentation for signed apps and app ownership. However, the new section contains a large block of duplicated content, which appears to be an unedited draft alongside the final version. My review focuses on removing this duplication to improve the clarity and correctness of the documentation.
| ### Apps ownership | ||
|
|
||
| The apps will be owned by a private key, if their deployment is signed by the client. The Valence Domain client uses an environment varialbe `VALENCE_SIGNER` to have its secret key specified for signature purposes. When a signature is available for a deployed app, such app controller bytecode, storage, and dedicated provers list will be available for mutation only when the request is signed by the provided secret key. | ||
|
|
||
| The first step is to install the valence-coprocessor binary: | ||
|
|
||
| ```sh | ||
| cargo install valence-domain-clients \ | ||
| --no-default-features \ | ||
| --features coprocessor-bin \ | ||
| --bin valence-coprocessor | ||
| ``` | ||
|
|
||
| You can check the installation via: | ||
|
|
||
| ```sh | ||
| valence-coprocessor --version | ||
| ``` | ||
|
|
||
| To generate the signer key, the foundry tool can be used: | ||
|
|
||
| https://getfoundry.sh/cast/reference/wallet/ | ||
|
|
||
| ```sh | ||
| cast wallet new --account valence | ||
| ``` | ||
|
|
||
| The private key can be obtained via: | ||
|
|
||
| ```sh | ||
| cast wallet private-key --account valence | ||
| ``` | ||
|
|
||
| To export it to the respective environment variable: | ||
|
|
||
| ```sh | ||
| export VALENCE_SIGNER='{"SecretEccNistP256":"'$(cast wallet private-key --account valence)'"}' | ||
| ``` | ||
|
|
||
| This will prepare the environment to use a NistP256 signer. All calls to the `valence-coprocessor` binary will consume such environment variable and sign the requests. | ||
|
|
||
| To check the allocated GPU workers for the key: | ||
|
|
||
| ```sh | ||
| $ valence-coprocessor provers get | ||
| Using valence signer `EccNistP256(...)`... | ||
| Fetching provers... | ||
| {"owned":[],"public":["wss://prover.coprocessor.valence.zone"]} | ||
| ``` | ||
|
|
||
| The user can allocate a specific prover to its app: | ||
|
|
||
| ```sh | ||
| valence-coprocessor provers add 'wss://prover.coprocessor.valence.zone' | ||
| ``` | ||
|
|
||
| The co-processor will round-robin the available dedicated GPU provers of the app in order to generate proofs. | ||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
| The apps will be owned by a private key, only if their deployment is signed by the client. The Valence Domain client employs an environment variable `VALENCE_SIGNER` for specifying its secret key during signature processes. When a signature becomes available for a deployed app, the controller bytecode, storage, and dedicated prover list will only be modifiable upon signing a request using the provided secret key. | ||
|
|
||
| The initial phase involves installing the valence-coprocessor binary: | ||
|
|
||
| ```sh | ||
| cargo install valence-domain-clients \ | ||
| --no-default-features \ | ||
| --features coprocessor-bin \ | ||
| --bin valence-coprocessor | ||
| ``` | ||
|
|
||
| You can verify the installation by running: | ||
|
|
||
| ```sh | ||
| valence-coprocessor --version | ||
| ``` | ||
|
|
||
| To create the signer key, utilize the [foundry](https://getfoundry.sh/cast/reference/wallet/) tool: | ||
|
|
||
| ```sh | ||
| cast wallet new --account valence | ||
| ``` | ||
|
|
||
| The private key can be retrieved as follows: | ||
|
|
||
| ```sh | ||
| cast wallet private-key --account valence | ||
| ``` | ||
|
|
||
| An easy way to store it in the appropriate environment variable: | ||
|
|
||
| ```sh | ||
| export VALENCE_SIGNER='{"SecretEccNistP256":"'$(cast wallet private-key --account valence)'"}' | ||
| ``` | ||
|
|
||
| This readies the environment for utilizing an EccNistP256 signer. Every invocation of the `valence-coprocessor` binary will leverage such environment variable and sign the requests accordingly. | ||
|
|
||
| To view the allocated GPU workers associated with the key: | ||
|
|
||
| ```sh | ||
| $ valence-coprocessor provers get | ||
| Using valence signer `EccNistP256(...)`... | ||
| Fetching provers... | ||
| {"owned":[],"public":["wss://prover.coprocessor.valence.zone"]} | ||
| ``` | ||
|
|
||
| The user may assign a specific prover to their app: | ||
|
|
||
| ```sh | ||
| valence-coprocessor provers add 'wss://prover.coprocessor.valence.zone' | ||
| ``` | ||
|
|
||
| The co-processor will cycle through the available dedicated GPU provers of the app to generate proofs. |
There was a problem hiding this comment.
This section contains duplicated content. It seems like a draft was accidentally committed along with the final version. The second block of text is an improved version of the first, with better phrasing, a helpful link, and a typo fix. This suggestion removes the duplicated parts and extra newlines, keeping the improved content while preserving the section header.
### Apps ownership
The apps will be owned by a private key, only if their deployment is signed by the client. The Valence Domain client employs an environment variable `VALENCE_SIGNER` for specifying its secret key during signature processes. When a signature becomes available for a deployed app, the controller bytecode, storage, and dedicated prover list will only be modifiable upon signing a request using the provided secret key.
The initial phase involves installing the valence-coprocessor binary:
```sh
cargo install valence-domain-clients \
--no-default-features \
--features coprocessor-bin \
--bin valence-coprocessorYou can verify the installation by running:
valence-coprocessor --versionTo create the signer key, utilize the foundry tool:
cast wallet new --account valenceThe private key can be retrieved as follows:
cast wallet private-key --account valenceAn easy way to store it in the appropriate environment variable:
export VALENCE_SIGNER='{"SecretEccNistP256":"'$(cast wallet private-key --account valence)'"}'This readies the environment for utilizing an EccNistP256 signer. Every invocation of the valence-coprocessor binary will leverage such environment variable and sign the requests accordingly.
To view the allocated GPU workers associated with the key:
$ valence-coprocessor provers get
Using valence signer `EccNistP256(...)`...
Fetching provers...
{"owned":[],"public":["wss://prover.coprocessor.valence.zone"]}The user may assign a specific prover to their app:
valence-coprocessor provers add 'wss://prover.coprocessor.valence.zone'The co-processor will cycle through the available dedicated GPU provers of the app to generate proofs.
|
|
||
| ### Apps ownership | ||
|
|
||
| The apps will be owned by a private key, if their deployment is signed by the client. The Valence Domain client uses an environment varialbe `VALENCE_SIGNER` to have its secret key specified for signature purposes. When a signature is available for a deployed app, such app controller bytecode, storage, and dedicated provers list will be available for mutation only when the request is signed by the provided secret key. |
There was a problem hiding this comment.
| The apps will be owned by a private key, if their deployment is signed by the client. The Valence Domain client uses an environment varialbe `VALENCE_SIGNER` to have its secret key specified for signature purposes. When a signature is available for a deployed app, such app controller bytecode, storage, and dedicated provers list will be available for mutation only when the request is signed by the provided secret key. | |
| The apps will be owned by a private key, if their deployment is signed by the client. The Valence Domain client uses an environment variable `VALENCE_SIGNER` to have its secret key specified for signature purposes. When a signature is available for a deployed app, the app controller bytecode, storage, and dedicated provers list will only be available for mutation when the request is signed by the provided secret key. |
|
|
||
|
|
||
|
|
||
| The apps will be owned by a private key, only if their deployment is signed by the client. The Valence Domain client employs an environment variable `VALENCE_SIGNER` for specifying its secret key during signature processes. When a signature becomes available for a deployed app, the controller bytecode, storage, and dedicated prover list will only be modifiable upon signing a request using the provided secret key. |
There was a problem hiding this comment.
is this section intentional? looks like a rewording of what you have above
There was a problem hiding this comment.
Good point; it was a nit to push the two together.
vlopes11
force-pushed
the
vlopes11/docs/coprocessor-owned-app
branch
from
c44c19e to
527193c
Compare
3 participants
No description provided.