search

semiotic-ai / timeline-aggregation-protocol

A fast, efficient and trust-minimized unidirectional micro-payments system.
Apache License 2.0
14 stars 3 forks source link

implement RAV and Receipt with EIP-712 #25

Closed ColePBryan closed 1 year ago

ColePBryan commented 1 year ago

Problem to solve:

currently we have to ensure that signers in the AllocationExchange in L1 and L2 do not overlap, or we open up a nasty cross-chain receipt reuse attack. If we can avoid this by including the chain ID in the signed data we remove this risk (and any future potential cross-chain problems) original message from Pablo V.

Currently receipts and RAV's don't know their chain ID, and therefore an indexer could open an allocation with the same allocation ID across multiple chains and submit the same RAV multiple times (same with receipts if we add a feature to allow receipt submission).

Proposed Solution: https://eips.ethereum.org/EIPS/eip-712

EIP-712 solves this problem (as well as some others). Specifically it adds a hash to the message of the type and domain separator. The domain separator contains a ChainID.

This hash would then be added to the message being signed for RAV/Receipt and would tie the message to a specific chainID. The smart contract would then need to implement logic to make sure the RAV/Receipt is intended for the same chainID that the smart contract is deployed on.

Implementing this solution would also resolve #15

ColePBryan commented 1 year ago

Quick analysis: Very little network and space overhead, some compute overhead. Implementation would be relatively simple with some caveats.

Both the indexer and the gateway would be able to generate the 32-byte hash on their own, so there would be no need to send that over network. Alternatively if we wanted to reduce compute we could include it and just take the hit to network. This would only really be very significant during RAV request which is off critical path. (EDIT: There is no choice, this has to be done by both parties to ensure validity)

The implementation would just require separating receipt/RAV from their signatures so the EIP-712 derive function in ethers-rs can be used on the message and signed. The one caveat is because the domain separator is defined as an attribute to the macro it is hard-coded. So in order to allow the library user (i.e. gateway/indexer) to have multiple chain options I think we need to create an impl! macro and predefine what chains are an option. Another approach might be to implement without using derive and make the chainID editable by user. Hopefully there is a better third option that uses derive but gives user full flexibility.

ColePBryan commented 1 year ago

I did a quick implementation of a eip-712 receipt with signing the resulting hash vs the original receipt implementation. Creation takes about 1.8µs longer (~4% increase) and validation takes about 2.3µs longer(~3% increase). This seems like an acceptable hit considering what it gives us.