SIP-37: Exposing ProgrammableTransaction data in TxContext in Move

[thounyy]

No description provided.

[sblackshear]

Thanks for writing this up! One question, would adding a function to TxContext returning a hash that commits to:

• Commands
• Non-gas input object ID's

also satisfy the requirement? This (of course) wouldn't give you the PTB itself on-chain--you'd have to post it elsewhere. But it would expose a lot less of the internal structure of PTBs, which is desirable for a number of reasons (more flexibility to extend/change, smaller protocol footprint, less invitation to write fragile Move code).

[thounyy]

Yes for sure that's an option, only the pure arguments would be missing but I don't think it is a big issue. It also removes the goal of making the proposal human readable but it's not a primary requirement.

[sblackshear]

Ah, I think we can (and probably should) include pure arguments in the hash as well

[thounyy]

bcs serialized then hashed or you're thinking of something else?

[tnowacki]

bcs serialized then hashed or you're thinking of something else?

Pure arguments are simply a series of bytes with no type information, so we would use the bytes as is.
We would likely also just use the Object IDs, but we might maintain some of the object information in the hash, i.e. all of the information present in the argument structure (object ref, shared immutable, shared mutable, etc)

[92GC]

Hello, are there any updates on this? This is a priority for us at @govexdotai. We are building a futarchy as a service protocol on Sui