From ce9a20cefd3f5d24e7379a7e8d6af7eed0983b1c Mon Sep 17 00:00:00 2001 From: xiaobei0715 <1505929057@qq.com> Date: Fri, 20 Dec 2024 21:27:33 +0800 Subject: [PATCH] Docs: remove duplication words --- abci/client/client.go | 2 +- blockchain/v0/pool.go | 2 +- blockchain/v1/peer.go | 2 +- consensus/reactor_test.go | 2 +- .../proposer-based-timestamp/pbts-sysmodel_001_draft.md | 2 +- spec/light-client/accountability/README.md | 2 +- spec/light-client/detection/detection_001_reviewed.md | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/abci/client/client.go b/abci/client/client.go index fb41ae6c0d..72afd9b7a2 100644 --- a/abci/client/client.go +++ b/abci/client/client.go @@ -107,7 +107,7 @@ func NewReqRes(req *types.Request) *ReqRes { } } -// Sets sets the callback. If reqRes is already done, it will call the cb +// Sets the callback. If reqRes is already done, it will call the cb // immediately. Note, reqRes.cb should not change if reqRes.done and only one // callback is supported. func (r *ReqRes) SetCallback(cb func(res *types.Response)) { diff --git a/blockchain/v0/pool.go b/blockchain/v0/pool.go index b3a09b1dc3..f333298041 100644 --- a/blockchain/v0/pool.go +++ b/blockchain/v0/pool.go @@ -35,7 +35,7 @@ const ( requestRetrySeconds = 30 // Minimum recv rate to ensure we're receiving blocks from a peer fast - // enough. If a peer is not sending us data at at least that rate, we + // enough. If a peer is not sending us data at least that rate, we // consider them to have timedout and we disconnect. // // Assuming a DSL connection (not a good choice) 128 Kbps (upload) ~ 15 KB/s, diff --git a/blockchain/v1/peer.go b/blockchain/v1/peer.go index ad26585b30..8dbc8ee566 100644 --- a/blockchain/v1/peer.go +++ b/blockchain/v1/peer.go @@ -197,7 +197,7 @@ func BpPeerDefaultParams() *BpPeerParams { timeout: 15 * time.Second, // Minimum recv rate to ensure we're receiving blocks from a peer fast - // enough. If a peer is not sending data at at least that rate, we + // enough. If a peer is not sending data at least that rate, we // consider them to have timedout and we disconnect. // // Assuming a DSL connection (not a good choice) 128 Kbps (upload) ~ 15 KB/s, diff --git a/consensus/reactor_test.go b/consensus/reactor_test.go index a82aa38859..7b9381898e 100644 --- a/consensus/reactor_test.go +++ b/consensus/reactor_test.go @@ -709,7 +709,7 @@ func timeoutWaitGroup(t *testing.T, n int, f func(int), css []*State) { close(done) }() - // we're running many nodes in-process, possibly in in a virtual machine, + // we're running many nodes in-process, possibly in a virtual machine, // and spewing debug messages - making a block could take a while, timeout := time.Second * 120 diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md index 1b0f9a3b70..48357ea996 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md @@ -105,7 +105,7 @@ then the time `b.time` in the block `b` that is signed by `c` satisfies - `beginConsensus(k) - PRECISION <= b.time < endConsensus(k) + PRECISION + MSGDELAY`. -> [PBTS-CONSENSUS-TIME-VALID.0] is based on an analysis where the proposer is faulty (and does does not count towards `beginConsensus(k)` and `endConsensus(k)`), and we estimate the times at which correct validators receive and `accept` the `propose` message. If the proposer is correct we obtain +> [PBTS-CONSENSUS-TIME-VALID.0] is based on an analysis where the proposer is faulty (and does not count towards `beginConsensus(k)` and `endConsensus(k)`), and we estimate the times at which correct validators receive and `accept` the `propose` message. If the proposer is correct we obtain #### **[PBTS-CONSENSUS-LIVE-VALID-CORR-PROP.0]** diff --git a/spec/light-client/accountability/README.md b/spec/light-client/accountability/README.md index 64b475bec7..75563df708 100644 --- a/spec/light-client/accountability/README.md +++ b/spec/light-client/accountability/README.md @@ -231,7 +231,7 @@ Execution Consequences: -* The validators in F1 will be detectable by the the fork accountability mechanisms. +* The validators in F1 will be detectable by the fork accountability mechanisms. * The validators in F2 cannot be detected using this mechanism. Only in case they signed something which conflicts with the application this can be used against them. Otherwise they do not do anything incorrect. * This case is not covered by the report as it only assumes at most 2/3 of faulty validators. diff --git a/spec/light-client/detection/detection_001_reviewed.md b/spec/light-client/detection/detection_001_reviewed.md index b204677d69..a971084123 100644 --- a/spec/light-client/detection/detection_001_reviewed.md +++ b/spec/light-client/detection/detection_001_reviewed.md @@ -722,7 +722,7 @@ func CreateEvidenceForPeer(peer PeerID, root LightBlock, trace LightStore) #### Argument for [[LCD-DIST-INV-ATTACK.1]](#LCD-DIST-INV-ATTACK1) Under the assumption that root and trace are a verification trace, -when in `CreateEvidenceForPeer` the detector the detector creates +when in `CreateEvidenceForPeer` the detector creates evidence, then the lightclient has seen two different headers (one via `trace` and one via `VerifyToTarget` for the same height that can both be verified in one step.