Content
@
0 reply
0 recast
0 reaction
horsefacts
@horsefacts.eth
The great and powerful @ilemi has suggested (strongly, several times) that we tack on cast hash to the frame tx calldata attribution suffix. This adds 20 bytes of extra calldata, but would identify the cast, author, frame, and client that originated a tx. What do you think? Two considerations: Adding more calldata costs a negligible amount more on L2s, a meaningful amount more on L1 Using a cast hash requires joining in other attributes offchain to work out author/frame/client
17 replies
3 recasts
48 reactions
Vladyslav Dalechyn
@dalechyn.eth
the first thought I have that this can be used for onchain FID gateways. the second thought I have that this can be easily manipulated, just add the bytes you want to "fake" at the end of calldata and here you go. can we trust this attribution? the next thought I have that we can make this trusted by having App Clients to sign the attribution data along with the data itself. this would result in 32 bytes (signature suffix) + 20 bytes (attritubion suffix). Since every App Client has a FID, they also have the private key to sign attribution with. Their corresponding addresses derived from the public key can be stored onchain (in a separate contract?) and derived from the "client" stated in the attribution field. so that contracts can: 1. Get the [pos:pos+52] bytes of calldata; 2. Get latest (4?) bytes to retrieve client FID; 3. Get client signer address; 4. Check that ecrecover of signature at[pos:pos+32] matches with signer; 5. Get [pos+32, pos+52] of trusted attribution data.
1 reply
0 recast
2 reactions
Vladyslav Dalechyn
@dalechyn.eth
what i find cool about it is that it can expand outside of frame transactions and expand to having Warpcast, Supercast or other App Client to have a public API to sign messages and thereof build gated experiences outside frames.
0 reply
0 recast
2 reactions
