Async chain state transition using messages

[Quintus]

Great post! I’m really happy we’re thinking about how info leakage works. Sorry I’m slow to the party - missed this somehow.

Two observations about the implications of the decisions we are making now:

• one function calling another, may want to control what information is emitted during the subcall. (E.g. in the M.O.S.S. idea the build() function needs to know info isn’t being leaked by the bundle function

• by processing SUAVE chain state transitions based on TEE signatures (verified pre-contract execution as opposed to by the contracts themselves), we are giving the whole of suave-chain the same security guarantees as a TEE. This might be fine and something we choose to do for computational efficiency reasons, but it certainly has tradeoffs. If we let these TEE signatures be verified at the application layer then apps could choose whether to rely on that security model or not.

@mateusz

we can rename it back to onchain and make it return the event that is supposed to be emitted, and have the user emit it.

This makes sense to me. I don’t see why we should break the abstraction of “info leaving the TEE” by providing different routes for info to leave the TEE.

@mateusz

You can deploy contracts from confidential transactions, since adding the to address is trivial

this feels like there’s some hidden cool competitive dynamics that can come from this