SIP-44: Multi-Address Object Usage in Transactions

[Sceat]

Enable transactions to use objects owned by multiple addresses with appropriate signatures

[RandyPen]

What if share object contains legit sender addresses

public struct SomeObject has key, store {
    id: UID,
    allow: vector<address>,
}

[Sceat]

On that game called Dofus, there was a feature where you as an artisan could lend your skills to craft an item for someone if he provides the ingredients.

Translating that to Sui, the SIP would allow

server -> create transaction (and potentially provide his approval through an adminCap if we want to include web2 checks)
server -> send to userA & userB

userA (artisan) -> provide skill/job object
userB (client) -> provide ingredients & payment

server <- receive both signature & execute transaction

userA <- receive payment
userB <- receive crafted Item

With shared objects the artisan would just "publish his workshop" for anyone to craft, that would be fundamentally different since removing the isolation, bot prevention, and social factor.

-> Shared objects are public elements anyone can use
-> Owned objects concerns only their owner or involved parties

While it's probably possible to work around those systems through shared object, you have a clear advantage for

• atomicity
• authorization
• separation of concerns (which is a core point of Sui's dag)

What if share object contains legit sender addresses

That would be a 2-step workaround to a more straightforward concept, like here in the signing idea from your tutorial https://x.com/Sceat_/status/1860368579318976994 this is currently the only one way solution but quite verbose and uncomfortable

[mystenmark]

Thanks for the proposal! This is something we've considered adding for some time. The main stumbling block is this: When there are multiple senders, all senders have to trust all other senders not to equivocate on any of their objects. Equivocation by one sender on one of their own objects could result in all objects referenced by the transaction being locked for the duration of the epoch. This would create a potential attack vector.

The solution to this is some form of "fast unlock". There was a design for adding fast unlock to the current consistent-broadcast based system, but it was quite complicated and we didn't have time to implement it.

Fortunately, as we move to mysticeti fast path (described in section IV of https://arxiv.org/pdf/2310.14821) we will have the opportunity to create a much simpler fast-unlock system. Once we have that, we will definitely consider adding true multi-agent transactions.

[Sceat]

Maybe it would make sense that there is still a single sender, others signers would just delegate their objects the same way a gas sponsor does it 🤔

That attack vector is a good point, I could imagine players using their objects concurrently just to lock others, this would be a functionality to use between servers and users only (like a gas-station), before fast-unlock is a thing

[Sceat]

@mystenmark would you have any idea of timeline for that mysticeti fast path/fast unlock draft ? Is there any capacity in Mysten's teams ? Could we expect such a feature to land next year ?

An alternative for server secured transactions would be #16