Open Lilyjjo opened 9 months ago
amiller
commented
9 months ago I don't see how this would be possible without coordination between the Kettles to implement a distributed counter. Maybe something like ROTE can be suitable and lower latency than Suave chain consensus https://eprint.iacr.org/2017/048.pdf
Lilyjjo
commented
9 months ago Ok this makes sense. I incorrectly keep on trying to program the CCR's off-chain/MEVM half of Suave like it is the on-chain/EVM half. In case it is helpful for future people: it was discussed in tg that Suave does not provide for synchronization or consistency in the off-chain execution environment.
dmarzzz
commented
8 months ago How I explained this issue internally
pistomat
commented
6 months ago Ok this makes sense. I incorrectly keep on trying to program the CCR's off-chain/MEVM half of Suave like it is the on-chain/EVM half. In case it is helpful for future people: it was discussed in tg that Suave does not provide for synchronization or consistency in the off-chain execution environment.
@Lilyjjo Is that tg public? Can you provide link?
Thanks a lot for this PSA.
I am confused on how to ensure that confidential compute requests (CCRs) only use a piece of state once.
Rationale
It would be useful for suave developers to know if a piece of state has been consumed by a CCR already.
Take the use case of trying to create and send transactions to an L1 using a singular private key. The suapp stores the private key in the confidential store so this operation must be ran in a CCR. Each transaction needs a unique and continuously increasing nonce to sign over. The question is: where can we store this nonce so CCRs can be triggered permissionlessly?
Option 1: Put the nonce on-chain and increment it during CCR callbacks. \ Issue: What happens if multiple CCRs are sent per on-chain block? In this case, the on-chain nonce would be used multilpe times and CCRs would fail to have their logic execute as intended.
Option 2: Put the nonce in the confidential store. \ Issue: What happens if two kettles get a CCR at the same time? How do the CCRs coordinate around the race condition of consuming and updating the confidential store?
Option 3: Have the user pass it in. \ Issue: Similar race condition to (1)/(2) and additional greifing attack vector of users intentionally submitting wrong nonces.
Option 4: Put the nonce in the confidential store and restrict the Suapp to a single kettle to avoid the race conditions. \ Issue: this is not decentralized enough for some applications.
Ask
Is there another solution that I'm not considering?
I'm working on an application and would like to have data stored somewhere that can be safely and permissonlessly acted on by multiple kettles inside of CCRs.