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 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: 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. ::: 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. 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: 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: 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: 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: 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 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: 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 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: 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 | | 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 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: 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 | | 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 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: 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. ::: 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 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: