diff --git a/.vscode/settings.json b/.vscode/settings.json new file mode 100644 index 0000000000..7a73a41bfd --- /dev/null +++ b/.vscode/settings.json @@ -0,0 +1,2 @@ +{ +} \ No newline at end of file diff --git a/docs/int/quickstart/advanced/_category_.json b/docs/advanced/_category_.json similarity index 74% rename from docs/int/quickstart/advanced/_category_.json rename to docs/advanced/_category_.json index c606c5656f..09a5dd1dd1 100644 --- a/docs/int/quickstart/advanced/_category_.json +++ b/docs/advanced/_category_.json @@ -1,5 +1,5 @@ { "label": "Advanced Guides", - "position": 10, + "position": 3, "collapsed": true } \ No newline at end of file diff --git a/docs/int/quickstart/advanced/adv-docker-configs.md b/docs/advanced/adv-docker-configs.md similarity index 100% rename from docs/int/quickstart/advanced/adv-docker-configs.md rename to docs/advanced/adv-docker-configs.md diff --git a/docs/int/quickstart/advanced/monitoring.md b/docs/advanced/monitoring.md similarity index 100% rename from docs/int/quickstart/advanced/monitoring.md rename to docs/advanced/monitoring.md diff --git a/docs/int/quickstart/advanced/obol-monitoring.md b/docs/advanced/obol-monitoring.md similarity index 100% rename from docs/int/quickstart/advanced/obol-monitoring.md rename to docs/advanced/obol-monitoring.md diff --git a/docs/int/quickstart/advanced/quickstart-builder-api.md b/docs/advanced/quickstart-builder-api.md similarity index 99% rename from docs/int/quickstart/advanced/quickstart-builder-api.md rename to docs/advanced/quickstart-builder-api.md index 5f6656fc09..2e633622a9 100644 --- a/docs/int/quickstart/advanced/quickstart-builder-api.md +++ b/docs/advanced/quickstart-builder-api.md @@ -6,7 +6,7 @@ description: Run a distributed validator cluster with the builder API (MEV-Boost import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; -# Run a cluster with MEV enabled +# Enable MEV :::caution Charon is in a beta state and should be used with caution according to its [Terms of Use](https://obol.tech/terms.pdf). diff --git a/docs/int/quickstart/advanced/quickstart-combine.md b/docs/advanced/quickstart-combine.md similarity index 100% rename from docs/int/quickstart/advanced/quickstart-combine.md rename to docs/advanced/quickstart-combine.md diff --git a/docs/int/quickstart/advanced/quickstart-sdk.md b/docs/advanced/quickstart-sdk.md similarity index 96% rename from docs/int/quickstart/advanced/quickstart-sdk.md rename to docs/advanced/quickstart-sdk.md index a658d9937b..87fe91e104 100644 --- a/docs/int/quickstart/advanced/quickstart-sdk.md +++ b/docs/advanced/quickstart-sdk.md @@ -12,7 +12,7 @@ import TabItem from '@theme/TabItem'; The Obol-SDK is in a beta state and should be used with caution on testnets only. ::: -This is a walkthrough of using the [Obol-SDK](https://www.npmjs.com/package/@obolnetwork/obol-sdk) to propose a four-node distributed validator cluster for creation using the [DV Launchpad](../../../dvl/intro.md). +This is a walkthrough of using the [Obol-SDK](https://www.npmjs.com/package/@obolnetwork/obol-sdk) to propose a four-node distributed validator cluster for creation using the [DV Launchpad](../dvl_intro.md). ## Pre-requisites @@ -85,9 +85,9 @@ console.log( ## Invite the Operators to complete the DKG -Once the Obol-API returns a `configHash` string from the `createClusterDefinition` method, you can use this identifier to invite the operators to the [Launchpad](../../../dvl/intro.md) to complete the process +Once the Obol-API returns a `configHash` string from the `createClusterDefinition` method, you can use this identifier to invite the operators to the [Launchpad](../dvl_intro.md) to complete the process -1. Operators navigate to `https://.launchpad.obol.tech/dv?configHash=` and complete the [run a DV with others](../group/quickstart-group-operator.md) flow. +1. Operators navigate to `https://.launchpad.obol.tech/dv?configHash=` and complete the [run a DV with others](../getting_started/quickstart_group.md) flow. 1. Once the DKG is complete, and operators are using the `--publish` flag, the created cluster details will be posted to the Obol API 1. The creator will be able to retrieve this data with `obol.getClusterLock(configHash)`, to use for activating the newly created validator. diff --git a/docs/int/quickstart/advanced/quickstart-split.md b/docs/advanced/quickstart-split.md similarity index 95% rename from docs/int/quickstart/advanced/quickstart-split.md rename to docs/advanced/quickstart-split.md index ca4c9ec945..f27ea06b2a 100644 --- a/docs/int/quickstart/advanced/quickstart-split.md +++ b/docs/advanced/quickstart-split.md @@ -10,12 +10,12 @@ Charon is in a beta state and should be used with caution according to its [Term This process should only be used if you want to split an *existing validator private key* into multiple private key shares for use in a Distributed Validator Cluster. If your existing validator is not properly shut down before the Distributed Validator starts, your validator may be slashed. -If you are starting a new validator, you should follow a [quickstart guide](../index.md) instead. +If you are starting a new validator, you should follow a [quickstart guide](../getting_started/quickstart_overview.md) instead. If you use MEV-Boost, make sure you turned off your MEV-Boost service for the time of splitting the keys, otherwise you may hit [this issue](https://github.com/ObolNetwork/charon/issues/2770). ::: -Split an existing Ethereum validator key into multiple key shares for use in an [Obol Distributed Validator Cluster](../../key-concepts#distributed-validator-cluster). +Split an existing Ethereum validator key into multiple key shares for use in an [Obol Distributed Validator Cluster](../intro/key-concepts.md#distributed-validator-cluster). ## Pre-requisites diff --git a/docs/int/quickstart/advanced/self-relay.md b/docs/advanced/self-relay.md similarity index 95% rename from docs/int/quickstart/advanced/self-relay.md rename to docs/advanced/self-relay.md index ab18fc122c..7af35ee894 100644 --- a/docs/int/quickstart/advanced/self-relay.md +++ b/docs/advanced/self-relay.md @@ -35,4 +35,4 @@ Configure **ALL** charon nodes in your cluster to use this relay: Note that a local `relay/.charon/charon-enr-private-key` file will be created next to `relay/docker-compose.yml` to ensure a persisted relay ENR across restarts. -A list of publicly available relays that can be used is maintained [here](../../faq/risks.md#risk-obol-hosting-the-relay-infrastructure). \ No newline at end of file +A list of publicly available relays that can be used is maintained [here](../faq/risks.md). diff --git a/docs/charon/_category_.json b/docs/charon/_category_.json index 5ed247b0e5..08dc9cc73c 100644 --- a/docs/charon/_category_.json +++ b/docs/charon/_category_.json @@ -1,5 +1,5 @@ { "label": "Charon", - "position": 3, - "collapsed": false + "position": 5, + "collapsed": true } diff --git a/docs/charon/charon-cli-reference.md b/docs/charon/charon-cli-reference.md index 83d3a19aaf..a619989317 100644 --- a/docs/charon/charon-cli-reference.md +++ b/docs/charon/charon-cli-reference.md @@ -358,4 +358,4 @@ Flags: --p2p-relays strings Comma-separated list of libp2p relay URLs or multiaddrs. (default [https://0.relay.obol.tech]) --p2p-tcp-address strings Comma-separated list of listening TCP addresses (ip and port) for libP2P traffic. Empty default doesn't bind to local port therefore only supports outgoing connections. ``` -You can also consider adding [alternative public relays](../int/faq/risks.md#risk-obol-hosting-the-relay-infrastructure) to your cluster by specifying a list of `p2p-relays` in [`charon run`](#run-the-charon-middleware). \ No newline at end of file +You can also consider adding [alternative public relays](../faq/risks.md) to your cluster by specifying a list of `p2p-relays` in [`charon run`](#run-the-charon-middleware). \ No newline at end of file diff --git a/docs/charon/cluster-configuration.md b/docs/charon/cluster-configuration.md index aab4104033..72507d72cc 100644 --- a/docs/charon/cluster-configuration.md +++ b/docs/charon/cluster-configuration.md @@ -67,7 +67,7 @@ The schema of the `cluster-definition.json` is defined as: ### Using the DV Launchpad -- A [`leader/creator`](docs/int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" +- A `leader/creator`, that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" - The `leader/creator` uses the user interface to configure all of the important details about the cluster including: - The `Withdrawal Address` for the created validators - The `Fee Recipient Address` for block proposals if it differs from the withdrawal address diff --git a/docs/charon/dkg.md b/docs/charon/dkg.md index 86b0e28d2d..0d27eef526 100644 --- a/docs/charon/dkg.md +++ b/docs/charon/dkg.md @@ -7,11 +7,11 @@ sidebar_position: 2 ## Overview -A [**distributed validator key**](docs/int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. +A [**distributed validator key**](../intro/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. -To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](docs/int/key-concepts.md#distributed-validator-key-generation-ceremony). +To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](../intro/key-concepts.md#distributed-validator-key-generation-ceremony). -The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster definition](../charon/cluster-configuration). +The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster definition](../charon/cluster-configuration.md). ## Actors Involved @@ -70,4 +70,4 @@ There are a number of aspects to this trust surface that can be mitigated with a ### Sample Configuration and Lock Files -Refer to the details [here](../charon/cluster-configuration). +Refer to the details [here](../charon/cluster-configuration.md). diff --git a/docs/charon/intro.md b/docs/charon/intro.md index 767a6a3ded..0d32b462ac 100644 --- a/docs/charon/intro.md +++ b/docs/charon/intro.md @@ -5,7 +5,7 @@ sidebar_position: 1 # Introduction -This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](/docs/int/key-concepts) section as background and context. +This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](../intro/key-concepts.md) section as background and context. ## What is Charon? @@ -79,4 +79,4 @@ The following is an outline of the services that can be exposed by charon. ## Getting started -For more information on running charon, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). +For more information on running charon, take a look at our [Quickstart Guides](../getting_started/quickstart_overview.md). diff --git a/docs/cg/_category_.json b/docs/contribution&feedback/_category_.json similarity index 77% rename from docs/cg/_category_.json rename to docs/contribution&feedback/_category_.json index 6658367ce5..0c3c0c0431 100644 --- a/docs/cg/_category_.json +++ b/docs/contribution&feedback/_category_.json @@ -1,5 +1,5 @@ { "label": "Contribution & Feedback", - "position": 10, + "position": 9, "collapsed": true } diff --git a/docs/cg/bug-report.md b/docs/contribution&feedback/bug-report.md similarity index 100% rename from docs/cg/bug-report.md rename to docs/contribution&feedback/bug-report.md diff --git a/docs/cg/docs.md b/docs/contribution&feedback/docs.md similarity index 100% rename from docs/cg/docs.md rename to docs/contribution&feedback/docs.md diff --git a/docs/cg/feedback.md b/docs/contribution&feedback/feedback.md similarity index 100% rename from docs/cg/feedback.md rename to docs/contribution&feedback/feedback.md diff --git a/docs/dvl/_category_.json b/docs/dvl/_category_.json deleted file mode 100644 index b7a2cf3a69..0000000000 --- a/docs/dvl/_category_.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "label": "DV Launchpad", - "position": 4, - "collapsed": true -} diff --git a/docs/dvl/intro.md b/docs/dvl_intro.md similarity index 85% rename from docs/dvl/intro.md rename to docs/dvl_intro.md index 728489e476..2b9c819d57 100644 --- a/docs/dvl/intro.md +++ b/docs/dvl_intro.md @@ -1,9 +1,9 @@ --- description: A dapp to securely create Distributed Validators alone or with a group. -sidebar_position: 1 +sidebar_position: 6 --- -# Introduction +# DV Launchpad ![DV Launchpad Promo Image](/img/DistributeYourValidators.svg) @@ -11,11 +11,11 @@ In order to activate an Ethereum validator, 32 ETH must be deposited into the of The vast majority of users that created validators to date have used the **[~~Eth2~~ Staking Launchpad](https://launchpad.ethereum.org/)**, a public good open source website built by the Ethereum Foundation alongside participants that later went on to found Obol. This tool has been wildly successful in the safe and educational creation of a significant number of validators on the Ethereum mainnet. -To facilitate the generation of distributed validator keys amongst remote users with high trust, the Obol Network developed and maintains a website that enables a group of users to come together and create these threshold keys: [**The DV Launchpad**](https://goerli.launchpad.obol.tech/). +To facilitate the generation of distributed validator keys amongst remote users with high trust, the Obol Network developed and maintains a website that enables a group of users to come together and create these threshold keys: **The DV Launchpad**. ## Getting started -For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). +For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](../docs/getting_started/quickstart_overview.md). ## DV Launchpad Links diff --git a/docs/int/faq/_category_.json b/docs/faq/_category_.json similarity index 69% rename from docs/int/faq/_category_.json rename to docs/faq/_category_.json index c5279cb839..09bd234f76 100644 --- a/docs/int/faq/_category_.json +++ b/docs/faq/_category_.json @@ -1,5 +1,5 @@ { "label": "FAQ", - "position": 10, + "position": 4, "collapsed": true } \ No newline at end of file diff --git a/docs/int/faq/dkg_failure.md b/docs/faq/dkg_failure.md similarity index 100% rename from docs/int/faq/dkg_failure.md rename to docs/faq/dkg_failure.md diff --git a/docs/int/faq/errors.mdx b/docs/faq/errors.mdx similarity index 100% rename from docs/int/faq/errors.mdx rename to docs/faq/errors.mdx diff --git a/docs/int/faq/general.md b/docs/faq/general.md similarity index 91% rename from docs/int/faq/general.md rename to docs/faq/general.md index f791d7bf41..cdd503e82f 100644 --- a/docs/int/faq/general.md +++ b/docs/faq/general.md @@ -36,7 +36,7 @@ Recommended specifications: For more hardware considerations, check out the [ethereum.org guides](https://ethereum.org/en/developers/docs/nodes-and-clients/run-a-node/#environment-and-hardware) which explores various setups and trade-offs, such as running the node locally or in the cloud. -For now, Geth, Teku & Lighthouse clients are packaged within the docker compose file provided in the [quickstart guides](../quickstart/group), so you don't have to install anything else to run a cluster. Just make sure you give them some time to sync once you start running your node. +For now, Geth, Teku & Lighthouse clients are packaged within the docker compose file provided in the [quickstart guides](../getting_started/quickstart_overview.md), so you don't have to install anything else to run a cluster. Just make sure you give them some time to sync once you start running your node. ### What is the difference between a node, a validator and a cluster? A node is a single instance of Ethereum EL+CL clients that can communicate with other nodes to maintain the Ethereum blockchain. @@ -55,7 +55,7 @@ It is possible to migrate your Charon node to another machine running the same c Currently, the minimum is 4 operators with a threshold of 3. -The threshold (aka quorum) corresponds to the minimum numbers of operators that need to be active for the validator(s) to be able to perform its duties. It is defined by the following formula `n-(ceil(n/3)-1)`. We strongly recommend using this default threshold in your DKG as it maximises liveness while maintaining BFT safety. Setting a 4 out of 4 cluster for example, would make your validator more vulnerable to going offline instead of less vulnerable. You can check the recommended threshold values for a cluster [here](../key-concepts.md#distributed-validator-threshold). +The threshold (aka quorum) corresponds to the minimum numbers of operators that need to be active for the validator(s) to be able to perform its duties. It is defined by the following formula `n-(ceil(n/3)-1)`. We strongly recommend using this default threshold in your DKG as it maximises liveness while maintaining BFT safety. Setting a 4 out of 4 cluster for example, would make your validator more vulnerable to going offline instead of less vulnerable. You can check the recommended threshold values for a cluster [here](../intro/key-concepts.md#distributed-validator-threshold). ## Obol Splits @@ -73,7 +73,7 @@ Generally Obol Splits are deployed in an immutable fashion, meaning you cannot e ### How do Obol Splits work? -You can read more about how Obol Splits work [here](../../sc/introducing-obol-splits.md). +You can read more about how Obol Splits work [here](../sc_obol-splits.md). ### Are Obol Splits open source? @@ -81,7 +81,7 @@ Yes, Obol Splits are licensed under GPLv3 and the source code is available [here ### Are Obol Splits audited? -The Obol Splits contracts have been audited, though further development has continued on the contracts since. Consult the audit results [here](../../sec/smart_contract_audit.md). +The Obol Splits contracts have been audited, though further development has continued on the contracts since. Consult the audit results [here](../security/smart_contract_audit.md). ### Are the Obol Splits contracts verified on Etherscan? @@ -95,7 +95,7 @@ No. Any address can trigger the contracts to move the funds, they do not need to The most important decision is to be aware of whether or not the Split contract you are using has been set up with editability. If a splitter is editable, you should understand what the address that can edit the split does. Is the editor an EOA? Who controls that address? How secure is their seed phrase? Is it a smart contract? What can that contract do? Can the controller contract be upgraded? etc. Generally, the safest thing in Obol's perspective is not to have an editable splitter, and if in future you are unhappy with the configuration, that you exit the validator and create a fresh cluster with new settings that fit your needs. -Another aspect to be aware of is how the splitting of principal from rewards works using the Optimistic Withdrawal Recipient contract. There are edge cases relating to not calling the contracts periodically or ahead of a withdrawal, activating more validators than the contract was configured for, and a worst case mass slashing on the network. Consult the documentation on the contract [here](../../sc/introducing-obol-splits.md#optimistic-withdrawal-recipient), its audit [here](../../sec/smart_contract_audit.md), and follow up with the core team if you have further questions. +Another aspect to be aware of is how the splitting of principal from rewards works using the Optimistic Withdrawal Recipient contract. There are edge cases relating to not calling the contracts periodically or ahead of a withdrawal, activating more validators than the contract was configured for, and a worst case mass slashing on the network. Consult the documentation on the contract [here](../sc_obol-splits.md#optimistic-withdrawal-recipient), its audit [here](../security/smart_contract_audit.md), and follow up with the core team if you have further questions. ## Debugging Errors in Logs diff --git a/docs/int/faq/risks.md b/docs/faq/risks.md similarity index 60% rename from docs/int/faq/risks.md rename to docs/faq/risks.md index 6931cd253f..b42a39335c 100644 --- a/docs/int/faq/risks.md +++ b/docs/faq/risks.md @@ -8,9 +8,9 @@ description: Centralization Risks and mitigation ## Risk: Obol hosting the relay infrastructure **Mitigation**: Self-host a relay -One of the risks associated with Obol hosting the [LibP2P relays](docs/charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. Ensure that all nodes in the cluster use the same relays, or they will not be able to find each other if they are connected to different relays. +One of the risks associated with Obol hosting the [LibP2P relays](../charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. Ensure that all nodes in the cluster use the same relays, or they will not be able to find each other if they are connected to different relays. -The following non-Obol entities run relays that you can consider adding to your cluster (you can have more than one per cluster, see the `--p2p-relays` flag of [`charon run`](../../charon/charon-cli-reference.md#the-run-subcommand)): +The following non-Obol entities run relays that you can consider adding to your cluster (you can have more than one per cluster, see the `--p2p-relays` flag of [`charon run`](../charon/charon-cli-reference.md#the-run-subcommand)): | Entity | Relay URL | |-----------|---------------------------------------| @@ -25,9 +25,9 @@ The following non-Obol entities run relays that you can consider adding to your Another risk associated with Obol is having the ability to update the [Charon code](https://github.com/ObolNetwork/charon) running on the network which could introduce vulnerabilities or malicious code. To mitigate this risk, operators can consider pinning specific versions of the code that have been thoroughly tested and accepted by the network. This would ensure that any updates are carefully vetted and reviewed by the community. ## Risk: Obol hosting the DV Launchpad -**Mitigation**: Use [`create cluster`](docs/charon/charon-cli-reference.md) or [`create dkg`](docs/charon/charon-cli-reference.md) locally and distribute the files manually +**Mitigation**: Use [`create cluster`](../charon/charon-cli-reference.md) or [`create dkg`](../charon/charon-cli-reference.md) locally and distribute the files manually -Hosting the first Charon frontend, the [DV Launchpad](docs/dvl/intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally. +Hosting the first Charon frontend, the [DV Launchpad](../dvl_intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally. To mitigate the risk of launchpad failure, consider using the `create cluster` or `create dkg` commands locally and distributing the key shares files manually. @@ -37,4 +37,4 @@ To mitigate the risk of launchpad failure, consider using the `create cluster` o The final centralization risk associated with Obol is the possibility of the company going bankrupt or acting maliciously, which would lead to a loss of control over the network and potentially cause damage to the ecosystem. To mitigate this risk, Obol has implemented a key recovery mechanism. This would allow the clusters to continue operating and to retrieve full private keys even if Obol is no longer able to provide support. -A guide to recombine key shares into a single private key can be accessed [here](../quickstart/advanced/quickstart-combine.md). +A guide to recombine key shares into a single private key can be accessed [here](../advanced/quickstart-combine.md). diff --git a/docs/fr/_category_.json b/docs/fr/_category_.json index 72d8434c21..427bf9a141 100644 --- a/docs/fr/_category_.json +++ b/docs/fr/_category_.json @@ -1,5 +1,5 @@ { "label": "Further reading", - "position": 11, + "position": 10, "collapsed": true } diff --git a/docs/fr/eth.md b/docs/fr/ethereum_and_dvt.md similarity index 99% rename from docs/fr/eth.md rename to docs/fr/ethereum_and_dvt.md index c8b68f4912..5f1b515166 100644 --- a/docs/fr/eth.md +++ b/docs/fr/ethereum_and_dvt.md @@ -1,5 +1,5 @@ --- -sidebar_position: 1 +sidebar_position: 4 description: Ethereum and its relationship with DVT --- diff --git a/docs/fr/testnet.md b/docs/fr/testnet.md index d533c60095..19477b6564 100644 --- a/docs/fr/testnet.md +++ b/docs/fr/testnet.md @@ -1,5 +1,5 @@ --- -sidebar_position: 2 +sidebar_position: 5 description: Community testing efforts --- @@ -7,7 +7,7 @@ description: Community testing efforts :::tip -This page looks at the community testing efforts organised by Obol to test Distributed Validators at scale. If you are looking for guides to run a Distributed Validator on testnet you can do so [here](../int/quickstart/index.md). +This page looks at the community testing efforts organised by Obol to test Distributed Validators at scale. If you are looking for guides to run a Distributed Validator on testnet you can do so [here](../getting_started/quickstart_overview.md). ::: diff --git a/docs/int/_category_.json b/docs/getting_started/_category_.json similarity index 70% rename from docs/int/_category_.json rename to docs/getting_started/_category_.json index f23f9bc2d0..0d0d566773 100644 --- a/docs/int/_category_.json +++ b/docs/getting_started/_category_.json @@ -1,5 +1,5 @@ { "label": "Getting started", "position": 2, - "collapsed": false + "collapsed": true } diff --git a/docs/getting_started/activate-dv.md b/docs/getting_started/activate-dv.md new file mode 100644 index 0000000000..282f3dc9bc --- /dev/null +++ b/docs/getting_started/activate-dv.md @@ -0,0 +1,41 @@ +--- +sidebar_position: 5 +description: Activate the Distributed Validator using the deposit contract +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +# Activate a DV + +:::caution +Charon is in a beta state and should be used with caution according to its [Terms of Use](https://obol.tech/terms.pdf). +::: + +If you have successfully created a distributed validator and you are ready to activate it, congratulations! πŸŽ‰ + +Once you have connected all of your charon clients together, synced all of your ethereum nodes such that the monitoring indicates that they are all healthy and ready to operate, **ONE operator** may proceed to deposit and activate the validator(s). + +The `deposit-data.json` to be used to deposit will be located in each operator's `.charon` folder. The copies across every node should be identical and any of them can be uploaded. + +:::warning +If you are being given a `deposit-data.json` file that you didn't generate yourself, please take extreme care to ensure this operator has not given you a malicious `deposit-data.json` file that is not the one you expect. Cross reference the files from multiple operators if there is any doubt. Activating the wrong validator or an invalid deposit could result in complete theft or loss of funds. +::: + +Use any of the following tools to deposit. Please use the third-party tools at your own risk and always double check the staking contract address. + +* Obol Distributed Validator Launchpad +* ethereum.org Staking Launchpad +* From a SAFE Multisig:
+(Repeat these steps for every validator to deposit in your cluster) + * From the SAFE UI, click on New Transaction then Transaction Builder to create a new custom transaction + * Enter the beacon chain contract for Deposit on mainnet - you can find it here + * Fill the transaction information + * Set amount to 32 in ETH + * Use your deposit-data.json to fill the required data : pubkey,withdrawal credentials,signature,deposit_data_root. Make sure to prefix the input with 0x to format them in bytes + * Click on Add transaction + * Click on Create Batch + * Click on Send Batch, you can click on Simulate to check if the transaction will execute successfully + * Get the minimum threshold of signatures from the other addresses and execute the custom transaction + +The activation process can take a minimum of 16 hours, with the maximum time to activation being dictated by the length of the activation queue, which can be weeks. \ No newline at end of file diff --git a/docs/int/quickstart/quickstart-exit.md b/docs/getting_started/quickstart-exit.md similarity index 99% rename from docs/int/quickstart/quickstart-exit.md rename to docs/getting_started/quickstart-exit.md index 359efd3476..3b5cca00a2 100644 --- a/docs/int/quickstart/quickstart-exit.md +++ b/docs/getting_started/quickstart-exit.md @@ -1,5 +1,5 @@ --- -sidebar_position: 6 +sidebar_position: 7 description: Exit a validator --- diff --git a/docs/getting_started/quickstart_alone.md b/docs/getting_started/quickstart_alone.md new file mode 100644 index 0000000000..0cca2ef740 --- /dev/null +++ b/docs/getting_started/quickstart_alone.md @@ -0,0 +1,184 @@ +--- +sidebar_position: 4 +description: New combined flow for leader/creator +--- +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +# Quickstart - Create a DV alone + +:::caution +Charon is in a beta state and should be used with caution according to its [Terms of Use](https://obol.tech/terms.pdf). +::: + +:::info +It is possible for a single operator to manage all of the nodes of a DV cluster. The nodes can be run on a single machine, which is only ideal for testing, or the nodes can be run on multiple machines, which is ideal for a production setup. + +The private key shares can be created centrally and distributed securely to each node. Alternatively, the private key shares can be created in a lower-trust manner with a Distributed Key Generation process, which avoids the validator private key being stored in full anywhere, at any point in its lifecycle. Follow the group quickstart instead for this latter case. +::: + +## Pre-requisites +
    +
  • A basic knowledge of Ethereum nodes and validators.
    • +
  • Ensure you have git installed.
    • +
  • Ensure you have docker installed. +
    (Click the above link, and choose your OS. Probably, you do not want to install "Docker Desktop" but rather choose one of the Linux OSs from "Supported platforms" to install "Docker Engine".)
    • +
  • Make sure docker is running before executing the commands below.
    • +
+ +
+ +## STEP 1: Create the key shares locally + + + +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, which you should run in your terminal. + + + + +1. Clone the CDVC repo and `cd` into the directory. + + ```sh + # Clone the repo + git clone https://github.com/ObolNetwork/charon-distributed-validator-cluster.git + + # Change directory + cd charon-distributed-validator-cluster/ + ``` + +2. Prepare the environment variables + +```sh +# Copy the sample environment variables +cp .env.sample .env +``` +`.env.sample` is a sample environment file that allows overriding default configuration defined in `docker-compose.yml`. Uncomment and set any variable to override its value. + +3. Setup the desired inputs for the DV, including the network you wish to operate on. Check the [Charon CLI reference](../charon/charon-cli-reference.md) for additional optional flags to set. + +
+  
+  WITHDRAWAL_ADDR=[ENTER YOUR WITHDRAWAL ADDRESS HERE]
+  

+  FEE_RECIPIENT_ADDR=[ENTER YOUR FEE RECIPIENT ADDRESS HERE]
+  

+  NB_NODES=[ENTER AMOUNT OF DESIRED NODES]
+  

+  NETWORK="holesky"
+  
+
+Then, run this command to create all the key shares and cluster artifacts locally: +
+  
+  docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.19.0 create cluster --name="Quickstart Cluster" --withdrawal-addresses="{'${WITHDRAWAL_ADDR}'}" --fee-recipient-addresses="{'${FEE_RECIPIENT_ADDR}'}" --nodes="{'${NB_NODES}'}" --network="{'${NETWORK}'}" --num-validators=1 --cluster-dir="cluster"
+  
+
+ + +
+ +You should now have multiple folders within `.charon/cluster`, one for each node created. Backup the `cluster/` folder, then move on to deploying the cluster physically. + +## STEP 2: Deploy and start the nodes + + + + +:::warning +This part of the guide only runs one Execution Client, one Consensus Client, and 6 Distributed Validator Charon Client + Validator Client pairs on a single docker instance, and **is not suitable for a mainnet deployment**. (If this machine fails, there will not be any fault tolerance - the cluster will also fail.) + +For a production deployment with fault tolerance, follow the part of the guide instructing you how to distribute the nodes across multiple machines. +::: + +Run this command to start your cluster containers if you deployed using CDVC repo above. + +```sh +# Start the distributed validator cluster +docker compose up --build +``` +Check the monitoring dashboard and see if things look all right + +```sh +# Open Grafana +open http://localhost:3000/d/laEp8vupp +``` + +
+ + + +:::caution +To distribute your cluster across multiple machines, each node in the cluster needs one of the folders called `node*/` to be copied to it. Each folder should be copied to a CDVN repo and renamed from `node*` to `.charon`. + +Right now, the `charon create cluster` command [used earlier to create the private keys](./create-keys) outputs a folder structure like `cluster/node*/`. Make sure to grab the `./node*/` folders, *rename* them to `.charon` and then move them to one of the single node repos below. Once all nodes are online, synced, and connected, you will be ready to activate your validator. +::: + + This is necessary for the folder to be found by the default `charon run` command. Optionally, it is possible to override `charon run`'s default file locations by using `charon run --private-key-file=".charon/cluster/node0/charon-enr-private-key" --lock-file=".charon/cluster/node0/cluster-lock.json"` for each instance of charon you start. + + :point_right: Use the single node [docker compose](https://github.com/ObolNetwork/charon-distributed-validator-node), the kubernetes [manifests](https://github.com/ObolNetwork/charon-k8s-distributed-validator-node), or the [helm chart](https://github.com/ObolNetwork/helm-charts) example repos to get your nodes up and connected after loading the `.charon` folder artifacts into them appropriately. +
+ +```log title="Output from create cluster" + +cluster +β”œβ”€β”€ node0 +β”‚ β”œβ”€β”€ charon-enr-private-key +β”‚ β”œβ”€β”€ cluster-lock.json +β”‚ β”œβ”€β”€ deposit-data.json +β”‚ └── validator_keys +β”‚ β”œβ”€β”€ keystore-0.json +β”‚ └── keystore-0.txt +β”œβ”€β”€ node1 +β”‚ β”œβ”€β”€ charon-enr-private-key +β”‚ β”œβ”€β”€ cluster-lock.json +β”‚ β”œβ”€β”€ deposit-data.json +β”‚ └── validator_keys +β”‚ β”œβ”€β”€ keystore-0.json +β”‚ └── keystore-0.txt +β”œβ”€β”€ node2 +β”‚ β”œβ”€β”€ charon-enr-private-key +β”‚ β”œβ”€β”€ cluster-lock.json +β”‚ β”œβ”€β”€ deposit-data.json +β”‚ └── validator_keys +β”‚ β”œβ”€β”€ keystore-0.json +β”‚ └── keystore-0.txt +└── node3 + β”œβ”€β”€ charon-enr-private-key + β”œβ”€β”€ cluster-lock.json + β”œβ”€β”€ deposit-data.json + └── validator_keys + β”œβ”€β”€ keystore-0.json + └── keystore-0.txt + β”œβ”€β”€ keystore-N.json + └── keystore-N.txt + +``` + +```log title="Folder structure to be placed on each DV node" +└── .charon + β”œβ”€β”€ charon-enr-private-key + β”œβ”€β”€ cluster-lock.json + β”œβ”€β”€ deposit-data.json + └── validator_keys + β”œβ”€β”€ keystore-0.json + β”œβ”€β”€ keystore-0.txt + β”œβ”€β”€ ... + β”œβ”€β”€ keystore-N.json + └── keystore-N.txt +``` + +:::info + Currently, the CDVN repo installs a node on Goerli testnet. It is possible to choose a different network (another testnet, or mainnet) by overriding the .env file. + From within the ```charon-distributed-validator-cluster``` directory: + ```sh + # Copy ".env.sample", renaming it ".env" + cp .env.sample .env + ``` + `.env.sample` is a sample environment file that allows overriding default configuration defined in `docker-compose.yml`. Uncomment and set any variable to override its value. + + Setup the desired inputs for the DV, including the network you wish to operate on. Check the [Charon CLI reference](../charon/charon-cli-reference.md) for additional optional flags to set. +::: + + + \ No newline at end of file diff --git a/docs/getting_started/quickstart_group.md b/docs/getting_started/quickstart_group.md new file mode 100644 index 0000000000..bec07653e4 --- /dev/null +++ b/docs/getting_started/quickstart_group.md @@ -0,0 +1,375 @@ +--- +sidebar_position: 3 +description: New combined flow for leader/creator +--- +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +# Quickstart - Create a DV with a group + +:::caution +Charon is in a beta state and should be used with caution according to its [Terms of Use](https://obol.tech/terms.pdf). +::: + + + +## Pre-requisites +
    +
  • A basic knowledge of Ethereum nodes and validators.
    • +
  • Ensure you have git installed.
    • +
  • Ensure you have docker installed. +
    (Click the above link, and choose your OS. Probably, you do not want to install "Docker Desktop" but rather choose one of the Linux OSs from "Supported platforms" to install "Docker Engine".)
    • +
  • Make sure docker is running before executing the commands below.
    • +
+ +
+ +## STEP 1: Generate ENR + + In order to prepare for a distributed key generation ceremony, you need to create an ENR for your charon client. This ENR is a public/private key pair that allows the other charon clients in the DKG to identify and connect to your node. + + + + Use docker to generate an ENR. (Note: in the "docker run" command, you may have to change the version from v0.19.0 to the correct version of the repo you are using)

+ + # Clone this repo + git clone https://github.com/ObolNetwork/charon-distributed-validator-node.git + + # Change directory + cd charon-distributed-validator-node + + # Create your charon ENR private key, this will create a charon-enr-private-key file in the .charon directory + docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.19.0 create enr + + If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. + + + + Use ansible to generate an ENR. See the repo here. + + + Use Helm to generate an ENR. See the repo here. + + + Use K8s to generate an ENR. See the repo here. + + +
+ + You should expect to see a console output like this: + + Created ENR private key: .charon/charon-enr-private-key + enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u + +:::caution +Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** +::: + + +For the next step, select the *Leader/Creator* tab if you are coordinating the creation of the cluster. (This role holds no position of privilege in the cluster, it only sets the initial terms of the cluster that the other operators agree to.) Select the *Leader/Creator* tab if you are simply operating a node in a cluster proposed by the cluster coordinator.
+ +## STEP 2: Create or join cluster config + + + +

Collect addresses, create cluster config, share with operators

+ Before starting the cluster creation, you will need to collect one Ethereum address per operator in the cluster. They will need to be able to sign messages through MetaMask with this address. (Broader wallet support will be added in future.)
+ Then, create the cluster configuration. + + + You will use Launchpad to create an invite link, and share it with the operators.
+ This video shows the flow within the DV Launchpad: + +

+ +You will prepare the configuration file for the distributed key generation ceremony using the launchpad. + +1. Go to the [DV Launchpad](https://docs.obol.tech/docs/dvl/intro#dv-launchpad-links) +2. Connect your wallet + + ![Connect your Wallet](/img/Guide01.png) + +3. Select `Create a Cluster with a group` then `Get Started`. + + ![Get Started](/img/Guide02.png) + +4. Follow the flow and accept the advisories. +5. Configure the Cluster + - Input the `Cluster Name` & `Cluster Size` (i.e. number of operators in the cluster). The threshold will update automatically, it shows the number of nodes that need to be functioning for the validator(s) to stay active. + +6. Input the Ethereum addresses for each operator that you collected previously. + - Select the desired amount of validators (32 ETH each) the cluster will run. (Note that the launchpad is restricted to one validator, for now.) + - Enter the `Principal address` which should receive the principal 32 ETH should go when the validator is exited. This can optionally be set to the contract address of a multisig / splitter contract. + - Enter the `Fee Recipient address` to which the validator rewards will go. This can be the same as the principal address, or it can be a different address. This can optionally be set to the contract address of a multisig / splitter contract. +7. Click `Create Cluster Configuration`, then paste your `ENR` that you generated previously. Review that all the details are correct, and press `Confirm and Sign`. You will be prompted to sign three transactions with your MetaMask wallet. These are: + - The config_hash. This is a hashed representation of the details of this cluster, to ensure everyone is agreeing to an identical setup. + - The operator_config_hash. This is your acceptance of the terms as a participating node operator. + - Your ENR. Signing your ENR authorises the corresponding private key to act on your behalf in the cluster. +8. Share your cluster invite link with the operators. Following the link will show you a screen waiting for other operators to accept the configuration you created. + + ![Invite Operators](/img/Guide04.png) + +You can use the link to monitor how many of the operators have already signed their approval of the cluster configuration. + + + + You will use the CLI to create the cluster config file, which you will distribute it to the operators. + + 1. The leader or creator of the cluster will prepare the `cluster-definition.json` file for the Distributed Key Generation ceremony using the `charon create dkg` command. + + ``` + # Prepare an environment variable file + cp .env.create_dkg.sample .env.create_dkg + ``` + 2. Populate the `.env.create_dkg` file created with the `cluster name`, the `fee recipient` and `withdrawal Ethereum addresses`, and the `ENRs` of all the operators participating in the cluster. + - The file generated is hidden by default. To view it, run `ls -al` in your terminal. Else, if you are on `macOS`, press `Cmd + Shift + .` to view all hidden files in the finder application. + + 3. Run the `charon create dkg` command that generates DKG cluster-definition.json file. + (Note: in the "docker run" command, you may have to change the version from v0.19.0 to the correct version of the repo you are using) + ``` + docker run --rm -v "$(pwd):/opt/charon" --env-file .env.create_dkg obolnetwork/charon:v0.19.0 create dkg + ``` + + This command should output a file at `.charon/cluster-definition.json`. This file needs to be shared with the other operators in a cluster. + + + + + + + + +

Join the cluster configuration generated by the leader/creator

+ Use the Launchpad or CLI to join the cluster configuration generated by the leader/creator: + + + Your cluster leader/creator needs to configure the cluster, and send you an invitation URL link to join the cluster on the Launchpad. Once you've received the Launchpad invite link, enter your ENR and sign with your wallet.

+ + +

+ + +1. Go to the DV launchpad link provided by the leader or creator. +2. Connect your wallet using the Ethereum address provided to the leader in [step 1](#step-1-share-an-ethereum-address-with-your-leader-or-creator). + + ![Connect Wallet](/img/Guide05.png) + +3. Review the operators addresses submitted and click `Get Started` to continue. + + ![Get Started](/img/Guide06.png) + +4. Review and accept the advisories. +5. Review the configuration created by the leader or creator and add your `ENR` that you generated previously. + + ![Review Config](/img/Guide07.png) + +6. Sign the two transactions with your wallet, these are: + - The config hash. This is a hashed representation of all of the details for this cluster. + - Your own `ENR`. This signature authorises the key represented by this ENR to act on your behalf in the cluster. + +7. Wait for all the other operators in your cluster to also finish these steps. + + + + You'll receive the `cluster-definition.json` file created by the leader/creator. You should save it in the `.charon/` folder that was created initially. (Alternatively, you can use the `--definition-file` flag to override the default expected location for this file.) + + + + + + +Once every participating operator is ready, the next step is the distributed key generation amongst the operators. +- If you are not planning on operating a node, and only wanted to configure the cluster for the operators, your journey ends here. Well done! +- If you are one of the cluster operators, continue to the next step. +

+ + +## STEP 3: Run the Distributed Key Generation (DKG) ceremony + +:::info +For the [DKG](docs/charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps if operators can agreed on a certain time or schedule a video call for them to all run the command together. +::: + + + + + +
+

+ +1. Once all operators successfully signed, your screen will automatically advance to the next step and look like this. Click `Continue`. (If you closed the tab, you can always go back to the invite link shared by the leader and connect your wallet.) + + ![Config Signing Success](/img/Guide08.png) + +2. Copy and run the `docker` command on the screen into your terminal. It will retrieve the remote cluster details and begin the DKG process. + + ![Run the DKG](/img/Guide10.png) + +3. Assuming the DKG is successful, a number of artefacts will be created in the `.charon` folder of the node. These include: + + - A `deposit-data.json` file. This contains the information needed to activate the validator on the Ethereum network. + - A `cluster-lock.json` file. This contains the information needed by charon to operate the distributed validator cluster with its peers. + - A `validator_keys/` folder. This folder contains the private key shares and passwords for the created distributed validators. + +:::caution +Please make sure to create a backup of `.charon/validator_keys`. **If you lose your keys you won't be able to start the DV cluster successfully.** +::: + +:::info +The `cluster-lock` and `deposit-data` files are identical for each operator, if lost, they can be copied from one operator to another. +::: + + + + + + [WIP 🚧] Please use the Launchpad option for now. + + +Now that the DKG has been completed, all operators can start their nodes. +
+ +## Step 4: Start your Distributed Validator Node + +With the DKG ceremony over, the last phase before activation is to prepare your node for validating over the long term. + + + + + Start a local node, using docker or otherwise: + + + + Start your node with docker. This repo is configured to sync an execution layer client (`Nethermind`) and a consensus layer client (`Lighthouse`).

+ +:::info + Currently, the CDVN repo installs a node on Holesky testnet. It is possible to choose a different network (another testnet, or mainnet) by overriding the .env file. + From within the ```charon-distributed-validator-node``` directory: + ```sh + # Copy ".env.sample", renaming it ".env" + cp .env.sample .env + ``` + `.env.sample` is a sample environment file that allows overriding default configuration defined in `docker-compose.yml`. Uncomment and set any variable to override its value. + + Setup the desired inputs for the DV, including the network you wish to operate on. Check the [Charon CLI reference](../charon/charon-cli-reference.md) for additional optional flags to set. +::: + +:::caution + If you manually update `docker compose` to mount `lighthouse` from your locally synced `~/.lighthouse`, the whole chain database may get deleted. It'd be best not to manually update as `lighthouse` checkpoint-syncs so the syncing doesn't take much time.
+ + **Note**: If you have a `nethermind` node already synced, you can simply copy over the directory. For ex: `cp -r ~/.ethereum/goerli data/nethermind`. This makes everything faster since you start from a synced nethermind node. +::: + +``` +# Delete lighthouse data if it exists +rm -r ./data/lighthouse + +# Spin up a Distributed Validator Node with a Validator Client +docker compose up + +``` +If at any point you need to turn off your node, you can run: + +``` +# Shut down the currently running distributed validator node +docker compose down +``` + + + + + + Use ansible to start your node. See the repo here. + + + Use Helm to start your node. See the repo here. + + + Use K8s to start your node. See the repo here. + + + + + + + + +### Using a remote beacon node + +:::caution +Using a remote beacon node will impact the performance of your Distributed Validator and should be used sparingly. +::: + +If you already have a beacon node running somewhere and you want to use that instead of running EL (`nethermind`) & CL (`lighthouse`) as part of the repo, you can disable these images. To do so, follow these steps: + +1. Copy the `docker-compose.override.yml.sample` file + +``` +cp -n docker-compose.override.yml.sample docker-compose.override.yml +``` + +2. Uncomment the `profiles: [disable]` section for both `nethermind` and `lighthouse`. The override file should now look like this + +``` +services: + nethermind: + # Disable nethermind + profiles: [disable] + # Bind nethermind internal ports to host ports + #ports: + #- 8545:8545 # JSON-RPC + #- 8551:8551 # AUTH-RPC + #- 6060:6060 # Metrics + + lighthouse: + # Disable lighthouse + profiles: [disable] + # Bind lighthouse internal ports to host ports + #ports: + #- 5052:5052 # HTTP + #- 5054:5054 # Metrics +... +``` + +3. Then, uncomment and set the `CHARON_BEACON_NODE_ENDPOINTS` variable in the `.env` file to your beacon node's URL + +``` +... +# Connect to one or more external beacon nodes. Use a comma separated list excluding spaces. +CHARON_BEACON_NODE_ENDPOINTS= +... +``` + +4. Restart your docker compose + +``` +docker compose down +docker compose up -d +``` + + + + + + +

+ +:::tip +In a Distributed Validator Cluster, it is important to have a low latency connection to your peers. Charon clients will use the NAT protocol to attempt to establish a direct connection to one another automatically. If this doesn't happen, you should port forward charon's p2p port to the public internet to facilitate direct connections. (The default port to expose is `:3610`). Read more about charon's networking [here](../charon/networking.md). +::: + + +You should use the grafana dashboard to infer whether your cluster is healthy. +``` +# Open Grafana dashboard +open http://localhost:3000/d/singlenode/ +``` +In particular you should check: + +- That your charon client can connect to the configured beacon client. +- That your charon client can connect to all peers directly. +- That your validator client is connected to charon, and has the private keys it needs loaded and accessible. + +Most components in the dashboard have some help text there to assist you in understanding your cluster performance. + +You might notice that there are logs indicating that a validator cannot be found and that APIs are returning 404. This is to be expected at this point, as the validator public keys listed in the lock file have not been deposited and acknowledged on the consensus layer yet (usually ~16 hours after the deposit is made). diff --git a/docs/getting_started/quickstart_overview.md b/docs/getting_started/quickstart_overview.md new file mode 100644 index 0000000000..e139b21b1f --- /dev/null +++ b/docs/getting_started/quickstart_overview.md @@ -0,0 +1,19 @@ +--- +sidebar_position: 1 +description: Quickstart Overview +--- + +# Quickstart Overview + +The quickstart guides are aimed at developers and stakers looking to utilize Distributed Validators for solo or multi-operator staking. To contribute to this documentation, head over to our [Github repository](https://github.com/ObolNetwork/obol-docs) and file a pull request. + +There are two ways to set up a distributed validator and each comes with its own quickstart, within the "Getting Started" section: +1. Run a DV cluster as a [**group**](./quickstart_group.md), where several operators run the nodes that make up the cluster. In this setup, the key shares are created using a distributed key generation process, avoiding the full private keys being stored in full in any one place. +This approach can also be used by single operators looking to manage all nodes of a cluster but wanting to create the key shares in a trust-minimised fashion. + +2. Run a DV cluster [**alone**](./quickstart_alone.md), where a single operator runs all the nodes of the DV. Depending on trust assumptions, there is not necessarily the need to create the key shares via a DKG process. Instead the key shares can be created in a centralised manner, and distributed securely to the nodes. + + +## Need assistance? + +If you have any questions about this documentation or are experiencing technical problems with any Obol-related projects, head on over to our [Discord](https://discord.gg/n6ebKsX46w) where a member of our team or the community will be happy to assist you. diff --git a/docs/int/quickstart/update.md b/docs/getting_started/update.md similarity index 99% rename from docs/int/quickstart/update.md rename to docs/getting_started/update.md index e6ca215bec..2cb7acae51 100644 --- a/docs/int/quickstart/update.md +++ b/docs/getting_started/update.md @@ -1,5 +1,5 @@ --- -sidebar_position: 5 +sidebar_position: 6 description: Update your DV cluster with the latest Charon release --- import Tabs from '@theme/Tabs'; diff --git a/docs/int/quickstart/_category_.json b/docs/int/quickstart/_category_.json deleted file mode 100644 index 3ef52ab186..0000000000 --- a/docs/int/quickstart/_category_.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "label": "Quickstart Guides", - "position": 3, - "collapsed": false -} diff --git a/docs/int/quickstart/activate-dv.md b/docs/int/quickstart/activate-dv.md deleted file mode 100644 index b60bd5b3fc..0000000000 --- a/docs/int/quickstart/activate-dv.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -sidebar_position: 4 -description: Activate the Distributed Validator using the deposit contract ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -# Activate a DV - -:::caution -Charon is in a beta state and should be used with caution according to its [Terms of Use](https://obol.tech/terms.pdf). -::: - -If you have successfully created a distributed validator and you are ready to activate it, congratulations! πŸŽ‰ - -Once you have connected all of your charon clients together, synced all of your ethereum nodes such that the monitoring indicates that they are all healthy and ready to operate, **ONE operator** may proceed to deposit and activate the validator(s). - -The `deposit-data.json` to be used to deposit will be located in each operator's `.charon` folder. The copies across every node should be identical and any of them can be uploaded. - -:::warning -If you are being given a `deposit-data.json` file that you didn't generate yourself, please take extreme care to ensure this operator has not given you a malicious `deposit-data.json` file that is not the one you expect. Cross reference the files from multiple operators if there is any doubt. Activating the wrong validator or an invalid deposit could result in complete theft or loss of funds. -::: - -Use any of the following tools to deposit. Please use the third-party tools at your own risk and always double check the staking contract address. - - - - - - -
    -
  • Obol Distributed Validator Launchpad
    • -
  • ethereum.org Staking Launchpad
    • -
  • From a SAFE Multisig (Repeat these steps for every validator to deposit in your cluster)
    • -
      -
    • From the SAFE UI, click on New Transaction then Transaction Builder to create a new custom transaction
      • -
    • Enter the beacon chain contract for Deposit on mainnet - you can find it here
      • -
    • Fill the transaction information
      • -
    • Set amount to 32 in ETH
      • -
    • Use your deposit-data.json to fill the required data : pubkey,withdrawal credentials,signature,deposit_data_root. Make sure to prefix the input with 0x to format them in bytes
      • -
    • Click on Add transaction
      • -
    • Click on Create Batch
      • -
    • Click on Send Batch, you can click on Simulate to check if the transaction will execute successfully
      • -
    • Get the minimum threshold of signatures from the other addresses and execute the custom transaction
      • -
    -
- - - -The activation process can take a minimum of 16 hours, with the maximum time to activation being dictated by the length of the activation queue, which can be weeks. diff --git a/docs/int/quickstart/alone/create-keys.md b/docs/int/quickstart/alone/create-keys.md deleted file mode 100644 index e098fbc67a..0000000000 --- a/docs/int/quickstart/alone/create-keys.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -sidebar_position: 2 -description: Run all nodes in a distributed validator cluster ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -# Create the private key shares - -:::caution -Charon is in a beta state and should be used with caution according to its [Terms of Use](https://obol.tech/terms.pdf). -::: - -:::info -Running a Distributed Validator alone means that a single operator manages all of the nodes of the DV. Depending on the operators security preferences, the private key shares can be created centrally, and distributed securely to each node. This is the focus of the below guide. - -Alternatively, the private key shares can be created in a lower-trust manner with a [Distributed Key Generation](../../key-concepts.md#distributed-validator-key-generation-ceremony) process, which avoids the validator private key being stored in full anywhere, at any point in its lifecycle. Follow the [group quickstart](./../group/index.md) instead for this latter case. -::: - -## Pre-requisites - -- Ensure you have [docker](https://docs.docker.com/engine/install/) installed. -- Make sure `docker` is running before executing the commands below. - -## Create the key shares locally - - - - Create the artifacts needed to run a DV cluster by running the following command to setup the inputs for the DV. - Check the Charon CLI reference for additional optional flags to set. -

- 
-      
-      WITHDRAWAL_ADDR=[ENTER YOUR WITHDRAWAL ADDRESS HERE]
-      

-      FEE_RECIPIENT_ADDR=[ENTER YOUR FEE RECIPIENT ADDRESS HERE]
-      

-      NB_NODES=[ENTER AMOUNT OF DESIRED NODES]
-      

-      NETWORK="goerli"
-      
-
- Then, run this command to create all the key shares and cluster artifacts locally:

- 
-      
-      docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.19.0 create cluster --name="Quickstart Cluster" --withdrawal-addresses="{'${WITHDRAWAL_ADDR}'}" --fee-recipient-addresses="{'${FEE_RECIPIENT_ADDR}'}" --nodes="{'${NB_NODES}'}" --network="{'${NETWORK}'}" --num-validators=1 --cluster-dir="cluster"
-      
-
- - - Go to the Obol Goerli DV Launchpad and select Create a distributed validator alone. Follow the steps to configure your DV cluster. - - - -After successful completion, a subdirectory `cluster/` should be created. In it are as many folders as nodes of the cluster. Each folder contains charon artifacts and partial private keys needed for each node of the cluster. - -Once you have made a backup of the `cluster/` folder, you can move to [deploying this cluster physically](./deploy.md). \ No newline at end of file diff --git a/docs/int/quickstart/alone/deploy.md b/docs/int/quickstart/alone/deploy.md deleted file mode 100644 index fba15ac129..0000000000 --- a/docs/int/quickstart/alone/deploy.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -sidebar_position: 3 -description: Move the private key shares to the nodes and run the cluster ---- - -# Deploy the cluster -To distribute your cluster physically and start the DV, each node in the cluster needs one of the folders called `node*/` within the output of the `create cluster` command. These folders should be copied to a CDVN repo, and the folder renamed from `node0/` to `.charon/`. (Or you can override `charon run`'s default file locations) - -```log title="Output from create cluster" - -cluster -β”œβ”€β”€ node0 -β”‚ β”œβ”€β”€ charon-enr-private-key -β”‚ β”œβ”€β”€ cluster-lock.json -β”‚ β”œβ”€β”€ deposit-data.json -β”‚ └── validator_keys -β”‚ β”œβ”€β”€ keystore-0.json -β”‚ └── keystore-0.txt -β”œβ”€β”€ node1 -β”‚ β”œβ”€β”€ charon-enr-private-key -β”‚ β”œβ”€β”€ cluster-lock.json -β”‚ β”œβ”€β”€ deposit-data.json -β”‚ └── validator_keys -β”‚ β”œβ”€β”€ keystore-0.json -β”‚ └── keystore-0.txt -β”œβ”€β”€ node2 -β”‚ β”œβ”€β”€ charon-enr-private-key -β”‚ β”œβ”€β”€ cluster-lock.json -β”‚ β”œβ”€β”€ deposit-data.json -β”‚ └── validator_keys -β”‚ β”œβ”€β”€ keystore-0.json -β”‚ └── keystore-0.txt -└── node3 - β”œβ”€β”€ charon-enr-private-key - β”œβ”€β”€ cluster-lock.json - β”œβ”€β”€ deposit-data.json - └── validator_keys - β”œβ”€β”€ keystore-0.json - └── keystore-0.txt - -``` - -```log title="Folder structure to be placed on each DV node" -└── .charon - β”œβ”€β”€ charon-enr-private-key - β”œβ”€β”€ cluster-lock.json - β”œβ”€β”€ deposit-data.json - └── validator_keys - β”œβ”€β”€ keystore-0.json - β”œβ”€β”€ keystore-0.txt - β”œβ”€β”€ ... - β”œβ”€β”€ keystore-N.json - └── keystore-N.txt -``` - -:point_right: Use the single node [docker compose](https://github.com/ObolNetwork/charon-distributed-validator-node), the kubernetes [manifests](https://github.com/ObolNetwork/charon-k8s-distributed-validator-node), or the [helm chart](https://github.com/ObolNetwork/helm-charts) example repos to get your nodes up and connected after loading the `.charon` folder artifacts into them appropriately. - -:::caution -Right now, the `charon create cluster` command [used earlier to create the private keys](./create-keys) outputs a folder structure like `cluster/node*/`. Make sure to grab the `./node*/` folders, *rename* them to `.charon` and then move them to one of the single node repos above. Once all nodes are online, synced, and connected, you will be ready to activate your validator. -::: diff --git a/docs/int/quickstart/alone/test-locally.md b/docs/int/quickstart/alone/test-locally.md deleted file mode 100644 index 7f1bb6aa12..0000000000 --- a/docs/int/quickstart/alone/test-locally.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -sidebar_position: 1 -description: Test the solo cluster locally ---- - -# Run a test cluster locally -:::warning -This is a demo repo to understand how Distributed Validators work and **is not suitable for a mainnet deployment**. - -This guide only runs one Execution Client, one Consensus Client, and 6 Distributed Validator Charon Client + Validator Client pairs on a single docker instance. As a consequence, if this machine fails, there will not be fault tolerance. - -Follow these two guides sequentially instead for production deployment: [create keys centrally](./create-keys.md) and [how to deploy them](./deploy.md). -::: - -The [`charon-distributed-validator-cluster`](https://github.com/ObolNetwork/charon-distributed-validator-cluster) repo contains six charon clients in separate docker containers along with an execution client and consensus client, simulating a Distributed Validator cluster running. - -The default cluster consists of: -- [Nethermind](https://github.com/NethermindEth/nethermind), an execution layer client -- [Lighthouse](https://github.com/sigp/lighthouse), a consensus layer client -- Six [charon](https://github.com/ObolNetwork/charon) nodes -- A mixture of validator clients: - - VC0: [Lighthouse](https://github.com/sigp/lighthouse) - - vc1: [Teku](https://github.com/ConsenSys/teku) - - vc2: [Nimbus](https://github.com/status-im/nimbus-eth2) - - vc3: [Lighthouse](https://github.com/sigp/lighthouse) - - vc4: [Teku](https://github.com/ConsenSys/teku) - - vc5: [Nimbus](https://github.com/status-im/nimbus-eth2) - -## Pre-requisites - -- Ensure you have [docker](https://docs.docker.com/engine/install/) installed. -- Ensure you have [git](https://git-scm.com/downloads) installed. -- Make sure `docker` is running before executing the commands below. - -## Create the key shares locally - -1. Clone the [charon-distributed-validator-cluster](https://github.com/ObolNetwork/charon-distributed-validator-cluster) repo and `cd` into the directory. - - ```sh - # Clone the repo - git clone https://github.com/ObolNetwork/charon-distributed-validator-cluster.git - - # Change directory - cd charon-distributed-validator-cluster/ - ``` - -2. Prepare the environment variables - - ```sh - # Copy the sample environment variables - cp .env.sample .env - ``` - `.env.sample` is a sample environment file that allows overriding default configuration defined in `docker-compose.yml`. Uncomment and set any variable to override its value. - -3. Create the artifacts needed to run a DV cluster by running the following command: - - ```sh - # Enter required validator addresses - WITHDRAWAL_ADDR= - FEE_RECIPIENT_ADDR= - - # Create a distributed validator cluster - docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.19.0 create cluster --name="mycluster" --cluster-dir=".charon/cluster/" --withdrawal-addresses="${WITHDRAWAL_ADDR}" --fee-recipient-addresses="${FEE_RECIPIENT_ADDR}" --nodes 6 --network goerli --num-validators=1 - ``` - -These commands will create six folders within `.charon/cluster`, one for each node created. You will need to rename `node*` to `.charon` for each folder to be found by the default `charon run` command, or you can use `charon run --private-key-file=".charon/cluster/node0/charon-enr-private-key" --lock-file=".charon/cluster/node0/cluster-lock.json"` for each instance of charon you start. - -## Start the cluster - -Run this command to start your cluster containers - -```sh -# Start the distributed validator cluster -docker compose up --build -``` -Check the monitoring dashboard and see if things look all right - -```sh -# Open Grafana -open http://localhost:3000/d/laEp8vupp -``` \ No newline at end of file diff --git a/docs/int/quickstart/group/_category_.json b/docs/int/quickstart/group/_category_.json deleted file mode 100644 index e4c14eb202..0000000000 --- a/docs/int/quickstart/group/_category_.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "label": "Create a DV as a group", - "position": 2, - "collapsed": true -} \ No newline at end of file diff --git a/docs/int/quickstart/group/index.md b/docs/int/quickstart/group/index.md deleted file mode 100644 index 6eafcd77d7..0000000000 --- a/docs/int/quickstart/group/index.md +++ /dev/null @@ -1,18 +0,0 @@ -# Run a cluster as a group - -:::caution -Charon is in a beta state and should be used with caution according to its [Terms of Use](https://obol.tech/terms.pdf). -::: - -:::info -Running a Distributed Validator with others typically means that several operators run the various nodes of the cluster. In such a case, the key shares should be created with a [distributed key generation process](../../key-concepts.md#distributed-validator-key-generation-ceremony), avoiding the private key being stored in full, anywhere. -::: - -There are two sequential user journeys when setting up a DV cluster with others. Each comes with its own quickstart: - -1. The [**Creator** (**Leader**) Journey](./group/quickstart-group-leader-creator), which outlines the steps to propose a Distributed Validator Cluster. - - In the **Creator** case, the person creating the cluster *will NOT* be a node operator in the cluster. - - In the **Leader** case, the person creating the cluster *will* be a node operator in the cluster. - - -2. The [**Operator** Journey](./group/quickstart-group-operator) which outlines the steps to create a Distributed Validator Cluster proposed by a leader or creator using the above process. \ No newline at end of file diff --git a/docs/int/quickstart/group/quickstart-cli.md b/docs/int/quickstart/group/quickstart-cli.md deleted file mode 100644 index bd6cc7e91b..0000000000 --- a/docs/int/quickstart/group/quickstart-cli.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -sidebar_position: 3 -description: Run one node in a multi-operator distributed validator cluster using the CLI ---- - -# Using the CLI - -:::caution -Charon is in a beta state and should be used with caution according to its [Terms of Use](https://obol.tech/terms.pdf). -::: - -The following instructions aim to assist a group of operators coordinating together to create a distributed validator cluster via the CLI. - -## Pre-requisites - -- Ensure you have [docker](https://docs.docker.com/engine/install/) installed. -- Ensure you have [git](https://git-scm.com/downloads) installed. -- Make sure `docker` is running before executing the commands below. -- Decide who the Leader or Creator of your cluster will be. Only them have to perform [step 2](#step-2-leader-creates-the-dkg-configuration-file-and-distributes-it-to-everyone-else) and [step 5](#step-5-activate-the-deposit-data) in this quickstart. They do not get any special privilege. - - In the **Leader** case, the operator creating the cluster will also operate a node in the cluster. - - In the **Creator** case, the cluster is created by an external party to the cluster. - -## Step 1. Create and back up a private key for charon - -In order to prepare for a distributed key generation ceremony, all operators (including the leader but NOT a creator) need to create an [ENR](../../faq/errors.mdx) for their charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. - -```sh -# Clone this repo -git clone https://github.com/ObolNetwork/charon-distributed-validator-node.git - -# Change directory -cd charon-distributed-validator-node - -# Create your charon ENR private key, this will create a charon-enr-private-key file in the .charon directory -docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.19.0 create enr -``` - -You should expect to see a console output like - - Created ENR private key: .charon/charon-enr-private-key - enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u - -:::caution -Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** -::: - -Finally, share your ENR with the leader or creator so that he/she can proceed to Step 2. - -## Step 2. Leader or Creator creates the DKG configuration file and distribute it to cluster operators - -1. The leader or creator of the cluster will prepare the `cluster-definition.json` file for the Distributed Key Generation ceremony using the `charon create dkg` command. - - ``` - # Prepare an environment variable file - cp .env.create_dkg.sample .env.create_dkg - ``` -2. Populate the `.env.create_dkg` file created with the `cluster name`, the `fee recipient` and `withdrawal Ethereum addresses`, and the `ENRs` of all the operators participating in the cluster. - - The file generated is hidden by default. To view it, run `ls -al` in your terminal. Else, if you are on `macOS`, press `Cmd + Shift + .` to view all hidden files in the finder application. - -3. Run the `charon create dkg` command that generates DKG cluster-definition.json file. - ``` - docker run --rm -v "$(pwd):/opt/charon" --env-file .env.create_dkg obolnetwork/charon:v0.19.0 create dkg - ``` - - This command should output a file at `.charon/cluster-definition.json`. This file needs to be shared with the other operators in a cluster. - -## Step 3. Run the DKG - -After receiving the `cluster-definition.json` file created by the leader, cluster operators should ideally save it in the `.charon/` folder that was created during step 1, alternatively the `--definition-file` flag can override the default expected location for this file. - -Every cluster member then participates in the DKG ceremony. For Charon v1, this needs to happen relatively synchronously between participants at an agreed time. - -``` -# Participate in DKG ceremony, this will create .charon/cluster-lock.json, .charon/deposit-data.json and .charon/validator_keys -docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.19.0 dkg -``` - ->This is a helpful [video walkthrough](https://www.youtube.com/watch?v=94Pkovp5zoQ&ab_channel=ObolNetwork). - -Assuming the DKG is successful, a number of artefacts will be created in the `.charon` folder. These include: - -- A `deposit-data.json` file. This contains the information needed to activate the validator on the Ethereum network. -- A `cluster-lock.json` file. This contains the information needed by charon to operate the distributed validator cluster with its peers. -- A `validator_keys/` folder. This folder contains the private key shares and passwords for the created distributed validators. - -:::caution -Please make sure to create a backup of `.charon/validator_keys`. **If you lose your keys you won't be able to start the DV cluster successfully.** -::: - -:::info -The `cluster-lock` and `deposit-data` files are identical for each operator and can be copied if lost. -::: - -## Step 4. Start your Distributed Validator Node - -With the DKG ceremony over, the last phase before activation is to prepare your node for validating over the long term. This repo is configured to sync an execution layer client (`geth`) and a consensus layer client (`lighthouse`). - -**Caution**: If you manually update `docker-compose` to mount `lighthouse` from your locally synced `~/.lighthouse`, the whole chain database may get deleted. It'd be best not to manually update as `lighthouse` checkpoint-syncs so the syncing doesn't take much time. - -**Note**: If you have a `geth` node already synced, you can simply copy over the directory. For ex: `cp -r ~/.ethereum/goerli data/geth`. This makes everything faster since you start from a synced geth node. - -``` -# Delete lighthouse data if it exists -rm -r ./data/lighthouse - -# Spin up a Distributed Validator Node with a Validator Client -docker compose up - -# Open Grafana dashboard -open http://localhost:3000/d/singlenode/ -``` - -You should use the grafana dashboard to infer whether your cluster is healthy. In particular you should check: - -- That your charon client can connect to the configured beacon client. -- That your charon client can connect to all peers. - -Most components in the dashboard have some help text there to assist you in understanding your cluster performance. - -You might notice that there are logs indicating that a validator cannot be found and that APIs are returning 404. This is to be expected at this point, as the validator public keys listed in the lock file have not been deposited and acknowledged on the consensus layer yet (usually ~16 hours after the deposit is made). - -If at any point you need to turn off your node, you can run: - -``` -# Shut down the currently running distributed validator node -docker compose down -``` - -:::tip -In a Distributed Validator Cluster, it is important to have a low latency connection to your peers. Charon clients will use the NAT protocol to attempt to establish a direct connection to one another automatically. If this doesn't happen, you should port forward charon's p2p port to the public internet to facilitate direct connections. (The default port to expose is `:3610`). Read more about charon's networking [here](../../../charon/networking.md). -::: \ No newline at end of file diff --git a/docs/int/quickstart/group/quickstart-group-leader-creator.md b/docs/int/quickstart/group/quickstart-group-leader-creator.md deleted file mode 100644 index 8fc8c4fdbb..0000000000 --- a/docs/int/quickstart/group/quickstart-group-leader-creator.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -sidebar_position: 1 -description: A leader/creator creates a cluster configuration to be shared with operators ---- -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -# Creator & Leader Journey - -:::caution -Charon is in a beta state and should be used with caution according to its [Terms of Use](https://obol.tech/terms.pdf). -::: - -The following instructions aim to assist with the preparation of a distributed validator key generation ceremony. Select the *Leader* tab if you **will** be an operator participating in the cluster, and select the *Creator* tab if you **will NOT** be an operator in the cluster. - -These roles hold no position of privilege in the cluster, they only set the initial terms of the cluster that the other operators agree to. - - - - The person creating the cluster will be a node operator in the cluster.

-

Pre-requisites

-
    -
  • Ensure you have docker installed.
    • -
  • Ensure you have git installed.
    • -
  • Make sure docker is running before executing the commands below.
    • -
- - - The person creating the cluster will not be a node operator in the cluster. - - - -## Overview Video - -

- -## Step 1. Collect Ethereum addresses of the cluster operators -Before starting the cluster creation, you will need to collect one Ethereum address per operator in the cluster. They will need to be able to sign messages through metamask with this address. Broader wallet support will be added in future. - -## Step 2. Create and back up a private key for charon - - - - - In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. - - ```sh - # Clone this repo - git clone https://github.com/ObolNetwork/charon-distributed-validator-node.git - - # Change directory - cd charon-distributed-validator-node - - # Create your charon ENR private key, this will create a charon-enr-private-key file in the .charon directory - docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.19.0 create enr - ``` - -You should expect to see a console output like - - Created ENR private key: .charon/charon-enr-private-key - enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u - -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. - -:::caution -Ensure you create a backup of the private key stored in the '.charon' folder, specifically at '.charon/charon-enr-private-key'. This is the file used to generate your private key. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** -::: - - - - - This step is not needed and you can move on to [Step 3](#step-3-create-the-dkg-configuration-file-and-distribute-it-to-cluster-operators). - - - - -## Step 3. Create the DKG configuration file and distribute it to cluster operators - -You will prepare the configuration file for the distributed key generation ceremony using the launchpad. - -1. Go to the [DV Launchpad](https://goerli.launchpad.obol.tech) -2. Connect your wallet - - ![Connect your Wallet](/img/Guide01.png) - -3. Select `Create a Cluster with a group` then `Get Started`. - - ![Get Started](/img/Guide02.png) - -4. Follow the flow and accept the advisories. -5. Configure the Cluster - - Input the `Cluster Name` & `Cluster Size` (i.e. number of operators in the cluster). The threshold for the cluster to operate sucessfully will update automatically. - - - -
  • - - ⚠️ Leave the `Non-Operator` toggle OFF. - -
- - -
  • - - ⚠️ Turn the `Non-Operator` toggle ON. - -
- - - - - Input the Ethereum addresses for each operator collected during [step 1](#step-1-collect-ethereum-addresses-of-the-cluster-operators). - - Select the desired amount of validators (32 ETH each) the cluster will run. - - Paste your `ENR` generated at [Step 2](#step-2-create-and-back-up-a-private-key-for-charon). - - Select the `Withdrawal Addresses` method. Use `Single address` to receive the principal and fees to a single address or `Splitter Contracts` to share them among operators. - - - -
    -
  • Enter the Withdrawal Address that will receive the validator effective balance at exit and when balance skimming occurs.
    • -
  • Enter the Fee Recipient Address to receive MEV rewards (if enabled), and block proposal priority fees.
    • -
- You can set them to be the same as your connected wallet address in one click. -

- - ![Create Group](/img/Guide03.png) - - - -
    -
  • Enter the Ethereum address to claim the validator principal (32 ether) at exit.
    • -
  • Enter the Ethereum addresses and their percentage split of the validator's rewards. Validator rewards include consensus rewards, MEV rewards and proposal priority fees.
    • -

- - ![Create Group](/img/Guide03-splitter.png) - - - - - - Click `Create Cluster Configuration` - - - - -
    - 6. Review the cluster configuration -
- - -
    6. Deploy the Obol Splits contracts by signing the transaction with your wallet.
- - - - - -
    - 7. You will be asked to confirm your configuration and to sign: -
-
    -
      -
    • The config_hash. This is a hashed representation of the details of this cluster, to ensure everyone is agreeing to an identical setup.
      • -
    • The operator_config_hash. This is your acceptance of the terms as a participating node operator.
      • -
    • Your ENR. Signing your ENR authorises the corresponding private key to act on your behalf in the cluster.
      • -
    -
- - -
    - 7. You will be asked to confirm your configuration and to sign: -
-
    -
      -
    • The config_hash. This is a hashed representation of the details of this cluster, to ensure everyone is agreeing to an identical setup.
      • -
    -
- - - -8. Share your cluster invite link with the operators. Following the link will show you a screen waiting for other operators to accept the configuration you created. - - ![Invite Operators](/img/Guide04.png) - - - - - πŸ‘‰ Once every participating operator has signed their approval to the terms, you will continue the [**Operator** journey](./quickstart-group-operator#step-3-run-the-dkg) by completing the distributed key generation step. - - - - - Your journey ends here and you can monitor with the link whether the operators confirm their agreement to the cluster by signing their approval. Future versions of the launchpad will allow a creator to track a distributed validator's lifecycle in its entirety. - - - - diff --git a/docs/int/quickstart/group/quickstart-group-operator.md b/docs/int/quickstart/group/quickstart-group-operator.md deleted file mode 100644 index 80bd856c84..0000000000 --- a/docs/int/quickstart/group/quickstart-group-operator.md +++ /dev/null @@ -1,147 +0,0 @@ ---- -sidebar_position: 1 -description: A node operator joins a DV cluster ---- - -# Operator Journey - -:::caution -Charon is in a beta state and should be used with caution according to its [Terms of Use](https://obol.tech/terms.pdf). -::: - -The following instructions aim to assist a group of operators coordinating together to create a distributed validator cluster after receiving an cluster invite link from a leader or creator. - -## Overview Video -

- -## Pre-requisites - -- Ensure you have [docker](https://docs.docker.com/engine/install/) installed. -- Ensure you have [git](https://git-scm.com/downloads) installed. -- Make sure `docker` is running before executing the commands below. - -## Step 1. Share an Ethereum address with your Leader or Creator -Before starting the cluster creation, make sure you have shared an Ethereum address with your cluster **Leader** or **Creator**. If you haven't chosen someone as a Leader or Creator yet, please go back to the [Quickstart intro](./index.md) and define one person to go through the [Leader & Creator Journey](./quickstart-group-leader-creator) before moving forward. - -## Step 2. Create and back up a private key for charon - -In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. - -```sh -# Clone this repo -git clone https://github.com/ObolNetwork/charon-distributed-validator-node.git - -# Change directory -cd charon-distributed-validator-node - -# Create your charon ENR private key, this will create a charon-enr-private-key file in the .charon directory -docker run --rm -v "$(pwd):/opt/charon" obolnetwork/charon:v0.19.0 create enr -``` - -You should expect to see a console output like - - Created ENR private key: .charon/charon-enr-private-key - enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u - -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. - -:::caution -Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** -::: - -## Step 3. Join and sign the cluster configuration - -After receiving the invite link created by the **Leader** or **Creator**, you will be able to join and sign the cluster configuration created. - -1. Go to the DV launchpad link provided by the leader or creator. -2. Connect your wallet using the Ethereum address provided to the leader in [step 1](#step-1-share-an-ethereum-address-with-your-leader-or-creator). - - ![Connect Wallet](/img/Guide05.png) - -3. Review the operators addresses submitted and click `Get Started` to continue. - - ![Get Started](/img/Guide06.png) - -4. Review and accept the advisories. -5. Review the configuration created by the leader or creator and add your `ENR` generated in [step 2](#step-2-create-and-back-up-a-private-key-for-charon). - - ![Review Config](/img/Guide07.png) - -6. Sign the following with your wallet - - The config hash. This is a hashed representation of all of the details for this cluster. - - Your own `ENR`. This signature authorises the key represented by this ENR to act on your behalf in the cluster. - -7. Wait for all the other operators in your cluster to do the same. - -## Step 4. Run the DKG -:::info -For the [DKG](docs/charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. -::: - -### Overview -

- -1. Once all operators successfully signed, your screen will automatically advance to the next step and look like this. Click `Continue`. If you closed the tab, just go back to the invite link shared by the leader and connect your wallet. - - ![Config Signing Success](/img/Guide08.png) - -2. You have two options to perform the DKG. - 1. **Option 1** and default is to copy and run the `docker` command on the screen into your terminal. It will retrieve the remote cluster details and begin the DKG process. - - 2. **Option 2** (Manual DKG) is to download the `cluster-definition` file manually and move it to the hidden `.charon` folder. Then, every cluster member participates in the DKG ceremony by running the command displayed. - - ![Run the DKG](/img/Guide10.png) - -3. Assuming the DKG is successful, a number of artefacts will be created in the `.charon` folder. These include: - - - A `deposit-data.json` file. This contains the information needed to activate the validator on the Ethereum network. - - A `cluster-lock.json` file. This contains the information needed by charon to operate the distributed validator cluster with its peers. - - A `validator_keys/` folder. This folder contains the private key shares and passwords for the created distributed validators. - -:::caution -Please make sure to create a backup of `.charon/validator_keys`. **If you lose your keys you won't be able to start the DV cluster successfully.** -::: - -:::info -The `cluster-lock` and `deposit-data` files are identical for each operator and can be copied if lost. -::: - -## Step 5. Start your Distributed Validator Node - -With the DKG ceremony over, the last phase before activation is to prepare your node for validating over the long term. This repo is configured to sync an execution layer client (`geth`) and a consensus layer client (`lighthouse`). - -**Caution**: If you manually update `docker compose` to mount `lighthouse` from your locally synced `~/.lighthouse`, the whole chain database may get deleted. It'd be best not to manually update as `lighthouse` checkpoint-syncs so the syncing doesn't take much time. - -**Note**: If you have a `geth` node already synced, you can simply copy over the directory. For ex: `cp -r ~/.ethereum/goerli data/geth`. This makes everything faster since you start from a synced geth node. - -``` -# Delete lighthouse data if it exists -rm -r ./data/lighthouse - -# Spin up a Distributed Validator Node with a Validator Client -docker compose up - -# Open Grafana dashboard -open http://localhost:3000/d/singlenode/ -``` - -You should use the grafana dashboard to infer whether your cluster is healthy. In particular you should check: - -- That your charon client can connect to the configured beacon client. -- That your charon client can connect to all peers directly. -- That your validator client is connected to charon, and has the private keys it needs loaded and accessible. - -Most components in the dashboard have some help text there to assist you in understanding your cluster performance. - -You might notice that there are logs indicating that a validator cannot be found and that APIs are returning 404. This is to be expected at this point, as the validator public keys listed in the lock file have not been deposited and acknowledged on the consensus layer yet (usually ~16 hours after the deposit is made). - -If at any point you need to turn off your node, you can run: - -``` -# Shut down the currently running distributed validator node -docker compose down -``` - -:::tip -In a Distributed Validator Cluster, it is important to have a low latency connection to your peers. Charon clients will use the NAT protocol to attempt to establish a direct connection to one another automatically. If this doesn't happen, you should port forward charon's p2p port to the public internet to facilitate direct connections. (The default port to expose is `:3610`). Read more about charon's networking [here](../../../charon/networking.md). -::: diff --git a/docs/int/quickstart/index.md b/docs/int/quickstart/index.md deleted file mode 100644 index dc6e712533..0000000000 --- a/docs/int/quickstart/index.md +++ /dev/null @@ -1,11 +0,0 @@ -# Quickstart Guides - -:::caution -Charon is in a beta state and should be used with caution according to its [Terms of Use](https://obol.tech/terms.pdf). -::: - -There are two ways to set up a distributed validator and each comes with its own quickstart -1. [Run a DV cluster as a **group**](./group/index.md), where several operators run the nodes that make up the cluster. In this setup, the key shares are created using a distributed key generation process, avoiding the full private keys being stored in full in any one place. -This approach can also be used by single operators looking to manage all nodes of a cluster but wanting to create the key shares in a trust-minimised fashion. - -2. [Run a DV cluster **alone**](./quickstart/alone/create-keys), where a single operator runs all the nodes of the DV. Depending on trust assumptions, there is not necessarily the need to create the key shares via a DKG process. Instead the key shares can be created in a centralised manner, and distributed securely to the nodes. \ No newline at end of file diff --git a/docs/int/quickstart/quickstart-mainnet.md b/docs/int/quickstart/quickstart-mainnet.md deleted file mode 100644 index d255f4a69d..0000000000 --- a/docs/int/quickstart/quickstart-mainnet.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -sidebar_position: 7 -description: Run a cluster on mainnet ---- - -# Run a DV on mainnet - -:::warning -Charon is in a beta state, and **you should proceed only if you accept the risk, the [terms of use](https://obol.tech/terms.pdf), and have tested running a Distributed Validator on a testnet first**. - -Distributed Validators created for goerli cannot be used on mainnet and vice versa, please take caution when creating, backing up, and activating mainnet validators. Incorrect usage may result in a loss of funds. -::: - -This section is intended for users who wish to run their Distributed Validator on Ethereum mainnet. - -## Pre-requisites - -- You have [enough up-to-spec nodes](../key-concepts.md#distributed-validator-threshold) for your mainnet deployment. -- Ensure you have [docker](https://docs.docker.com/engine/install/) installed on each node. -- Ensure you have [git](https://git-scm.com/downloads) installed on each node. -- Make sure `docker` is running before executing the commands below. - -## Steps - -### Using charon-distributed-validator-node in full - -1. Clone the [charon-distributed-validator-node](https://github.com/ObolNetwork/charon-distributed-validator-node) repo and `cd` into the directory. - -```sh -# Clone this repo -git clone https://github.com/ObolNetwork/charon-distributed-validator-node.git - -# Change directory -cd charon-distributed-validator-node -``` - -2. If you have already cloned the repo previously, make sure that it is [up-to-date](./update). - -3. Copy the `.env.sample.mainnet` file to `.env` - -``` -cp -n .env.sample.mainnet .env -``` - -4. Run the docker compose file - -``` -docker compose up -d -``` - -Once your clients can connect and sync appropriately, your DV stack is now mainnet ready πŸŽ‰ - -### Using a remote mainnet beacon node - -:::caution -Using a remote beacon node will impact the performance of your Distributed Validator and should be used sparingly. -::: - -If you already have a mainnet beacon node running somewhere and you want to use that instead of running EL (`geth`) & CL (`lighthouse`) as part of the repo, you can disable these images. To do so, follow these steps: - -1. Copy the `docker-compose.override.yml.sample` file - -``` -cp -n docker-compose.override.yml.sample docker-compose.override.yml -``` - -2. Uncomment the `profiles: [disable]` section for both `geth` and `lighthouse`. The override file should now look like this - -``` -services: - geth: - # Disable geth - profiles: [disable] - # Bind geth internal ports to host ports - #ports: - #- 8545:8545 # JSON-RPC - #- 8551:8551 # AUTH-RPC - #- 6060:6060 # Metrics - - lighthouse: - # Disable lighthouse - profiles: [disable] - # Bind lighthouse internal ports to host ports - #ports: - #- 5052:5052 # HTTP - #- 5054:5054 # Metrics -... -``` - -3. Then, uncomment and set the `CHARON_BEACON_NODE_ENDPOINTS` variable in the `.env` file to your mainnet beacon node's URL - -``` -... -# Connect to one or more external beacon nodes. Use a comma separated list excluding spaces. -CHARON_BEACON_NODE_ENDPOINTS= -... -``` - -4. Restart your docker compose - -``` -docker compose down -docker compose up -d -``` - -### Exit a mainnet Distributed Validator - -If you want to exit your mainnet validator, refer to our [exit guide](./quickstart-exit.md). \ No newline at end of file diff --git a/docs/intro.md b/docs/intro.md deleted file mode 100644 index 7c43380b83..0000000000 --- a/docs/intro.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -sidebar_position: 1 -description: Welcome to Obol and Distributed Validator Technology ---- - -# Introduction - -## What is Obol? - -Obol Labs is a research and software development team focused on proof-of-stake infrastructure for public blockchain networks. Specific topics of focus are Internet Bonds, Distributed Validator Technology and Multi-Operator Validation. The team currently includes 35 members that are spread across the world. - -The core team is building the Distributed Validator Protocol, a protocol to foster trust minimized staking through multi-operator validation. This will enable low-trust access to Ethereum staking yield, which can be used as a core building block in a variety of Web3 products. - -## About this documentation - -This manual is aimed at developers and stakers looking to utilize Distributed Validators for solo or multi-operator staking. To contribute to this documentation, head over to our [Github repository](https://github.com/ObolNetwork/obol-docs) and file a pull request. - -## Need assistance? - -If you have any questions about this documentation or are experiencing technical problems with any Obol-related projects, head on over to our [Discord](https://discord.gg/n6ebKsX46w) where a member of our team or the community will be happy to assist you. diff --git a/docs/int/quickstart/alone/_category_.json b/docs/intro/_category_.json similarity index 54% rename from docs/int/quickstart/alone/_category_.json rename to docs/intro/_category_.json index 9f98f73841..baa4b331b2 100644 --- a/docs/int/quickstart/alone/_category_.json +++ b/docs/intro/_category_.json @@ -1,5 +1,5 @@ { - "label": "Create a DV alone", + "label": "Introduction", "position": 1, "collapsed": true -} \ No newline at end of file +} diff --git a/docs/int/key-concepts.md b/docs/intro/key-concepts.md similarity index 99% rename from docs/int/key-concepts.md rename to docs/intro/key-concepts.md index c6014ba322..05cdbc4580 100644 --- a/docs/int/key-concepts.md +++ b/docs/intro/key-concepts.md @@ -1,5 +1,5 @@ --- -sidebar_position: 3 +sidebar_position: 2 description: Some of the key terms in the field of Distributed Validator Technology --- diff --git a/docs/int/Overview.md b/docs/intro/obol_overview.md similarity index 81% rename from docs/int/Overview.md rename to docs/intro/obol_overview.md index 4ca066bb52..c72b16044e 100644 --- a/docs/int/Overview.md +++ b/docs/intro/obol_overview.md @@ -1,8 +1,17 @@ --- -sidebar_position: 2 +sidebar_position: 1 description: An overview of the Obol network --- +# Overview of Obol + +## What is Obol? + +Obol Labs is a research and software development team focused on proof-of-stake infrastructure for public blockchain networks. Specific topics of focus are Internet Bonds, Distributed Validator Technology and Multi-Operator Validation. The team currently includes 35 members that are spread across the world. + +The core team is building the Distributed Validator Protocol, a protocol to foster trust minimized staking through multi-operator validation. This will enable low-trust access to Ethereum staking yield, which can be used as a core building block in a variety of Web3 products. + + ## The Network The network can be best visualized as a work layer that sits directly on top of base layer consensus. This work layer is designed to provide the base layer with more resiliency and promote decentralization as it scales. As Ethereum matures over the coming years, the community will move onto the next great scaling challenge, which is stake centralization. To effectively mitigate these risks, community building and credible neutrality must be used as primary design principles. @@ -13,10 +22,10 @@ Similar to how roll-up technology laid the foundation for L2 scaling implementat The Obol Network consists of four core public goods: -- The [Distributed Validator Launchpad](../dvl/intro), a [User Interface](https://goerli.launchpad.obol.tech/) for bootstrapping Distributed Validators -- [Charon](../charon/intro), a middleware client that enables validators to run in a fault-tolerant, distributed manner -- [Obol Splits](../sc/introducing-obol-splits.md), a set of solidity smart contracts for the distribution of rewards from Distributed Validators -- [Obol Testnets](../fr/testnet.md), distributed valdiator infrastructure for Ethereum public test networks, to enable any sized operator to test their deployment before running Distributed Validators on mainnet. +- The [Distributed Validator Launchpad](../dvl_intro.md), a user interface for bootstrapping Distributed Validators +- [Charon](../charon/intro.md), a middleware client that enables validators to run in a fault-tolerant, distributed manner +- [Obol Splits](../sc_obol-splits.md), a set of solidity smart contracts for the distribution of rewards from Distributed Validators +- [Obol Testnets](../fr/testnet.md), distributed validator infrastructure for Ethereum public test networks, to enable any sized operator to test their deployment before running Distributed Validators on mainnet. ### Sustainable Public Goods diff --git a/docs/sc/_category_.json b/docs/sc/_category_.json deleted file mode 100644 index c740383c52..0000000000 --- a/docs/sc/_category_.json +++ /dev/null @@ -1,5 +0,0 @@ -{ - "label": "Smart contracts", - "position": 5, - "collapsed": true -} diff --git a/docs/sc/introducing-obol-splits.md b/docs/sc_obol-splits.md similarity index 99% rename from docs/sc/introducing-obol-splits.md rename to docs/sc_obol-splits.md index 2f14d01024..9c1c604c85 100644 --- a/docs/sc/introducing-obol-splits.md +++ b/docs/sc_obol-splits.md @@ -1,5 +1,5 @@ --- -sidebar_position: 1 +sidebar_position: 7 description: Smart contracts for managing Distributed Validators --- diff --git a/docs/sec/_category_.json b/docs/security/_category_.json similarity index 73% rename from docs/sec/_category_.json rename to docs/security/_category_.json index 2c9d0b38b7..f445b9f96c 100644 --- a/docs/sec/_category_.json +++ b/docs/security/_category_.json @@ -1,5 +1,5 @@ { "label": "Security", - "position": 7, + "position": 8, "collapsed": true } diff --git a/docs/sec/bug-bounty.md b/docs/security/bug-bounty.md similarity index 100% rename from docs/sec/bug-bounty.md rename to docs/security/bug-bounty.md diff --git a/docs/sec/contact.md b/docs/security/contact.md similarity index 100% rename from docs/sec/contact.md rename to docs/security/contact.md diff --git a/docs/sec/ev-assessment.md b/docs/security/ev-assessment.md similarity index 99% rename from docs/sec/ev-assessment.md rename to docs/security/ev-assessment.md index 429c3f1ffa..a6141e1f73 100644 --- a/docs/sec/ev-assessment.md +++ b/docs/security/ev-assessment.md @@ -64,9 +64,9 @@ Obol’s business model is to eventually capture a portion of the revenue genera Obol’s product consists of three main components, each run by its own team: a webapp, a client, and smart contracts. -- [DV Launchpad](../dvl/intro.md): A webapp to create and manage distributed validators. +- [DV Launchpad](../dvl_intro.md): A webapp to create and manage distributed validators. - [Charon](../charon/intro.md): A middleware client that enables operators to run distributed validators. -- [Solidity](../sc/introducing-obol-splits.md): Withdrawal and fee recipient contracts for use with distributed validators. +- [Solidity](../sc_obol-splits.md): Withdrawal and fee recipient contracts for use with distributed validators. ## Analysis - Cluster Setup and DKG diff --git a/docs/sec/overview.md b/docs/security/overview.md similarity index 100% rename from docs/sec/overview.md rename to docs/security/overview.md diff --git a/docs/sec/smart_contract_audit.md b/docs/security/smart_contract_audit.md similarity index 100% rename from docs/sec/smart_contract_audit.md rename to docs/security/smart_contract_audit.md diff --git a/docs/sec/threat_model.md b/docs/security/threat_model.md similarity index 99% rename from docs/sec/threat_model.md rename to docs/security/threat_model.md index fbca3c7ce8..db9b4bff15 100644 --- a/docs/sec/threat_model.md +++ b/docs/security/threat_model.md @@ -123,7 +123,7 @@ A malicious relay owned by a OA could lead to: We note that BFT consensus liveness disruption can only happen if the number of nodes using the malicious relay for communication is equal to the byzantine nodes amount defined in the consensus parameters. -This risk can be mitigated by configuring nodes with multiple relay URLs from only [trusted entities](../int/quickstart/advanced/self-relay.md). +This risk can be mitigated by configuring nodes with multiple relay URLs from only [trusted entities](../advanced/self-relay.md). The likelihood of this scenario is medium: Charon nodes are configured with a default set of relay nodes, so if an OA were to compromise those, it would lead to many cluster topologies getting discovered and potentially attacked and disrupted. diff --git a/src/pages/sdk.md b/src/pages/sdk.md deleted file mode 100644 index 20eb84e4dd..0000000000 --- a/src/pages/sdk.md +++ /dev/null @@ -1,403 +0,0 @@ -**Obol SDK Documentation v1.0.8** β€’ API - -*** - -![Obol Logo](https://obol.tech/obolnetwork.png) - -

Obol SDK

- -This repo contains the Obol Software Development Kit, for creating Distributed Validators with the help of the [Obol API](https://docs.obol.tech/api). - -## Getting Started - -Checkout our [docs](https://docs.obol.tech/docs/int/quickstart/advanced/quickstart-sdk), [examples](https://github.com/ObolNetwork/obol-sdk-examples/), and SDK [reference](https://obolnetwork.github.io/obol-packages). Further guides and walkthroughs coming soon. - -## Enumerations - -### FORK\_MAPPING - -Permitted ChainID's - -#### Enumeration Members - -| Enumeration Member | Value | Description | -| :------ | :------ | :------ | -| `0x00000000` | `1` | Mainnet. | -| `0x00000064` | `100` | Gnosis Chain. | -| `0x00001020` | `5` | Goerli/Prater. | -| `0x01017000` | `17000` | Holesky. | - -## Classes - -### Client - -Obol sdk Client can be used for creating, managing and activating distributed validators. - -#### Extends - -- `Base` - -#### Constructors - -##### new Client(config, signer) - -> **new Client**(`config`, `signer`?): [`Client`](sdk#client) - -###### Parameters - -| Parameter | Type | Description | -| :------ | :------ | :------ | -| `config` | `Object` | | -| `config.baseUrl`? | `string` | - | -| `config.chainId`? | `number` | - | -| `signer`? | `Signer` | ethersJS Signer | - -###### Returns - -[`Client`](sdk#client) - -Obol-SDK Client instance - -An example of how to instantiate obol-sdk Client: -[obolClient](https://github.com/ObolNetwork/obol-sdk-examples/blob/main/TS-Example/index.ts#L29) - -###### Overrides - -`Base.constructor` - -###### Source - -[index.ts:27](https://github.com/ObolNetwork/obol-packages/blob/9a4d69b/packages/obol-sdk/src/index.ts#L27) - -#### Methods - -##### createClusterDefinition() - -> **createClusterDefinition**(`newCluster`): `Promise`\<`string`\> - -Creates a cluster definition which contains cluster configuration. - -###### Parameters - -| Parameter | Type | Description | -| :------ | :------ | :------ | -| `newCluster` | [`ClusterPayload`](sdk#clusterpayload) | The new unique cluster. | - -###### Returns - -`Promise`\<`string`\> - -config_hash. - -###### Throws - -On duplicate entries, missing or wrong cluster keys. - -An example of how to use createClusterDefinition: -[createObolCluster](https://github.com/ObolNetwork/obol-sdk-examples/blob/main/TS-Example/index.ts) - -###### Source - -[index.ts:42](https://github.com/ObolNetwork/obol-packages/blob/9a4d69b/packages/obol-sdk/src/index.ts#L42) - -##### getClusterDefinition() - -> **getClusterDefinition**(`configHash`): `Promise`\<[`ClusterDefintion`](sdk#clusterdefintion)\> - -###### Parameters - -| Parameter | Type | -| :------ | :------ | -| `configHash` | `string` | - -###### Returns - -`Promise`\<[`ClusterDefintion`](sdk#clusterdefintion)\> - -The cluster definition for config hash - -###### Throws - -On not found config hash. - -An example of how to use getClusterDefinition: -[getObolClusterDefinition](https://github.com/ObolNetwork/obol-sdk-examples/blob/main/TS-Example/index.ts) - -###### Source - -[index.ts:132](https://github.com/ObolNetwork/obol-packages/blob/9a4d69b/packages/obol-sdk/src/index.ts#L132) - -##### getClusterLock() - -> **getClusterLock**(`configHash`): `Promise`\<[`ClusterLock`](sdk#clusterlock)\> - -###### Parameters - -| Parameter | Type | -| :------ | :------ | -| `configHash` | `string` | - -###### Returns - -`Promise`\<[`ClusterLock`](sdk#clusterlock)\> - -The matched cluster details (lock) from DB - -###### Throws - -On not found cluster definition or lock. - -An example of how to use getClusterLock: -[getObolClusterLock](https://github.com/ObolNetwork/obol-sdk-examples/blob/main/TS-Example/index.ts) - -###### Source - -[index.ts:148](https://github.com/ObolNetwork/obol-packages/blob/9a4d69b/packages/obol-sdk/src/index.ts#L148) - -##### updateClusterDefinition() - -> **updateClusterDefinition**(`operatorPayload`, `configHash`): `Promise`\<[`ClusterDefintion`](sdk#clusterdefintion)\> - -Approves joining a cluster with specific configuration. - -###### Parameters - -| Parameter | Type | Description | -| :------ | :------ | :------ | -| `operatorPayload` | [`OperatorPayload`](sdk#operatorpayload) | The operator data including signatures. | -| `configHash` | `string` | The config hash of the cluster which the operator confirms joining to. | - -###### Returns - -`Promise`\<[`ClusterDefintion`](sdk#clusterdefintion)\> - -The cluster definition. - -###### Throws - -On unauthorized, duplicate entries, missing keys, not found cluster or invalid data. - -An example of how to use updateClusterDefinition: -[updateClusterDefinition](https://github.com/ObolNetwork/obol-sdk-examples/blob/main/TS-Example/index.ts) - -###### Source - -[index.ts:93](https://github.com/ObolNetwork/obol-packages/blob/9a4d69b/packages/obol-sdk/src/index.ts#L93) - -## Interfaces - -### ClusterDefintion - -Cluster Definition - -#### Extends - -- [`ClusterPayload`](sdk#clusterpayload) - -#### Properties - -| Property | Type | Description | Inherited from | -| :------ | :------ | :------ | :------ | -| `config_hash` | `string` | The cluster configuration hash. | - | -| `creator` | [`ClusterCreator`](sdk#clustercreator) | The creator of the cluster. | - | -| `definition_hash?` | `string` | The hash of the cluster definition. | - | -| `dkg_algorithm` | `string` | The cluster dkg algorithm. | - | -| `fork_version` | `string` | The cluster fork version. | - | -| `name` | `string` | The cluster name. | [`ClusterPayload`](sdk#clusterpayload).`name` | -| `num_validators` | `number` | The number of distributed validators in the cluster. | - | -| `operators` | [`ClusterOperator`](sdk#clusteroperator)[] | The cluster nodes operators addresses. | [`ClusterPayload`](sdk#clusterpayload).`operators` | -| `threshold` | `number` | The distributed validator threshold. | - | -| `timestamp` | `string` | The cluster creation timestamp. | - | -| `uuid` | `string` | The cluster uuid. | - | -| `validators` | [`ClusterValidator`](sdk#clustervalidator)[] | The clusters validators information. | [`ClusterPayload`](sdk#clusterpayload).`validators` | -| `version` | `string` | The cluster configuration version. | - | - -*** - -### ClusterLock - -Cluster Lock (Cluster Details after DKG is complete) - -#### Properties - -| Property | Type | Description | -| :------ | :------ | :------ | -| `cluster_definition` | [`ClusterDefintion`](sdk#clusterdefintion) | The cluster definition. | -| `distributed_validators` | [`DistributedValidator`](sdk#distributedvalidator)[] | The cluster distributed validators. | -| `lock_hash` | `string` | The hash of the cluster lock. | -| `node_signatures` | `string`[] | Node Signature for the lock hash by the node secp256k1 key. | -| `signature_aggregate` | `string` | The cluster bls signature aggregate. | - -*** - -### ClusterPayload - -Cluster Required Configuration - -#### Extended by - -- [`ClusterDefintion`](sdk#clusterdefintion) - -#### Properties - -| Property | Type | Description | -| :------ | :------ | :------ | -| `name` | `string` | The cluster name. | -| `operators` | [`ClusterOperator`](sdk#clusteroperator)[] | The cluster nodes operators addresses. | -| `validators` | [`ClusterValidator`](sdk#clustervalidator)[] | The clusters validators information. | - -## Type Aliases - -### BuilderRegistration - -> **BuilderRegistration**: `Object` - -Pre-generated Signed Validator Builder Registration - -#### Type declaration - -| Member | Type | Description | -| :------ | :------ | :------ | -| `message` | [`BuilderRegistrationMessage`](sdk#builderregistrationmessage) | Builder registration message. | -| `signature` | `string` | BLS signature of the builder registration message. | - -#### Source - -[types.ts:143](https://github.com/ObolNetwork/obol-packages/blob/9a4d69b/packages/obol-sdk/src/types.ts#L143) - -*** - -### BuilderRegistrationMessage - -> **BuilderRegistrationMessage**: `Object` - -Unsigned DV Builder Registration Message - -#### Type declaration - -| Member | Type | Description | -| :------ | :------ | :------ | -| `fee_recipient` | `string` | The DV fee recipient. | -| `gas_limit` | `number` | Default is 30000000. | -| `pubkey` | `string` | The public key of the DV. | -| `timestamp` | `number` | Timestamp when generating cluster lock file. | - -#### Source - -[types.ts:125](https://github.com/ObolNetwork/obol-packages/blob/9a4d69b/packages/obol-sdk/src/types.ts#L125) - -*** - -### ClusterCreator - -> **ClusterCreator**: `Object` - -Cluster Creator - -#### Type declaration - -| Member | Type | Description | -| :------ | :------ | :------ | -| `address` | `string` | The creator address. | -| `config_signature` | `string` | The cluster configuration signature. | - -#### Source - -[types.ts:51](https://github.com/ObolNetwork/obol-packages/blob/9a4d69b/packages/obol-sdk/src/types.ts#L51) - -*** - -### ClusterOperator - -> **ClusterOperator**: `Object` - -Cluster Node Operator - -#### Type declaration - -| Member | Type | Description | -| :------ | :------ | :------ | -| `address` | `string` | The operator address. | -| `config_signature` | `string` | The operator configuration signature. | -| `enr` | `string` | The operator ethereum node record. | -| `enr_signature` | `string` | The operator enr signature. | -| `fork_version` | `string` | The cluster fork_version. | -| `version` | `string` | The cluster version. | - -#### Source - -[types.ts:22](https://github.com/ObolNetwork/obol-packages/blob/9a4d69b/packages/obol-sdk/src/types.ts#L22) - -*** - -### ClusterValidator - -> **ClusterValidator**: `Object` - -Cluster Validator - -#### Type declaration - -| Member | Type | Description | -| :------ | :------ | :------ | -| `fee_recipient_address` | `string` | The validator fee recipient address. | -| `withdrawal_address` | `string` | The validator reward address. | - -#### Source - -[types.ts:62](https://github.com/ObolNetwork/obol-packages/blob/9a4d69b/packages/obol-sdk/src/types.ts#L62) - -*** - -### DepositData - -> **DepositData**: `Object` - -Deposit Data - -#### Type declaration - -| Member | Type | Description | -| :------ | :------ | :------ | -| `amount` | `string` | 32 ethers. | -| `deposit_data_root` | `string` | A checksum for DepositData fields . | -| `pubkey` | `string` | The public key of the distributed validator. | -| `signature` | `string` | BLS signature of the deposit message. | -| `withdrawal_credentials` | `string` | The 0x01 withdrawal address of the DV. | - -#### Source - -[types.ts:155](https://github.com/ObolNetwork/obol-packages/blob/9a4d69b/packages/obol-sdk/src/types.ts#L155) - -*** - -### DistributedValidator - -> **DistributedValidator**: `Object` - -Distributed Validator - -#### Type declaration - -| Member | Type | Description | -| :------ | :------ | :------ | -| `builder_registration` | [`BuilderRegistration`](sdk#builderregistration) | pre-generated signed validator builder registration to be sent to builder network. | -| `deposit_data` | `Partial`\<[`DepositData`](sdk#depositdata)\> | The required deposit data for activating the DV. | -| `distributed_public_key` | `string` | The public key of the distributed validator. | -| `public_shares` | `string`[] | The public key of the node distributed validator share. | - -#### Source - -[types.ts:176](https://github.com/ObolNetwork/obol-packages/blob/9a4d69b/packages/obol-sdk/src/types.ts#L176) - -*** - -### OperatorPayload - -> **OperatorPayload**: `Partial`\<[`ClusterOperator`](sdk#clusteroperator)\> & `Required`\<`Pick`\<[`ClusterOperator`](sdk#clusteroperator), `"enr"` \| `"version"`\>\> - -A partial view of `ClusterOperator` with `enr` and `version` as required properties. - -#### Source - -[types.ts:46](https://github.com/ObolNetwork/obol-packages/blob/9a4d69b/packages/obol-sdk/src/types.ts#L46) diff --git a/versioned_docs/version-v0.10.0/int/quickstart/quickstart-group.md b/versioned_docs/version-v0.10.0/int/quickstart/quickstart-group.md index e53064ff84..c66a6a42ec 100644 --- a/versioned_docs/version-v0.10.0/int/quickstart/quickstart-group.md +++ b/versioned_docs/version-v0.10.0/int/quickstart/quickstart-group.md @@ -13,7 +13,7 @@ Ensure you have [docker](https://docs.docker.com/engine/install/) and [git](http ## Step 1. Creating and backing up a private key for charon -The first step of running a cluster is preparing for a distributed key generation ceremony. To do this everyone must create an [ENR](https://docs.obol.tech/docs/int/faq#what-is-an-enr) for their charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. +The first step of running a cluster is preparing for a distributed key generation ceremony. To do this everyone must create an [ENR](../../int/faq) for their charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -41,7 +41,7 @@ If you are taking part in an organised Obol testnet, submit the created ENR publ One person, in the cluster or otherwise, will prepare the configuration file for the distributed key generation ceremony using the `charon create dkg` command. For the official Obol testnets, this step will be completed by an Obol core team member or the cluster captain and the definition file will be distributed to the cluster members for DKG completion. -In future, step 1 and step 2 of this guide will use the [Obol Distributed Validator Launchpad](https://docs.obol.tech/docs/dvk/distributed_validator_launchpad) to facilitate and verify these files are created in an authenticated manner. +In future, step 1 and step 2 of this guide will use the [Obol Distributed Validator Launchpad](../../dvk/distributed_validator_launchpad) to facilitate and verify these files are created in an authenticated manner. ``` # Prepare an environment variable file diff --git a/versioned_docs/version-v0.10.1/int/quickstart/group/quickstart-group-cli.md b/versioned_docs/version-v0.10.1/int/quickstart/group/quickstart-group-cli.md index bbc3b9b87b..8f0ec09649 100644 --- a/versioned_docs/version-v0.10.1/int/quickstart/group/quickstart-group-cli.md +++ b/versioned_docs/version-v0.10.1/int/quickstart/group/quickstart-group-cli.md @@ -42,7 +42,7 @@ If you are taking part in an organised Obol testnet, submit the created ENR publ The leader will prepare the `cluster-definition.json` file for the Distributed Key Generation ceremony using the `charon create dkg` command. -In future, step 1 and step 2 of this guide will use the [Obol Distributed Validator Launchpad](https://docs.obol.tech/docs/dvk/distributed_validator_launchpad) to facilitate and verify these files are created in an authenticated manner. +In future, step 1 and step 2 of this guide will use the [Obol Distributed Validator Launchpad](../../../dvk/distributed_validator_launchpad) to facilitate and verify these files are created in an authenticated manner. ``` # Prepare an environment variable file diff --git a/versioned_docs/version-v0.10.1/int/quickstart/group/quickstart-group-launchpad.md b/versioned_docs/version-v0.10.1/int/quickstart/group/quickstart-group-launchpad.md index 50d558916d..2e116a25a1 100644 --- a/versioned_docs/version-v0.10.1/int/quickstart/group/quickstart-group-launchpad.md +++ b/versioned_docs/version-v0.10.1/int/quickstart/group/quickstart-group-launchpad.md @@ -18,7 +18,7 @@ The following instructions aim to assist a group of users coordinating together ## Step 1. Creating and backing up a private key for charon -The first step of running a cluster is preparing for a distributed key generation ceremony. To do this everyone must create an [ENR](docs/int/faq/errors.mdx#what-is-an-enr) for their charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. +The first step of running a cluster is preparing for a distributed key generation ceremony. To do this everyone must create an [ENR](../../../int/faq/errors.mdx#what-is-an-enr) for their charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo diff --git a/versioned_docs/version-v0.11.0/int/quickstart/group/quickstart-group-cli.md b/versioned_docs/version-v0.11.0/int/quickstart/group/quickstart-group-cli.md index c810292ef2..57e340af6d 100644 --- a/versioned_docs/version-v0.11.0/int/quickstart/group/quickstart-group-cli.md +++ b/versioned_docs/version-v0.11.0/int/quickstart/group/quickstart-group-cli.md @@ -42,7 +42,7 @@ If you are taking part in an organised Obol testnet, submit the created ENR publ The leader will prepare the `cluster-definition.json` file for the Distributed Key Generation ceremony using the `charon create dkg` command. -In future, step 1 and step 2 of this guide will use the [Obol Distributed Validator Launchpad](https://docs.obol.tech/docs/dvk/distributed_validator_launchpad) to facilitate and verify these files are created in an authenticated manner. +In future, step 1 and step 2 of this guide will use the [Obol Distributed Validator Launchpad](../../../dvk/distributed_validator_launchpad) to facilitate and verify these files are created in an authenticated manner. ``` # Prepare an environment variable file diff --git a/versioned_docs/version-v0.11.0/int/quickstart/group/quickstart-group-launchpad.md b/versioned_docs/version-v0.11.0/int/quickstart/group/quickstart-group-launchpad.md index c2c7eb7af3..bb34ee6509 100644 --- a/versioned_docs/version-v0.11.0/int/quickstart/group/quickstart-group-launchpad.md +++ b/versioned_docs/version-v0.11.0/int/quickstart/group/quickstart-group-launchpad.md @@ -18,7 +18,7 @@ The following instructions aim to assist a group of users coordinating together ## Step 1. Creating and backing up a private key for charon -The first step of running a cluster is preparing for a distributed key generation ceremony. To do this everyone must create an [ENR](docs/int/faq/errors.mdx#what-is-an-enr) for their charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. +The first step of running a cluster is preparing for a distributed key generation ceremony. To do this everyone must create an [ENR](../../../int/faq/errors.mdx#what-is-an-enr) for their charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo diff --git a/versioned_docs/version-v0.12.0/int/quickstart/group/quickstart-group-cli.md b/versioned_docs/version-v0.12.0/int/quickstart/group/quickstart-group-cli.md index 784639ece7..ccaccfbb57 100644 --- a/versioned_docs/version-v0.12.0/int/quickstart/group/quickstart-group-cli.md +++ b/versioned_docs/version-v0.12.0/int/quickstart/group/quickstart-group-cli.md @@ -42,7 +42,7 @@ If you are taking part in an organised Obol testnet, submit the created ENR publ The leader will prepare the `cluster-definition.json` file for the Distributed Key Generation ceremony using the `charon create dkg` command. -In future, step 1 and step 2 of this guide will use the [Obol Distributed Validator Launchpad](https://docs.obol.tech/docs/dvk/distributed_validator_launchpad) to facilitate and verify these files are created in an authenticated manner. +In future, step 1 and step 2 of this guide will use the [Obol Distributed Validator Launchpad](../../../dvk/distributed_validator_launchpad) to facilitate and verify these files are created in an authenticated manner. ``` # Prepare an environment variable file diff --git a/versioned_docs/version-v0.12.0/int/quickstart/group/quickstart-group-launchpad.md b/versioned_docs/version-v0.12.0/int/quickstart/group/quickstart-group-launchpad.md index 87435fa205..07adfee3e0 100644 --- a/versioned_docs/version-v0.12.0/int/quickstart/group/quickstart-group-launchpad.md +++ b/versioned_docs/version-v0.12.0/int/quickstart/group/quickstart-group-launchpad.md @@ -18,7 +18,7 @@ The following instructions aim to assist a group of users coordinating together ## Step 1. Creating and backing up a private key for charon -The first step of running a cluster is preparing for a distributed key generation ceremony. To do this everyone must create an [ENR](docs/int/faq/errors.mdx#what-is-an-enr) for their charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. +The first step of running a cluster is preparing for a distributed key generation ceremony. To do this everyone must create an [ENR](../../../int/faq/errors.mdx#what-is-an-enr) for their charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo diff --git a/versioned_docs/version-v0.13.0/charon/cluster-configuration.md b/versioned_docs/version-v0.13.0/charon/cluster-configuration.md index 7152bb870b..ee3f3bea78 100644 --- a/versioned_docs/version-v0.13.0/charon/cluster-configuration.md +++ b/versioned_docs/version-v0.13.0/charon/cluster-configuration.md @@ -55,7 +55,7 @@ The schema of the `cluster-definition.json` is defined as: ### Using the DV Launchpad -- A [`leader/creator`](docs/int/quickstart/group/index.md), that wishes to co-ordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" +- A [`leader/creator`](../int/quickstart/group/index.md), that wishes to co-ordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" - The `leader/creator` uses the user interface to configure all of the important details about the cluster including: - The `Withdrawal Address` for the created validators - The `Fee Recipient Address` for block proposals if it differs from the withdrawal address diff --git a/versioned_docs/version-v0.13.0/charon/dkg.md b/versioned_docs/version-v0.13.0/charon/dkg.md index 08dde4cd0a..4fda42eb92 100644 --- a/versioned_docs/version-v0.13.0/charon/dkg.md +++ b/versioned_docs/version-v0.13.0/charon/dkg.md @@ -7,9 +7,9 @@ sidebar_position: 2 ## Overview -A [**distributed validator key**](docs/int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. +A [**distributed validator key**](../int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. -To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all neccessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](docs/int/key-concepts.md#distributed-validator-key-generation-ceremony). +To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all neccessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](../int/key-concepts.md#distributed-validator-key-generation-ceremony). The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster definition](../charon/cluster-configuration). diff --git a/versioned_docs/version-v0.13.0/charon/intro.md b/versioned_docs/version-v0.13.0/charon/intro.md index 84b207f9df..386af0edf2 100644 --- a/versioned_docs/version-v0.13.0/charon/intro.md +++ b/versioned_docs/version-v0.13.0/charon/intro.md @@ -38,4 +38,4 @@ The following is an outline of the services that can be exposed by charon. ## Getting started -For more information on running charon, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). +For more information on running charon, take a look at our [Quickstart Guides](../int/quickstart/index.md). diff --git a/versioned_docs/version-v0.13.0/dvl/intro.md b/versioned_docs/version-v0.13.0/dvl/intro.md index dcb6a4cb8d..2a39cb5871 100644 --- a/versioned_docs/version-v0.13.0/dvl/intro.md +++ b/versioned_docs/version-v0.13.0/dvl/intro.md @@ -15,4 +15,4 @@ To facilitate the generation of distributed validator keys amongst remote users ## Getting started -For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). \ No newline at end of file +For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](../int/quickstart/index.md). \ No newline at end of file diff --git a/versioned_docs/version-v0.13.0/int/quickstart/group/quickstart-group-leader-creator.md b/versioned_docs/version-v0.13.0/int/quickstart/group/quickstart-group-leader-creator.md index 420a4be600..97d6203a11 100644 --- a/versioned_docs/version-v0.13.0/int/quickstart/group/quickstart-group-leader-creator.md +++ b/versioned_docs/version-v0.13.0/int/quickstart/group/quickstart-group-leader-creator.md @@ -42,7 +42,7 @@ Before starting the cluster creation, you will need to collect one Ethereum addr - In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. + In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo diff --git a/versioned_docs/version-v0.13.0/int/quickstart/group/quickstart-group-operator.md b/versioned_docs/version-v0.13.0/int/quickstart/group/quickstart-group-operator.md index 6bf039187b..da43179969 100644 --- a/versioned_docs/version-v0.13.0/int/quickstart/group/quickstart-group-operator.md +++ b/versioned_docs/version-v0.13.0/int/quickstart/group/quickstart-group-operator.md @@ -25,7 +25,7 @@ Before starting the cluster creation, make sure you have shared an Ethereum addr ## Step 2. Create and back up a private key for charon -In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. +In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -73,7 +73,7 @@ After receiving the invite link created by the **Leader** or **Creator**, you wi ## Step 3. Run the DKG :::info -For the [DKG](docs/charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. +For the [DKG](../../../charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. ::: ### Overview diff --git a/versioned_docs/version-v0.14.0/charon/cluster-configuration.md b/versioned_docs/version-v0.14.0/charon/cluster-configuration.md index 1c6278eb24..407ff4cdcf 100644 --- a/versioned_docs/version-v0.14.0/charon/cluster-configuration.md +++ b/versioned_docs/version-v0.14.0/charon/cluster-configuration.md @@ -55,7 +55,7 @@ The schema of the `cluster-definition.json` is defined as: ### Using the DV Launchpad -- A [`leader/creator`](docs/int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" +- A [`leader/creator`](../int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" - The `leader/creator` uses the user interface to configure all of the important details about the cluster including: - The `Withdrawal Address` for the created validators - The `Fee Recipient Address` for block proposals if it differs from the withdrawal address diff --git a/versioned_docs/version-v0.14.0/charon/dkg.md b/versioned_docs/version-v0.14.0/charon/dkg.md index a2689ad830..395fd931de 100644 --- a/versioned_docs/version-v0.14.0/charon/dkg.md +++ b/versioned_docs/version-v0.14.0/charon/dkg.md @@ -7,9 +7,9 @@ sidebar_position: 2 ## Overview -A [**distributed validator key**](docs/int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. +A [**distributed validator key**](../int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. -To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](docs/int/key-concepts.md#distributed-validator-key-generation-ceremony). +To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](../int/key-concepts.md#distributed-validator-key-generation-ceremony). The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster definition](../charon/cluster-configuration). diff --git a/versioned_docs/version-v0.14.0/charon/intro.md b/versioned_docs/version-v0.14.0/charon/intro.md index 8594419aeb..a4a4acb5ba 100644 --- a/versioned_docs/version-v0.14.0/charon/intro.md +++ b/versioned_docs/version-v0.14.0/charon/intro.md @@ -5,7 +5,7 @@ sidebar_position: 1 # Introduction -This section introduces and outlines the Charon [kharon] middleware, Obol's implementation of DVT. Please see the [key concepts](/docs/int/key-concepts) section as background and context. +This section introduces and outlines the Charon [kharon] middleware, Obol's implementation of DVT. Please see the [key concepts](../int/key-concepts) section as background and context. ## What is Charon? @@ -79,4 +79,4 @@ The following is an outline of the services that can be exposed by charon. ## Getting started -For more information on running charon, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). +For more information on running charon, take a look at our [Quickstart Guides](../int/quickstart/index.md). diff --git a/versioned_docs/version-v0.14.0/dvl/intro.md b/versioned_docs/version-v0.14.0/dvl/intro.md index f227f32130..a0ea53c8c0 100644 --- a/versioned_docs/version-v0.14.0/dvl/intro.md +++ b/versioned_docs/version-v0.14.0/dvl/intro.md @@ -15,4 +15,4 @@ To facilitate the generation of distributed validator keys amongst remote users ## Getting started -For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). \ No newline at end of file +For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](../int/quickstart/index.md). \ No newline at end of file diff --git a/versioned_docs/version-v0.14.0/int/quickstart/group/quickstart-group-leader-creator.md b/versioned_docs/version-v0.14.0/int/quickstart/group/quickstart-group-leader-creator.md index e21af8cd66..d9e44b90e8 100644 --- a/versioned_docs/version-v0.14.0/int/quickstart/group/quickstart-group-leader-creator.md +++ b/versioned_docs/version-v0.14.0/int/quickstart/group/quickstart-group-leader-creator.md @@ -42,7 +42,7 @@ Before starting the cluster creation, you will need to collect one Ethereum addr - In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. + In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -60,7 +60,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** diff --git a/versioned_docs/version-v0.14.0/int/quickstart/group/quickstart-group-operator.md b/versioned_docs/version-v0.14.0/int/quickstart/group/quickstart-group-operator.md index 61d02331b9..dfe782dac1 100644 --- a/versioned_docs/version-v0.14.0/int/quickstart/group/quickstart-group-operator.md +++ b/versioned_docs/version-v0.14.0/int/quickstart/group/quickstart-group-operator.md @@ -25,7 +25,7 @@ Before starting the cluster creation, make sure you have shared an Ethereum addr ## Step 2. Create and back up a private key for charon -In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. +In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -43,7 +43,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** @@ -75,7 +75,7 @@ After receiving the invite link created by the **Leader** or **Creator**, you wi ## Step 4. Run the DKG :::info -For the [DKG](docs/charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. +For the [DKG](../../../charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. ::: ### Overview diff --git a/versioned_docs/version-v0.14.4/charon/cluster-configuration.md b/versioned_docs/version-v0.14.4/charon/cluster-configuration.md index 1c6278eb24..407ff4cdcf 100644 --- a/versioned_docs/version-v0.14.4/charon/cluster-configuration.md +++ b/versioned_docs/version-v0.14.4/charon/cluster-configuration.md @@ -55,7 +55,7 @@ The schema of the `cluster-definition.json` is defined as: ### Using the DV Launchpad -- A [`leader/creator`](docs/int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" +- A [`leader/creator`](../int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" - The `leader/creator` uses the user interface to configure all of the important details about the cluster including: - The `Withdrawal Address` for the created validators - The `Fee Recipient Address` for block proposals if it differs from the withdrawal address diff --git a/versioned_docs/version-v0.14.4/charon/dkg.md b/versioned_docs/version-v0.14.4/charon/dkg.md index 86b0e28d2d..2aa24f04d0 100644 --- a/versioned_docs/version-v0.14.4/charon/dkg.md +++ b/versioned_docs/version-v0.14.4/charon/dkg.md @@ -7,9 +7,9 @@ sidebar_position: 2 ## Overview -A [**distributed validator key**](docs/int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. +A [**distributed validator key**](../int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. -To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](docs/int/key-concepts.md#distributed-validator-key-generation-ceremony). +To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](../int/key-concepts.md#distributed-validator-key-generation-ceremony). The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster definition](../charon/cluster-configuration). diff --git a/versioned_docs/version-v0.14.4/charon/intro.md b/versioned_docs/version-v0.14.4/charon/intro.md index 8594419aeb..a4a4acb5ba 100644 --- a/versioned_docs/version-v0.14.4/charon/intro.md +++ b/versioned_docs/version-v0.14.4/charon/intro.md @@ -5,7 +5,7 @@ sidebar_position: 1 # Introduction -This section introduces and outlines the Charon [kharon] middleware, Obol's implementation of DVT. Please see the [key concepts](/docs/int/key-concepts) section as background and context. +This section introduces and outlines the Charon [kharon] middleware, Obol's implementation of DVT. Please see the [key concepts](../int/key-concepts) section as background and context. ## What is Charon? @@ -79,4 +79,4 @@ The following is an outline of the services that can be exposed by charon. ## Getting started -For more information on running charon, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). +For more information on running charon, take a look at our [Quickstart Guides](../int/quickstart/index.md). diff --git a/versioned_docs/version-v0.14.4/dvl/intro.md b/versioned_docs/version-v0.14.4/dvl/intro.md index f227f32130..a0ea53c8c0 100644 --- a/versioned_docs/version-v0.14.4/dvl/intro.md +++ b/versioned_docs/version-v0.14.4/dvl/intro.md @@ -15,4 +15,4 @@ To facilitate the generation of distributed validator keys amongst remote users ## Getting started -For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). \ No newline at end of file +For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](../int/quickstart/index.md). \ No newline at end of file diff --git a/versioned_docs/version-v0.14.4/int/quickstart/group/quickstart-group-leader-creator.md b/versioned_docs/version-v0.14.4/int/quickstart/group/quickstart-group-leader-creator.md index 557005f114..434617f4ff 100644 --- a/versioned_docs/version-v0.14.4/int/quickstart/group/quickstart-group-leader-creator.md +++ b/versioned_docs/version-v0.14.4/int/quickstart/group/quickstart-group-leader-creator.md @@ -42,7 +42,7 @@ Before starting the cluster creation, you will need to collect one Ethereum addr - In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. + In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -60,7 +60,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** diff --git a/versioned_docs/version-v0.14.4/int/quickstart/group/quickstart-group-operator.md b/versioned_docs/version-v0.14.4/int/quickstart/group/quickstart-group-operator.md index 80d2b6d068..22d4e938bc 100644 --- a/versioned_docs/version-v0.14.4/int/quickstart/group/quickstart-group-operator.md +++ b/versioned_docs/version-v0.14.4/int/quickstart/group/quickstart-group-operator.md @@ -25,7 +25,7 @@ Before starting the cluster creation, make sure you have shared an Ethereum addr ## Step 2. Create and back up a private key for charon -In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. +In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -43,7 +43,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** @@ -75,7 +75,7 @@ After receiving the invite link created by the **Leader** or **Creator**, you wi ## Step 4. Run the DKG :::info -For the [DKG](docs/charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. +For the [DKG](../../../charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. ::: ### Overview @@ -187,7 +187,7 @@ scrape_configs: Exiting your validator(s) can be useful in situations where you want to stop staking and withdraw your staked ETH. -πŸ‘‰ Follow the exit guide [here](docs/int/quickstart/quickstart-exit.md) +πŸ‘‰ Follow the exit guide [here](../../../int/quickstart/quickstart-exit.md) ## Feedback diff --git a/versioned_docs/version-v0.14.4/int/quickstart/quickstart-alone.md b/versioned_docs/version-v0.14.4/int/quickstart/quickstart-alone.md index 2cea330fea..9863e7e96f 100644 --- a/versioned_docs/version-v0.14.4/int/quickstart/quickstart-alone.md +++ b/versioned_docs/version-v0.14.4/int/quickstart/quickstart-alone.md @@ -97,7 +97,7 @@ This process can take a minimum of 16 hours, with the maximum time to activation Exiting your validator(s) can be useful in situations where you want to stop staking and withdraw your staked ETH. -πŸ‘‰ Follow the exit guide [here](docs/int/quickstart/quickstart-exit.md) +πŸ‘‰ Follow the exit guide [here](../../int/quickstart/quickstart-exit.md) ## Run Prysm VCs in a DV Cluster diff --git a/versioned_docs/version-v0.14.4/int/quickstart/quickstart-cli.md b/versioned_docs/version-v0.14.4/int/quickstart/quickstart-cli.md index 84a3a660e8..34bfb157f8 100644 --- a/versioned_docs/version-v0.14.4/int/quickstart/quickstart-cli.md +++ b/versioned_docs/version-v0.14.4/int/quickstart/quickstart-cli.md @@ -172,7 +172,7 @@ scrape_configs: Exiting your validator(s) can be useful in situations where you want to stop staking and withdraw your staked ETH. -πŸ‘‰ Follow the exit guide [here](docs/int/quickstart/quickstart-exit.md) +πŸ‘‰ Follow the exit guide [here](../../int/quickstart/quickstart-exit.md) ## Feedback diff --git a/versioned_docs/version-v0.15.0/charon/cluster-configuration.md b/versioned_docs/version-v0.15.0/charon/cluster-configuration.md index f94a495e2f..322cf7f53f 100644 --- a/versioned_docs/version-v0.15.0/charon/cluster-configuration.md +++ b/versioned_docs/version-v0.15.0/charon/cluster-configuration.md @@ -67,7 +67,7 @@ The schema of the `cluster-definition.json` is defined as: ### Using the DV Launchpad -- A [`leader/creator`](docs/int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" +- A [`leader/creator`](../int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" - The `leader/creator` uses the user interface to configure all of the important details about the cluster including: - The `Withdrawal Address` for the created validators - The `Fee Recipient Address` for block proposals if it differs from the withdrawal address diff --git a/versioned_docs/version-v0.15.0/charon/dkg.md b/versioned_docs/version-v0.15.0/charon/dkg.md index 86b0e28d2d..2aa24f04d0 100644 --- a/versioned_docs/version-v0.15.0/charon/dkg.md +++ b/versioned_docs/version-v0.15.0/charon/dkg.md @@ -7,9 +7,9 @@ sidebar_position: 2 ## Overview -A [**distributed validator key**](docs/int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. +A [**distributed validator key**](../int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. -To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](docs/int/key-concepts.md#distributed-validator-key-generation-ceremony). +To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](../int/key-concepts.md#distributed-validator-key-generation-ceremony). The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster definition](../charon/cluster-configuration). diff --git a/versioned_docs/version-v0.15.0/charon/intro.md b/versioned_docs/version-v0.15.0/charon/intro.md index 8594419aeb..a4a4acb5ba 100644 --- a/versioned_docs/version-v0.15.0/charon/intro.md +++ b/versioned_docs/version-v0.15.0/charon/intro.md @@ -5,7 +5,7 @@ sidebar_position: 1 # Introduction -This section introduces and outlines the Charon [kharon] middleware, Obol's implementation of DVT. Please see the [key concepts](/docs/int/key-concepts) section as background and context. +This section introduces and outlines the Charon [kharon] middleware, Obol's implementation of DVT. Please see the [key concepts](../int/key-concepts) section as background and context. ## What is Charon? @@ -79,4 +79,4 @@ The following is an outline of the services that can be exposed by charon. ## Getting started -For more information on running charon, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). +For more information on running charon, take a look at our [Quickstart Guides](../int/quickstart/index.md). diff --git a/versioned_docs/version-v0.15.0/dvl/intro.md b/versioned_docs/version-v0.15.0/dvl/intro.md index f227f32130..a0ea53c8c0 100644 --- a/versioned_docs/version-v0.15.0/dvl/intro.md +++ b/versioned_docs/version-v0.15.0/dvl/intro.md @@ -15,4 +15,4 @@ To facilitate the generation of distributed validator keys amongst remote users ## Getting started -For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). \ No newline at end of file +For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](../int/quickstart/index.md). \ No newline at end of file diff --git a/versioned_docs/version-v0.15.0/int/faq/general.md b/versioned_docs/version-v0.15.0/int/faq/general.md index 87014075ac..6b9ca5024b 100644 --- a/versioned_docs/version-v0.15.0/int/faq/general.md +++ b/versioned_docs/version-v0.15.0/int/faq/general.md @@ -51,7 +51,7 @@ It is possible to migrate your Charon node to another machine running the same c Currently, the minimum is 4 operators with a threshold of 3. -The threshold (aka quorum) corresponds to the minimum numbers of operators that need to be active for the validator(s) to be able to perform its(their) duties. It is defined by the following formula `n-(ceil(n/3)-1)`. We strongly recommend using this default threshold in your DKG as it maximises liveness while maintaining BFT safety. Setting a 4 out of 4 cluster for example, would make your validator more vulnerable to going offline instead of less vulnerable. You can check threshold value in your [`cluster-lock.json`](docs/charon/cluster-configuration.md) file. +The threshold (aka quorum) corresponds to the minimum numbers of operators that need to be active for the validator(s) to be able to perform its(their) duties. It is defined by the following formula `n-(ceil(n/3)-1)`. We strongly recommend using this default threshold in your DKG as it maximises liveness while maintaining BFT safety. Setting a 4 out of 4 cluster for example, would make your validator more vulnerable to going offline instead of less vulnerable. You can check threshold value in your [`cluster-lock.json`](../../charon/cluster-configuration.md) file. The maximum, honest answer, we don't know yet! It will depend heavily on your nodes network latency to talk to one another. The CLI caps out at 31 for now for a sane maximum. In practice, 10 nodes allows 3 nodes to fail at any one time, and probably is the largest cluster you should attempt for now unless you you're really experimenting πŸ˜…. diff --git a/versioned_docs/version-v0.15.0/int/quickstart/group/quickstart-group-leader-creator.md b/versioned_docs/version-v0.15.0/int/quickstart/group/quickstart-group-leader-creator.md index ed712d00b4..2264675703 100644 --- a/versioned_docs/version-v0.15.0/int/quickstart/group/quickstart-group-leader-creator.md +++ b/versioned_docs/version-v0.15.0/int/quickstart/group/quickstart-group-leader-creator.md @@ -42,7 +42,7 @@ Before starting the cluster creation, you will need to collect one Ethereum addr - In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. + In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -60,7 +60,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** diff --git a/versioned_docs/version-v0.15.0/int/quickstart/group/quickstart-group-operator.md b/versioned_docs/version-v0.15.0/int/quickstart/group/quickstart-group-operator.md index 20ab158203..5180163f7b 100644 --- a/versioned_docs/version-v0.15.0/int/quickstart/group/quickstart-group-operator.md +++ b/versioned_docs/version-v0.15.0/int/quickstart/group/quickstart-group-operator.md @@ -25,7 +25,7 @@ Before starting the cluster creation, make sure you have shared an Ethereum addr ## Step 2. Create and back up a private key for charon -In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. +In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -43,7 +43,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** @@ -75,7 +75,7 @@ After receiving the invite link created by the **Leader** or **Creator**, you wi ## Step 4. Run the DKG :::info -For the [DKG](docs/charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. +For the [DKG](../../../charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. ::: ### Overview @@ -187,7 +187,7 @@ scrape_configs: Exiting your validator(s) can be useful in situations where you want to stop staking and withdraw your staked ETH. -πŸ‘‰ Follow the exit guide [here](docs/int/quickstart/quickstart-exit.md) +πŸ‘‰ Follow the exit guide [here](../../../int/quickstart/quickstart-exit.md) ## Updating DV stack diff --git a/versioned_docs/version-v0.15.0/int/quickstart/quickstart-alone.md b/versioned_docs/version-v0.15.0/int/quickstart/quickstart-alone.md index 635b1069d3..63fd6127b8 100644 --- a/versioned_docs/version-v0.15.0/int/quickstart/quickstart-alone.md +++ b/versioned_docs/version-v0.15.0/int/quickstart/quickstart-alone.md @@ -97,7 +97,7 @@ This process can take a minimum of 16 hours, with the maximum time to activation Exiting your validator(s) can be useful in situations where you want to stop staking and withdraw your staked ETH. -πŸ‘‰ Follow the exit guide [here](docs/int/quickstart/quickstart-exit.md) +πŸ‘‰ Follow the exit guide [here](../../int/quickstart/quickstart-exit.md) ## Run Prysm VCs in a DV Cluster diff --git a/versioned_docs/version-v0.15.0/int/quickstart/quickstart-cli.md b/versioned_docs/version-v0.15.0/int/quickstart/quickstart-cli.md index 8be14c32c9..e003e15fa8 100644 --- a/versioned_docs/version-v0.15.0/int/quickstart/quickstart-cli.md +++ b/versioned_docs/version-v0.15.0/int/quickstart/quickstart-cli.md @@ -172,7 +172,7 @@ scrape_configs: Exiting your validator(s) can be useful in situations where you want to stop staking and withdraw your staked ETH. -πŸ‘‰ Follow the exit guide [here](docs/int/quickstart/quickstart-exit.md) +πŸ‘‰ Follow the exit guide [here](../../int/quickstart/quickstart-exit.md) ## Feedback diff --git a/versioned_docs/version-v0.16.0/charon/cluster-configuration.md b/versioned_docs/version-v0.16.0/charon/cluster-configuration.md index 56565254a1..6db2d8da21 100644 --- a/versioned_docs/version-v0.16.0/charon/cluster-configuration.md +++ b/versioned_docs/version-v0.16.0/charon/cluster-configuration.md @@ -67,7 +67,7 @@ The schema of the `cluster-definition.json` is defined as: ### Using the DV Launchpad -- A [`leader/creator`](docs/int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" +- A [`leader/creator`](../int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" - The `leader/creator` uses the user interface to configure all of the important details about the cluster including: - The `Withdrawal Address` for the created validators - The `Fee Recipient Address` for block proposals if it differs from the withdrawal address diff --git a/versioned_docs/version-v0.16.0/charon/dkg.md b/versioned_docs/version-v0.16.0/charon/dkg.md index 86b0e28d2d..2aa24f04d0 100644 --- a/versioned_docs/version-v0.16.0/charon/dkg.md +++ b/versioned_docs/version-v0.16.0/charon/dkg.md @@ -7,9 +7,9 @@ sidebar_position: 2 ## Overview -A [**distributed validator key**](docs/int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. +A [**distributed validator key**](../int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. -To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](docs/int/key-concepts.md#distributed-validator-key-generation-ceremony). +To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](../int/key-concepts.md#distributed-validator-key-generation-ceremony). The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster definition](../charon/cluster-configuration). diff --git a/versioned_docs/version-v0.16.0/charon/intro.md b/versioned_docs/version-v0.16.0/charon/intro.md index 767a6a3ded..03e6cfb6f7 100644 --- a/versioned_docs/version-v0.16.0/charon/intro.md +++ b/versioned_docs/version-v0.16.0/charon/intro.md @@ -5,7 +5,7 @@ sidebar_position: 1 # Introduction -This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](/docs/int/key-concepts) section as background and context. +This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](../int/key-concepts) section as background and context. ## What is Charon? @@ -79,4 +79,4 @@ The following is an outline of the services that can be exposed by charon. ## Getting started -For more information on running charon, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). +For more information on running charon, take a look at our [Quickstart Guides](../int/quickstart/index.md). diff --git a/versioned_docs/version-v0.16.0/dvl/intro.md b/versioned_docs/version-v0.16.0/dvl/intro.md index f227f32130..a0ea53c8c0 100644 --- a/versioned_docs/version-v0.16.0/dvl/intro.md +++ b/versioned_docs/version-v0.16.0/dvl/intro.md @@ -15,4 +15,4 @@ To facilitate the generation of distributed validator keys amongst remote users ## Getting started -For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). \ No newline at end of file +For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](../int/quickstart/index.md). \ No newline at end of file diff --git a/versioned_docs/version-v0.16.0/int/faq/risks.md b/versioned_docs/version-v0.16.0/int/faq/risks.md index ef6f988108..1315d4faec 100644 --- a/versioned_docs/version-v0.16.0/int/faq/risks.md +++ b/versioned_docs/version-v0.16.0/int/faq/risks.md @@ -8,7 +8,7 @@ description: Centralization Risks and mitigation # Risk: Obol hosting the relay infrastructure **Mitigation**: Self-host a relay -One of the risks associated with Obol hosting the [LibP2P relays](docs/charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. +One of the risks associated with Obol hosting the [LibP2P relays](../../charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. # Risk: Obol being able to update Charon code **Mitigation**: Pin specific versions @@ -16,9 +16,9 @@ One of the risks associated with Obol hosting the [LibP2P relays](docs/charon/ne Another risk associated with Obol is having the ability to update the [Charon code](https://github.com/ObolNetwork/charon) running on the network which could introduce vulnerabilities or malicious code. To mitigate this risk, Obol can consider pinning specific versions of the code that have been thoroughly tested and accepted by the network. This would ensure that any updates are carefully vetted and reviewed by the community. # Risk: Obol hosting the DV Launchpad -**Mitigation**: Use [`create cluster`](docs/charon/charon-cli-reference.md) or [`create dkg`](docs/charon/charon-cli-reference.md) locally and distribute the files manually +**Mitigation**: Use [`create cluster`](../../charon/charon-cli-reference.md) or [`create dkg`](../../charon/charon-cli-reference.md) locally and distribute the files manually -Hosting the first Charon frontend, the [DV Launchpad](docs/dvl/intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally. +Hosting the first Charon frontend, the [DV Launchpad](../../dvl/intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally. To mitigate the risk of launchpad failure, consider using the `create cluster` or `create dkg` commands locally and distributing the key shares files manually. diff --git a/versioned_docs/version-v0.16.0/int/quickstart/group/quickstart-group-leader-creator.md b/versioned_docs/version-v0.16.0/int/quickstart/group/quickstart-group-leader-creator.md index a79ede60cd..8a1941f9e7 100644 --- a/versioned_docs/version-v0.16.0/int/quickstart/group/quickstart-group-leader-creator.md +++ b/versioned_docs/version-v0.16.0/int/quickstart/group/quickstart-group-leader-creator.md @@ -42,7 +42,7 @@ Before starting the cluster creation, you will need to collect one Ethereum addr - In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. + In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -60,7 +60,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** diff --git a/versioned_docs/version-v0.16.0/int/quickstart/group/quickstart-group-operator.md b/versioned_docs/version-v0.16.0/int/quickstart/group/quickstart-group-operator.md index 3394e64282..5914d40840 100644 --- a/versioned_docs/version-v0.16.0/int/quickstart/group/quickstart-group-operator.md +++ b/versioned_docs/version-v0.16.0/int/quickstart/group/quickstart-group-operator.md @@ -25,7 +25,7 @@ Before starting the cluster creation, make sure you have shared an Ethereum addr ## Step 2. Create and back up a private key for charon -In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. +In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -43,7 +43,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** @@ -75,7 +75,7 @@ After receiving the invite link created by the **Leader** or **Creator**, you wi ## Step 4. Run the DKG :::info -For the [DKG](docs/charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. +For the [DKG](../../../charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. ::: ### Overview diff --git a/versioned_docs/version-v0.17.0/charon/cluster-configuration.md b/versioned_docs/version-v0.17.0/charon/cluster-configuration.md index aab4104033..bfde92cf6c 100644 --- a/versioned_docs/version-v0.17.0/charon/cluster-configuration.md +++ b/versioned_docs/version-v0.17.0/charon/cluster-configuration.md @@ -67,7 +67,7 @@ The schema of the `cluster-definition.json` is defined as: ### Using the DV Launchpad -- A [`leader/creator`](docs/int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" +- A [`leader/creator`](../int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" - The `leader/creator` uses the user interface to configure all of the important details about the cluster including: - The `Withdrawal Address` for the created validators - The `Fee Recipient Address` for block proposals if it differs from the withdrawal address diff --git a/versioned_docs/version-v0.17.0/charon/dkg.md b/versioned_docs/version-v0.17.0/charon/dkg.md index 86b0e28d2d..2aa24f04d0 100644 --- a/versioned_docs/version-v0.17.0/charon/dkg.md +++ b/versioned_docs/version-v0.17.0/charon/dkg.md @@ -7,9 +7,9 @@ sidebar_position: 2 ## Overview -A [**distributed validator key**](docs/int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. +A [**distributed validator key**](../int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. -To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](docs/int/key-concepts.md#distributed-validator-key-generation-ceremony). +To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](../int/key-concepts.md#distributed-validator-key-generation-ceremony). The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster definition](../charon/cluster-configuration). diff --git a/versioned_docs/version-v0.17.0/charon/intro.md b/versioned_docs/version-v0.17.0/charon/intro.md index 767a6a3ded..03e6cfb6f7 100644 --- a/versioned_docs/version-v0.17.0/charon/intro.md +++ b/versioned_docs/version-v0.17.0/charon/intro.md @@ -5,7 +5,7 @@ sidebar_position: 1 # Introduction -This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](/docs/int/key-concepts) section as background and context. +This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](../int/key-concepts) section as background and context. ## What is Charon? @@ -79,4 +79,4 @@ The following is an outline of the services that can be exposed by charon. ## Getting started -For more information on running charon, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). +For more information on running charon, take a look at our [Quickstart Guides](../int/quickstart/index.md). diff --git a/versioned_docs/version-v0.17.0/dvl/intro.md b/versioned_docs/version-v0.17.0/dvl/intro.md index f227f32130..a0ea53c8c0 100644 --- a/versioned_docs/version-v0.17.0/dvl/intro.md +++ b/versioned_docs/version-v0.17.0/dvl/intro.md @@ -15,4 +15,4 @@ To facilitate the generation of distributed validator keys amongst remote users ## Getting started -For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). \ No newline at end of file +For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](../int/quickstart/index.md). \ No newline at end of file diff --git a/versioned_docs/version-v0.17.0/int/faq/risks.md b/versioned_docs/version-v0.17.0/int/faq/risks.md index e2af412935..ff6229b66e 100644 --- a/versioned_docs/version-v0.17.0/int/faq/risks.md +++ b/versioned_docs/version-v0.17.0/int/faq/risks.md @@ -8,7 +8,7 @@ description: Centralization Risks and mitigation ## Risk: Obol hosting the relay infrastructure **Mitigation**: Self-host a relay -One of the risks associated with Obol hosting the [LibP2P relays](docs/charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. +One of the risks associated with Obol hosting the [LibP2P relays](../../charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. ## Risk: Obol being able to update Charon code **Mitigation**: Pin specific docker versions or compile from source on a trusted commit @@ -16,9 +16,9 @@ One of the risks associated with Obol hosting the [LibP2P relays](docs/charon/ne Another risk associated with Obol is having the ability to update the [Charon code](https://github.com/ObolNetwork/charon) running on the network which could introduce vulnerabilities or malicious code. To mitigate this risk, operators can consider pinning specific versions of the code that have been thoroughly tested and accepted by the network. This would ensure that any updates are carefully vetted and reviewed by the community. ## Risk: Obol hosting the DV Launchpad -**Mitigation**: Use [`create cluster`](docs/charon/charon-cli-reference.md) or [`create dkg`](docs/charon/charon-cli-reference.md) locally and distribute the files manually +**Mitigation**: Use [`create cluster`](../../charon/charon-cli-reference.md) or [`create dkg`](../../charon/charon-cli-reference.md) locally and distribute the files manually -Hosting the first Charon frontend, the [DV Launchpad](docs/dvl/intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally. +Hosting the first Charon frontend, the [DV Launchpad](../../dvl/intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally. To mitigate the risk of launchpad failure, consider using the `create cluster` or `create dkg` commands locally and distributing the key shares files manually. diff --git a/versioned_docs/version-v0.17.0/int/quickstart/group/quickstart-group-leader-creator.md b/versioned_docs/version-v0.17.0/int/quickstart/group/quickstart-group-leader-creator.md index d0b7481c94..2de62eb5ae 100644 --- a/versioned_docs/version-v0.17.0/int/quickstart/group/quickstart-group-leader-creator.md +++ b/versioned_docs/version-v0.17.0/int/quickstart/group/quickstart-group-leader-creator.md @@ -42,7 +42,7 @@ Before starting the cluster creation, you will need to collect one Ethereum addr - In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. + In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -60,7 +60,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** diff --git a/versioned_docs/version-v0.17.0/int/quickstart/group/quickstart-group-operator.md b/versioned_docs/version-v0.17.0/int/quickstart/group/quickstart-group-operator.md index 3c56d24c8f..6c67c72cf7 100644 --- a/versioned_docs/version-v0.17.0/int/quickstart/group/quickstart-group-operator.md +++ b/versioned_docs/version-v0.17.0/int/quickstart/group/quickstart-group-operator.md @@ -25,7 +25,7 @@ Before starting the cluster creation, make sure you have shared an Ethereum addr ## Step 2. Create and back up a private key for charon -In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. +In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -43,7 +43,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** @@ -75,7 +75,7 @@ After receiving the invite link created by the **Leader** or **Creator**, you wi ## Step 4. Run the DKG :::info -For the [DKG](docs/charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. +For the [DKG](../../../charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. ::: ### Overview diff --git a/versioned_docs/version-v0.17.1/charon/cluster-configuration.md b/versioned_docs/version-v0.17.1/charon/cluster-configuration.md index aab4104033..bfde92cf6c 100644 --- a/versioned_docs/version-v0.17.1/charon/cluster-configuration.md +++ b/versioned_docs/version-v0.17.1/charon/cluster-configuration.md @@ -67,7 +67,7 @@ The schema of the `cluster-definition.json` is defined as: ### Using the DV Launchpad -- A [`leader/creator`](docs/int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" +- A [`leader/creator`](../int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" - The `leader/creator` uses the user interface to configure all of the important details about the cluster including: - The `Withdrawal Address` for the created validators - The `Fee Recipient Address` for block proposals if it differs from the withdrawal address diff --git a/versioned_docs/version-v0.17.1/charon/dkg.md b/versioned_docs/version-v0.17.1/charon/dkg.md index 86b0e28d2d..2aa24f04d0 100644 --- a/versioned_docs/version-v0.17.1/charon/dkg.md +++ b/versioned_docs/version-v0.17.1/charon/dkg.md @@ -7,9 +7,9 @@ sidebar_position: 2 ## Overview -A [**distributed validator key**](docs/int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. +A [**distributed validator key**](../int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. -To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](docs/int/key-concepts.md#distributed-validator-key-generation-ceremony). +To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](../int/key-concepts.md#distributed-validator-key-generation-ceremony). The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster definition](../charon/cluster-configuration). diff --git a/versioned_docs/version-v0.17.1/charon/intro.md b/versioned_docs/version-v0.17.1/charon/intro.md index 767a6a3ded..03e6cfb6f7 100644 --- a/versioned_docs/version-v0.17.1/charon/intro.md +++ b/versioned_docs/version-v0.17.1/charon/intro.md @@ -5,7 +5,7 @@ sidebar_position: 1 # Introduction -This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](/docs/int/key-concepts) section as background and context. +This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](../int/key-concepts) section as background and context. ## What is Charon? @@ -79,4 +79,4 @@ The following is an outline of the services that can be exposed by charon. ## Getting started -For more information on running charon, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). +For more information on running charon, take a look at our [Quickstart Guides](../int/quickstart/index.md). diff --git a/versioned_docs/version-v0.17.1/dvl/intro.md b/versioned_docs/version-v0.17.1/dvl/intro.md index f227f32130..a0ea53c8c0 100644 --- a/versioned_docs/version-v0.17.1/dvl/intro.md +++ b/versioned_docs/version-v0.17.1/dvl/intro.md @@ -15,4 +15,4 @@ To facilitate the generation of distributed validator keys amongst remote users ## Getting started -For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). \ No newline at end of file +For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](../int/quickstart/index.md). \ No newline at end of file diff --git a/versioned_docs/version-v0.17.1/int/faq/risks.md b/versioned_docs/version-v0.17.1/int/faq/risks.md index e2af412935..ff6229b66e 100644 --- a/versioned_docs/version-v0.17.1/int/faq/risks.md +++ b/versioned_docs/version-v0.17.1/int/faq/risks.md @@ -8,7 +8,7 @@ description: Centralization Risks and mitigation ## Risk: Obol hosting the relay infrastructure **Mitigation**: Self-host a relay -One of the risks associated with Obol hosting the [LibP2P relays](docs/charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. +One of the risks associated with Obol hosting the [LibP2P relays](../../charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. ## Risk: Obol being able to update Charon code **Mitigation**: Pin specific docker versions or compile from source on a trusted commit @@ -16,9 +16,9 @@ One of the risks associated with Obol hosting the [LibP2P relays](docs/charon/ne Another risk associated with Obol is having the ability to update the [Charon code](https://github.com/ObolNetwork/charon) running on the network which could introduce vulnerabilities or malicious code. To mitigate this risk, operators can consider pinning specific versions of the code that have been thoroughly tested and accepted by the network. This would ensure that any updates are carefully vetted and reviewed by the community. ## Risk: Obol hosting the DV Launchpad -**Mitigation**: Use [`create cluster`](docs/charon/charon-cli-reference.md) or [`create dkg`](docs/charon/charon-cli-reference.md) locally and distribute the files manually +**Mitigation**: Use [`create cluster`](../../charon/charon-cli-reference.md) or [`create dkg`](../../charon/charon-cli-reference.md) locally and distribute the files manually -Hosting the first Charon frontend, the [DV Launchpad](docs/dvl/intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally. +Hosting the first Charon frontend, the [DV Launchpad](../../dvl/intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally. To mitigate the risk of launchpad failure, consider using the `create cluster` or `create dkg` commands locally and distributing the key shares files manually. diff --git a/versioned_docs/version-v0.17.1/int/quickstart/group/quickstart-group-leader-creator.md b/versioned_docs/version-v0.17.1/int/quickstart/group/quickstart-group-leader-creator.md index 6163d8d9cc..648dcc3374 100644 --- a/versioned_docs/version-v0.17.1/int/quickstart/group/quickstart-group-leader-creator.md +++ b/versioned_docs/version-v0.17.1/int/quickstart/group/quickstart-group-leader-creator.md @@ -42,7 +42,7 @@ Before starting the cluster creation, you will need to collect one Ethereum addr - In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. + In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -60,7 +60,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** diff --git a/versioned_docs/version-v0.17.1/int/quickstart/group/quickstart-group-operator.md b/versioned_docs/version-v0.17.1/int/quickstart/group/quickstart-group-operator.md index bf0a135df0..f0903d9589 100644 --- a/versioned_docs/version-v0.17.1/int/quickstart/group/quickstart-group-operator.md +++ b/versioned_docs/version-v0.17.1/int/quickstart/group/quickstart-group-operator.md @@ -25,7 +25,7 @@ Before starting the cluster creation, make sure you have shared an Ethereum addr ## Step 2. Create and back up a private key for charon -In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. +In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -43,7 +43,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** @@ -75,7 +75,7 @@ After receiving the invite link created by the **Leader** or **Creator**, you wi ## Step 4. Run the DKG :::info -For the [DKG](docs/charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. +For the [DKG](../../../charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. ::: ### Overview diff --git a/versioned_docs/version-v0.18.0/charon/cluster-configuration.md b/versioned_docs/version-v0.18.0/charon/cluster-configuration.md index aab4104033..bfde92cf6c 100644 --- a/versioned_docs/version-v0.18.0/charon/cluster-configuration.md +++ b/versioned_docs/version-v0.18.0/charon/cluster-configuration.md @@ -67,7 +67,7 @@ The schema of the `cluster-definition.json` is defined as: ### Using the DV Launchpad -- A [`leader/creator`](docs/int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" +- A [`leader/creator`](../int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" - The `leader/creator` uses the user interface to configure all of the important details about the cluster including: - The `Withdrawal Address` for the created validators - The `Fee Recipient Address` for block proposals if it differs from the withdrawal address diff --git a/versioned_docs/version-v0.18.0/charon/dkg.md b/versioned_docs/version-v0.18.0/charon/dkg.md index 86b0e28d2d..2aa24f04d0 100644 --- a/versioned_docs/version-v0.18.0/charon/dkg.md +++ b/versioned_docs/version-v0.18.0/charon/dkg.md @@ -7,9 +7,9 @@ sidebar_position: 2 ## Overview -A [**distributed validator key**](docs/int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. +A [**distributed validator key**](../int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. -To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](docs/int/key-concepts.md#distributed-validator-key-generation-ceremony). +To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](../int/key-concepts.md#distributed-validator-key-generation-ceremony). The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster definition](../charon/cluster-configuration). diff --git a/versioned_docs/version-v0.18.0/charon/intro.md b/versioned_docs/version-v0.18.0/charon/intro.md index 767a6a3ded..03e6cfb6f7 100644 --- a/versioned_docs/version-v0.18.0/charon/intro.md +++ b/versioned_docs/version-v0.18.0/charon/intro.md @@ -5,7 +5,7 @@ sidebar_position: 1 # Introduction -This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](/docs/int/key-concepts) section as background and context. +This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](../int/key-concepts) section as background and context. ## What is Charon? @@ -79,4 +79,4 @@ The following is an outline of the services that can be exposed by charon. ## Getting started -For more information on running charon, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). +For more information on running charon, take a look at our [Quickstart Guides](../int/quickstart/index.md). diff --git a/versioned_docs/version-v0.18.0/dvl/intro.md b/versioned_docs/version-v0.18.0/dvl/intro.md index f227f32130..a0ea53c8c0 100644 --- a/versioned_docs/version-v0.18.0/dvl/intro.md +++ b/versioned_docs/version-v0.18.0/dvl/intro.md @@ -15,4 +15,4 @@ To facilitate the generation of distributed validator keys amongst remote users ## Getting started -For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). \ No newline at end of file +For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](../int/quickstart/index.md). \ No newline at end of file diff --git a/versioned_docs/version-v0.18.0/int/faq/risks.md b/versioned_docs/version-v0.18.0/int/faq/risks.md index 6931cd253f..df05298311 100644 --- a/versioned_docs/version-v0.18.0/int/faq/risks.md +++ b/versioned_docs/version-v0.18.0/int/faq/risks.md @@ -8,7 +8,7 @@ description: Centralization Risks and mitigation ## Risk: Obol hosting the relay infrastructure **Mitigation**: Self-host a relay -One of the risks associated with Obol hosting the [LibP2P relays](docs/charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. Ensure that all nodes in the cluster use the same relays, or they will not be able to find each other if they are connected to different relays. +One of the risks associated with Obol hosting the [LibP2P relays](../../charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. Ensure that all nodes in the cluster use the same relays, or they will not be able to find each other if they are connected to different relays. The following non-Obol entities run relays that you can consider adding to your cluster (you can have more than one per cluster, see the `--p2p-relays` flag of [`charon run`](../../charon/charon-cli-reference.md#the-run-subcommand)): @@ -25,9 +25,9 @@ The following non-Obol entities run relays that you can consider adding to your Another risk associated with Obol is having the ability to update the [Charon code](https://github.com/ObolNetwork/charon) running on the network which could introduce vulnerabilities or malicious code. To mitigate this risk, operators can consider pinning specific versions of the code that have been thoroughly tested and accepted by the network. This would ensure that any updates are carefully vetted and reviewed by the community. ## Risk: Obol hosting the DV Launchpad -**Mitigation**: Use [`create cluster`](docs/charon/charon-cli-reference.md) or [`create dkg`](docs/charon/charon-cli-reference.md) locally and distribute the files manually +**Mitigation**: Use [`create cluster`](../../charon/charon-cli-reference.md) or [`create dkg`](../../charon/charon-cli-reference.md) locally and distribute the files manually -Hosting the first Charon frontend, the [DV Launchpad](docs/dvl/intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally. +Hosting the first Charon frontend, the [DV Launchpad](../../dvl/intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally. To mitigate the risk of launchpad failure, consider using the `create cluster` or `create dkg` commands locally and distributing the key shares files manually. diff --git a/versioned_docs/version-v0.18.0/int/quickstart/group/quickstart-group-leader-creator.md b/versioned_docs/version-v0.18.0/int/quickstart/group/quickstart-group-leader-creator.md index 0909b44f75..8614488df0 100644 --- a/versioned_docs/version-v0.18.0/int/quickstart/group/quickstart-group-leader-creator.md +++ b/versioned_docs/version-v0.18.0/int/quickstart/group/quickstart-group-leader-creator.md @@ -42,7 +42,7 @@ Before starting the cluster creation, you will need to collect one Ethereum addr - In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. + In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -60,7 +60,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** diff --git a/versioned_docs/version-v0.18.0/int/quickstart/group/quickstart-group-operator.md b/versioned_docs/version-v0.18.0/int/quickstart/group/quickstart-group-operator.md index 771dbdb035..1a6f7f3b5e 100644 --- a/versioned_docs/version-v0.18.0/int/quickstart/group/quickstart-group-operator.md +++ b/versioned_docs/version-v0.18.0/int/quickstart/group/quickstart-group-operator.md @@ -25,7 +25,7 @@ Before starting the cluster creation, make sure you have shared an Ethereum addr ## Step 2. Create and back up a private key for charon -In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. +In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -43,7 +43,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** @@ -75,7 +75,7 @@ After receiving the invite link created by the **Leader** or **Creator**, you wi ## Step 4. Run the DKG :::info -For the [DKG](docs/charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. +For the [DKG](../../../charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. ::: ### Overview diff --git a/versioned_docs/version-v0.19.0/charon/cluster-configuration.md b/versioned_docs/version-v0.19.0/charon/cluster-configuration.md index aab4104033..bfde92cf6c 100644 --- a/versioned_docs/version-v0.19.0/charon/cluster-configuration.md +++ b/versioned_docs/version-v0.19.0/charon/cluster-configuration.md @@ -67,7 +67,7 @@ The schema of the `cluster-definition.json` is defined as: ### Using the DV Launchpad -- A [`leader/creator`](docs/int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" +- A [`leader/creator`](../int/quickstart/group/index.md), that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launchpad and selects "Create new Cluster" - The `leader/creator` uses the user interface to configure all of the important details about the cluster including: - The `Withdrawal Address` for the created validators - The `Fee Recipient Address` for block proposals if it differs from the withdrawal address diff --git a/versioned_docs/version-v0.19.0/charon/dkg.md b/versioned_docs/version-v0.19.0/charon/dkg.md index 86b0e28d2d..2aa24f04d0 100644 --- a/versioned_docs/version-v0.19.0/charon/dkg.md +++ b/versioned_docs/version-v0.19.0/charon/dkg.md @@ -7,9 +7,9 @@ sidebar_position: 2 ## Overview -A [**distributed validator key**](docs/int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. +A [**distributed validator key**](../int/key-concepts.md#distributed-validator-key) is a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. -To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](docs/int/key-concepts.md#distributed-validator-key-generation-ceremony). +To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve). To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a [**distributed key generation ceremony**](../int/key-concepts.md#distributed-validator-key-generation-ceremony). The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster definition](../charon/cluster-configuration). diff --git a/versioned_docs/version-v0.19.0/charon/intro.md b/versioned_docs/version-v0.19.0/charon/intro.md index 767a6a3ded..03e6cfb6f7 100644 --- a/versioned_docs/version-v0.19.0/charon/intro.md +++ b/versioned_docs/version-v0.19.0/charon/intro.md @@ -5,7 +5,7 @@ sidebar_position: 1 # Introduction -This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](/docs/int/key-concepts) section as background and context. +This section introduces and outlines the Charon *[kharon]* middleware, Obol's implementation of DVT. Please see the [key concepts](../int/key-concepts) section as background and context. ## What is Charon? @@ -79,4 +79,4 @@ The following is an outline of the services that can be exposed by charon. ## Getting started -For more information on running charon, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). +For more information on running charon, take a look at our [Quickstart Guides](../int/quickstart/index.md). diff --git a/versioned_docs/version-v0.19.0/dvl/intro.md b/versioned_docs/version-v0.19.0/dvl/intro.md index 728489e476..ae8c8ef84e 100644 --- a/versioned_docs/version-v0.19.0/dvl/intro.md +++ b/versioned_docs/version-v0.19.0/dvl/intro.md @@ -15,7 +15,7 @@ To facilitate the generation of distributed validator keys amongst remote users ## Getting started -For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](docs/int/quickstart/index.md). +For more information on running charon in a UI friendly way through the DV Launchpad, take a look at our [Quickstart Guides](../int/quickstart/index.md). ## DV Launchpad Links diff --git a/versioned_docs/version-v0.19.0/int/faq/risks.md b/versioned_docs/version-v0.19.0/int/faq/risks.md index 6931cd253f..df05298311 100644 --- a/versioned_docs/version-v0.19.0/int/faq/risks.md +++ b/versioned_docs/version-v0.19.0/int/faq/risks.md @@ -8,7 +8,7 @@ description: Centralization Risks and mitigation ## Risk: Obol hosting the relay infrastructure **Mitigation**: Self-host a relay -One of the risks associated with Obol hosting the [LibP2P relays](docs/charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. Ensure that all nodes in the cluster use the same relays, or they will not be able to find each other if they are connected to different relays. +One of the risks associated with Obol hosting the [LibP2P relays](../../charon/networking.md) infrastructure allowing peer discovery is that if Obol-hosted relays go down, peers won't be able to discover each other and perform the DKG. To mitigate this risk, external organizations and node operators can consider self-hosting a relay. This way, if Obol's relays go down, the clusters can still operate through other relays in the network. Ensure that all nodes in the cluster use the same relays, or they will not be able to find each other if they are connected to different relays. The following non-Obol entities run relays that you can consider adding to your cluster (you can have more than one per cluster, see the `--p2p-relays` flag of [`charon run`](../../charon/charon-cli-reference.md#the-run-subcommand)): @@ -25,9 +25,9 @@ The following non-Obol entities run relays that you can consider adding to your Another risk associated with Obol is having the ability to update the [Charon code](https://github.com/ObolNetwork/charon) running on the network which could introduce vulnerabilities or malicious code. To mitigate this risk, operators can consider pinning specific versions of the code that have been thoroughly tested and accepted by the network. This would ensure that any updates are carefully vetted and reviewed by the community. ## Risk: Obol hosting the DV Launchpad -**Mitigation**: Use [`create cluster`](docs/charon/charon-cli-reference.md) or [`create dkg`](docs/charon/charon-cli-reference.md) locally and distribute the files manually +**Mitigation**: Use [`create cluster`](../../charon/charon-cli-reference.md) or [`create dkg`](../../charon/charon-cli-reference.md) locally and distribute the files manually -Hosting the first Charon frontend, the [DV Launchpad](docs/dvl/intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally. +Hosting the first Charon frontend, the [DV Launchpad](../../dvl/intro.md), on a centralized server could create a single point of failure, as users would have to rely on Obol's server to access the protocol. This could limit the decentralization of the protocol and could make it vulnerable to attacks or downtime. Obol hosting the launchpad on a decentralized network, such as IPFS is a first step but not enough. This is why the Charon code is open-source and contains a CLI interface to interact with the protocol locally. To mitigate the risk of launchpad failure, consider using the `create cluster` or `create dkg` commands locally and distributing the key shares files manually. diff --git a/versioned_docs/version-v0.19.0/int/quickstart/group/quickstart-group-leader-creator.md b/versioned_docs/version-v0.19.0/int/quickstart/group/quickstart-group-leader-creator.md index 8fc8c4fdbb..e55d10020d 100644 --- a/versioned_docs/version-v0.19.0/int/quickstart/group/quickstart-group-leader-creator.md +++ b/versioned_docs/version-v0.19.0/int/quickstart/group/quickstart-group-leader-creator.md @@ -42,7 +42,7 @@ Before starting the cluster creation, you will need to collect one Ethereum addr - In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. + In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. Operators in your cluster will also need to do this step, as per their [quickstart](./quickstart-group-operator#step-2-create-and-back-up-a-private-key-for-charon). This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -60,7 +60,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Ensure you create a backup of the private key stored in the '.charon' folder, specifically at '.charon/charon-enr-private-key'. This is the file used to generate your private key. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** diff --git a/versioned_docs/version-v0.19.0/int/quickstart/group/quickstart-group-operator.md b/versioned_docs/version-v0.19.0/int/quickstart/group/quickstart-group-operator.md index 80bd856c84..5a1841ff0b 100644 --- a/versioned_docs/version-v0.19.0/int/quickstart/group/quickstart-group-operator.md +++ b/versioned_docs/version-v0.19.0/int/quickstart/group/quickstart-group-operator.md @@ -25,7 +25,7 @@ Before starting the cluster creation, make sure you have shared an Ethereum addr ## Step 2. Create and back up a private key for charon -In order to prepare for a distributed key generation ceremony, you need to create an [ENR](docs/int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. +In order to prepare for a distributed key generation ceremony, you need to create an [ENR](../../../int/faq/errors.mdx#enrs-keys) for your charon client. This ENR is a public/private key pair, and allows the other charon clients in the DKG to identify and connect to your node. ```sh # Clone this repo @@ -43,7 +43,7 @@ You should expect to see a console output like Created ENR private key: .charon/charon-enr-private-key enr:-JG4QGQpV4qYe32QFUAbY1UyGNtNcrVMip83cvJRhw1brMslPeyELIz3q6dsZ7GblVaCjL_8FKQhF6Syg-O_kIWztimGAYHY5EvPgmlkgnY0gmlwhH8AAAGJc2VjcDI1NmsxoQKzMe_GFPpSqtnYl-mJr8uZAUtmkqccsAx7ojGmFy-FY4N0Y3CCDhqDdWRwgg4u -If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](/docs/int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. +If instead of being shown your `enr` you see an error saying `permission denied` then you may need to [update docker permissions](../../../int/faq/errors#docker-permission-denied-error) to allow the command to run successfully. :::caution Please make sure to create a backup of the private key at `.charon/charon-enr-private-key`. Be careful not to commit it to git! **If you lose this file you won't be able to take part in the DKG ceremony and start the DV cluster successfully.** @@ -75,7 +75,7 @@ After receiving the invite link created by the **Leader** or **Creator**, you wi ## Step 4. Run the DKG :::info -For the [DKG](docs/charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. +For the [DKG](../../../charon/dkg.md) to complete, all operators need to be running the command simultaneously. It helps to coordinate an agreed upon time amongst operators at which to run the command. ::: ### Overview