mirrors/tendermint
1
0
Fork 0
mirror of https://github.com/tendermint/tendermint.git synced 2026-08-19 13:46:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

add more notes

Browse Source
This commit is contained in:
William Banfield
2022-02-25 09:21:00 -05:00
parent 2b94a0be82
commit 81ea318242
1 changed files with 48 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/rfc/rfc-015-tx-replacement.md
+48
View File
@@ -33,3 +33,51 @@
> There is no fixed format for this section, but ideally changes to this
> section should be updated before merging to reflect any discussion that took
> place on the PR that made those changes.
### INITIAL NOTES
* What do we store in the block?
* Just bytes are stored in the block at the moment:
https://github.com/tendermint/tendermint/blob/2b94a0be8273e5f1af2b0b9303eff598adab9c2b/proto/tendermint/types/types.proto
* These appear to be the bytes of the original Tx as broadcast by the user
* double check this assumption
* What do clients query for?
* https://github.com/tendermint/tendermint/blob/2b94a0be8273e5f1af2b0b9303eff598adab9c2b/types/mempool.go
* sha256 hashes are searched for by clients when removing txs
* Where is this hashing done?
https://github.com/tendermint/tendermint/blob/2b94a0be8273e5f1af2b0b9303eff598adab9c2b/internal/mempool/tx.go
* stored in the mempool as sha256 hash
* https://github.com/tendermint/tendermint/blob/2b94a0be8273e5f1af2b0b9303eff598adab9c2b/light/rpc/client.go
* Clients add Txs as a blob of bytes when broadcasting the transaction
* https://github.com/tendermint/tendermint/blob/2b94a0be8273e5f1af2b0b9303eff598adab9c2b/types/events.go
* Search by hash when using the `tx_search` endpoint
* At the moment, there is a 'hash' and 'key' method, both of which do the same thing, but implemented in different libraries
* What would implementing this require?
* From Tendermint Consensus
* Mempool would need to be told what to remove:
* Removed Txs are gossiped via some 2ndary channel
* Application provides deterministic way to map Txs
* Alternatively, blocks would contain the set of Hashes for replaced Txs
* Mechanism for clients to determine if their Tx was executed
* Txs may be removed from the block.
* How can clients know if their Tx was executed?
* From Applications
* Either: we provide a mechanism for applications to gossip what was replaced
* This could be within the block or as part of a secondary mechanism
* Proofs are built off of hashes at the moment
https://github.com/tendermint/tendermint/blob/2b94a0be8273e5f1af2b0b9303eff598adab9c2b/types/tx.go
* From Tendermint p2p
* Either add a secondary channel to broadcast the tx
* add the Tx to the block structure
* This breaks the block structure anyway
* Why might we want to do this?
* Why might my applications want this?
* Applications may want to recombine a set of txs.
* Is there literally any advantage to this over just executing all of Txs?
* What kind of bad behavior does this allow?
* Can you verify that a proposer actually did the substitution correctly?
* what stops a malicious proposer from just selecting Txs is doesn't want
* executed as the substitution?
* Probably not!