hdevalence
commented
4 months ago Hmm, the reason that the chain ID is included in the transaction is so that the auth sigs can sign over it and bind to the correct network.
If I'm understanding correctly, the idea is that the chain could instead slot its own data of what the chain ID should be in during verification time rather than having it be included in the tx and then checked against the state?
This was actually something we designed against: we wanted to construct Penumbra transactions so that they always include all the data necessary to check all proofs and signatures. This allows us to do all those checks statelessly and in parallel well in advance of any queries to the chain state. It also means we can do "preflight" checks on standalone Txs client side. There are actually other places where we have even more wasteful duplication of public inputs (eg the batchswapoutputdata for a swap claim).
Longer term I'd prefer to keep transactions as standalone blobs but reduce bandwidth by moving to systems that gossip hashes, etc., which feels like a more powerful solution.
ValarDragon
The ChainID gets serialized in bandwidth for every transaction
This arguably would get handled if the p2p layers has context-aware compression, but right now as far as I can tell the chain ID gets serialized into every TransactionBody in TransactionParameters. You see its included here which is included in every tx body here
In a future version, this doesn't need to be in the p2p layer, as it gets authenticated by checking the tx signature. In the SDK there is two different versions of transactions, a gossip version, that can be converted into the signing data.
This seems super low priority, and may never be worth the client break, vs getting smarter p2p layer compression.