dtebbs
commented
3 years ago Note that, if nested transactions were identified by, say, the hash of their data (as it appears in the wrapping transaction), and the dispatcher contract emitted events with the id of each nested transaction, the above issue of a confused receiver may be less relevant. Since the 2 duplicate nested transactions in the example above would have the same nested tx id, and this would not be maleable (by assumption on the application protocol), a sender could tell the receiver to listen for a specific nested tx id via the dispatcher events.
In the case above of duplicates being sent with different proofs, the receiver would see the nested tx id appear twice (unless some filtering were implemented in the dispatcher) where the second instance would fail (assuming that the application implements the appropriate protection). In most cases, this should be fairly easy for a client app / wallet to deal with.
However, this still provides the application implementor with the problem of having to provide 2 differet forms of malleability protection. One for zeth (in which the proof is not seen by the contract) and one for calls to the application contract from regular Ethereum transactions.
In general, application protocols such as Zeth will want to prevent: 1) tx malleability by observers (msg.sender + ETH signature, ciphertexts) 2) front-running (msg.sender) 3) malleability by the sender (all inputs + proof)
(3) requires that proof data (or some derivatve of it) is available to the application contract. Otherwise, a malicious sender willing to spend the compute resources can create 2 proofs for the same public inputs, and hence 2 tx ids for the same application transaction. (In particular, in the case of Zeth, if the proof data is not included in the signature
sigma, a malicious sender could create 2 proofs and sign 2 transactions such that all public inputs, ot-sig public key, os-sig signaturesigmaand ciphertexts, are the same in both transactions.)However, Zecale applications do not currently have access to the proof data.
This is not necessarily a critical issue, but it appears to conflict with the original motivation behind the inclusion of the proof in the OT signature in the Zeth protocol.
When using Zecale, this translates to the senders ability to either include 2 equivalent transactions in a single batch (the duplication will probably not be noticed by the receiver), or to create 2 equivalent transactions each of which is included in a different batch (in which case, a receiver expecting a nested transaction to be applied as part of a specific batch may be confused). Depending on the setting, this 2nd case may also be considered a non-issue, since there is actually no concept of
nested tx id.Possible solutions:
1) Require that applications DO NOT protect against proof maleability when used with Zecale. Either: a) The application does not protect against proof-maleability at all. b) The application distinguishes between the case of regular transactions (which DO protect against proof maleability), and
dispatchcalls via Zecale (in which protection is NOT provided). (In Zeth, this equates to 2 different signature creation and evaluation methods)a2) Provide the HASH of the proof to the application, and extend the wrapped zk-proof statement to show that the hash is correct. Applications can then implement protection against proof malleability. (In Zeth, this would mean including the proof hash instead of the raw proof data in the signature
sigma)Related to this (and possibly more fundamentally) we do not have a standard way to uniquely identify nested transactions (equivalent to txid), which would allow the aggregator to inform the zecale client which batch contains a specific nested tx.