From 03f59dc42b28f25dc610cf8332a23e07fe97d63a Mon Sep 17 00:00:00 2001 From: Abhishek Kumar Date: Fri, 12 Jan 2024 17:06:04 +0530 Subject: [PATCH] fix docs from small prs --- core/validatorapi/router.go | 1 + docs/contributing.md | 2 +- docs/dkg.md | 6 +++--- docs/goguidelines.md | 2 +- 4 files changed, 6 insertions(+), 5 deletions(-) diff --git a/core/validatorapi/router.go b/core/validatorapi/router.go index e77903e2b..b300930a4 100644 --- a/core/validatorapi/router.go +++ b/core/validatorapi/router.go @@ -595,6 +595,7 @@ func proposeBlock(p eth2client.ProposalProvider) handlerFunc { RandaoReveal: randao, Graffiti: graff, } + eth2Resp, err := p.Proposal(ctx, opts) if err != nil { return nil, nil, err diff --git a/docs/contributing.md b/docs/contributing.md index f37c7db90..893bf91e3 100644 --- a/docs/contributing.md +++ b/docs/contributing.md @@ -23,7 +23,7 @@ instead of opening a public issue or PR on GitHub. - Open a GitHub issue if everything else checks out 🤓 - Are you thinking of a small change that just makes sense? Feel free to submit a PR. - If you're envisioning a larger feature or are just looking for a discussion, - let's chat in the [Obol Discord](https://discord.gg/n6ebKsX46w/) under `#dev-community`. + let's chat in the [Obol Discord](https://discord.com/invite/n6ebKsX46w)under `#dev-community`. - A quick sync before coding avoids conflicting work and makes large PRs much more likely to be accepted. - 👀 The Discord channel is currently _invite-only_ to prevent spam. Please ping a team member to get access. diff --git a/docs/dkg.md b/docs/dkg.md index aa916b614..72c523951 100644 --- a/docs/dkg.md +++ b/docs/dkg.md @@ -12,7 +12,7 @@ ## Overview -To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together. (4 randomly chosen points on a graph don't all neccessarily sit on the same order three curve.) To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a distributed key generation ceremony. +To make a distributed validator with no fault-tolerance (i.e. all nodes need to be online to sign every message), due to the BLS signature scheme used by Proof of Stake Ethereum, each key share could be chosen by operators independently. However, to create a distributed validator that can stay online despite a subset of its nodes going offline, the key shares need to be generated together. (4 randomly chosen points on a graph don't all necessarily sit on the same order three curve.) To do this in a secure manner with no one party being trusted to distribute the keys requires what is known as a distributed key generation ceremony. The charon client has the responsibility of securely completing a distributed key generation ceremony with its counterparty nodes. The ceremony configuration is outlined in a [cluster configuration](https://docs.obol.tech/docs/dv/distributed-validator-cluster-manifest). @@ -28,8 +28,8 @@ A distributed key generation ceremony involves `Operators` and their `Charon cli This cluster-definition file is created with the help of the [Distributed Validator Launchpad](https://docs.obol.tech/docs/dvk/distributed_validator_launchpad). The creation process involves a number of steps. -- A `leader` Operator, that wishes to co-ordinate the creation of a new Distributed Validator Cluster navigates to the launch pad and selects "Create new Cluster" -- The `leader` uses the user interface to configure all of the important details about the cluster including: +- A `leader` Operator, that wishes to coordinate the creation of a new Distributed Validator Cluster navigates to the launch pad and selects "Create new Cluster" +- The `leader` uses the user interface to configure all the important details about the cluster including: - The `withdrawal address` for the created validators - The `feeRecipient` for block proposals if it differs from the withdrawal address - The number of distributed validators to create diff --git a/docs/goguidelines.md b/docs/goguidelines.md index b00fbf6d6..44581bcaa 100644 --- a/docs/goguidelines.md +++ b/docs/goguidelines.md @@ -51,7 +51,7 @@ checker := newReadyChecker(foo, bar) // Use the checker instance for checker.IsReady() { ... } ``` -Reasoning: The startReadyChecker contains all state and logic in one function and the resulting isReady function cannot be misused. The checker instance introduces a new type with fields that are accesible and can therefore be misused, it is also at risk of being extended with more logic and coupling. +Reasoning: The startReadyChecker contains all state and logic in one function and the resulting isReady function cannot be misused. The checker instance introduces a new type with fields that are accessible and can therefore be misused, it is also at risk of being extended with more logic and coupling. ### Prefer functions returning functions over new types with methods #2 ```go