mirror of
https://github.com/fluencelabs/tendermint
synced 2025-06-26 03:01:42 +00:00
lint markdown docs using a stop-words and write-good linters (#2195)
* lint docs with write-good, stop-words * remove package-lock.json * update changelog * fix wrong paragraph formatting * fix some docs formatting * fix docs format * fix abci spec format
This commit is contained in:
Peng Zhong
committed by
Anton Kaliaev
Anton Kaliaev
parent
8a84593c02
commit
20e35654c6
@ -7,8 +7,7 @@ a subset of transactions** (rather than all of them) using `/subscribe?event=X`.
|
||||
example, I want to subscribe for all transactions associated with a particular
|
||||
account. Same for fetching. The user may want to **fetch transactions based on
|
||||
some filter** (rather than fetching all the blocks). For example, I want to get
|
||||
all transactions for a particular account in the last two weeks (`tx's block
|
||||
time >= '2017-06-05'`).
|
||||
all transactions for a particular account in the last two weeks (`tx's block time >= '2017-06-05'`).
|
||||
|
||||
Now you can't even subscribe to "all txs" in Tendermint.
|
||||
|
||||
|
||||
@ -3,11 +3,11 @@
|
||||
## Context
|
||||
|
||||
Right now, we can query the present validator set, but there is no history.
|
||||
If you were offline for a long time, there is no way to reconstruct past validators. This is needed for the light client and we agreed needs enhancement of the API.
|
||||
If you were offline for a long time, there is no way to reconstruct past validators. This is needed for the light client and we agreed needs enhancement of the API.
|
||||
|
||||
## Decision
|
||||
|
||||
For every block, store a new structure that contains either the latest validator set,
|
||||
For every block, store a new structure that contains either the latest validator set,
|
||||
or the height of the last block for which the validator set changed. Note this is not
|
||||
the height of the block which returned the validator set change itself, but the next block,
|
||||
ie. the first block it comes into effect for.
|
||||
@ -19,7 +19,7 @@ are updated frequently - for instance by only saving the diffs, rather than the
|
||||
|
||||
An alternative approach suggested keeping the validator set, or diffs of it, in a merkle IAVL tree.
|
||||
While it might afford cheaper proofs that a validator set has not changed, it would be more complex,
|
||||
and likely less efficient.
|
||||
and likely less efficient.
|
||||
|
||||
## Status
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ Since they may be need to be different in different networks, and potentially to
|
||||
networks, we seek to initialize them in a genesis file, and expose them through the ABCI.
|
||||
|
||||
While we have some specific parameters now, like maximum block and transaction size, we expect to have more in the future,
|
||||
such as a period over which evidence is valid, or the frequency of checkpoints.
|
||||
such as a period over which evidence is valid, or the frequency of checkpoints.
|
||||
|
||||
## Decision
|
||||
|
||||
@ -45,7 +45,7 @@ type BlockGossip struct {
|
||||
|
||||
The `ConsensusParams` can evolve over time by adding new structs that cover different aspects of the consensus rules.
|
||||
|
||||
The `BlockPartSizeBytes` and the `BlockSize.MaxBytes` are enforced to be greater than 0.
|
||||
The `BlockPartSizeBytes` and the `BlockSize.MaxBytes` are enforced to be greater than 0.
|
||||
The former because we need a part size, the latter so that we always have at least some sanity check over the size of blocks.
|
||||
|
||||
### ABCI
|
||||
@ -53,14 +53,14 @@ The former because we need a part size, the latter so that we always have at lea
|
||||
#### InitChain
|
||||
|
||||
InitChain currently takes the initial validator set. It should be extended to also take parts of the ConsensusParams.
|
||||
There is some case to be made for it to take the entire Genesis, except there may be things in the genesis,
|
||||
There is some case to be made for it to take the entire Genesis, except there may be things in the genesis,
|
||||
like the BlockPartSize, that the app shouldn't really know about.
|
||||
|
||||
#### EndBlock
|
||||
|
||||
The EndBlock response includes a `ConsensusParams`, which includes BlockSize and TxSize, but not BlockGossip.
|
||||
Other param struct can be added to `ConsensusParams` in the future.
|
||||
The `0` value is used to denote no change.
|
||||
The `0` value is used to denote no change.
|
||||
Any other value will update that parameter in the `State.ConsensusParams`, to be applied for the next block.
|
||||
Tendermint should have hard-coded upper limits as sanity checks.
|
||||
|
||||
@ -83,4 +83,3 @@ Proposed.
|
||||
### Neutral
|
||||
|
||||
- The TxSize, which checks validity, may be in conflict with the config's `max_block_size_tx`, which determines proposal sizes
|
||||
|
||||
|
||||
@ -8,13 +8,13 @@ The proposed trust metric will allow Tendermint to maintain local trust rankings
|
||||
|
||||
The Tendermint Core project developers would like to improve Tendermint security and reliability by keeping track of the level of trustworthiness peers have demonstrated within the peer-to-peer network. This way, undesirable outcomes from peers will not immediately result in them being dropped from the network (potentially causing drastic changes to take place). Instead, peers behavior can be monitored with appropriate metrics and be removed from the network once Tendermint Core is certain the peer is a threat. For example, when the PEXReactor makes a request for peers network addresses from a already known peer, and the returned network addresses are unreachable, this untrustworthy behavior should be tracked. Returning a few bad network addresses probably shouldn’t cause a peer to be dropped, while excessive amounts of this behavior does qualify the peer being dropped.
|
||||
|
||||
Trust metrics can be circumvented by malicious nodes through the use of strategic oscillation techniques, which adapts the malicious node’s behavior pattern in order to maximize its goals. For instance, if the malicious node learns that the time interval of the Tendermint trust metric is *X* hours, then it could wait *X* hours in-between malicious activities. We could try to combat this issue by increasing the interval length, yet this will make the system less adaptive to recent events.
|
||||
Trust metrics can be circumvented by malicious nodes through the use of strategic oscillation techniques, which adapts the malicious node’s behavior pattern in order to maximize its goals. For instance, if the malicious node learns that the time interval of the Tendermint trust metric is _X_ hours, then it could wait _X_ hours in-between malicious activities. We could try to combat this issue by increasing the interval length, yet this will make the system less adaptive to recent events.
|
||||
|
||||
Instead, having shorter intervals, but keeping a history of interval values, will give our metric the flexibility needed in order to keep the network stable, while also making it resilient against a strategic malicious node in the Tendermint peer-to-peer network. Also, the metric can access trust data over a rather long period of time while not greatly increasing its history size by aggregating older history values over a larger number of intervals, and at the same time, maintain great precision for the recent intervals. This approach is referred to as fading memories, and closely resembles the way human beings remember their experiences. The trade-off to using history data is that the interval values should be preserved in-between executions of the node.
|
||||
|
||||
### References
|
||||
|
||||
S. Mudhakar, L. Xiong, and L. Liu, “TrustGuard: Countering Vulnerabilities in Reputation Management for Decentralized Overlay Networks,” in *Proceedings of the 14th international conference on World Wide Web, pp. 422-431*, May 2005.
|
||||
S. Mudhakar, L. Xiong, and L. Liu, “TrustGuard: Countering Vulnerabilities in Reputation Management for Decentralized Overlay Networks,” in _Proceedings of the 14th international conference on World Wide Web, pp. 422-431_, May 2005.
|
||||
|
||||
## Decision
|
||||
|
||||
@ -26,25 +26,23 @@ The three subsections below will cover the process being considered for calculat
|
||||
|
||||
The proposed trust metric will count good and bad events relevant to the object, and calculate the percent of counters that are good over an interval with a predefined duration. This is the procedure that will continue for the life of the trust metric. When the trust metric is queried for the current **trust value**, a resilient equation will be utilized to perform the calculation.
|
||||
|
||||
The equation being proposed resembles a Proportional-Integral-Derivative (PID) controller used in control systems. The proportional component allows us to be sensitive to the value of the most recent interval, while the integral component allows us to incorporate trust values stored in the history data, and the derivative component allows us to give weight to sudden changes in the behavior of a peer. We compute the trust value of a peer in interval i based on its current trust ranking, its trust rating history prior to interval *i* (over the past *maxH* number of intervals) and its trust ranking fluctuation. We will break up the equation into the three components.
|
||||
The equation being proposed resembles a Proportional-Integral-Derivative (PID) controller used in control systems. The proportional component allows us to be sensitive to the value of the most recent interval, while the integral component allows us to incorporate trust values stored in the history data, and the derivative component allows us to give weight to sudden changes in the behavior of a peer. We compute the trust value of a peer in interval i based on its current trust ranking, its trust rating history prior to interval _i_ (over the past _maxH_ number of intervals) and its trust ranking fluctuation. We will break up the equation into the three components.
|
||||
|
||||
```math
|
||||
(1) Proportional Value = a * R[i]
|
||||
```
|
||||
|
||||
where *R*[*i*] denotes the raw trust value at time interval *i* (where *i* == 0 being current time) and *a* is the weight applied to the contribution of the current reports. The next component of our equation uses a weighted sum over the last *maxH* intervals to calculate the history value for time *i*:
|
||||
|
||||
where _R_[*i*] denotes the raw trust value at time interval _i_ (where _i_ == 0 being current time) and _a_ is the weight applied to the contribution of the current reports. The next component of our equation uses a weighted sum over the last _maxH_ intervals to calculate the history value for time _i_:
|
||||
|
||||
`H[i] = ` 
|
||||
`H[i] =` 
|
||||
|
||||
|
||||
The weights can be chosen either optimistically or pessimistically. An optimistic weight creates larger weights for newer history data values, while the the pessimistic weight creates larger weights for time intervals with lower scores. The default weights used during the calculation of the history value are optimistic and calculated as *Wk* = 0.8^*k*, for time interval *k*. With the history value available, we can now finish calculating the integral value:
|
||||
The weights can be chosen either optimistically or pessimistically. An optimistic weight creates larger weights for newer history data values, while the the pessimistic weight creates larger weights for time intervals with lower scores. The default weights used during the calculation of the history value are optimistic and calculated as _Wk_ = 0.8^_k_, for time interval _k_. With the history value available, we can now finish calculating the integral value:
|
||||
|
||||
```math
|
||||
(2) Integral Value = b * H[i]
|
||||
```
|
||||
|
||||
Where *H*[*i*] denotes the history value at time interval *i* and *b* is the weight applied to the contribution of past performance for the object being measured. The derivative component will be calculated as follows:
|
||||
Where _H_[*i*] denotes the history value at time interval _i_ and _b_ is the weight applied to the contribution of past performance for the object being measured. The derivative component will be calculated as follows:
|
||||
|
||||
```math
|
||||
D[i] = R[i] – H[i]
|
||||
@ -52,25 +50,25 @@ D[i] = R[i] – H[i]
|
||||
(3) Derivative Value = c(D[i]) * D[i]
|
||||
```
|
||||
|
||||
Where the value of *c* is selected based on the *D*[*i*] value relative to zero. The default selection process makes *c* equal to 0 unless *D*[*i*] is a negative value, in which case c is equal to 1. The result is that the maximum penalty is applied when current behavior is lower than previously experienced behavior. If the current behavior is better than the previously experienced behavior, then the Derivative Value has no impact on the trust value. With the three components brought together, our trust value equation is calculated as follows:
|
||||
Where the value of _c_ is selected based on the _D_[*i*] value relative to zero. The default selection process makes _c_ equal to 0 unless _D_[*i*] is a negative value, in which case c is equal to 1. The result is that the maximum penalty is applied when current behavior is lower than previously experienced behavior. If the current behavior is better than the previously experienced behavior, then the Derivative Value has no impact on the trust value. With the three components brought together, our trust value equation is calculated as follows:
|
||||
|
||||
```math
|
||||
TrustValue[i] = a * R[i] + b * H[i] + c(D[i]) * D[i]
|
||||
```
|
||||
|
||||
As a performance optimization that will keep the amount of raw interval data being saved to a reasonable size of *m*, while allowing us to represent 2^*m* - 1 history intervals, we can employ the fading memories technique that will trade space and time complexity for the precision of the history data values by summarizing larger quantities of less recent values. While our equation above attempts to access up to *maxH* (which can be 2^*m* - 1), we will map those requests down to *m* values using equation 4 below:
|
||||
As a performance optimization that will keep the amount of raw interval data being saved to a reasonable size of _m_, while allowing us to represent 2^_m_ - 1 history intervals, we can employ the fading memories technique that will trade space and time complexity for the precision of the history data values by summarizing larger quantities of less recent values. While our equation above attempts to access up to _maxH_ (which can be 2^_m_ - 1), we will map those requests down to _m_ values using equation 4 below:
|
||||
|
||||
```math
|
||||
(4) j = index, where index > 0
|
||||
```
|
||||
|
||||
Where *j* is one of *(0, 1, 2, … , m – 1)* indices used to access history interval data. Now we can access the raw intervals using the following calculations:
|
||||
Where _j_ is one of _(0, 1, 2, … , m – 1)_ indices used to access history interval data. Now we can access the raw intervals using the following calculations:
|
||||
|
||||
```math
|
||||
R[0] = raw data for current time interval
|
||||
```
|
||||
|
||||
`R[j] = ` 
|
||||
`R[j] =` 
|
||||
|
||||
### Trust Metric Store
|
||||
|
||||
@ -84,9 +82,7 @@ When the node is shutting down, the trust metric store will save history data fo
|
||||
|
||||
Each trust metric allows for the recording of positive/negative events, querying the current trust value/score, and the stopping/pausing of tracking over time intervals. This can be seen below:
|
||||
|
||||
|
||||
```go
|
||||
|
||||
// TrustMetric - keeps track of peer reliability
|
||||
type TrustMetric struct {
|
||||
// Private elements.
|
||||
@ -123,13 +119,11 @@ tm.BadEvents(1)
|
||||
score := tm.TrustScore()
|
||||
|
||||
tm.Stop()
|
||||
|
||||
```
|
||||
|
||||
Some of the trust metric parameters can be configured. The weight values should probably be left alone in more cases, yet the time durations for the tracking window and individual time interval should be considered.
|
||||
|
||||
```go
|
||||
|
||||
// TrustMetricConfig - Configures the weight functions and time intervals for the metric
|
||||
type TrustMetricConfig struct {
|
||||
// Determines the percentage given to current behavior
|
||||
@ -165,23 +159,21 @@ config := TrustMetricConfig{
|
||||
tm := NewMetricWithConfig(config)
|
||||
|
||||
tm.BadEvents(10)
|
||||
tm.Pause()
|
||||
tm.Pause()
|
||||
tm.GoodEvents(1) // becomes active again
|
||||
|
||||
```
|
||||
|
||||
A trust metric store should be created with a DB that has persistent storage so it can save history data across node executions. All trust metrics instantiated by the store will be created with the provided TrustMetricConfig configuration.
|
||||
A trust metric store should be created with a DB that has persistent storage so it can save history data across node executions. All trust metrics instantiated by the store will be created with the provided TrustMetricConfig configuration.
|
||||
|
||||
When you attempt to fetch the trust metric for a peer, and an entry does not exist in the trust metric store, a new metric is automatically created and the entry made within the store.
|
||||
|
||||
In additional to the fetching method, GetPeerTrustMetric, the trust metric store provides a method to call when a peer has disconnected from the node. This is so the metric can be paused (history data will not be saved) for periods of time when the node is not having direct experiences with the peer.
|
||||
|
||||
```go
|
||||
|
||||
// TrustMetricStore - Manages all trust metrics for peers
|
||||
type TrustMetricStore struct {
|
||||
cmn.BaseService
|
||||
|
||||
|
||||
// Private elements
|
||||
}
|
||||
|
||||
@ -214,7 +206,6 @@ tm := tms.GetPeerTrustMetric(key)
|
||||
tm.BadEvents(1)
|
||||
|
||||
tms.PeerDisconnected(key)
|
||||
|
||||
```
|
||||
|
||||
## Status
|
||||
|
||||
@ -17,11 +17,13 @@ For example, when the PEXReactor makes a request for peers network addresses fro
|
||||
The trust metric implementation allows a developer to obtain a peer's trust metric from a trust metric store, and track good and bad events relevant to a peer's behavior, and at any time, the peer's metric can be queried for a current trust value. The current trust value is calculated with a formula that utilizes current behavior, previous behavior, and change between the two. Current behavior is calculated as the percentage of good behavior within a time interval. The time interval is short; probably set between 30 seconds and 5 minutes. On the other hand, the historic data can estimate a peer's behavior over days worth of tracking. At the end of a time interval, the current behavior becomes part of the historic data, and a new time interval begins with the good and bad counters reset to zero.
|
||||
|
||||
These are some important things to keep in mind regarding how the trust metrics handle time intervals and scoring:
|
||||
|
||||
- Each new time interval begins with a perfect score
|
||||
- Bad events quickly bring the score down and good events cause the score to slowly rise
|
||||
- When the time interval is over, the percentage of good events becomes historic data.
|
||||
|
||||
Some useful information about the inner workings of the trust metric:
|
||||
|
||||
- When a trust metric is first instantiated, a timer (ticker) periodically fires in order to handle transitions between trust metric time intervals
|
||||
- If a peer is disconnected from a node, the timer should be paused, since the node is no longer connected to that peer
|
||||
- The ability to pause the metric is supported with the store **PeerDisconnected** method and the metric **Pause** method
|
||||
@ -76,6 +78,7 @@ Peer quality is tracked in the connection and across the reactors by storing the
|
||||
thread safe Data store.
|
||||
|
||||
Peer behaviour is then defined as one of the following:
|
||||
|
||||
- Fatal - something outright malicious that causes us to disconnect the peer and ban it from the address book for some amount of time
|
||||
- Bad - Any kind of timeout, messages that don't unmarshal, fail other validity checks, or messages we didn't ask for or aren't expecting (usually worth one bad event)
|
||||
- Neutral - Unknown channels/message types/version upgrades (no good or bad events recorded)
|
||||
|
||||
@ -11,18 +11,18 @@ implementations:
|
||||
The SocketPV address can be provided via flags at the command line - doing so
|
||||
will cause Tendermint to ignore any "priv_validator.json" file and to listen on
|
||||
the given address for incoming connections from an external priv_validator
|
||||
process. It will halt any operation until at least one external process
|
||||
process. It will halt any operation until at least one external process
|
||||
succesfully connected.
|
||||
|
||||
The external priv_validator process will dial the address to connect to
|
||||
Tendermint, and then Tendermint will send requests on the ensuing connection to
|
||||
sign votes and proposals. Thus the external process initiates the connection,
|
||||
but the Tendermint process makes all requests. In a later stage we're going to
|
||||
sign votes and proposals. Thus the external process initiates the connection,
|
||||
but the Tendermint process makes all requests. In a later stage we're going to
|
||||
support multiple validators for fault tolerance. To prevent double signing they
|
||||
need to be synced, which is deferred to an external solution (see #1185).
|
||||
|
||||
In addition, Tendermint will provide implementations that can be run in that
|
||||
external process. These include:
|
||||
external process. These include:
|
||||
|
||||
- FilePV will encrypt the private key, and the user must enter password to
|
||||
decrypt key when process is started.
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
|
||||
## Context
|
||||
|
||||
The ABCI was first introduced in late 2015. It's purpose is to be:
|
||||
The ABCI was first introduced in late 2015. It's purpose is to be:
|
||||
|
||||
- a generic interface between state machines and their replication engines
|
||||
- agnostic to the language the state machine is written in
|
||||
@ -66,8 +66,8 @@ possible.
|
||||
### Validators
|
||||
|
||||
To change the validator set, applications can return a list of validator updates
|
||||
with ResponseEndBlock. In these updates, the public key *must* be included,
|
||||
because Tendermint requires the public key to verify validator signatures. This
|
||||
with ResponseEndBlock. In these updates, the public key _must_ be included,
|
||||
because Tendermint requires the public key to verify validator signatures. This
|
||||
means ABCI developers have to work with PubKeys. That said, it would also be
|
||||
convenient to work with address information, and for it to be simple to do so.
|
||||
|
||||
@ -80,7 +80,7 @@ in commits.
|
||||
|
||||
### InitChain
|
||||
|
||||
Tendermint passes in a list of validators here, and nothing else. It would
|
||||
Tendermint passes in a list of validators here, and nothing else. It would
|
||||
benefit the application to be able to control the initial validator set. For
|
||||
instance the genesis file could include application-based information about the
|
||||
initial validator set that the application could process to determine the
|
||||
@ -120,7 +120,6 @@ v1 will:
|
||||
That said, an Amino v2 will be worked on to improve the performance of the
|
||||
format and its useability in cryptographic applications.
|
||||
|
||||
|
||||
### PubKey
|
||||
|
||||
Encoding schemes infect software. As a generic middleware, ABCI aims to have
|
||||
@ -143,7 +142,6 @@ where `type` can be:
|
||||
- "ed225519", with `data = <raw 32-byte pubkey>`
|
||||
- "secp256k1", with `data = <33-byte OpenSSL compressed pubkey>`
|
||||
|
||||
|
||||
As we want to retain flexibility here, and since ideally, PubKey would be an
|
||||
interface type, we do not use `enum` or `oneof`.
|
||||
|
||||
|
||||
@ -66,13 +66,10 @@ Make the following changes:
|
||||
|
||||
- More modern and standard cryptographic functions with wider adoption and hardware acceleration
|
||||
|
||||
|
||||
### Negative
|
||||
|
||||
- Exact authenticated encryption construction isn't already provided in a well-used library
|
||||
|
||||
|
||||
### Neutral
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@ -15,11 +15,11 @@ https://github.com/tendermint/tendermint/issues/986.
|
||||
A few solutions were considered:
|
||||
|
||||
1. [Prometheus](https://prometheus.io)
|
||||
a) Prometheus API
|
||||
b) [go-kit metrics package](https://github.com/go-kit/kit/tree/master/metrics) as an interface plus Prometheus
|
||||
c) [telegraf](https://github.com/influxdata/telegraf)
|
||||
d) new service, which will listen to events emitted by pubsub and report metrics
|
||||
5. [OpenCensus](https://opencensus.io/go/index.html)
|
||||
a) Prometheus API
|
||||
b) [go-kit metrics package](https://github.com/go-kit/kit/tree/master/metrics) as an interface plus Prometheus
|
||||
c) [telegraf](https://github.com/influxdata/telegraf)
|
||||
d) new service, which will listen to events emitted by pubsub and report metrics
|
||||
2. [OpenCensus](https://opencensus.io/go/index.html)
|
||||
|
||||
### 1. Prometheus
|
||||
|
||||
@ -70,30 +70,30 @@ will need to write interfaces ourselves.
|
||||
|
||||
### List of metrics
|
||||
|
||||
| | Name | Type | Description |
|
||||
| - | --------------------------------------- | ------- | ----------------------------------------------------------------------------- |
|
||||
| A | consensus_height | Gauge | |
|
||||
| A | consensus_validators | Gauge | Number of validators who signed |
|
||||
| A | consensus_validators_power | Gauge | Total voting power of all validators |
|
||||
| A | consensus_missing_validators | Gauge | Number of validators who did not sign |
|
||||
| A | consensus_missing_validators_power | Gauge | Total voting power of the missing validators |
|
||||
| A | consensus_byzantine_validators | Gauge | Number of validators who tried to double sign |
|
||||
| A | consensus_byzantine_validators_power | Gauge | Total voting power of the byzantine validators |
|
||||
| A | consensus_block_interval | Timing | Time between this and last block (Block.Header.Time) |
|
||||
| | consensus_block_time | Timing | Time to create a block (from creating a proposal to commit) |
|
||||
| | consensus_time_between_blocks | Timing | Time between committing last block and (receiving proposal creating proposal) |
|
||||
| A | consensus_rounds | Gauge | Number of rounds |
|
||||
| | consensus_prevotes | Gauge | |
|
||||
| | consensus_precommits | Gauge | |
|
||||
| | consensus_prevotes_total_power | Gauge | |
|
||||
| | consensus_precommits_total_power | Gauge | |
|
||||
| A | consensus_num_txs | Gauge | |
|
||||
| A | mempool_size | Gauge | |
|
||||
| A | consensus_total_txs | Gauge | |
|
||||
| A | consensus_block_size | Gauge | In bytes |
|
||||
| A | p2p_peers | Gauge | Number of peers node's connected to |
|
||||
| | Name | Type | Description |
|
||||
| --- | ------------------------------------ | ------ | ----------------------------------------------------------------------------- |
|
||||
| A | consensus_height | Gauge | |
|
||||
| A | consensus_validators | Gauge | Number of validators who signed |
|
||||
| A | consensus_validators_power | Gauge | Total voting power of all validators |
|
||||
| A | consensus_missing_validators | Gauge | Number of validators who did not sign |
|
||||
| A | consensus_missing_validators_power | Gauge | Total voting power of the missing validators |
|
||||
| A | consensus_byzantine_validators | Gauge | Number of validators who tried to double sign |
|
||||
| A | consensus_byzantine_validators_power | Gauge | Total voting power of the byzantine validators |
|
||||
| A | consensus_block_interval | Timing | Time between this and last block (Block.Header.Time) |
|
||||
| | consensus_block_time | Timing | Time to create a block (from creating a proposal to commit) |
|
||||
| | consensus_time_between_blocks | Timing | Time between committing last block and (receiving proposal creating proposal) |
|
||||
| A | consensus_rounds | Gauge | Number of rounds |
|
||||
| | consensus_prevotes | Gauge | |
|
||||
| | consensus_precommits | Gauge | |
|
||||
| | consensus_prevotes_total_power | Gauge | |
|
||||
| | consensus_precommits_total_power | Gauge | |
|
||||
| A | consensus_num_txs | Gauge | |
|
||||
| A | mempool_size | Gauge | |
|
||||
| A | consensus_total_txs | Gauge | |
|
||||
| A | consensus_block_size | Gauge | In bytes |
|
||||
| A | p2p_peers | Gauge | Number of peers node's connected to |
|
||||
|
||||
`A` - will be implemented in the fist place.
|
||||
`A` - will be implemented in the fist place.
|
||||
|
||||
**Proposed solution**
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ Due to the requirements of [Minimal Viable Plasma (MVP)](https://ethresear.ch/t/
|
||||
special treatment.
|
||||
|
||||
2. Other "internal" transactions on the child chain, which may be initiated
|
||||
unilaterally. The most basic example of is a coinbase transaction
|
||||
unilaterally. The most basic example of is a coinbase transaction
|
||||
implementing validator node incentives, but may also be app-specific. In
|
||||
these cases, it may be favourable for such transactions to
|
||||
be ordered in a specific manner, e.g., coinbase transactions will always be
|
||||
@ -86,14 +86,14 @@ current proposer is passed to `BeginBlock`.
|
||||
It is much easier to relay these transactions directly to the Root
|
||||
Chain smart contract and/or maintain a "compressed" auxiliary chain comprised
|
||||
of Plasma-friendly blocks that 100% reflect the canonical (Tendermint)
|
||||
blockchain. Unfortunately, this approach not idiomatic (i.e., utilises the
|
||||
blockchain. Unfortunately, this approach not idiomatic (i.e., utilises the
|
||||
Tendermint consensus engine in unintended ways). Additionally, it does not
|
||||
allow the application developer to:
|
||||
|
||||
- Control the _ordering_ of transactions in the proposed block (e.g., index 0,
|
||||
or 0 to `n` for coinbase transactions)
|
||||
or 0 to `n` for coinbase transactions)
|
||||
- Control the _number_ of transactions in the block (e.g., when a `deposit`
|
||||
block is required)
|
||||
block is required)
|
||||
|
||||
Since determinism is of utmost importance in blockchain engineering, this approach,
|
||||
while more viable, should also not be considered as fit for production.
|
||||
@ -163,9 +163,9 @@ Pending
|
||||
|
||||
- Tendermint ABCI apps will be able to function as minimally viable Plasma chains.
|
||||
- It will thereby become possible to add an extension to `cosmos-sdk` to enable
|
||||
ABCI apps to support both IBC and Plasma, maximising interop.
|
||||
ABCI apps to support both IBC and Plasma, maximising interop.
|
||||
- ABCI apps will have great control and flexibility in managing blockchain state,
|
||||
without having to resort to non-deterministic hacks and/or unsafe workarounds
|
||||
without having to resort to non-deterministic hacks and/or unsafe workarounds
|
||||
|
||||
### Negative
|
||||
|
||||
|
||||
@ -9,8 +9,9 @@ handling. An artifact is the dependency of the Switch on
|
||||
`[config.P2PConfig`](https://github.com/tendermint/tendermint/blob/05a76fb517f50da27b4bfcdc7b4cf185fc61eff6/config/config.go#L272-L339).
|
||||
|
||||
Addresses:
|
||||
* [#2046](https://github.com/tendermint/tendermint/issues/2046)
|
||||
* [#2047](https://github.com/tendermint/tendermint/issues/2047)
|
||||
|
||||
- [#2046](https://github.com/tendermint/tendermint/issues/2046)
|
||||
- [#2047](https://github.com/tendermint/tendermint/issues/2047)
|
||||
|
||||
First iteraton in [#2067](https://github.com/tendermint/tendermint/issues/2067)
|
||||
|
||||
@ -29,15 +30,14 @@ transport implementation is responsible to filter establishing peers specific
|
||||
to its domain, for the default multiplexed implementation the following will
|
||||
apply:
|
||||
|
||||
* connections from our own node
|
||||
* handshake fails
|
||||
* upgrade to secret connection fails
|
||||
* prevent duplicate ip
|
||||
* prevent duplicate id
|
||||
* nodeinfo incompatibility
|
||||
- connections from our own node
|
||||
- handshake fails
|
||||
- upgrade to secret connection fails
|
||||
- prevent duplicate ip
|
||||
- prevent duplicate id
|
||||
- nodeinfo incompatibility
|
||||
|
||||
|
||||
``` go
|
||||
```go
|
||||
// PeerTransport proxies incoming and outgoing peer connections.
|
||||
type PeerTransport interface {
|
||||
// Accept returns a newly connected Peer.
|
||||
@ -75,7 +75,7 @@ func NewMTransport(
|
||||
nodeAddr NetAddress,
|
||||
nodeInfo NodeInfo,
|
||||
nodeKey NodeKey,
|
||||
) *multiplexTransport
|
||||
) *multiplexTransport
|
||||
```
|
||||
|
||||
### Switch
|
||||
@ -84,7 +84,7 @@ From now the Switch will depend on a fully setup `PeerTransport` to
|
||||
retrieve/reach out to its peers. As the more low-level concerns are pushed to
|
||||
the transport, we can omit passing the `config.P2PConfig` to the Switch.
|
||||
|
||||
``` go
|
||||
```go
|
||||
func NewSwitch(transport PeerTransport, opts ...SwitchOption) *Switch
|
||||
```
|
||||
|
||||
@ -96,17 +96,17 @@ In Review.
|
||||
|
||||
### Positive
|
||||
|
||||
* free Switch from transport concerns - simpler implementation
|
||||
* pluggable transport implementation - simpler test setup
|
||||
* remove Switch dependency on P2PConfig - easier to test
|
||||
- free Switch from transport concerns - simpler implementation
|
||||
- pluggable transport implementation - simpler test setup
|
||||
- remove Switch dependency on P2PConfig - easier to test
|
||||
|
||||
### Negative
|
||||
|
||||
* more setup for tests which depend on Switches
|
||||
- more setup for tests which depend on Switches
|
||||
|
||||
### Neutral
|
||||
|
||||
* multiplexed will be the default implementation
|
||||
- multiplexed will be the default implementation
|
||||
|
||||
[0] These guards could be potentially extended to be pluggable much like
|
||||
middlewares to express different concerns required by differentally configured
|
||||
|
||||
@ -14,22 +14,23 @@ to easily swap these out.
|
||||
|
||||
### How do we encrypt with AEAD's
|
||||
|
||||
AEAD's typically require a nonce in addition to the key.
|
||||
AEAD's typically require a nonce in addition to the key.
|
||||
For the purposes we require symmetric cryptography for,
|
||||
we need encryption to be stateless.
|
||||
Because of this we use random nonces.
|
||||
Because of this we use random nonces.
|
||||
(Thus the AEAD must support random nonces)
|
||||
|
||||
We currently construct a random nonce, and encrypt the data with it.
|
||||
We currently construct a random nonce, and encrypt the data with it.
|
||||
The returned value is `nonce || encrypted data`.
|
||||
The limitation of this is that does not provide a way to identify
|
||||
which algorithm was used in encryption.
|
||||
Consequently decryption with multiple algoritms is sub-optimal.
|
||||
Consequently decryption with multiple algoritms is sub-optimal.
|
||||
(You have to try them all)
|
||||
|
||||
## Decision
|
||||
|
||||
We should create the following two methods in a new `crypto/encoding/symmetric` package:
|
||||
We should create the following two methods in a new `crypto/encoding/symmetric` package:
|
||||
|
||||
```golang
|
||||
func Encrypt(aead cipher.AEAD, plaintext []byte) (ciphertext []byte, err error)
|
||||
func Decrypt(key []byte, ciphertext []byte) (plaintext []byte, err error)
|
||||
@ -37,18 +38,19 @@ func Register(aead cipher.AEAD, algo_name string, NewAead func(key []byte) (ciph
|
||||
```
|
||||
|
||||
This allows you to specify the algorithm in encryption, but not have to specify
|
||||
it in decryption.
|
||||
it in decryption.
|
||||
This is intended for ease of use in downstream applications, in addition to people
|
||||
looking at the file directly.
|
||||
One downside is that for the encrypt function you must have already initialized an AEAD,
|
||||
but I don't really see this as an issue.
|
||||
but I don't really see this as an issue.
|
||||
|
||||
If there is no error in encryption, Encrypt will return `algo_name || nonce || aead_ciphertext`.
|
||||
If there is no error in encryption, Encrypt will return `algo_name || nonce || aead_ciphertext`.
|
||||
`algo_name` should be length prefixed, using standard varuint encoding.
|
||||
This will be binary data, but thats not a problem considering the nonce and ciphertext are also binary.
|
||||
|
||||
This solution requires a mapping from aead type to name.
|
||||
We can achieve this via reflection.
|
||||
This solution requires a mapping from aead type to name.
|
||||
We can achieve this via reflection.
|
||||
|
||||
```golang
|
||||
func getType(myvar interface{}) string {
|
||||
if t := reflect.TypeOf(myvar); t.Kind() == reflect.Ptr {
|
||||
@ -58,7 +60,8 @@ func getType(myvar interface{}) string {
|
||||
}
|
||||
}
|
||||
```
|
||||
Then we maintain a map from the name returned from `getType(aead)` to `algo_name`.
|
||||
|
||||
Then we maintain a map from the name returned from `getType(aead)` to `algo_name`.
|
||||
|
||||
In decryption, we read the `algo_name`, and then instantiate a new AEAD with the key.
|
||||
Then we call the AEAD's decrypt method on the provided nonce/ciphertext.
|
||||
@ -81,13 +84,16 @@ Proposed.
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
* Allows us to support new AEAD's, in a way that makes decryption easier
|
||||
* Allows downstream users to add their own AEAD
|
||||
|
||||
- Allows us to support new AEAD's, in a way that makes decryption easier
|
||||
- Allows downstream users to add their own AEAD
|
||||
|
||||
### Negative
|
||||
* We will have to break all private keys stored on disk.
|
||||
They can be recovered using seed words, and upgrade scripts are simple.
|
||||
|
||||
- We will have to break all private keys stored on disk.
|
||||
They can be recovered using seed words, and upgrade scripts are simple.
|
||||
|
||||
### Neutral
|
||||
* Caller has to instantiate the AEAD with the private key.
|
||||
However it forces them to be aware of what signing algorithm they are using, which is a positive.
|
||||
|
||||
- Caller has to instantiate the AEAD with the private key.
|
||||
However it forces them to be aware of what signing algorithm they are using, which is a positive.
|
||||
|
||||
@ -22,21 +22,21 @@ Removing this second layer of signature malleability concerns could ease downstr
|
||||
### ECDSA context
|
||||
|
||||
Secp256k1 is ECDSA over a particular curve.
|
||||
The signature is of the form `(r, s)`, where `s` is a field element.
|
||||
The signature is of the form `(r, s)`, where `s` is a field element.
|
||||
(The particular field is the `Z_n`, where the elliptic curve has order `n`)
|
||||
However `(r, -s)` is also another valid solution.
|
||||
Note that anyone can negate a group element, and therefore can get this second signature.
|
||||
|
||||
## Decision
|
||||
|
||||
We can just distinguish a canonical form for the ECDSA signatures.
|
||||
We can just distinguish a canonical form for the ECDSA signatures.
|
||||
Then we require that all ECDSA signatures be in the form which we defined as canonical.
|
||||
We reject signatures in non-canonical form.
|
||||
|
||||
A canonical form is rather easy to define and check.
|
||||
A canonical form is rather easy to define and check.
|
||||
It would just be the smaller of the two values for `s`, defined lexicographically.
|
||||
This is a simple check, instead of checking if `s < n`, instead check `s <= (n - 1)/2`.
|
||||
An example of another cryptosystem using this
|
||||
An example of another cryptosystem using this
|
||||
is the parity definition here https://github.com/zkcrypto/pairing/pull/30#issuecomment-372910663.
|
||||
|
||||
This is the same solution Ethereum has chosen for solving secp malleability.
|
||||
@ -52,10 +52,12 @@ Proposed.
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
* Lets us maintain the ability to expect a tx hash to appear in the blockchain.
|
||||
|
||||
- Lets us maintain the ability to expect a tx hash to appear in the blockchain.
|
||||
|
||||
### Negative
|
||||
* More work in all future implementations (Though this is a very simple check)
|
||||
* Requires us to maintain another fork
|
||||
|
||||
- More work in all future implementations (Though this is a very simple check)
|
||||
- Requires us to maintain another fork
|
||||
|
||||
### Neutral
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
# ADR 015: Crypto encoding
|
||||
# ADR 015: Crypto encoding
|
||||
|
||||
## Context
|
||||
|
||||
We must standardize our method for encoding public keys and signatures on chain.
|
||||
We must standardize our method for encoding public keys and signatures on chain.
|
||||
Currently we amino encode the public keys and signatures.
|
||||
The reason we are using amino here is primarily due to ease of support in
|
||||
parsing for other languages.
|
||||
@ -54,9 +54,11 @@ When placed in state, signatures will still be amino encoded, but it will be the
|
||||
primitive type `[]byte` getting encoded.
|
||||
|
||||
#### Ed25519
|
||||
|
||||
Use the canonical representation for signatures.
|
||||
|
||||
#### Secp256k1
|
||||
|
||||
There isn't a clear canonical representation here.
|
||||
Signatures have two elements `r,s`.
|
||||
These bytes are encoded as `r || s`, where `r` and `s` are both exactly
|
||||
@ -71,10 +73,13 @@ Needs decision on Enum types.
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
* More space efficient signatures
|
||||
|
||||
- More space efficient signatures
|
||||
|
||||
### Negative
|
||||
* We have an amino dependency for cryptography.
|
||||
|
||||
- We have an amino dependency for cryptography.
|
||||
|
||||
### Neutral
|
||||
* No change to public keys
|
||||
|
||||
- No change to public keys
|
||||
|
||||
@ -8,14 +8,14 @@
|
||||
## Changelog
|
||||
|
||||
- 03-08-2018: Updates from discussion with Jae:
|
||||
- ProtocolVersion contains Block/AppVersion, not Current/Next
|
||||
- signal upgrades to Tendermint using EndBlock fields
|
||||
- dont restrict peer compatibilty by version to simplify syncing old nodes
|
||||
- ProtocolVersion contains Block/AppVersion, not Current/Next
|
||||
- signal upgrades to Tendermint using EndBlock fields
|
||||
- dont restrict peer compatibilty by version to simplify syncing old nodes
|
||||
- 28-07-2018: Updates from review
|
||||
- split into two ADRs - one for protocol, one for chains
|
||||
- include signalling for upgrades in header
|
||||
- split into two ADRs - one for protocol, one for chains
|
||||
- include signalling for upgrades in header
|
||||
- 16-07-2018: Initial draft - was originally joint ADR for protocol and chain
|
||||
versions
|
||||
versions
|
||||
|
||||
## Context
|
||||
|
||||
@ -59,18 +59,16 @@ to connect to peers with older version.
|
||||
### BlockVersion
|
||||
|
||||
- All tendermint hashed data-structures (headers, votes, txs, responses, etc.).
|
||||
- Note the semantic meaning of a transaction may change according to the AppVersion,
|
||||
but the way txs are merklized into the header is part of the BlockVersion
|
||||
- Note the semantic meaning of a transaction may change according to the AppVersion, but the way txs are merklized into the header is part of the BlockVersion
|
||||
- It should be the least frequent/likely to change.
|
||||
- Tendermint should be stabilizing - it's just Atomic Broadcast.
|
||||
- We can start considering for Tendermint v2.0 in a year
|
||||
- Tendermint should be stabilizing - it's just Atomic Broadcast.
|
||||
- We can start considering for Tendermint v2.0 in a year
|
||||
- It's easy to determine the version of a block from its serialized form
|
||||
|
||||
### P2PVersion
|
||||
|
||||
- All p2p and reactor messaging (messages, detectable behaviour)
|
||||
- Will change gradually as reactors evolve to improve performance and support new features
|
||||
- eg proposed new message types BatchTx in the mempool and HasBlockPart in the consensus
|
||||
- Will change gradually as reactors evolve to improve performance and support new features - eg proposed new message types BatchTx in the mempool and HasBlockPart in the consensus
|
||||
- It's easy to determine the version of a peer from its first serialized message/s
|
||||
- New versions must be compatible with at least one old version to allow gradual upgrades
|
||||
|
||||
@ -79,10 +77,10 @@ to connect to peers with older version.
|
||||
- The ABCI state machine (txs, begin/endblock behaviour, commit hashing)
|
||||
- Behaviour and message types will change abruptly in the course of the life of a chain
|
||||
- Need to minimize complexity of the code for supporting different AppVersions at different heights
|
||||
- Ideally, each version of the software supports only a *single* AppVersion at one time
|
||||
- this means we checkout different versions of the software at different heights instead of littering the code
|
||||
with conditionals
|
||||
- minimize the number of data migrations required across AppVersion (ie. most AppVersion should be able to read the same state from disk as previous AppVersion).
|
||||
- Ideally, each version of the software supports only a _single_ AppVersion at one time
|
||||
- this means we checkout different versions of the software at different heights instead of littering the code
|
||||
with conditionals
|
||||
- minimize the number of data migrations required across AppVersion (ie. most AppVersion should be able to read the same state from disk as previous AppVersion).
|
||||
|
||||
## Ideal
|
||||
|
||||
@ -125,7 +123,6 @@ serve as a complete description of the consensus-critical protocol.
|
||||
Using the `NextVersion` field, proposer's can signal their readiness to upgrade
|
||||
to a new Block and/or App version.
|
||||
|
||||
|
||||
### NodeInfo
|
||||
|
||||
NodeInfo should include a Version struct as its first field like:
|
||||
@ -150,7 +147,6 @@ it's SemVer version - this is for convenience only. Eg.
|
||||
|
||||
The other versions and ChainID will determine peer compatibility (described below).
|
||||
|
||||
|
||||
### ABCI
|
||||
|
||||
Since the ABCI is responsible for keeping Tendermint and the App in sync, we
|
||||
@ -280,7 +276,6 @@ checking out and installing new software versions and restarting the process. It
|
||||
would subscribe to the relevant upgrade event (needs to be implemented) and call `/unsafe_stop` at
|
||||
the correct height (of course only after getting approval from its user!)
|
||||
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
@ -7,9 +7,9 @@
|
||||
## Changelog
|
||||
|
||||
- 28-07-2018: Updates from review
|
||||
- split into two ADRs - one for protocol, one for chains
|
||||
- split into two ADRs - one for protocol, one for chains
|
||||
- 16-07-2018: Initial draft - was originally joint ADR for protocol and chain
|
||||
versions
|
||||
versions
|
||||
|
||||
## Context
|
||||
|
||||
@ -41,20 +41,19 @@ Peers only connect to other peers with the same NetworkName.
|
||||
|
||||
We need to support existing networks upgrading and forking, wherein they may do any of:
|
||||
|
||||
- revert back to some height, continue with the same versions but new blocks
|
||||
- arbitrarily mutate state at some height, continue with the same versions (eg. Dao Fork)
|
||||
- change the AppVersion at some height
|
||||
- revert back to some height, continue with the same versions but new blocks
|
||||
- arbitrarily mutate state at some height, continue with the same versions (eg. Dao Fork)
|
||||
- change the AppVersion at some height
|
||||
|
||||
Note because of Tendermint's voting power threshold rules, a chain can only be extended under the "original" rules and under the new rules
|
||||
if 1/3 or more is double signing, which is expressly prohibited, and is supposed to result in their punishment on both chains. Since they can censor
|
||||
the punishment, the chain is expected to be hardforked to remove the validators. Thus, if both branches are to continue after a fork,
|
||||
they will each require a new identifier, and the old chain identifier will be retired (ie. only useful for syncing history, not for new blocks)..
|
||||
|
||||
TODO: explain how to handle slashing when chain id changed!
|
||||
TODO: explain how to handle slashing when chain id changed!
|
||||
|
||||
We need a consistent way to describe forks.
|
||||
|
||||
|
||||
## Proposal
|
||||
|
||||
### ChainDescription
|
||||
@ -92,9 +91,9 @@ ChainDescription = <ChainID>/x/<Height>/<ForkDescription>
|
||||
```
|
||||
|
||||
Where
|
||||
- ChainID is the ChainID from the previous ChainDescription (ie. its hash)
|
||||
- `x` denotes that a change occured
|
||||
- `Height` is the height the change occured
|
||||
- ForkDescription has the same form as ChainDescription but for the fork
|
||||
- this allows forks to specify new versions for tendermint or the app, as well as arbitrary changes to the state or validator set
|
||||
|
||||
- ChainID is the ChainID from the previous ChainDescription (ie. its hash)
|
||||
- `x` denotes that a change occured
|
||||
- `Height` is the height the change occured
|
||||
- ForkDescription has the same form as ChainDescription but for the fork
|
||||
- this allows forks to specify new versions for tendermint or the app, as well as arbitrary changes to the state or validator set
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# ADR 019: Encoding standard for Multisignatures
|
||||
|
||||
## Changelog
|
||||
## Changelog
|
||||
|
||||
06-08-2018: Minor updates
|
||||
|
||||
@ -10,9 +10,9 @@
|
||||
|
||||
## Context
|
||||
|
||||
Multisignatures, or technically _Accountable Subgroup Multisignatures_ (ASM),
|
||||
are signature schemes which enable any subgroup of a set of signers to sign any message,
|
||||
and reveal to the verifier exactly who the signers were.
|
||||
Multisignatures, or technically _Accountable Subgroup Multisignatures_ (ASM),
|
||||
are signature schemes which enable any subgroup of a set of signers to sign any message,
|
||||
and reveal to the verifier exactly who the signers were.
|
||||
This allows for complex conditionals of when to validate a signature.
|
||||
|
||||
Suppose the set of signers is of size _n_.
|
||||
@ -22,7 +22,7 @@ this becomes what is commonly reffered to as a _k of n multisig_ in Bitcoin.
|
||||
This ADR specifies the encoding standard for general accountable subgroup multisignatures,
|
||||
k of n accountable subgroup multisignatures, and its weighted variant.
|
||||
|
||||
In the future, we can also allow for more complex conditionals on the accountable subgroup.
|
||||
In the future, we can also allow for more complex conditionals on the accountable subgroup.
|
||||
|
||||
## Proposed Solution
|
||||
|
||||
@ -42,6 +42,7 @@ type ThresholdMultiSignaturePubKey struct { // K of N threshold multisig
|
||||
Pubkeys []crypto.Pubkey `json:"pubkeys"`
|
||||
}
|
||||
```
|
||||
|
||||
We will derive N from the length of pubkeys. (For spatial efficiency in encoding)
|
||||
|
||||
`Verify` will expect an `[]byte` encoded version of the Multisignature.
|
||||
@ -56,7 +57,7 @@ the kth public key on the message.
|
||||
Address will be `Hash(amino_encoded_pubkey)`
|
||||
|
||||
The reason this doesn't use `log_8(n)` bytes per signer is because that heavily optimizes for the case where a very small number of signers are required.
|
||||
e.g. for `n` of size `24`, that would only be more space efficient for `k < 3`.
|
||||
e.g. for `n` of size `24`, that would only be more space efficient for `k < 3`.
|
||||
This seems less likely, and that it should not be the case optimized for.
|
||||
|
||||
#### Weighted threshold signature
|
||||
@ -70,17 +71,19 @@ type WeightedThresholdMultiSignaturePubKey struct {
|
||||
Pubkeys []crypto.Pubkey `json:"pubkeys"`
|
||||
}
|
||||
```
|
||||
|
||||
Weights and Pubkeys must be of the same length.
|
||||
Everything else proceeds identically to the K of N multisig,
|
||||
Everything else proceeds identically to the K of N multisig,
|
||||
except the multisig fails if the sum of the weights is less than the threshold.
|
||||
|
||||
#### Multisignature
|
||||
|
||||
The inter-mediate phase of the signatures (as it accrues more signatures) will be the following struct:
|
||||
|
||||
```golang
|
||||
type Multisignature struct {
|
||||
BitArray CryptoBitArray // Documented later
|
||||
Sigs [][]byte
|
||||
Sigs [][]byte
|
||||
```
|
||||
|
||||
It is important to recall that each private key will output a signature on the provided message itself.
|
||||
@ -88,24 +91,29 @@ So no signing algorithm ever outputs the multisignature.
|
||||
The UI will take a signature, cast into a multisignature, and then keep adding
|
||||
new signatures into it, and when done marshal into `[]byte`.
|
||||
This will require the following helper methods:
|
||||
|
||||
```golang
|
||||
func SigToMultisig(sig []byte, n int)
|
||||
func GetIndex(pk crypto.Pubkey, []crypto.Pubkey)
|
||||
func AddSignature(sig Signature, index int, multiSig *Multisignature)
|
||||
```
|
||||
|
||||
The multisignature will be converted to an `[]byte` using amino.MarshalBinaryBare. \*
|
||||
|
||||
#### Bit Array
|
||||
We would be using a new implementation of a bitarray. The struct it would be encoded/decoded from is
|
||||
|
||||
We would be using a new implementation of a bitarray. The struct it would be encoded/decoded from is
|
||||
|
||||
```golang
|
||||
type CryptoBitArray struct {
|
||||
ExtraBitsStored byte `json:"extra_bits"` // The number of extra bits in elems.
|
||||
ExtraBitsStored byte `json:"extra_bits"` // The number of extra bits in elems.
|
||||
Elems []byte `json:"elems"`
|
||||
}
|
||||
```
|
||||
|
||||
The reason for not using the BitArray currently implemented in `libs/common/bit_array.go`
|
||||
is that it is less space efficient, due to a space / time trade-off.
|
||||
Evidence for this is outlined in [this issue](https://github.com/tendermint/tendermint/issues/2077).
|
||||
Evidence for this is outlined in [this issue](https://github.com/tendermint/tendermint/issues/2077).
|
||||
|
||||
In the multisig, we will not be performing arithmetic operations,
|
||||
so there is no performance increase with the current implementation,
|
||||
@ -122,7 +130,7 @@ Again the implementation of this space saving feature is straight forward.
|
||||
|
||||
### Encoding the structs
|
||||
|
||||
We will use straight forward amino encoding. This is chosen for ease of compatibility in other languages.
|
||||
We will use straight forward amino encoding. This is chosen for ease of compatibility in other languages.
|
||||
|
||||
### Future points of discussion
|
||||
|
||||
@ -133,18 +141,20 @@ Aggregation of pubkeys / sigs in Schnorr sigs / BLS sigs is not backwards compat
|
||||
|
||||
## Status
|
||||
|
||||
Proposed.
|
||||
Proposed.
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
* Supports multisignatures, in a way that won't require any special cases in our downstream verification code.
|
||||
* Easy to serialize / deserialize
|
||||
* Unbounded number of signers
|
||||
|
||||
- Supports multisignatures, in a way that won't require any special cases in our downstream verification code.
|
||||
- Easy to serialize / deserialize
|
||||
- Unbounded number of signers
|
||||
|
||||
### Negative
|
||||
* Larger codebase, however this should reside in a subfolder of tendermint/crypto, as it provides no new interfaces. (Ref #https://github.com/tendermint/go-crypto/issues/136)
|
||||
* Space inefficient due to utilization of amino encoding
|
||||
* Suggested implementation requires a new struct for every ASM.
|
||||
|
||||
- Larger codebase, however this should reside in a subfolder of tendermint/crypto, as it provides no new interfaces. (Ref #https://github.com/tendermint/go-crypto/issues/136)
|
||||
- Space inefficient due to utilization of amino encoding
|
||||
- Suggested implementation requires a new struct for every ASM.
|
||||
|
||||
### Neutral
|
||||
|
||||
@ -6,7 +6,6 @@
|
||||
|
||||
## Status
|
||||
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
Reference in New Issue
Block a user