github.com/badrootd/nibiru-cometbft@v0.37.5-0.20240307173500-2a75559eee9b/docs/architecture/adr-037-deliver-block.md (about) 1 # ADR 037: Deliver Block 2 3 Author: Daniil Lashin (@danil-lashin) 4 5 ## Changelog 6 7 13-03-2019: Initial draft 8 9 ## Context 10 11 Initial conversation: https://github.com/tendermint/tendermint/issues/2901 12 13 Some applications can handle transactions in parallel, or at least some 14 part of tx processing can be parallelized. Now it is not possible for developer 15 to execute txs in parallel because Tendermint delivers them consequentially. 16 17 ## Decision 18 19 Now Tendermint have `BeginBlock`, `EndBlock`, `Commit`, `DeliverTx` steps 20 while executing block. This doc proposes merging this steps into one `DeliverBlock` 21 step. It will allow developers of applications to decide how they want to 22 execute transactions (in parallel or consequentially). Also it will simplify and 23 speed up communications between application and Tendermint. 24 25 As @jaekwon [mentioned](https://github.com/tendermint/tendermint/issues/2901#issuecomment-477746128) 26 in discussion not all application will benefit from this solution. In some cases, 27 when application handles transaction consequentially, it way slow down the blockchain, 28 because it need to wait until full block is transmitted to application to start 29 processing it. Also, in the case of complete change of ABCI, we need to force all the apps 30 to change their implementation completely. That's why I propose to introduce one more ABCI 31 type. 32 33 # Implementation Changes 34 35 In addition to default application interface which now have this structure 36 37 ```go 38 type Application interface { 39 // Info and Mempool methods... 40 41 // Consensus Connection 42 InitChain(RequestInitChain) ResponseInitChain // Initialize blockchain with validators and other info from TendermintCore 43 BeginBlock(RequestBeginBlock) ResponseBeginBlock // Signals the beginning of a block 44 DeliverTx(tx []byte) ResponseDeliverTx // Deliver a tx for full processing 45 EndBlock(RequestEndBlock) ResponseEndBlock // Signals the end of a block, returns changes to the validator set 46 Commit() ResponseCommit // Commit the state and return the application Merkle root hash 47 } 48 ``` 49 50 this doc proposes to add one more: 51 52 ```go 53 type Application interface { 54 // Info and Mempool methods... 55 56 // Consensus Connection 57 InitChain(RequestInitChain) ResponseInitChain // Initialize blockchain with validators and other info from TendermintCore 58 DeliverBlock(RequestDeliverBlock) ResponseDeliverBlock // Deliver full block 59 Commit() ResponseCommit // Commit the state and return the application Merkle root hash 60 } 61 62 type RequestDeliverBlock struct { 63 Hash []byte 64 Header Header 65 Txs Txs 66 LastCommitInfo LastCommitInfo 67 ByzantineValidators []Evidence 68 } 69 70 type ResponseDeliverBlock struct { 71 ValidatorUpdates []ValidatorUpdate 72 ConsensusParamUpdates *ConsensusParams 73 Tags []kv.Pair 74 TxResults []ResponseDeliverTx 75 } 76 77 ``` 78 79 Also, we will need to add new config param, which will specify what kind of ABCI application uses. 80 For example, it can be `abci_type`. Then we will have 2 types: 81 - `advanced` - current ABCI 82 - `simple` - proposed implementation 83 84 ## Status 85 86 In review 87 88 ## Consequences 89 90 ### Positive 91 92 - much simpler introduction and tutorials for new developers (instead of implementing 5 methods whey 93 will need to implement only 3) 94 - txs can be handled in parallel 95 - simpler interface 96 - faster communications between Tendermint and application 97 98 ### Negative 99 100 - Tendermint should now support 2 kinds of ABCI