diff --git a/bento/README.md b/bento/README.md index a8604defa..0e9c69d45 100644 --- a/bento/README.md +++ b/bento/README.md @@ -249,7 +249,7 @@ Bento supports optional Proof of Verifiable Work for enhanced security: ```bash # Enable POVW -export POVW_LOG_ID="0x0000000000000000000000000000000000000000" +export REWARDS_ADDRESS="0x0000000000000000000000000000000000000000" # Start agents with POVW support cargo run -p workflow -- join --task-stream join @@ -285,7 +285,7 @@ When POVW is enabled: | `DATABASE_URL` | PostgreSQL connection string | Required | | `REDIS_URL` | Redis connection string | Required | | `RISC0_DEV_MODE` | Enable development mode | `false` | -| `POVW_LOG_ID` | POVW log identifier | Required to enable POVW | +| `REWARDS_ADDRESS`| Rewards address for POVW | Required to enable POVW | ### Agent Configuration diff --git a/compose.yml b/compose.yml index ef3b3df72..ece4aca58 100644 --- a/compose.yml +++ b/compose.yml @@ -10,7 +10,8 @@ x-base-environment: &base-environment RUST_LOG: ${RUST_LOG:-info} RISC0_HOME: /usr/local/risc0 RUST_BACKTRACE: 1 - POVW_LOG_ID: ${POVW_LOG_ID:-} + REWARDS_ADDRESS: ${REWARDS_ADDRESS:-${POVW_LOG_ID:-}} + POVW_LOG_ID: ${REWARDS_ADDRESS:-${POVW_LOG_ID:-}} x-agent-common: &agent-common runtime: nvidia build: diff --git a/crates/boundless-cli/src/commands/povw/claim.rs b/crates/boundless-cli/src/commands/povw/claim.rs index 2ed484210..da45e5f5e 100644 --- a/crates/boundless-cli/src/commands/povw/claim.rs +++ b/crates/boundless-cli/src/commands/povw/claim.rs @@ -46,17 +46,13 @@ const HOUR: Duration = Duration::from_secs(60 * 60); #[non_exhaustive] #[derive(Args, Clone, Debug)] pub struct PovwClaim { - // TODO(povw): Support providing multiple log IDs. - /// Work log ID for the reward claim. + // TODO(povw): Support providing multiple rewards addresses. + /// Rewards address for the reward claim. /// - /// State for submitted updates is retrieved from the chain using the ID. Note that initiating - /// the claim can be done for any log ID and does not require authorization. - /// Work log ID for the reward claim. - /// - /// State for submitted updates is retrieved from the chain using the ID. Note that initiating - /// the claim can be done for any log ID and does not require authorization. - #[arg(short, long)] - pub log_id: PovwLogId, + /// State for submitted updates is retrieved from the chain using the address. Note that initiating + /// the claim can be done for any rewards address and does not require authorization. + #[arg(short, long = "rewards-address", alias = "log-id")] + pub rewards_address: PovwLogId, // TODO: Deprecate and/or remove this when history support works without the Beacon API. /// URL for an Ethereum Beacon chain (i.e. consensus chain) API. @@ -141,20 +137,24 @@ impl PovwClaim { // Determine the commit range for which we can mint. This is the difference between the // recoreded work log commit on the accounting contract and on the mint contract. let initial_commit = Digest::from( - *povw_mint.workLogCommit(self.log_id.into()).call().await.with_context(|| { - format!( - "Failed to call IPovwMint.workLogCommit on {}", - deployment.povw_mint_address - ) - })?, + *povw_mint.workLogCommit(self.rewards_address.into()).call().await.with_context( + || { + format!( + "Failed to call IPovwMint.workLogCommit on {}", + deployment.povw_mint_address + ) + }, + )?, ); let final_commit = Digest::from( - *povw_accounting.workLogCommit(self.log_id.into()).call().await.with_context(|| { - format!( - "Failed to call IPovwAccounting.workLogCommit on {}", - deployment.povw_accounting_address - ) - })?, + *povw_accounting.workLogCommit(self.rewards_address.into()).call().await.with_context( + || { + format!( + "Failed to call IPovwAccounting.workLogCommit on {}", + deployment.povw_accounting_address + ) + }, + )?, ); tracing::debug!(%initial_commit, %final_commit, "Commit range for mint"); @@ -167,7 +167,7 @@ impl PovwClaim { tracing::info!("Searching for work log update events in the past {} days", self.days); let update_events = search_work_log_updated( &povw_accounting, - self.log_id, + self.rewards_address, initial_commit, final_commit, latest_block_number, @@ -256,7 +256,7 @@ impl PovwClaim { tracing::info!("Building input data for Mint Calculator guest"); let mint_input = mint_calculator_prover - .build_input(event_block_numbers, [self.log_id]) + .build_input(event_block_numbers, [self.rewards_address]) .await .context("Failed to build input for Mint Calculator Guest")?; @@ -365,7 +365,7 @@ async fn block_number_near_timestamp( /// found [WorkLogUpdated] events along with the block number at which they were emitted. async fn search_work_log_updated( povw_accounting: &IPovwAccountingInstance, - log_id: PovwLogId, + rewards_address: PovwLogId, initial_commit: Digest, final_commit: Digest, upper_limit_block_number: u64, @@ -392,7 +392,7 @@ async fn search_work_log_updated( let filter = Filter::new() .address(*povw_accounting.address()) .event_signature(WorkLogUpdated::SIGNATURE_HASH) - .topic1(Address::from(log_id)); + .topic1(Address::from(rewards_address)); tracing::debug!(%initial_commit, %final_commit, %upper_limit_block_number, %lower_limit_block_number, "Searching for WorkLogUpdated events"); search_events( diff --git a/crates/boundless-cli/src/commands/povw/prepare.rs b/crates/boundless-cli/src/commands/povw/prepare.rs index b5472903f..7d5cdc81d 100644 --- a/crates/boundless-cli/src/commands/povw/prepare.rs +++ b/crates/boundless-cli/src/commands/povw/prepare.rs @@ -29,17 +29,17 @@ use super::{State, WorkReceipt}; #[non_exhaustive] #[derive(Args, Clone, Debug)] pub struct PovwPrepare { - /// Create a new work log with the given work log identifier. + /// Create a new work log with the given rewards address. /// - /// The work log identifier is a 160-bit public key hash (i.e. an Ethereum address) which is + /// The rewards address is a 160-bit public key hash (i.e. an Ethereum address) which is /// used to identify the work log. A work log is a collection of work claims, including their /// value and nonces. A single work log can only include a nonce (and so a receipt) once. /// - /// A prover may have one or more work logs, and may set the work log ID equal to their onchain - /// prover address, or to a new address just used as the work log ID. + /// A prover may have one or more work logs, and may set the rewards address equal to their onchain + /// prover address, or to a new address just used as the rewards address. /// If this not set, then the state file must exist. - #[arg(short, long = "new")] - new_log_id: Option, + #[arg(short, long = "new", alias = "new-log-id")] + new_rewards_address: Option, /// Path of the work log state file to load the work log and store the prepared update. #[arg(short, long, env = "POVW_STATE_PATH")] @@ -74,17 +74,17 @@ impl PovwPrepare { /// Run the [PovwPrepare] command. pub async fn run(&self) -> Result<()> { // Load the existing state, if provided. - let mut state = if let Some(log_id) = self.new_log_id { + let mut state = if let Some(log_id) = self.new_rewards_address { if self.state.exists() { bail!("File already exists at the state path; refusing to overwrite"); } - tracing::info!("Initializing a new work log with ID {log_id:x}"); + tracing::info!("Initializing a new work log with rewards address {log_id:x}"); State::new(log_id) } else { let state = State::load(&self.state).await.context("Failed to load state file")?; tracing::info!("Loaded work log state from {}", self.state.display(),); tracing::debug!(commit = %state.work_log.commit(), "Loaded work log commit"); - tracing::info!("Preparing work log update for log ID: {:x}", state.log_id); + tracing::info!("Preparing work log update for rewards address: {:x}", state.log_id); state }; @@ -236,7 +236,7 @@ fn check_work_receipt>( // NOTE: If nonce_max does not have the same log ID as nonce_min, the exec will fail. ensure!( work_claim.nonce_min.log == log_id, - "Receipt has a log ID that does not match the work log: receipt: {:x}, work log: {:x}", + "Receipt has a rewards address that does not match the work log: receipt: {:x}, work log: {:x}", work_claim.nonce_min.log, log_id ); diff --git a/crates/boundless-cli/src/commands/povw/submit.rs b/crates/boundless-cli/src/commands/povw/submit.rs index 5035476b6..d024ea1ec 100644 --- a/crates/boundless-cli/src/commands/povw/submit.rs +++ b/crates/boundless-cli/src/commands/povw/submit.rs @@ -42,13 +42,18 @@ pub struct PovwSubmit { #[arg(short, long, env = "POVW_STATE_PATH")] pub state: PathBuf, - /// Private key used to sign work log updates. Should have an address equal to the work log ID. + /// Private key used to sign work log updates. Should have an address equal to the rewards address. /// /// If this option is not set, the value of the private key from global config will be used. - #[clap(long, env = "POVW_PRIVATE_KEY", hide_env_values = true)] - pub povw_private_key: Option, - - /// The address to assign any PoVW rewards to. If not provided, defaults to the work log ID. + #[clap( + long = "rewards-address-private-key", + alias = "povw-private-key", + env = "REWARDS_ADDRESS_PRIVATE_KEY", + hide_env_values = true + )] + pub rewards_private_key: Option, + + /// The address to assign any PoVW rewards to. If not provided, defaults to the rewards address. #[clap(short, long, env = "POVW_VALUE_RECIPIENT")] pub value_recipient: Option
, @@ -64,18 +69,18 @@ impl PovwSubmit { /// Run the [PovwSubmit] command. pub async fn run(&self, global_config: &GlobalConfig) -> anyhow::Result<()> { let tx_signer = global_config.require_private_key()?; - let work_log_signer = self.povw_private_key.as_ref().unwrap_or(&tx_signer); + let work_log_signer = self.rewards_private_key.as_ref().unwrap_or(&tx_signer); let rpc_url = global_config.require_rpc_url()?; // Load the state and check to make sure the private key matches. let mut state = State::load(&self.state) .await .with_context(|| format!("Failed to load state from {}", self.state.display()))?; - tracing::info!("Submitting work log update for log ID: {:x}", state.log_id); + tracing::info!("Submitting work log update for rewards address: {:x}", state.log_id); ensure!( Address::from(state.log_id) == work_log_signer.address(), - "Signer does not match the state log ID: signer: {}, state: {}", + "Signer does not match the rewards address: signer: {}, state: {}", work_log_signer.address(), state.log_id ); diff --git a/crates/boundless-cli/tests/povw.rs b/crates/boundless-cli/tests/povw.rs index 571dccb98..716dee6df 100644 --- a/crates/boundless-cli/tests/povw.rs +++ b/crates/boundless-cli/tests/povw.rs @@ -161,7 +161,7 @@ async fn prove_and_send_update() -> anyhow::Result<()> { .env("PRIVATE_KEY", format!("{:#x}", tx_signer.to_bytes())) .env("RISC0_DEV_MODE", "1") .env("RPC_URL", ctx.anvil.lock().await.endpoint_url().as_str()) - .env("POVW_PRIVATE_KEY", format!("{:#x}", work_log_signer.to_bytes())) + .env("REWARDS_ADDRESS_PRIVATE_KEY", format!("{:#x}", work_log_signer.to_bytes())) .assert() .success() // 4. Confirm that the command logs success @@ -271,7 +271,7 @@ async fn claim_reward_multi_epoch() -> anyhow::Result<()> { .env("PRIVATE_KEY", format!("{:#x}", tx_signer.to_bytes())) .env("RISC0_DEV_MODE", "1") .env("RPC_URL", ctx.anvil.lock().await.endpoint_url().as_str()) - .env("POVW_PRIVATE_KEY", format!("{:#x}", work_log_signer.to_bytes())); + .env("REWARDS_ADDRESS_PRIVATE_KEY", format!("{:#x}", work_log_signer.to_bytes())); let result = cmd.assert().success().stdout(contains("Work log update confirmed")); @@ -291,7 +291,7 @@ async fn claim_reward_multi_epoch() -> anyhow::Result<()> { // Run the claim command to mint the accumulated rewards println!("Running claim command"); let mut cmd = Command::cargo_bin("boundless")?; - cmd.args(["povw", "claim", "--log-id", &format!("{:#x}", log_id)]) + cmd.args(["povw", "claim", "--rewards-address", &format!("{:#x}", log_id)]) .env("NO_COLOR", "1") .env("RUST_LOG", "boundless_cli=debug,info") .env("POVW_ACCOUNTING_ADDRESS", format!("{:#x}", ctx.povw_accounting.address())) @@ -383,7 +383,7 @@ async fn claim_on_partially_finalized_epochs() -> anyhow::Result<()> { .env("PRIVATE_KEY", format!("{:#x}", tx_signer.to_bytes())) .env("RISC0_DEV_MODE", "1") .env("RPC_URL", ctx.anvil.lock().await.endpoint_url().as_str()) - .env("POVW_PRIVATE_KEY", format!("{:#x}", work_log_signer.to_bytes())); + .env("REWARDS_ADDRESS_PRIVATE_KEY", format!("{:#x}", work_log_signer.to_bytes())); let result = cmd.assert().success().stdout(contains("Work log update confirmed")); @@ -434,7 +434,7 @@ async fn claim_on_partially_finalized_epochs() -> anyhow::Result<()> { .env("PRIVATE_KEY", format!("{:#x}", tx_signer.to_bytes())) .env("RISC0_DEV_MODE", "1") .env("RPC_URL", ctx.anvil.lock().await.endpoint_url().as_str()) - .env("POVW_PRIVATE_KEY", format!("{:#x}", work_log_signer.to_bytes())); + .env("REWARDS_ADDRESS_PRIVATE_KEY", format!("{:#x}", work_log_signer.to_bytes())); let result = cmd.assert().success().stdout(contains("Work log update confirmed")); @@ -448,7 +448,7 @@ async fn claim_on_partially_finalized_epochs() -> anyhow::Result<()> { // Will warn about the second epoch. println!("Running claim command"); let mut cmd = Command::cargo_bin("boundless")?; - cmd.args(["povw", "claim", "--log-id", &format!("{:#x}", log_id)]) + cmd.args(["povw", "claim", "--rewards-address", &format!("{:#x}", log_id)]) .env("NO_COLOR", "1") .env("RUST_LOG", "boundless_cli=debug,info") .env("POVW_ACCOUNTING_ADDRESS", format!("{:#x}", ctx.povw_accounting.address())) diff --git a/documentation/site/pages/zkc/povw-claiming-rewards.mdx b/documentation/site/pages/zkc/povw-claiming-rewards.mdx index 7999c6001..71f3af9cd 100644 --- a/documentation/site/pages/zkc/povw-claiming-rewards.mdx +++ b/documentation/site/pages/zkc/povw-claiming-rewards.mdx @@ -60,17 +60,17 @@ Bento and/or broker can be safely stopped with: just broker down ``` -#### Specify the Log ID Address +#### Specify the Rewards Address :::note[PoVW Specific Terminology] It is recommended to read the [Terminology](/zkc/povw-claiming-rewards#terminology) section before running the commands listed below. ::: :::tip[Tip] -Provers can use their Log ID as their $ZKC staking address; for simplicity, the following tutorial uses the Log ID to stake $ZKC as well. In practice, provers may decide to use a separate wallet to stake $ZKC. For more information, see [Key Separation](#key-separation). +Provers can use their rewards address as their $ZKC staking address; for simplicity, the following tutorial uses the rewards address to stake $ZKC as well. In practice, provers may decide to use a separate wallet to stake $ZKC. For more information, see [Key Separation](#key-separation). ::: -Before starting Bento again, provers need to enable the PoVW feature. This requires a valid Ethereum address set to the `POVW_LOG_ID` environment variable. It is recommended to set this directly with your compose.yml file: +Before starting Bento again, provers need to enable the PoVW feature. This requires a valid Ethereum address set to the `REWARDS_ADDRESS` environment variable. It is recommended to set this directly with your compose.yml file: ```yml x-base-environment: &base-environment @@ -83,14 +83,14 @@ x-base-environment: &base-environment RUST_LOG: ${RUST_LOG:-info} RISC0_HOME: /usr/local/risc0 RUST_BACKTRACE: 1 - POVW_LOG_ID: "0x1234...5678" // [!code hl] [!code focus] + REWARDS_ADDRESS: "0x1234...5678" // [!code hl] [!code focus] ``` Provers will need the private key for this address when using the PoVW CLI to prepare and submit valid work to the PoVW contracts. Please see [Provers submit a Work Log Update](/zkc/povw-claiming-rewards#provers-submit-a-work-log-update-with-submit) for more information. #### Export the PRIVATE_KEY and RPC_URL environment variables -Export the private key for the `POVW_LOG_ID`, and a valid RPC endpoint URL for Ethereum mainnet: +Export the private key for the `REWARDS_ADDRESS`, and a valid RPC endpoint URL for Ethereum mainnet: ```bash export PRIVATE_KEY=[PRIVATE_KEY] @@ -121,7 +121,7 @@ Before continuing with the tutorial, it is recommended to read both the [Termino :::warning[PoVW rewards are claimed on Ethereum mainnet] -For all relevant commands below: `stake`, `delegate-rewards` and `submit`, the CLI will require a private key denoted by the environment variable `PRIVATE_KEY`. This must be the private key used for the `POVW_LOG_ID`. This private key that corresponds with `POVW_LOG_ID` will require funds on Ethereum Mainnet. +For all relevant commands below: `stake`, `delegate-rewards` and `submit`, the CLI will require a private key denoted by the environment variable `PRIVATE_KEY`. This must be the private key used for the `REWARDS_ADDRESS`. This private key that corresponds with `REWARDS_ADDRESS` will require funds on Ethereum Mainnet. ::: ::::steps @@ -138,10 +138,10 @@ First, make sure to set a valid RPC URL environment variable for Ethereum mainne export RPC_URL=https://... ``` -To check the current $ZKC balance of `POVW_LOG_ID`: +To check the current $ZKC balance of `REWARDS_ADDRESS`: ```bash -boundless zkc balance ${POVW_LOG_ID:?} --rpc-url ${RPC_URL} +boundless zkc balance ${REWARDS_ADDRESS:?} --rpc-url ${RPC_URL} ``` To stake 100 $ZKC, run the following command: @@ -161,14 +161,14 @@ For each proving job, R0VM will automatically generate [work receipts](/zkc/povw Once provers have run some jobs, they can create a new work log (i.e. state file) from receipts stored in Bento using `prepare`: ```bash -boundless povw prepare --new ${POVW_LOG_ID} --state ${STATE_FILE_LOCATION} --from-bento +boundless povw prepare --new ${REWARDS_ADDRESS} --state ${STATE_FILE_LOCATION} --from-bento ``` where `${STATE_FILE_LOCATION}` is something like: `~/folder/state.bin`. Please note that this state file is very important and it should be kept in a durable location. Please see [Keeping the State File Safe](/zkc/povw-claiming-rewards#keeping-the-state-file-safe). `prepare` compresses all work receipts and stores the work log update to the state file. This process is entirely local (i.e. it does not send any transaction). For this work to be eligible for $ZKC rewards from the PoVW contract, this work log update must now be sent onchain. -Provers only specify the `--new ${POVW_LOG_ID}` flag once, this is necessary to create the state file for that specific Log ID. Once the state file is created, for any further updates to the work log, run the following: +Provers only specify the `--new ${REWARDS_ADDRESS}` flag once, this is necessary to create the state file for that specific rewards address. Once the state file is created, for any further updates to the work log, run the following: ```bash boundless povw prepare --state ${STATE_FILE_LOCATION} --from-bento @@ -191,7 +191,7 @@ boundless povw submit --state ${STATE_FILE_LOCATION} --rpc-url ${RPC_URL} After the reward epoch has finalized, rewards can be claimed with: ```bash -boundless povw claim --log-id ${POVW_LOG_ID} --beacon-api-url${BEACON_CHAIN_RPC_ENDPOINT} --rpc-url ${RPC_URL} +boundless povw claim --rewards-address ${REWARDS_ADDRESS} --beacon-api-url${BEACON_CHAIN_RPC_ENDPOINT} --rpc-url ${RPC_URL} ``` ### Checking Details of Current Reward Epoch @@ -214,9 +214,9 @@ boundless zkc get-epoch-end-time | Term | Description | |------|-------------| -| **Log ID** | This is the Ethereum address set with the `POVW_LOG_ID` environment variable. This address can be the same as the one used for a prover on the Boundless Market, but it doesn't have to be. See [Recommended Practices](/zkc/povw-claiming-rewards#recommended-practices) for more information. | +| **Rewards Address** | This is the Ethereum address set with the `REWARDS_ADDRESS` environment variable. This address can be the same as the one used for a prover on the Boundless Market, but it doesn't have to be. See [Recommended Practices](/zkc/povw-claiming-rewards#recommended-practices) for more information. | | **Work Receipts** | For each proving workload, PoVW generates work receipts alongside the expected ZK proof. These work receipts are compressed into a “work log” update to post onchain. This work log update represents the combined work of all compressed work receipts. Work receipts are compressed using the `prepare` CLI command, and this process is entirely local. | -| **Work Log** | The work log is a record of work tracked against a specific log ID i.e. it represents a tally of all work done by that address. A work log commitment prevents “double-spending” of verifiable work when claiming PoVW rewards. The work log is updated using the `submit` CLI command, which takes a work log update (generated by `prepare`) and updates the commitment onchain to reflect all the work done by the log ID since the last update. | +| **Work Log** | The work log is a record of work tracked against a specific rewards address i.e. it represents a tally of all work done by that address. A work log commitment prevents "double-spending" of verifiable work when claiming PoVW rewards. The work log is updated using the `submit` CLI command, which takes a work log update (generated by `prepare`) and updates the commitment onchain to reflect all the work done by the rewards address since the last update. | | **Reward Epoch** | The PoVW reward epoch is approximately 2 days. Verifiable work submitted within a given epoch is eligible for that epoch’s reward emissions. To be eligible for these rewards, a prover must stake an amount of $ZKC that scales with the size of their rewards for a given epoch. For more information, please see this [blog post](https://boundless.network/blog/introducing-zk-coin). | @@ -242,11 +242,11 @@ The `prepare` command compresses all local work receipts to reflect work done du #### Provers submit a work log update with `submit` -Towards the end of an epoch, the prover must verify their work done to the PoVW contracts using the `submit` command. This will sign the work log update using the Log ID’s private key and post the update to the PoVW contracts. +Towards the end of an epoch, the prover must verify their work done to the PoVW contracts using the `submit` command. This will sign the work log update using the rewards address's private key and post the update to the PoVW contracts. #### Provers wait for current epoch to finalize -The prover waits for the current reward epoch to finalize. This allows all work log updates to be tallied, and all the respective rewards for each log ID to be calculated. +The prover waits for the current reward epoch to finalize. This allows all work log updates to be tallied, and all the respective rewards for each rewards address to be calculated. To check details of the current epoch, please see [Checking Details of Current Reward Epoch](/zkc/povw-claiming-rewards#checking-details-of-current-reward-epoch), @@ -264,15 +264,15 @@ Claiming rewards does not have to be done every epoch; all unclaimed rewards fro ### Key Separation -In PoVW, the prover specifies the Log ID which must be a valid Ethereum address. This **does not** have to be the same as the $ZKC staking wallet address or a Boundless prover address, though it can be used for all three purposes. Note that PoVW rewards are eligible for *all verifiable work*, not solely work done to prove Boundless market orders. Therefore, provers not connected to the Boundless market are still eligible for $ZKC rewards, provided they are proving during the epoch and they have staked $ZKC. +In PoVW, the prover specifies the rewards address which must be a valid Ethereum address. This **does not** have to be the same as the $ZKC staking wallet address or a Boundless prover address, though it can be used for all three purposes. Note that PoVW rewards are eligible for *all verifiable work*, not solely work done to prove Boundless market orders. Therefore, provers not connected to the Boundless market are still eligible for $ZKC rewards, provided they are proving during the epoch and they have staked $ZKC. -#### Separating the Staking Wallet from the Log ID +#### Separating the Staking Wallet from the Rewards Address -When [enabling PoVW in Bento](/zkc/povw-claiming-rewards#specify-the-log-id-address), provers specify the following environment variables: +When [enabling PoVW in Bento](/zkc/povw-claiming-rewards#specify-the-rewards-address), provers specify the following environment variables: ```bash -export POVW_LOG_ID="0x0000...0000" -export POVW_PRIVATE_KEY="..." +export REWARDS_ADDRESS="0x0000...0000" +export REWARDS_ADDRESS_PRIVATE_KEY="..." ``` To stake from a separate wallet, provers may additionally specify: @@ -282,10 +282,10 @@ export ZKC_WALLET_ADDRESS="0x0000...0000" export PRIVATE_KEY="..." ``` -Provers can now follow the [staking instructions](/zkc/povw-claiming-rewards#staking-zkc) to stake $ZKC from the `ZKC_WALLET_ADDRESS`. Once staked, provers must delegate rewards i.e. associate the `POVW_LOG_ID` with `ZKC_WALLET_ADDRESS`. This is done with the following command: +Provers can now follow the [staking instructions](/zkc/povw-claiming-rewards#staking-zkc) to stake $ZKC from the `ZKC_WALLET_ADDRESS`. Once staked, provers must delegate rewards i.e. associate the `REWARDS_ADDRESS` with `ZKC_WALLET_ADDRESS`. This is done with the following command: ```bash -boundless zkc delegate-rewards ${POVW_LOG_ID} +boundless zkc delegate-rewards ${REWARDS_ADDRESS} ``` This command uses the `PRIVATE_KEY` environment variable to send a transaction onchain, therefore funds are required on `ZKC_WALLET_ADDRESS`. @@ -294,7 +294,7 @@ Once the rewards are delegated, the prover can continue with the normal reward c #### Separating the Staking Wallet from the Value Recipient -Additionally, the prover can specify a separate Ethereum address to receive the $ZKC reward. By default this is the log ID, but you can override it with `--value-recipient
` when running `submit`. +Additionally, the prover can specify a separate Ethereum address to receive the $ZKC reward. By default this is the rewards address, but you can override it with `--value-recipient
` when running `submit`. #### Separating Keys when running a Boundless Prover @@ -302,12 +302,12 @@ Since many Boundless provers run clusters on hosted cloud providers, and because At the minimum, we recommend most provers separate their value recipient address, such that: -* Boundless Prover Address + Log ID Address can be the same +* Boundless Prover Address + Rewards Address can be the same * Value Recipient is a separate address -This setup allows the proving cluster to prove orders on the Boundless market and generate and post work log updates onchain to be eligible for rewards. It also means that after running `claim`, the reward $ZKC is transferred to a separate address. Claiming rewards is a permissionless process and does not require access to the private key for the Log ID. +This setup allows the proving cluster to prove orders on the Boundless market and generate and post work log updates onchain to be eligible for rewards. It also means that after running `claim`, the reward $ZKC is transferred to a separate address. Claiming rewards is a permissionless process and does not require access to the private key for the rewards address. ### Keeping the State File Safe -`prepare` uses a state file to track compressed work receipts. Loss of this state file **will result in the loss of all work that is not submitted** for the respective Log ID, meaning rewards for any work done since the last work log update (via `submit`) **will be lost**. In this scenario, a new work log ID must be specified for Bento, and Bento should be restarted to allow further work to be recorded properly against the new Log ID. *To avoid this scenario, it is recommended to store the state file in a durable location.* +`prepare` uses a state file to track compressed work receipts. Loss of this state file **will result in the loss of all work that is not submitted** for the respective rewards address, meaning rewards for any work done since the last work log update (via `submit`) **will be lost**. In this scenario, a new rewards address must be specified for Bento, and Bento should be restarted to allow further work to be recorded properly against the new rewards address. *To avoid this scenario, it is recommended to store the state file in a durable location.*