zolfa
/
tendermint
1
0
Fork 0
Code Issues 0 Pull Requests 0 Projects 0 Releases 221 Wiki Activity
Browse Source

Clean up lint failures for Markdown files (#367) 

Many of the Markdown files in this repository fail the Markdown lint check.
This change cleans up most of them, either by:

- Removing links to targets that no longer exist.
- Updating links to targets that have moved.
- Disabling the linter for files that need more revision.
- Clean up trailing whitespace in files that peeves the super-linter.

Fixes #363.
pull/7804/head
M. J. Fromberger 3 years ago
committed by GitHub
parent
48e008ed10
commit
e92aa56a75
No known key found for this signature in database GPG Key ID: 4AEE18F83AFDEB23
24 changed files with 62 additions and 44 deletions
Unified View
Diff Options
Show Stats Download Patch File Download Diff File
  1. +1
    -1
      rust-spec/fastsync/README.md
  2. +3
    -3
      spec/abci/README.md
  3. +14
    -14
      spec/abci/abci.md
  4. +5
    -4
      spec/abci/apps.md
  5. +8
    -8
      spec/abci/client-server.md
  6. +1
    -1
      spec/consensus/light-client/accountability.md
  7. +1
    -1
      spec/consensus/light-client/detection.md
  8. +1
    -1
      spec/consensus/light-client/verification.md
  9. +2
    -0
      spec/consensus/proposer-based-timestamp/pbts_001_draft.md
  10. +1
    -1
      spec/consensus/readme.md
  11. +1
    -0
      spec/light-client/README.md
  12. +1
    -0
      spec/light-client/attacks/isolate-attackers_001_draft.md
  13. +2
    -0
      spec/light-client/attacks/isolate-attackers_002_reviewed.md
  14. +1
    -1
      spec/light-client/detection/README.md
  15. +2
    -0
      spec/light-client/detection/detection_001_reviewed.md
  16. +2
    -0
      spec/light-client/detection/detection_003_reviewed.md
  17. +2
    -0
      spec/light-client/detection/req-ibc-detection.md
  18. +3
    -1
      spec/light-client/supervisor/supervisor_001_draft.md
  19. +2
    -2
      spec/light-client/verification/README.md
  20. +3
    -1
      spec/light-client/verification/verification_001_published.md
  21. +2
    -0
      spec/light-client/verification/verification_002_draft.md
  22. +3
    -2
      spec/p2p/messages/state-sync.md
  23. +0
    -2
      spec/p2p/node.md
  24. +1
    -1
      spec/p2p/peer.md

+ 1
- 1
rust-spec/fastsync/README.md View File

@ -1,3 +1,3 @@
# Fast Sync # Fast Sync
Deprecated see [tendermint/tendermint/docs/tendermint-core/fastsync.md](https://github.com/tendermint/tendermint/blob/master/docs/tendermint-core/fast-sync.md)
Deprecated see [tendermint/docs/tendermint-core/block-sync](https://github.com/tendermint/tendermint/blob/master/docs/tendermint-core/block-sync/README.md)

+ 3
- 3
spec/abci/README.md View File

@ -10,11 +10,11 @@ parent:
ABCI stands for "**A**pplication **B**lock**c**hain **I**nterface". ABCI stands for "**A**pplication **B**lock**c**hain **I**nterface".
ABCI is the interface between Tendermint (a state-machine replication engine) ABCI is the interface between Tendermint (a state-machine replication engine)
and your application (the actual state machine). It consists of a set of and your application (the actual state machine). It consists of a set of
_methods_, each with a corresponding `Request` and `Response`message type.
To perform state-machine replication, Tendermint calls the ABCI methods on the
_methods_, each with a corresponding `Request` and `Response`message type.
To perform state-machine replication, Tendermint calls the ABCI methods on the
ABCI application by sending the `Request*` messages and receiving the `Response*` messages in return. ABCI application by sending the `Request*` messages and receiving the `Response*` messages in return.
All ABCI messages and methods are defined in [protocol buffers](https://github.com/tendermint/spec/blob/master/proto/tendermint/abci/types.proto).
All ABCI messages and methods are defined in [protocol buffers](../../proto/tendermint/abci/types.proto).
This allows Tendermint to run with applications written in many programming languages. This allows Tendermint to run with applications written in many programming languages.
This specification is split as follows: This specification is split as follows:


+ 14
- 14
spec/abci/abci.md View File

@ -79,7 +79,7 @@ Tendermint consensus.
### Query ### Query
The `Query` ABCI method query queries the application for information about application state. The `Query` ABCI method query queries the application for information about application state.
When Tendermint receives a `ResponseQuery` with a non-zero `Code`, this code is
When Tendermint receives a `ResponseQuery` with a non-zero `Code`, this code is
returned directly to the client that initiated the query. returned directly to the client that initiated the query.
## Events ## Events
@ -91,7 +91,7 @@ transactions and blocks this metadata relates to.
Events returned via these ABCI methods do not impact Tendermint consensus in any way Events returned via these ABCI methods do not impact Tendermint consensus in any way
and instead exist to power subscriptions and queries of Tendermint state. and instead exist to power subscriptions and queries of Tendermint state.
An `Event` contains a `type` and a list of `EventAttributes`, which are key-value
An `Event` contains a `type` and a list of `EventAttributes`, which are key-value
string pairs denoting metadata about what happened during the method's execution. string pairs denoting metadata about what happened during the method's execution.
`Event` values can be used to index transactions and blocks according to what happened `Event` values can be used to index transactions and blocks according to what happened
during their execution. Note that the set of events returned for a block from during their execution. Note that the set of events returned for a block from
@ -163,8 +163,8 @@ Example:
Tendermint's security model relies on the use of "evidence". Evidence is proof of Tendermint's security model relies on the use of "evidence". Evidence is proof of
malicious behaviour by a network participant. It is the responsibility of Tendermint malicious behaviour by a network participant. It is the responsibility of Tendermint
to detect such malicious behaviour. When malicious behavior is detected, Tendermint to detect such malicious behaviour. When malicious behavior is detected, Tendermint
will gossip evidence of the behavior to other nodes and commit the evidence to
the chain once it is verified by all validators. This evidence will then be
will gossip evidence of the behavior to other nodes and commit the evidence to
the chain once it is verified by all validators. This evidence will then be
passed it on to the application through the ABCI. It is the responsibility of the passed it on to the application through the ABCI. It is the responsibility of the
application to handle the evidence and exercise punishment. application to handle the evidence and exercise punishment.
@ -179,8 +179,8 @@ enum EvidenceType {
``` ```
There are two forms of evidence: Duplicate Vote and Light Client Attack. More There are two forms of evidence: Duplicate Vote and Light Client Attack. More
information can be found in either [data structures](https://github.com/tendermint/spec/blob/master/spec/core/data_structures.md)
or [accountability](https://github.com/tendermint/spec/blob/master/spec/light-client/accountability/)
information can be found in either [data structures](../core/data_structures.md)
or [accountability](../light-client/accountability/README.md)
## Determinism ## Determinism
@ -246,7 +246,7 @@ Commit are included in the header of the next block.
State sync allows new nodes to rapidly bootstrap by discovering, fetching, and applying State sync allows new nodes to rapidly bootstrap by discovering, fetching, and applying
state machine snapshots instead of replaying historical blocks. For more details, see the state machine snapshots instead of replaying historical blocks. For more details, see the
[state sync section](../spec/p2p/messages/state-sync.md).
[state sync section](../p2p/messages/state-sync.md).
New nodes will discover and request snapshots from other nodes in the P2P network. New nodes will discover and request snapshots from other nodes in the P2P network.
A Tendermint node that receives a request for snapshots from a peer will call A Tendermint node that receives a request for snapshots from a peer will call
@ -263,7 +263,7 @@ the `LoadSnapshotChunk` method.
As the new node receives "chunks" it will apply them sequentially to the local As the new node receives "chunks" it will apply them sequentially to the local
application with `ApplySnapshotChunk`. When all chunks have been applied, the application application with `ApplySnapshotChunk`. When all chunks have been applied, the application
`AppHash` is retrieved via an `Info` query. The `AppHash` is then compared to `AppHash` is retrieved via an `Info` query. The `AppHash` is then compared to
the blockchain's `AppHash` which is verified via [light client verification](../spec/light-client/verification/README.md).
the blockchain's `AppHash` which is verified via [light client verification](../light-client/verification/README.md).
## Messages ## Messages
@ -297,7 +297,7 @@ the blockchain's `AppHash` which is verified via [light client verification](../
| abci_version | string | The Tendermint ABCI semantic version | 4 | | abci_version | string | The Tendermint ABCI semantic version | 4 |
* **Response**: * **Response**:
| Name | Type | Description | Field Number | | Name | Type | Description | Field Number |
|---------------------|--------|--------------------------------------------------|--------------| |---------------------|--------|--------------------------------------------------|--------------|
| data | string | Some arbitrary information | 1 | | data | string | Some arbitrary information | 1 |
@ -351,7 +351,7 @@ the blockchain's `AppHash` which is verified via [light client verification](../
### Query ### Query
* **Request**: * **Request**:
| Name | Type | Description | Field Number | | Name | Type | Description | Field Number |
|--------|--------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------| |--------|--------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------|
| data | bytes | Raw query bytes. Can be used with or in lieu of Path. | 1 | | data | bytes | Raw query bytes. Can be used with or in lieu of Path. | 1 |
@ -495,7 +495,7 @@ the blockchain's `AppHash` which is verified via [light client verification](../
* `H+3`: `LastCommitInfo` is changed to include the altered validator set. * `H+3`: `LastCommitInfo` is changed to include the altered validator set.
* `consensus_param_updates` returned for block `H` apply to the consensus * `consensus_param_updates` returned for block `H` apply to the consensus
params for block `H+1`. For more information on the consensus parameters, params for block `H+1`. For more information on the consensus parameters,
see the [application spec entry on consensus parameters](../spec/abci/apps.md#consensus-parameters).
see the [application spec entry on consensus parameters](./apps.md#consensus-parameters).
### Commit ### Commit
@ -605,7 +605,7 @@ the blockchain's `AppHash` which is verified via [light client verification](../
can be spoofed by adversaries, so applications should employ additional verification schemes can be spoofed by adversaries, so applications should employ additional verification schemes
to avoid denial-of-service attacks. The verified `AppHash` is automatically checked against to avoid denial-of-service attacks. The verified `AppHash` is automatically checked against
the restored application at the end of snapshot restoration. the restored application at the end of snapshot restoration.
* For more information, see the `Snapshot` data type or the [state sync section](../spec/p2p/messages/state-sync.md).
* For more information, see the `Snapshot` data type or the [state sync section](../p2p/messages/state-sync.md).
### ApplySnapshotChunk ### ApplySnapshotChunk
@ -651,7 +651,7 @@ the blockchain's `AppHash` which is verified via [light client verification](../
## Data Types ## Data Types
Most of the data structures used in ABCI are shared [common data structures](../spec/core/data_structures.md). In certain cases, ABCI uses different data structures which are documented here:
Most of the data structures used in ABCI are shared [common data structures](../core/data_structures.md). In certain cases, ABCI uses different data structures which are documented here:
### Validator ### Validator
@ -769,7 +769,7 @@ Most of the data structures used in ABCI are shared [common data structures](../
| metadata | bytes | Arbitrary application metadata, for example chunk hashes or other verification data. | 3 | | metadata | bytes | Arbitrary application metadata, for example chunk hashes or other verification data. | 3 |
* **Usage**: * **Usage**:
* Used for state sync snapshots, see the [state sync section](../spec/p2p/messages/state-sync.md) for details.
* Used for state sync snapshots, see the [state sync section](../p2p/messages/state-sync.md) for details.
* A snapshot is considered identical across nodes only if _all_ fields are equal (including * A snapshot is considered identical across nodes only if _all_ fields are equal (including
`Metadata`). Chunks may be retrieved from all nodes that have the same snapshot. `Metadata`). Chunks may be retrieved from all nodes that have the same snapshot.
* When sent across the network, a snapshot message can be at most 4 MB. * When sent across the network, a snapshot message can be at most 4 MB.

+ 5
- 4
spec/abci/apps.md View File

@ -166,9 +166,10 @@ the difference credited back. Tendermint adopts a similar abstraction,
though uses it only optionally and weakly, allowing applications to define though uses it only optionally and weakly, allowing applications to define
their own sense of the cost of execution. their own sense of the cost of execution.
In Tendermint, the [ConsensusParams.Block.MaxGas](../proto/types/params.proto) limits the amount of `gas` that can be used in a block.
The default value is `-1`, meaning no limit, or that the concept of gas is
meaningless.
In Tendermint, the
[ConsensusParams.Block.MaxGas](../../proto/tendermint/types/params.proto)
limits the amount of `gas` that can be used in a block. The default value is
`-1`, meaning no limit, or that the concept of gas is meaningless.
Responses contain a `GasWanted` and `GasUsed` field. The former is the maximum Responses contain a `GasWanted` and `GasUsed` field. The former is the maximum
amount of gas the sender of a tx is willing to use, and the later is how much it actually amount of gas the sender of a tx is willing to use, and the later is how much it actually
@ -217,7 +218,7 @@ the Tendermint protocol.
If DeliverTx returns `Code != 0`, the transaction will be considered invalid, If DeliverTx returns `Code != 0`, the transaction will be considered invalid,
though it is still included in the block. though it is still included in the block.
DeliverTx also returns a [Code, Data, and Log](../../proto/abci/types.proto#L189-L191).
DeliverTx also returns a [Code, Data, and Log](../../proto/tendermint/abci/types.proto#L189-L191).
`Data` contains the result of the CheckTx transaction execution, if any. It is `Data` contains the result of the CheckTx transaction execution, if any. It is
semantically meaningless to Tendermint. semantically meaningless to Tendermint.


+ 8
- 8
spec/abci/client-server.md View File

@ -14,7 +14,7 @@ Applications](./apps.md).
## Message Protocol ## Message Protocol
The message protocol consists of pairs of requests and responses defined in the The message protocol consists of pairs of requests and responses defined in the
[protobuf file](https://github.com/tendermint/tendermint/blob/master/proto/tendermint/abci/types.proto).
[protobuf file](../../proto/tendermint/abci/types.proto).
Some messages have no fields, while others may include byte-arrays, strings, integers, Some messages have no fields, while others may include byte-arrays, strings, integers,
or custom protobuf types. or custom protobuf types.
@ -54,13 +54,13 @@ If GRPC is available in your language, this is the easiest approach,
though it will have significant performance overhead. though it will have significant performance overhead.
To get started with GRPC, copy in the [protobuf To get started with GRPC, copy in the [protobuf
file](https://github.com/tendermint/tendermint/blob/master/proto/tendermint/abci/types.proto)
and compile it using the GRPC plugin for your language. For instance,
for golang, the command is `protoc --go_out=plugins=grpc:. types.proto`.
See the [grpc documentation for more details](http://www.grpc.io/docs/).
`protoc` will autogenerate all the necessary code for ABCI client and
server in your language, including whatever interface your application
must satisfy to be used by the ABCI server for handling requests.
file](../../proto/tendermint/abci/types.proto) and compile it using the GRPC
plugin for your language. For instance, for golang, the command is `protoc
--go_out=plugins=grpc:. types.proto`. See the [grpc documentation for more
details](http://www.grpc.io/docs/). `protoc` will autogenerate all the
necessary code for ABCI client and server in your language, including whatever
interface your application must satisfy to be used by the ABCI server for
handling requests.
Note the length-prefixing used in the socket implementation (TSP) does not apply for GRPC. Note the length-prefixing used in the socket implementation (TSP) does not apply for GRPC.


+ 1
- 1
spec/consensus/light-client/accountability.md View File

@ -1,3 +1,3 @@
# Fork accountability # Fork accountability
Deprecated, please see [light-client/accountability](../../light-client/accountability.md).
Deprecated, please see [light-client/accountability](../../light-client/accountability/README.md).

+ 1
- 1
spec/consensus/light-client/detection.md View File

@ -1,3 +1,3 @@
# Detection # Detection
Deprecated, please see [light-client/detection](../../light-client/detection.md).
Deprecated, please see [light-client/detection](../../light-client/detection/README.md).

+ 1
- 1
spec/consensus/light-client/verification.md View File

@ -1,3 +1,3 @@
# Core Verification # Core Verification
Deprecated, please see [light-client/accountability](../../light-client/verification.md).
Deprecated, please see [light-client/accountability](../../light-client/verification/README.md).

+ 2
- 0
spec/consensus/proposer-based-timestamp/pbts_001_draft.md View File

@ -1,3 +1,5 @@
<!-- markdown-link-check-disable -->
# Proposer-Based Time # Proposer-Based Time
## Current BFTTime ## Current BFTTime


+ 1
- 1
spec/consensus/readme.md View File

@ -26,7 +26,7 @@ Specification of the Tendermint consensus protocol.
consensus state machine to recover from crashes. consensus state machine to recover from crashes.
The protocol used to gossip consensus messages between peers, which is critical The protocol used to gossip consensus messages between peers, which is critical
for liveness, is described in the [reactors section](../reactors/consensus/consensus.md).
for liveness, is described in the [reactors section](./consensus.md).
There is also a [stale markdown description](consensus.md) of the consensus state machine There is also a [stale markdown description](consensus.md) of the consensus state machine
(TODO update this). (TODO update this).

+ 1
- 0
spec/light-client/README.md View File

@ -4,6 +4,7 @@ parent:
title: Light Client title: Light Client
order: 5 order: 5
--- ---
<!-- markdown-link-check-disable -->
# Light Client Specification # Light Client Specification


+ 1
- 0
spec/light-client/attacks/isolate-attackers_001_draft.md View File

@ -1,3 +1,4 @@
<!-- markdown-link-check-disable -->
# Lightclient Attackers Isolation # Lightclient Attackers Isolation


+ 2
- 0
spec/light-client/attacks/isolate-attackers_002_reviewed.md View File

@ -1,3 +1,5 @@
<!-- markdown-link-check-disable -->
# Lightclient Attackers Isolation # Lightclient Attackers Isolation
Adversarial nodes may have the incentive to lie to a lightclient about the state of a Tendermint blockchain. An attempt to do so is called attack. Light client [verification][verification] checks incoming data by checking a so-called "commit", which is a forwarded set of signed messages that is (supposedly) produced during executing Tendermint consensus. Thus, an attack boils down to creating and signing Tendermint consensus messages in deviation from the Tendermint consensus algorithm rules. Adversarial nodes may have the incentive to lie to a lightclient about the state of a Tendermint blockchain. An attempt to do so is called attack. Light client [verification][verification] checks incoming data by checking a so-called "commit", which is a forwarded set of signed messages that is (supposedly) produced during executing Tendermint consensus. Thus, an attack boils down to creating and signing Tendermint consensus messages in deviation from the Tendermint consensus algorithm rules.


+ 1
- 1
spec/light-client/detection/README.md View File

@ -14,7 +14,7 @@ This directory captures the ongoing work and discussion on fork
detection both in the context of a Tendermint light node and in the detection both in the context of a Tendermint light node and in the
context of IBC. It contains the following files context of IBC. It contains the following files
### [detection.md](./detection.md)
### detection.md
a draft of the light node fork detection including "proof of fork" a draft of the light node fork detection including "proof of fork"
definition, that is, the data structure to submit evidence to full definition, that is, the data structure to submit evidence to full


+ 2
- 0
spec/light-client/detection/detection_001_reviewed.md View File

@ -1,3 +1,5 @@
<!-- markdown-link-check-disable -->
# ***This an unfinished draft. Comments are welcome!*** # ***This an unfinished draft. Comments are welcome!***
**TODO:** We will need to do small adaptations to the verification **TODO:** We will need to do small adaptations to the verification


+ 2
- 0
spec/light-client/detection/detection_003_reviewed.md View File

@ -1,3 +1,5 @@
<!-- markdown-link-check-disable -->
# Light Client Attack Detector # Light Client Attack Detector
In this specification, we strengthen the light client to be resistant In this specification, we strengthen the light client to be resistant


+ 2
- 0
spec/light-client/detection/req-ibc-detection.md View File

@ -1,3 +1,5 @@
<!-- markdown-link-check-disable -->
# Requirements for Fork Detection in the IBC Context # Requirements for Fork Detection in the IBC Context
## What you need to know about IBC ## What you need to know about IBC


+ 3
- 1
spec/light-client/supervisor/supervisor_001_draft.md View File

@ -1,3 +1,5 @@
<!-- markdown-link-check-disable -->
# Draft of Light Client Supervisor for discussion # Draft of Light Client Supervisor for discussion
## TODOs ## TODOs
@ -634,4 +636,4 @@ func VerifyAndDetect (lightStore LightStore, targetHeight Height)
- an attack is detected - an attack is detected
- [LC-DATA-PEERLIST-INV.1] is violated - [LC-DATA-PEERLIST-INV.1] is violated
----
----

+ 2
- 2
spec/light-client/verification/README.md View File

@ -27,7 +27,7 @@ Given a known bound `TRUSTED_PERIOD`, and a block `b` with header `h` generated
in `validators(b.Header.NextValidatorsHash)` is correct until time `b.Header.Time + TRUSTED_PERIOD`. in `validators(b.Header.NextValidatorsHash)` is correct until time `b.Header.Time + TRUSTED_PERIOD`.
*Assumption*: "correct" is defined w.r.t. realtime (some Newtonian global notion of time, i.e., wall time), *Assumption*: "correct" is defined w.r.t. realtime (some Newtonian global notion of time, i.e., wall time),
while `Header.Time` corresponds to the [BFT time](../consensus/bft-time.md). In this note, we assume that clocks of correct processes
while `Header.Time` corresponds to the [BFT time](../../consensus/bft-time.md). In this note, we assume that clocks of correct processes
are synchronized (for example using NTP), and therefore there is bounded clock drift (`CLOCK_DRIFT`) between local clocks and are synchronized (for example using NTP), and therefore there is bounded clock drift (`CLOCK_DRIFT`) between local clocks and
BFT time. More precisely, for every correct light client process and every `header.Time` (i.e. BFT Time, for a header correctly BFT time. More precisely, for every correct light client process and every `header.Time` (i.e. BFT Time, for a header correctly
generated by the Tendermint consensus), the following inequality holds: `Header.Time < now + CLOCK_DRIFT`, generated by the Tendermint consensus), the following inequality holds: `Header.Time < now + CLOCK_DRIFT`,
@ -47,7 +47,7 @@ Mechanisms like `fork accountability` and `evidence submission` are defined in t
they incentivize validators to follow the protocol specification defined in this document. If they don't, they incentivize validators to follow the protocol specification defined in this document. If they don't,
and we have 1/3 (or more) faulty validators, safety may be violated. Our approach then is and we have 1/3 (or more) faulty validators, safety may be violated. Our approach then is
to *detect* these cases (after the fact), and take suitable repair actions (automatic and social). to *detect* these cases (after the fact), and take suitable repair actions (automatic and social).
This is discussed in document on [Fork accountability](./accountability.md).
This is discussed in document on [Fork accountability](../accountability/README.md).
The term "trusted" above indicates that the correctness of the protocol depends on The term "trusted" above indicates that the correctness of the protocol depends on
this assumption. It is in the responsibility of the user that runs the light client to make sure that the risk this assumption. It is in the responsibility of the user that runs the light client to make sure that the risk


+ 3
- 1
spec/light-client/verification/verification_001_published.md View File

@ -1,3 +1,5 @@
<!-- markdown-link-check-disable -->
# Light Client Verification # Light Client Verification
The light client implements a read operation of a The light client implements a read operation of a
@ -1175,4 +1177,4 @@ func Main (primary PeerID, lightStore LightStore, targetHeight Height)
[FN-ManifestFaulty-link]: https://github.com/tendermint/spec/blob/master/spec/blockchain/fullnode.md#fn-manifestfaulty [FN-ManifestFaulty-link]: https://github.com/tendermint/spec/blob/master/spec/blockchain/fullnode.md#fn-manifestfaulty
[arXiv]: https://arxiv.org/abs/1807.04938
[arXiv]: https://arxiv.org/abs/1807.04938

+ 2
- 0
spec/light-client/verification/verification_002_draft.md View File

@ -1,3 +1,5 @@
<!-- markdown-link-check-disable -->
# Light Client Verification # Light Client Verification
The light client implements a read operation of a The light client implements a read operation of a


+ 3
- 2
spec/p2p/messages/state-sync.md View File

@ -91,8 +91,9 @@ if necessary. The light block at the height of the snapshot will be used to veri
|---------------|---------------------------------------------------------|--------------------------------------|--------------| |---------------|---------------------------------------------------------|--------------------------------------|--------------|
| light_block | [LightBlock](../../core/data_structures.md#lightblock) | Light block at the height requested | 1 | | light_block | [LightBlock](../../core/data_structures.md#lightblock) | Light block at the height requested | 1 |
State sync will use [light client verification](../../light-client/verification.README.md) to verify
the light blocks.
State sync will use [light client
verification](https://github.com/tendermint/tendermint/blob/master/docs/tendermint-core/light-client.md)
to verify the light blocks.
If no state sync is in progress (i.e. during normal operation), any unsolicited response messages If no state sync is in progress (i.e. during normal operation), any unsolicited response messages


+ 0
- 2
spec/p2p/node.md View File

@ -12,8 +12,6 @@ Seeds should operate full nodes with the PEX reactor in a "crawler" mode
that continuously explores to validate the availability of peers. that continuously explores to validate the availability of peers.
Seeds should only respond with some top percentile of the best peers it knows about. Seeds should only respond with some top percentile of the best peers it knows about.
See [the peer-exchange docs](https://github.com/tendermint/spec/blob/master/spec/reactors/pex/pex.md) for
details on peer quality.
## New Full Node ## New Full Node


+ 1
- 1
spec/p2p/peer.md View File

@ -2,7 +2,7 @@
This document explains how Tendermint Peers are identified and how they connect to one another. This document explains how Tendermint Peers are identified and how they connect to one another.
For details on peer discovery, see the [peer exchange (PEX) reactor doc](https://github.com/tendermint/spec/blob/master/spec/reactors/pex/pex.md).
For details on peer discovery, see the [peer exchange (PEX) doc](https://github.com/tendermint/tendermint/blob/master/docs/tendermint-core/pex/README.md).
## Peer Identity ## Peer Identity


Write Preview
Loading…
Cancel
Save