diff --git a/versioned_docs/version-v1.1.2/advanced/lido-csm.md b/versioned_docs/version-v1.1.2/advanced/lido-csm.md index 4e81b0fd79..6afd08ca91 100644 --- a/versioned_docs/version-v1.1.2/advanced/lido-csm.md +++ b/versioned_docs/version-v1.1.2/advanced/lido-csm.md @@ -60,7 +60,7 @@ Select `Split` for the contract type. ![Selecting Split Contract](/img/CSM_walkthrough6.png) -Add the reward addresses of all cluster members. Choose whether the contract is immutable (reccommended option), whether to sponsor the maintainers of [splits.org](https://splits.org), and optionally whether to set a distribution bounty such that third parties could pay the gas costs of distributing the accrued rewards in exchange for a small fee. +Add the reward addresses of all cluster members. Choose whether the contract is immutable (recommended option), whether to sponsor the maintainers of [splits.org](https://splits.org), and optionally whether to set a distribution bounty such that third parties could pay the gas costs of distributing the accrued rewards in exchange for a small fee. :::tip If your cluster would like to contribute a portion of its rewards to Obol’s '[1% for Decentralisation](https://blog.obol.org/1-percent-for-decentralisation/)' Retroactive Fund, thereby earning [Obol Contributions](https://obol.org/contributions) as part of Lido's [integration of CSM](https://research.lido.fi/t/integrate-csm-into-the-decentralized-validator-vault/8621) into the DV Vault, you must add [retroactivefunding.obol.eth](https://etherscan.io/address/0xDe5aE4De36c966747Ea7DF13BD9589642e2B1D0d) as a recipient of 0.1% of the splitter contract. This will contribute 0.1% of rewards **and your CSM bond** to Obol's RAF. Future versions of CSM integrations will enable contributing exactly 1% of accruing CSM rewards. diff --git a/versioned_docs/version-v1.1.2/advanced/monitoring.md b/versioned_docs/version-v1.1.2/advanced/monitoring.md index 1ad9cc06ec..62accafa2c 100644 --- a/versioned_docs/version-v1.1.2/advanced/monitoring.md +++ b/versioned_docs/version-v1.1.2/advanced/monitoring.md @@ -24,7 +24,7 @@ The local Grafana server will have a few pre-built dashboards: | Alert Name | Description | Troubleshoot | | --- | --- | --- | -| ClusterBeaconNodeDown | This alert is activated when the beacon node in a the cluster is offline. The beacon node is crucial for validating transactions and producing new blocks. Its unavailability could disrupt the overall functionality of the cluster. | Most likely data is corrupted. Wipe data from the point you know data was corrupted and restart beacon node so it can be synced again. | +| ClusterBeaconNodeDown | This alert is activated when the beacon node in the cluster is offline. The beacon node is crucial for validating transactions and producing new blocks. Its unavailability could disrupt the overall functionality of the cluster. | Most likely data is corrupted. Wipe data from the point you know data was corrupted and restart beacon node so it can be synced again. | | ClusterMissedAttestations | This alert indicates that there have been missed attestations in the cluster. Missed attestations may suggest that validators are not operating correctly, compromising the security and efficiency of the cluster. | This alert is triggered when 3 attestations are missed in 2 minutes. Check if the minimum threshold of peers are online. If correct, check for beacon node API errors and downstream validator errors using Loki. Lastly, debug from Docker using `docker compose debug`. | | ClusterInUnknownStatus | This alert is designed to activate when a node within the cluster is detected to be in an unknown state. The condition is evaluated by checking whether the maximum of the `app_monitoring_readyz` metric is 0. | This is most likely a bug in Charon. Report to us via [Discord](https://discord.com/channels/849256203614945310/970759460693901362). | | ClusterInsufficientPeers | This alert is set to activate when the number of peers for a node in the cluster is insufficient. The condition is evaluated by checking whether the maximum of the `app_monitoring_readyz` equals 4. | If you are running group cluster, check with other peers to troubleshoot the issue. If you are running solo cluster, look into other machines running the DVs to find the problem. | diff --git a/versioned_docs/version-v1.1.2/charon/charon-cli-reference.md b/versioned_docs/version-v1.1.2/charon/charon-cli-reference.md index 339d6c834a..5816ea0797 100644 --- a/versioned_docs/version-v1.1.2/charon/charon-cli-reference.md +++ b/versioned_docs/version-v1.1.2/charon/charon-cli-reference.md @@ -235,7 +235,7 @@ Flags: ## The `exit` command -A running Charon client will [aggregate and broadcast](../start/quickstart-exit.mdx) signed exit messages it receives from its valdiator client immediately. These `exit` commands are instead used to *pre-sign* exit messages for an active distributed validator, to save to disk, or to broadcast; once enough of the operators of the cluster have submitted their partial exit signatures. Fully signed exit messages give a user or protocol a guarantee that they can exit an active validator at any point in future without the further assistance of the cluster's operators. In future, [execution-layer initiated exits](https://eips.ethereum.org/EIPS/eip-7002) will provide an even stronger guarantee that a validator can be exited by the withdrawal address it belongs to. +A running Charon client will [aggregate and broadcast](../start/quickstart-exit.mdx) signed exit messages it receives from its validator client immediately. These `exit` commands are instead used to *pre-sign* exit messages for an active distributed validator, to save to disk, or to broadcast; once enough of the operators of the cluster have submitted their partial exit signatures. Fully signed exit messages give a user or protocol a guarantee that they can exit an active validator at any point in future without the further assistance of the cluster's operators. In future, [execution-layer initiated exits](https://eips.ethereum.org/EIPS/eip-7002) will provide an even stronger guarantee that a validator can be exited by the withdrawal address it belongs to. ```markdown charon exit --help diff --git a/versioned_docs/version-v1.1.2/faq/errors.mdx b/versioned_docs/version-v1.1.2/faq/errors.mdx index f4dbdc125e..343939a674 100644 --- a/versioned_docs/version-v1.1.2/faq/errors.mdx +++ b/versioned_docs/version-v1.1.2/faq/errors.mdx @@ -154,7 +154,7 @@ docker compose logs

- This could be linked to a internet connection being too slow or relying on + This could be linked to an internet connection being too slow or relying on a slow third-party service such as Infura.

@@ -263,7 +263,7 @@ docker compose logs Error opening relay circuit NO_RESERVATION (204) indicates the peer - isn't connected to the relay, so the the Charon client cannot connect to the + isn't connected to the relay, so the Charon client cannot connect to the peer via the relay. That might be because the peer is offline or the peer is configured to connect to a different relay.
@@ -482,7 +482,7 @@ docker compose logs
  • Bob's private key share(s) are imported to a VC that is connected to - Alice's Charon node. This is a invalid setup/deployment. Alice's Charon + Alice's Charon node. This is an invalid setup/deployment. Alice's Charon node should only be connected to Alice's VC.
  • diff --git a/versioned_docs/version-v1.1.2/faq/peer_score.md b/versioned_docs/version-v1.1.2/faq/peer_score.md index b12e9782d0..c4d8b36402 100644 --- a/versioned_docs/version-v1.1.2/faq/peer_score.md +++ b/versioned_docs/version-v1.1.2/faq/peer_score.md @@ -7,7 +7,7 @@ description: Measuring Individual Performance in Distributed Validators ## Introduction -Validator effectiveness is a critical metric for assessing the health of a rated network. It determines how well validators perform their attestation and block proposal duties. Existing solutions, like RAVER (Rated Validator Effectiveness Rating), provide a effectiveness score of a validator. In a monolithic validator that is run by a single operator, validator effectiveness can be considered as a proxy for the effectiveness or “score” of that operator. However, this approach falls short when dealing with distributed validators (DVs) maintained by multiple operators. +Validator effectiveness is a critical metric for assessing the health of a rated network. It determines how well validators perform their attestation and block proposal duties. Existing solutions, like RAVER (Rated Validator Effectiveness Rating), provide an effectiveness score of a validator. In a monolithic validator that is run by a single operator, validator effectiveness can be considered as a proxy for the effectiveness or “score” of that operator. However, this approach falls short when dealing with distributed validators (DVs) maintained by multiple operators. Peer Score v0 addresses this limitation by introducing a method to evaluate the performance of individual operators within a DV. This enables a more granular assessment of contribution within a distributed setting. @@ -42,6 +42,6 @@ Peer Score v0 lays the foundation for a more comprehensive evaluation system. Pl Peer Score offers valuable insights for various stakeholders: -- **Staking/Restaking Protocols:** Peer Score is crucial component of Obol’s Techne Credential Program. LSPs and LRPs can utilize Techne Credentials ,and hence Peer Score, to identify efficient operators for expanding their operator sets. +- **Staking/Restaking Protocols:** Peer Score is a crucial component of Obol’s Techne Credential Program. LSPs and LRPs can utilize Techne Credentials, and hence Peer Score, to identify efficient operators for expanding their operator sets. - **DV Operators:** Forming operator collectives based on peer effectiveness and potentially removing underperforming peers from DVs (with Charon v2 cluster mutability). - **DV Software Developers:** Establishing a standardized metric for evaluating operator performance across various DV software, enabling the development of new tools and services. diff --git a/versioned_docs/version-v1.1.2/int/key-concepts.md b/versioned_docs/version-v1.1.2/int/key-concepts.md index 0c0e84039b..4772b2fd72 100644 --- a/versioned_docs/version-v1.1.2/int/key-concepts.md +++ b/versioned_docs/version-v1.1.2/int/key-concepts.md @@ -20,7 +20,7 @@ Distributed validator technology removes some of the single points of failure in ![A Distributed Validator Node](/img/DVNode.png) -A distributed validator node is the set of clients an operator needs to configure and run to fulfil the duties of a Distributed Validator Operator. An operator may also run redundant execution and consensus clients, an execution payload relayer like [mev-boost](https://github.com/flashbots/mev-boost), or other monitoring or telemetry services on the same hardware to ensure optimal performance. +A distributed validator node is the set of clients an operator needs to configure and run to fulfill the duties of a Distributed Validator Operator. An operator may also run redundant execution and consensus clients, an execution payload relayer like [mev-boost](https://github.com/flashbots/mev-boost), or other monitoring or telemetry services on the same hardware to ensure optimal performance. In the above example, the stack includes Geth, Lighthouse, Charon and Teku. diff --git a/versioned_docs/version-v1.1.2/sdk/classes/Client.md b/versioned_docs/version-v1.1.2/sdk/classes/Client.md index efa5e2b25f..ae502f1198 100644 --- a/versioned_docs/version-v1.1.2/sdk/classes/Client.md +++ b/versioned_docs/version-v1.1.2/sdk/classes/Client.md @@ -79,7 +79,7 @@ Deploys OWR and Splitter Proxy. `Promise`\<[`ClusterValidator`](../type-aliases/ClusterValidator.md)\> -owr address as withdrawal address and splitter as fee recipient +our address as withdrawal address and splitter as fee recipient An example of how to use createObolRewardsSplit: [createObolRewardsSplit](https://github.com/ObolNetwork/obol-sdk-examples/blob/main/TS-Example/index.ts#L141) @@ -105,7 +105,7 @@ Deploys Splitter Proxy. | Parameter | Type | Description | | ------ | ------ | ------ | -| `totalSplitPayload` | [`TotalSplitPayload`](../type-aliases/TotalSplitPayload.md) | Data needed to deploy splitter if it doesnt exist. | +| `totalSplitPayload` | [`TotalSplitPayload`](../type-aliases/TotalSplitPayload.md) | Data needed to deploy splitter if it doesn't exist. | #### Returns diff --git a/versioned_docs/version-v1.1.2/sdk/type-aliases/DepositData.md b/versioned_docs/version-v1.1.2/sdk/type-aliases/DepositData.md index 7659bf7e98..e719c7b3b2 100644 --- a/versioned_docs/version-v1.1.2/sdk/type-aliases/DepositData.md +++ b/versioned_docs/version-v1.1.2/sdk/type-aliases/DepositData.md @@ -9,7 +9,7 @@ Required deposit data for validator activation | `pubkey` | `string` | The public key of the distributed validator. | types.ts:195 | | `withdrawal_credentials` | `string` | The 0x01 withdrawal address of the DV. | types.ts:198 | | `amount` | `string` | 32 ethers. | types.ts:201 | -| `deposit_data_root` | `string` | A checksum for DepositData fields . | types.ts:204 | +| `deposit_data_root` | `string` | A checksum for DepositData fields. | types.ts:204 | | `signature` | `string` | BLS signature of the deposit message. | types.ts:207 | ## Defined in diff --git a/versioned_docs/version-v1.1.2/sec/ev-assessment.md b/versioned_docs/version-v1.1.2/sec/ev-assessment.md index 37a25600bd..d6f2630ab1 100644 --- a/versioned_docs/version-v1.1.2/sec/ev-assessment.md +++ b/versioned_docs/version-v1.1.2/sec/ev-assessment.md @@ -5,7 +5,7 @@ description: Software Development Security Assessment # Software Development at Obol -When hardening a projects technical security, team member's operational security, and the security of the software development practices in use by the team are some of the most criticial areas to secure. Many hacks and compromises in the space to date have been a result of these attack vectors rather than exploits of the software itself. +When hardening a projects technical security, team member's operational security, and the security of the software development practices in use by the team are some of the most critical areas to secure. Many hacks and compromises in the space to date have been a result of these attack vectors rather than exploits of the software itself. With this in mind, in January 2023 the Obol team retained the expertise of Ethereal Venture's security researcher Alex Wade; to interview key stakeholders and produce a report into the teams Software Development Lifecycle. diff --git a/versioned_docs/version-v1.1.2/sec/smart_contract_audit.mdx b/versioned_docs/version-v1.1.2/sec/smart_contract_audit.mdx index 0d94ada792..e5c8f20305 100644 --- a/versioned_docs/version-v1.1.2/sec/smart_contract_audit.mdx +++ b/versioned_docs/version-v1.1.2/sec/smart_contract_audit.mdx @@ -70,7 +70,7 @@ It is assumed that all rewards will flow through the splitter, because (a) all d This creates a fairly strong guarantee that reward funds will flow to the `rewardRecipient`. Even if a user were to set their `amountOfPrincipalStake` high enough that the `principalRecipient` could receive unlimited funds, the Obol team could call `distributeFunds()` when the balance got near 16 ETH to ensure fees were paid. -However, if the user selects a non-ETH token, all ETH will be withdrawable only thorugh the `recoverFunds()` function. If they set up a split with their node operators as their `recoveryAddress`, all funds will be withdrawable via `recoverFunds()` without ever touching the `rewardRecipient` or paying a fee. +However, if the user selects a non-ETH token, all ETH will be withdrawable only through the `recoverFunds()` function. If they set up a split with their node operators as their `recoveryAddress`, all funds will be withdrawable via `recoverFunds()` without ever touching the `rewardRecipient` or paying a fee. #### Recommendation @@ -466,7 +466,7 @@ Here are a select few examples of attacks that a malicious set of node operators 1) Since there is currently no mechanism for withdrawals besides the consensus of the node operators, a minority of them sufficient to withhold consensus could blackmail the principal for a payment of up to 16 ether in order to allow them to withdraw. Otherwise, they could turn off their node operators and force the principal to bleed down to a final withdrawn balance of just over 16 ether. -2) Node operators are all able to propose blocks within the P2P network, which are then propogated out to the rest of the network. Node software is accustomed to signing for blocks built by block builders based on the metadata including quantity of fees and the address they'll be sent to. This is enforced by social consensus, with block builders not wanting to harm validators in order to have their blocks accepted in the future. However, node operators in a DVT are not concerned with the social consensus of the network, and could therefore build blocks that include large MEV payments to their personal address (instead of the DVT's 0xSplit), add fictious metadata to the block header, have their fellow node operators accept the block, and take the MEV for themselves. +2) Node operators are all able to propose blocks within the P2P network, which are then propagated out to the rest of the network. Node software is accustomed to signing for blocks built by block builders based on the metadata including quantity of fees and the address they'll be sent to. This is enforced by social consensus, with block builders not wanting to harm validators in order to have their blocks accepted in the future. However, node operators in a DVT are not concerned with the social consensus of the network, and could therefore build blocks that include large MEV payments to their personal address (instead of the DVT's 0xSplit), add fictitious metadata to the block header, have their fellow node operators accept the block, and take the MEV for themselves. 3) While the withdrawal address is immutably set on the beacon chain to the OWR, the fee address is added by the nodes to each block. Any majority of node operators sufficient to reach consensus could create a new 0xSplit with only themselves on it, and use that for all execution layer fees. The principal (and other node operators) would not be able to stop them or withdraw their principal, and would be stuck with staked funds paying fees to the malicious node operators. diff --git a/versioned_docs/version-v1.1.2/start/quickstart_alone.mdx b/versioned_docs/version-v1.1.2/start/quickstart_alone.mdx index 5da1196d79..2658dadd47 100644 --- a/versioned_docs/version-v1.1.2/start/quickstart_alone.mdx +++ b/versioned_docs/version-v1.1.2/start/quickstart_alone.mdx @@ -25,7 +25,7 @@ The private key shares can be created centrally and distributed securely to each - Go to the the DV Launchpad and select Create a distributed validator alone. Follow the steps to configure your DV cluster. The Launchpad will give you a docker command to create your cluster.
    Before you run the command, clone the CDVC repo and cd into the directory. + Go to the DV Launchpad and select Create a distributed validator alone. Follow the steps to configure your DV cluster. The Launchpad will give you a docker command to create your cluster.
    Before you run the command, clone the CDVC repo and cd into the directory. ```shell # Clone the repo diff --git a/versioned_docs/version-v1.1.2/start/update.mdx b/versioned_docs/version-v1.1.2/start/update.mdx index b8f1e913e8..9f6a56179b 100644 --- a/versioned_docs/version-v1.1.2/start/update.mdx +++ b/versioned_docs/version-v1.1.2/start/update.mdx @@ -44,7 +44,7 @@ docker compose up -d --build ``` :::danger -If you run more than one node in a DV Cluster, please take caution upgrading them simultaneously. Particularly if you are updating or changing the validator client used or recreating disks. It is recommended to update nodes on a sequential basis to minimse liveness and safety risks. +If you run more than one node in a DV Cluster, please take caution upgrading them simultaneously. Particularly if you are updating or changing the validator client used or recreating disks. It is recommended to update nodes on a sequential basis to minimise liveness and safety risks. ::: ### Conflicts