Quickly recap as there are a lot of words here:
- EIP-3686 CCIP Read
OffchainLookup()
- EIP-5559 Cross Chain Write
StorageHandledByL2()StorageHandledByOffChainDatabase()
- NameSys: Draft 3 (this thread) / Draft 2 / Draft 1
StorageHandledByL2()StorageHandledByDatabase()StorageHandledByIPNS()
- JustaName: Draft
- EIP-129 Signed Data
- EIP-721 Typed Signed Data
My understanding:
-
Contract A: send this signed to here, then tell me
A.setX()→ revert → sign → POST →A.callbackX(response) -
Contract A: hey client, call this on chain C for me, (then tell me?)
A.setX()→ revert →chain(C).sendTx(to: B, request)→A.callbackX()?
For case (1): I could see the need for a challenge, but that’s just doing it multiple times (if you need 2 signatures) or using OffchainLookup first (eg. to acquire a nonce):
Example: setX() → revert OffchainLookup → POST → callback1(response) → revert OffchainWrite → sign → POST → callback2(response)
OffchainWrite() (or whatever) is EIP-5559’s POST {sender, data, signature} but I think the arguments the exactly the same as OffchainLookup() just the client behavior is different: request a signature (+ cancel behavior) + include the signature in the fetch(). Technically, you could just reuse OffchainLookup() with a wrapper on the calldata that indicates “sign me”.
If we’re using EIP-712, we just need a standard for how to make the calldata, for example: setX(a,b,c) should expose typed (a, b, c) to the signer + any intermediates.
For case (2): this should be a separate proposal. Security issues if the transaction invokes prior-approved asset transfer. Probably the function that gets called L2 should be a fixed receiver like offchainWrite() so stuff like transfer() and setApproval() cannot be called at top-level.
I don’t understand how specific storage mechanisms that are invoked using case (1) via a fetchable() gateway are involved. There must be something I’m missing?