Use Wrapped Txs
Summary
Linking a given transaction to an intermediate state root is crucial for creating state fraud proofs. When merging shares, some meta data outlined in the spec is needed to link txs and isrs, and should be preserved.
Details
Due to encoding and decoding of Txs and ISRs, swapping them for WrappedTxs and WrappedISRs will be slightly more involved than simply adding the meta data. We will also need some helper functions to aid in finding linked Txs and ISRs.
Action Items
- [ ] Create the proto types for WrappedTxs and WrappedISRs
- [ ] Implement methods to merge into shares
- [ ] Modify current share splitting functions to accommodate new types and meta data
- [ ] Replace usage elsewhere where necessary in celestia-core
- [ ] Create helper functions to find linked transactions and intermediate state roots
References
tracking issue #459
It should be noted that since we are not adding state fraud proofs until after mainnet, the main use for wrapped transactions will be to indicate where a message is located in the block, and not connecting it to an ISR. Although the concept remains the same.
for an easy solution, since we already wrap malleated txs with their original hash, we can simply add the message location to that struct.
Along with the above changes, we will also have to change how we create these wrapped transaction in the app during the PrepareProposal along with a significant refactor to the app's implementation of ProcessProposal.
Can we add a very short ADR for this as well. I'm also wondering what the best way to document this. Maybe the ADR could simply reference and slightly augment the existing spec when describing the decision here?
Can we add a very short ADR for this as well. I'm also wondering what the best way to document this. Maybe the ADR could simply reference and slightly augment the existing spec when describing the decision here?
yeah that's a great idea. The implementation specifically for wrapped txs is very simple, but I agree that an ADR for how/why wrapped txs are used in the app. Specifically their usage when performing message inclusion checks and their involvement in non-interactive defaults