Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

WIP: Add third party relays #277

Merged
merged 2 commits into from
Nov 11, 2023
Merged

WIP: Add third party relays #277

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f5f7407
Add third party relays here for the time being
OisinKyne Oct 26, 2023
625d106
Update risks.md
LukeHackett12 Oct 26, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 11 additions & 2 deletions docs/int/faq/risks.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,16 @@ 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](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.

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 |
|-----------|---------------------------------------|
| [DSRV](https://www.dsrvlabs.com/) | https://charon-relay.dsrvlabs.dev |
| [Infstones](https://infstones.com/) | https://obol-relay.infstones.com:3640/ |
| [Hashquark](https://www.hashquark.io/) | https://relay-2.prod-relay.721.land/ |
| [Figment](https://figment.io/) | https://relay-1.obol.figment.io/ |

## Risk: Obol being able to update Charon code
**Mitigation**: Pin specific docker versions or compile from source on a trusted commit
Expand All @@ -28,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](../quickstart/advanced/quickstart-combine.md).
Loading