fluencelabs/tendermint
1
0
Fork 0
mirror of https://github.com/fluencelabs/tendermint synced 2025-04-24 22:32:15 +00:00
Code Issues Projects Releases Wiki Activity

adr renames (#3622)

Browse Source
This commit is contained in:
Ethan Buchman 2019-05-05 12:42:26 -04:00 committed by GitHub
parent 86f2765b32
commit 4519ef3109
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 17 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
docs/architecture/adr-038-deliver-block.md → docs/architecture/adr-037-deliver-block.md
View File

@ -10,24 +10,24 @@ Author: Daniil Lashin (@danil-lashin)
Initial conversation: https://github.com/tendermint/tendermint/issues/2901 Initial conversation: https://github.com/tendermint/tendermint/issues/2901
Some applications can handle transactions in parallel, or at least some Some applications can handle transactions in parallel, or at least some
part of tx processing can be parallelized. Now it is not possible for developer part of tx processing can be parallelized. Now it is not possible for developer
to execute txs in parallel because Tendermint delivers them consequentially. to execute txs in parallel because Tendermint delivers them consequentially.
## Decision ## Decision
Now Tendermint have `BeginBlock`, `EndBlock`, `Commit`, `DeliverTx` steps Now Tendermint have `BeginBlock`, `EndBlock`, `Commit`, `DeliverTx` steps
while executing block. This doc proposes merging this steps into one `DeliverBlock` while executing block. This doc proposes merging this steps into one `DeliverBlock`
step. It will allow developers of applications to decide how they want to step. It will allow developers of applications to decide how they want to
execute transactions (in parallel or consequentially). Also it will simplify and execute transactions (in parallel or consequentially). Also it will simplify and
speed up communications between application and Tendermint. speed up communications between application and Tendermint.
As @jaekwon [mentioned](https://github.com/tendermint/tendermint/issues/2901#issuecomment-477746128) As @jaekwon [mentioned](https://github.com/tendermint/tendermint/issues/2901#issuecomment-477746128)
in discussion not all application will benefit from this solution. In some cases, in discussion not all application will benefit from this solution. In some cases,
when application handles transaction consequentially, it way slow down the blockchain, when application handles transaction consequentially, it way slow down the blockchain,
because it need to wait until full block is transmitted to application to start because it need to wait until full block is transmitted to application to start
processing it. Also, in the case of complete change of ABCI, we need to force all the apps processing it. Also, in the case of complete change of ABCI, we need to force all the apps
to change their implementation completely. That's why I propose to introduce one more ABCI to change their implementation completely. That's why I propose to introduce one more ABCI
type. type.
# Implementation Changes # Implementation Changes
@ -52,7 +52,7 @@ this doc proposes to add one more:
```go ```go
type Application interface { type Application interface {
// Info and Mempool methods... // Info and Mempool methods...
// Consensus Connection // Consensus Connection
InitChain(RequestInitChain) ResponseInitChain // Initialize blockchain with validators and other info from TendermintCore InitChain(RequestInitChain) ResponseInitChain // Initialize blockchain with validators and other info from TendermintCore
DeliverBlock(RequestDeliverBlock) ResponseDeliverBlock // Deliver full block DeliverBlock(RequestDeliverBlock) ResponseDeliverBlock // Deliver full block
@ -61,9 +61,9 @@ type Application interface {
type RequestDeliverBlock struct { type RequestDeliverBlock struct {
Hash []byte Hash []byte
Header Header Header Header
Txs Txs Txs Txs
LastCommitInfo LastCommitInfo LastCommitInfo LastCommitInfo
ByzantineValidators []Evidence ByzantineValidators []Evidence
} }
@ -71,7 +71,7 @@ type ResponseDeliverBlock struct {
ValidatorUpdates []ValidatorUpdate ValidatorUpdates []ValidatorUpdate
ConsensusParamUpdates *ConsensusParams ConsensusParamUpdates *ConsensusParams
Tags []common.KVPair Tags []common.KVPair
TxResults []ResponseDeliverTx TxResults []ResponseDeliverTx
} }
``` ```
@ -79,7 +79,7 @@ type ResponseDeliverBlock struct {
Also, we will need to add new config param, which will specify what kind of ABCI application uses. Also, we will need to add new config param, which will specify what kind of ABCI application uses.
For example, it can be `abci_type`. Then we will have 2 types: For example, it can be `abci_type`. Then we will have 2 types:
- `advanced` - current ABCI - `advanced` - current ABCI
- `simple` - proposed implementation - `simple` - proposed implementation
## Status ## Status
@ -89,7 +89,7 @@ In review
### Positive ### Positive
- much simpler introduction and tutorials for new developers (instead of implementing 5 methods whey - much simpler introduction and tutorials for new developers (instead of implementing 5 methods whey
will need to implement only 3) will need to implement only 3)
- txs can be handled in parallel - txs can be handled in parallel
- simpler interface - simpler interface

2
docs/architecture/adr-036-validator-set-by-app.md → docs/architecture/adr-041-proposer-selection-via-abci.md
View File

@ -1,4 +1,4 @@
# ADR 036: Application should be in charge of validator set # ADR 041: Application should be in charge of validator set
## Changelog ## Changelog