From a8c7122a82b83f489b480bc54be9a36527fe0423 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:34:59 +0200 Subject: [PATCH 01/21] typos bug-bounty.md --- docs/adv/security/bug-bounty.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/adv/security/bug-bounty.md b/docs/adv/security/bug-bounty.md index accdc2d72e..8a6f467faa 100644 --- a/docs/adv/security/bug-bounty.md +++ b/docs/adv/security/bug-bounty.md @@ -108,7 +108,7 @@ For vulnerabilities with a moderate impact, affecting system availability or int Impacts: - Attacker that is a member of a cluster can exfiltrate K1 key material from another member. -- Attacker that is a member of the cluster can denial of service attack enough peers in the cluster to prevent operation of the validator(s) +- Attacker that is a member of the cluster can denial-of-service attack enough peers in the cluster to prevent operation of the validator(s) - Attacker that is a member of the cluster can bias the protocol in a manner to control the majority of block proposal opportunities. - Attacker can get a DV Launchpad user to inadvertently interact with a smart contract that is not a part of normal operation of the launchpad. - Increasing network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours @@ -152,7 +152,7 @@ Rewards may be issued as cash, merchandise, or other forms of recognition, at Ob - Any testing with pricing oracles or third-party smart contracts - Attempting phishing or other social engineering attacks against our employees and/or customers - Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks) -- Any denial of service attacks that are executed against project assets +- Any denial-of-service attacks that are executed against project assets - Automated testing of services that generate significant amounts of traffic - Public disclosure of an unpatched vulnerability in an embargoed bounty From 26a2b475f791ae454a4b542667859613f4cb5186 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:36:03 +0200 Subject: [PATCH 02/21] typos bug-bounty.md --- versioned_docs/version-v1.0.0/sec/bug-bounty.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v1.0.0/sec/bug-bounty.md b/versioned_docs/version-v1.0.0/sec/bug-bounty.md index e7207db803..03d0512471 100644 --- a/versioned_docs/version-v1.0.0/sec/bug-bounty.md +++ b/versioned_docs/version-v1.0.0/sec/bug-bounty.md @@ -108,7 +108,7 @@ For vulnerabilities with a moderate impact, affecting system availability or int Impacts: - Attacker that is a member of a cluster can exfiltrate K1 key material from another member. -- Attacker that is a member of the cluster can denial of service attack enough peers in the cluster to prevent operation of the validator(s) +- Attacker that is a member of the cluster can denial-of-service attack enough peers in the cluster to prevent operation of the validator(s) - Attacker that is a member of the cluster can bias the protocol in a manner to control the majority of block proposal opportunities. - Attacker can get a DV Launchpad user to inadvertently interact with a smart contract that is not a part of normal operation of the launchpad. - Increasing network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours @@ -152,7 +152,7 @@ Rewards may be issued as cash, merchandise, or other forms of recognition, at Ob - Any testing with pricing oracles or third-party smart contracts - Attempting phishing or other social engineering attacks against our employees and/or customers - Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks) -- Any denial of service attacks that are executed against project assets +- Any denial-of-service attacks that are executed against project assets - Automated testing of services that generates significant amounts of traffic - Public disclosure of an unpatched vulnerability in an embargoed bounty From 3bb2d4baa1be01a76a75b3a22907bf84faa80c79 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:36:43 +0200 Subject: [PATCH 03/21] typos bug-bounty.md --- versioned_docs/version-v1.1.0/sec/bug-bounty.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v1.1.0/sec/bug-bounty.md b/versioned_docs/version-v1.1.0/sec/bug-bounty.md index eff2d0c29d..56a8c54b9b 100644 --- a/versioned_docs/version-v1.1.0/sec/bug-bounty.md +++ b/versioned_docs/version-v1.1.0/sec/bug-bounty.md @@ -108,7 +108,7 @@ For vulnerabilities with a moderate impact, affecting system availability or int Impacts: - Attacker that is a member of a cluster can exfiltrate K1 key material from another member. -- Attacker that is a member of the cluster can denial of service attack enough peers in the cluster to prevent operation of the validator(s) +- Attacker that is a member of the cluster can denial-of-service attack enough peers in the cluster to prevent operation of the validator(s) - Attacker that is a member of the cluster can bias the protocol in a manner to control the majority of block proposal opportunities. - Attacker can get a DV Launchpad user to inadvertently interact with a smart contract that is not a part of normal operation of the launchpad. - Increasing network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours @@ -152,7 +152,7 @@ Rewards may be issued as cash, merchandise, or other forms of recognition, at Ob - Any testing with pricing oracles or third-party smart contracts - Attempting phishing or other social engineering attacks against our employees and/or customers - Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks) -- Any denial of service attacks that are executed against project assets +- Any denial-of-service attacks that are executed against project assets - Automated testing of services that generate significant amounts of traffic - Public disclosure of an unpatched vulnerability in an embargoed bounty From 7a1fd87f7f9e3939c9df9c553479ec32eae1ca21 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:37:08 +0200 Subject: [PATCH 04/21] typos bug-bounty.md --- versioned_docs/version-v1.1.1/sec/bug-bounty.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v1.1.1/sec/bug-bounty.md b/versioned_docs/version-v1.1.1/sec/bug-bounty.md index eff2d0c29d..56a8c54b9b 100644 --- a/versioned_docs/version-v1.1.1/sec/bug-bounty.md +++ b/versioned_docs/version-v1.1.1/sec/bug-bounty.md @@ -108,7 +108,7 @@ For vulnerabilities with a moderate impact, affecting system availability or int Impacts: - Attacker that is a member of a cluster can exfiltrate K1 key material from another member. -- Attacker that is a member of the cluster can denial of service attack enough peers in the cluster to prevent operation of the validator(s) +- Attacker that is a member of the cluster can denial-of-service attack enough peers in the cluster to prevent operation of the validator(s) - Attacker that is a member of the cluster can bias the protocol in a manner to control the majority of block proposal opportunities. - Attacker can get a DV Launchpad user to inadvertently interact with a smart contract that is not a part of normal operation of the launchpad. - Increasing network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours @@ -152,7 +152,7 @@ Rewards may be issued as cash, merchandise, or other forms of recognition, at Ob - Any testing with pricing oracles or third-party smart contracts - Attempting phishing or other social engineering attacks against our employees and/or customers - Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks) -- Any denial of service attacks that are executed against project assets +- Any denial-of-service attacks that are executed against project assets - Automated testing of services that generate significant amounts of traffic - Public disclosure of an unpatched vulnerability in an embargoed bounty From 03df4c0a18b58b0df45af12b79d99782652d3f6e Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:37:33 +0200 Subject: [PATCH 05/21] typos bug-bounty.md --- versioned_docs/version-v1.1.2/sec/bug-bounty.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v1.1.2/sec/bug-bounty.md b/versioned_docs/version-v1.1.2/sec/bug-bounty.md index eff2d0c29d..56a8c54b9b 100644 --- a/versioned_docs/version-v1.1.2/sec/bug-bounty.md +++ b/versioned_docs/version-v1.1.2/sec/bug-bounty.md @@ -108,7 +108,7 @@ For vulnerabilities with a moderate impact, affecting system availability or int Impacts: - Attacker that is a member of a cluster can exfiltrate K1 key material from another member. -- Attacker that is a member of the cluster can denial of service attack enough peers in the cluster to prevent operation of the validator(s) +- Attacker that is a member of the cluster can denial-of-service attack enough peers in the cluster to prevent operation of the validator(s) - Attacker that is a member of the cluster can bias the protocol in a manner to control the majority of block proposal opportunities. - Attacker can get a DV Launchpad user to inadvertently interact with a smart contract that is not a part of normal operation of the launchpad. - Increasing network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours @@ -152,7 +152,7 @@ Rewards may be issued as cash, merchandise, or other forms of recognition, at Ob - Any testing with pricing oracles or third-party smart contracts - Attempting phishing or other social engineering attacks against our employees and/or customers - Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks) -- Any denial of service attacks that are executed against project assets +- Any denial-of-service attacks that are executed against project assets - Automated testing of services that generate significant amounts of traffic - Public disclosure of an unpatched vulnerability in an embargoed bounty From ee91ae2c042de4f70bf62aea06a05d43becab68e Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:38:12 +0200 Subject: [PATCH 06/21] typos bug-bounty.md --- versioned_docs/version-v0.19.2/sec/bug-bounty.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v0.19.2/sec/bug-bounty.md b/versioned_docs/version-v0.19.2/sec/bug-bounty.md index cd7ec0c909..f2dbe80557 100644 --- a/versioned_docs/version-v0.19.2/sec/bug-bounty.md +++ b/versioned_docs/version-v0.19.2/sec/bug-bounty.md @@ -108,7 +108,7 @@ For vulnerabilities with a moderate impact, affecting system availability or int Impacts: - Attacker that is a member of a cluster can exfiltrate K1 key material from another member. -- Attacker that is a member of the cluster can denial of service attack enough peers in the cluster to prevent operation of the validator(s) +- Attacker that is a member of the cluster can denial-of-service attack enough peers in the cluster to prevent operation of the validator(s) - Attacker that is a member of the cluster can bias the protocol in a manner to control the majority of block proposal opportunities. - Attacker can get a DV Launchpad user to inadvertently interact with a smart contract that is not a part of normal operation of the launchpad. - Increasing network processing node resource consumption by at least 30% without brute force actions, compared to the preceding 24 hours @@ -152,7 +152,7 @@ Rewards may be issued as cash, merchandise, or other forms of recognition, at Ob - Any testing with pricing oracles or third-party smart contracts - Attempting phishing or other social engineering attacks against our employees and/or customers - Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks) -- Any denial of service attacks that are executed against project assets +- Any denial-of-service attacks that are executed against project assets - Automated testing of services that generates significant amounts of traffic - Public disclosure of an unpatched vulnerability in an embargoed bounty From dc01463b2fd769603e57fe47c5cb7b80f7014a16 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:39:57 +0200 Subject: [PATCH 07/21] typos ev-assessment.md --- docs/adv/security/ev-assessment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/adv/security/ev-assessment.md b/docs/adv/security/ev-assessment.md index dee3538934..3c41561a72 100644 --- a/docs/adv/security/ev-assessment.md +++ b/docs/adv/security/ev-assessment.md @@ -102,7 +102,7 @@ These final steps are potentially the most difficult, and may require significan From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad. -What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. +What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are: @@ -199,7 +199,7 @@ This is not likely to be particularly motivating to potential attackers - and pa During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed). -Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: +Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts. - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example: From fe49f300fa6510dd0baaa1012fd286eca0780033 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:40:18 +0200 Subject: [PATCH 08/21] typos ev-assessment.md --- versioned_docs/version-v1.0.0/sec/ev-assessment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v1.0.0/sec/ev-assessment.md b/versioned_docs/version-v1.0.0/sec/ev-assessment.md index 3014e030c9..acabb8072a 100644 --- a/versioned_docs/version-v1.0.0/sec/ev-assessment.md +++ b/versioned_docs/version-v1.0.0/sec/ev-assessment.md @@ -102,7 +102,7 @@ These final steps are potentially the most difficult, and may require significan From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad. -What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. +What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are: @@ -199,7 +199,7 @@ This is not likely to be particularly motivating to potential attackers - and pa During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed). -Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: +Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts. - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example: From 2a3f063e8e4eab2423dbf1005018f28e1b36d0ed Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:40:39 +0200 Subject: [PATCH 09/21] typos ev-assessment.md --- versioned_docs/version-v1.1.0/sec/ev-assessment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v1.1.0/sec/ev-assessment.md b/versioned_docs/version-v1.1.0/sec/ev-assessment.md index 37a25600bd..afb016ebac 100644 --- a/versioned_docs/version-v1.1.0/sec/ev-assessment.md +++ b/versioned_docs/version-v1.1.0/sec/ev-assessment.md @@ -102,7 +102,7 @@ These final steps are potentially the most difficult, and may require significan From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad. -What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. +What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are: @@ -199,7 +199,7 @@ This is not likely to be particularly motivating to potential attackers - and pa During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed). -Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: +Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts. - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example: From 8f1b574795a0c874c2b41ec33c1d29a0e65c5b3a Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:41:00 +0200 Subject: [PATCH 10/21] typos ev-assessment.md --- versioned_docs/version-v1.1.1/sec/ev-assessment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v1.1.1/sec/ev-assessment.md b/versioned_docs/version-v1.1.1/sec/ev-assessment.md index 37a25600bd..afb016ebac 100644 --- a/versioned_docs/version-v1.1.1/sec/ev-assessment.md +++ b/versioned_docs/version-v1.1.1/sec/ev-assessment.md @@ -102,7 +102,7 @@ These final steps are potentially the most difficult, and may require significan From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad. -What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. +What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are: @@ -199,7 +199,7 @@ This is not likely to be particularly motivating to potential attackers - and pa During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed). -Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: +Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts. - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example: From 4d6198bc4ad0fef6f658d3f15440d0d51f048137 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:41:27 +0200 Subject: [PATCH 11/21] typos ev-assessment.md --- versioned_docs/version-v1.1.2/sec/ev-assessment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v1.1.2/sec/ev-assessment.md b/versioned_docs/version-v1.1.2/sec/ev-assessment.md index 37a25600bd..afb016ebac 100644 --- a/versioned_docs/version-v1.1.2/sec/ev-assessment.md +++ b/versioned_docs/version-v1.1.2/sec/ev-assessment.md @@ -102,7 +102,7 @@ These final steps are potentially the most difficult, and may require significan From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad. -What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. +What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are: @@ -199,7 +199,7 @@ This is not likely to be particularly motivating to potential attackers - and pa During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed). -Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: +Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts. - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example: From 9758421509d845860d64bdf24948c98ed6aa1666 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:41:50 +0200 Subject: [PATCH 12/21] typos ev-assessment.md --- versioned_docs/version-v0.17.1/sec/ev-assessment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v0.17.1/sec/ev-assessment.md b/versioned_docs/version-v0.17.1/sec/ev-assessment.md index 1c63b2bc48..7d2a3aa32d 100644 --- a/versioned_docs/version-v0.17.1/sec/ev-assessment.md +++ b/versioned_docs/version-v0.17.1/sec/ev-assessment.md @@ -101,7 +101,7 @@ These final steps are potentially the most difficult, and may require significan From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad. -What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. +What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are: @@ -198,7 +198,7 @@ This is not likely to be particularly motivating to potential attackers - and pa During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed). -Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: +Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts. - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example: From 5ee80fffe9ebf32d3d09b446ce6947c364bcbab3 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:42:11 +0200 Subject: [PATCH 13/21] typos ev-assessment.md --- versioned_docs/version-v0.18.0/sec/ev-assessment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v0.18.0/sec/ev-assessment.md b/versioned_docs/version-v0.18.0/sec/ev-assessment.md index 429c3f1ffa..f0cf5d6f48 100644 --- a/versioned_docs/version-v0.18.0/sec/ev-assessment.md +++ b/versioned_docs/version-v0.18.0/sec/ev-assessment.md @@ -101,7 +101,7 @@ These final steps are potentially the most difficult, and may require significan From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad. -What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. +What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are: @@ -198,7 +198,7 @@ This is not likely to be particularly motivating to potential attackers - and pa During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed). -Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: +Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts. - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example: From 608668d93e769b004e0d52c7b98270b7432cb568 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:42:33 +0200 Subject: [PATCH 14/21] typos ev-assessment.md --- versioned_docs/version-v0.19.0/sec/ev-assessment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v0.19.0/sec/ev-assessment.md b/versioned_docs/version-v0.19.0/sec/ev-assessment.md index 429c3f1ffa..f0cf5d6f48 100644 --- a/versioned_docs/version-v0.19.0/sec/ev-assessment.md +++ b/versioned_docs/version-v0.19.0/sec/ev-assessment.md @@ -101,7 +101,7 @@ These final steps are potentially the most difficult, and may require significan From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad. -What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. +What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are: @@ -198,7 +198,7 @@ This is not likely to be particularly motivating to potential attackers - and pa During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed). -Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: +Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts. - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example: From d4062262563bb05f45eccea8a3641c4c56dc5546 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:42:57 +0200 Subject: [PATCH 15/21] typos ev-assessment.md --- versioned_docs/version-v0.19.1/sec/ev-assessment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v0.19.1/sec/ev-assessment.md b/versioned_docs/version-v0.19.1/sec/ev-assessment.md index 429c3f1ffa..f0cf5d6f48 100644 --- a/versioned_docs/version-v0.19.1/sec/ev-assessment.md +++ b/versioned_docs/version-v0.19.1/sec/ev-assessment.md @@ -101,7 +101,7 @@ These final steps are potentially the most difficult, and may require significan From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad. -What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. +What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are: @@ -198,7 +198,7 @@ This is not likely to be particularly motivating to potential attackers - and pa During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed). -Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: +Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts. - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example: From 5edbf2871b60154430f7eabe0b79100b7a6b0853 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:43:16 +0200 Subject: [PATCH 16/21] typos ev-assessment.md --- versioned_docs/version-v0.19.2/sec/ev-assessment.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v0.19.2/sec/ev-assessment.md b/versioned_docs/version-v0.19.2/sec/ev-assessment.md index 429c3f1ffa..f0cf5d6f48 100644 --- a/versioned_docs/version-v0.19.2/sec/ev-assessment.md +++ b/versioned_docs/version-v0.19.2/sec/ev-assessment.md @@ -101,7 +101,7 @@ These final steps are potentially the most difficult, and may require significan From my interviews, it seems that the user deploys both the withdrawal and fee recipient contracts through the Launchpad. -What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses an npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. +What I’m picturing is that during the first parts of the cluster setup process, the user is prompted to sign one or more transactions deploying the withdrawal and fee recipient contracts to mainnet. The Launchpad apparently uses a npm package to deploy these contracts: `0xsplits/splits-sdk`, which I assume provides either JSON artifacts or a factory address on chain. The Launchpad then places the deployed contracts into the cluster config file, and the process moves on. If an attacker has published a malicious update to the Launchpad (or compromised an underlying dependency), the contracts deployed by the Launchpad may be malicious. The questions I’d like to pose are: @@ -198,7 +198,7 @@ This is not likely to be particularly motivating to potential attackers - and pa During setup, users should only sign one transaction via the Launchpad - to a contract located at an Obol-held ENS (e.g. `launchpad.obol.eth`). This contract should deploy everything needed for the cluster to operate, like the withdrawal and fee recipient contracts. It should also initialize them with the provided reward split configuration (and any other config needed). -Rather than using an NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: +Rather than using a NPM library to supply a factory address or JSON artifacts, this has the benefit of being both: - **Harder to compromise:** as long as the user knows launchpad.obol.eth, it’s pretty difficult to trick them into deploying the wrong contracts. - **Easier to validate** for non-technical users: the Obol contract can be queried for deployment information via etherscan. For example: From a2cb92193002891239596c97d1c25b32f0cb5410 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:44:58 +0200 Subject: [PATCH 17/21] typos obol-splits.mdx --- docs/learn/intro/obol-splits.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/learn/intro/obol-splits.mdx b/docs/learn/intro/obol-splits.mdx index 685931d6aa..718555603f 100644 --- a/docs/learn/intro/obol-splits.mdx +++ b/docs/learn/intro/obol-splits.mdx @@ -51,7 +51,7 @@ This contract **assumes that any ether that has appeared in its address since it Worst-case mass slashings can theoretically exceed 16 ether, if this were to occur, the returned principal would be misclassified as a reward, and distributed to the wrong address. This risk is the drawback that makes this contract variant 'optimistic'. If you intend to use this contract type, **it is important you fully understand and accept this risk**. -The alternative is to use an splits.org [waterfall contract](https://docs.splits.org/core/waterfall), which won't allow the claiming of rewards until all principal ether has been returned, meaning validators need to be exited for operators to claim their CL rewards. +The alternative is to use a splits.org [waterfall contract](https://docs.splits.org/core/waterfall), which won't allow the claiming of rewards until all principal ether has been returned, meaning validators need to be exited for operators to claim their CL rewards. ::: From 565e36553223cffdaf637e80d65e1034f8fe753e Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:45:14 +0200 Subject: [PATCH 18/21] typos introducing-obol-splits.mdx --- versioned_docs/version-v1.1.0/sc/introducing-obol-splits.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v1.1.0/sc/introducing-obol-splits.mdx b/versioned_docs/version-v1.1.0/sc/introducing-obol-splits.mdx index 3708abee23..53615176ab 100644 --- a/versioned_docs/version-v1.1.0/sc/introducing-obol-splits.mdx +++ b/versioned_docs/version-v1.1.0/sc/introducing-obol-splits.mdx @@ -51,7 +51,7 @@ This contract **assumes that any ether that has appeared in it's address since i Worst-case mass slashings can theoretically exceed 16 ether, if this were to occur, the returned principal would be misclassified as a reward, and distributed to the wrong address. This risk is the drawback that makes this contract variant 'optimistic'. If you intend to use this contract type, **it is important you understand and accept this risk**, however minute. -The alternative is to use an splits.org [waterfall contract](https://docs.splits.org/core/waterfall), which won't allow the claiming of rewards until all principal ether has been returned, meaning validators need to be exited for operators to claim their CL rewards. +The alternative is to use a splits.org [waterfall contract](https://docs.splits.org/core/waterfall), which won't allow the claiming of rewards until all principal ether has been returned, meaning validators need to be exited for operators to claim their CL rewards. ::: @@ -97,4 +97,4 @@ The Immutable Split Controller [factory contract](https://github.com/ObolNetwork | Mainnet | [0x49e7cA187F1E94d9A0d1DFBd6CCCd69Ca17F56a4](https://etherscan.io/address/0x49e7cA187F1E94d9A0d1DFBd6CCCd69Ca17F56a4)| | Goerli | [0x64a2c4A50B1f46c3e2bF753CFe270ceB18b5e18f](https://goerli.etherscan.io/address/0x64a2c4A50B1f46c3e2bF753CFe270ceB18b5e18f) | | Holesky | | -| Sepolia | | \ No newline at end of file +| Sepolia | | From 7efacf3c596915f6a4a409bb528c26f51a7810c7 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:45:29 +0200 Subject: [PATCH 19/21] typos introducing-obol-splits.mdx --- versioned_docs/version-v1.1.1/sc/introducing-obol-splits.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/versioned_docs/version-v1.1.1/sc/introducing-obol-splits.mdx b/versioned_docs/version-v1.1.1/sc/introducing-obol-splits.mdx index 3708abee23..53615176ab 100644 --- a/versioned_docs/version-v1.1.1/sc/introducing-obol-splits.mdx +++ b/versioned_docs/version-v1.1.1/sc/introducing-obol-splits.mdx @@ -51,7 +51,7 @@ This contract **assumes that any ether that has appeared in it's address since i Worst-case mass slashings can theoretically exceed 16 ether, if this were to occur, the returned principal would be misclassified as a reward, and distributed to the wrong address. This risk is the drawback that makes this contract variant 'optimistic'. If you intend to use this contract type, **it is important you understand and accept this risk**, however minute. -The alternative is to use an splits.org [waterfall contract](https://docs.splits.org/core/waterfall), which won't allow the claiming of rewards until all principal ether has been returned, meaning validators need to be exited for operators to claim their CL rewards. +The alternative is to use a splits.org [waterfall contract](https://docs.splits.org/core/waterfall), which won't allow the claiming of rewards until all principal ether has been returned, meaning validators need to be exited for operators to claim their CL rewards. ::: @@ -97,4 +97,4 @@ The Immutable Split Controller [factory contract](https://github.com/ObolNetwork | Mainnet | [0x49e7cA187F1E94d9A0d1DFBd6CCCd69Ca17F56a4](https://etherscan.io/address/0x49e7cA187F1E94d9A0d1DFBd6CCCd69Ca17F56a4)| | Goerli | [0x64a2c4A50B1f46c3e2bF753CFe270ceB18b5e18f](https://goerli.etherscan.io/address/0x64a2c4A50B1f46c3e2bF753CFe270ceB18b5e18f) | | Holesky | | -| Sepolia | | \ No newline at end of file +| Sepolia | | From 379fbbd340e95d3b3eacde081c68af9e56e86ffb Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:45:46 +0200 Subject: [PATCH 20/21] typos introducing-obol-splits.mdx --- versioned_docs/version-v1.1.2/sc/introducing-obol-splits.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/versioned_docs/version-v1.1.2/sc/introducing-obol-splits.mdx b/versioned_docs/version-v1.1.2/sc/introducing-obol-splits.mdx index 901d59c8ea..74741e21a2 100644 --- a/versioned_docs/version-v1.1.2/sc/introducing-obol-splits.mdx +++ b/versioned_docs/version-v1.1.2/sc/introducing-obol-splits.mdx @@ -51,7 +51,7 @@ This contract **assumes that any ether that has appeared in its address since it Worst-case mass slashings can theoretically exceed 16 ether, if this were to occur, the returned principal would be misclassified as a reward, and distributed to the wrong address. This risk is the drawback that makes this contract variant 'optimistic'. If you intend to use this contract type, **it is important you fully understand and accept this risk**. -The alternative is to use an splits.org [waterfall contract](https://docs.splits.org/core/waterfall), which won't allow the claiming of rewards until all principal ether has been returned, meaning validators need to be exited for operators to claim their CL rewards. +The alternative is to use a splits.org [waterfall contract](https://docs.splits.org/core/waterfall), which won't allow the claiming of rewards until all principal ether has been returned, meaning validators need to be exited for operators to claim their CL rewards. ::: From 102ecc11b6da03a34cfac4243bdffb5a870dd078 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Tue, 3 Dec 2024 15:46:39 +0200 Subject: [PATCH 21/21] typos staking-stack.md --- docs/learn/intro/staking-stack.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/learn/intro/staking-stack.md b/docs/learn/intro/staking-stack.md index 78b72472b5..de445b6f91 100644 --- a/docs/learn/intro/staking-stack.md +++ b/docs/learn/intro/staking-stack.md @@ -24,10 +24,10 @@ The road to decentralizing stake is a long one. At Obol we have divided our visi The first version of distributed validators will have dispute resolution out of band. Meaning you need to know and communicate with your other operators if there is an issue with your shared cluster. -A DV without in-band dispute resolution/incentivisation is still extremely valuable. Individuals and staking as a service providers can deploy DVs on their own to make their validators fault tolerant. Groups can run DVs together, but need to bring their own dispute resolution to the table, whether that be a smart contract of their own, a traditional legal service agreement, or simply high trust between the group. +A DV without in-band dispute resolution/incentivisation is still extremely valuable. Individuals and staking as a service providers can deploy DVs on their own to make their validators fault-tolerant. Groups can run DVs together, but need to bring their own dispute resolution to the table, whether that be a smart contract of their own, a traditional legal service agreement, or simply high trust between the group. ### V2 - Trustless Distributed Validators As described in our [roadmap blog article](https://blog.obol.org/roadmap-the-distributed-validator-protocol/) published in February 2024, Version 2 of Charon will layer in a (dis)incentivisation scheme to solve the “lazy operator” problem, whereby an offline operator within a DV cluster does not earn any rewards. Further incentivisation alignment can be achieved with operator bonding requirements that can be slashed for unacceptable performance. -To add an un-gameable incentivisation layer to threshold validation requires complex interactive cryptography schemes, secure off-chain dispute resolution, and EVM support for proofs of the consensus layer state, as a result, this will be a longer and more complex undertaking than V1, hence the delineation between the two. Some of the published R&D material is available in the [further reading](https://docs.obol.org/next/fr/resources#research-and-development) section of the docs. \ No newline at end of file +To add an un-gameable incentivisation layer to threshold validation requires complex interactive cryptography schemes, secure off-chain dispute resolution, and EVM support for proofs of the consensus layer state, as a result, this will be a longer and more complex undertaking than V1, hence the delineation between the two. Some of the published R&D material is available in the [further reading](https://docs.obol.org/next/fr/resources#research-and-development) section of the docs.