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

[mystenmark]

Sorry I missed the notification here - mysticeti fast path is being implemented now - we don't know exactly when it will be done but it's a high priority item for us.

[mystenmark]

I think there are a few questions that require some thought:

• Does this have any "soft" security issues? For instance, does it enable scammers? Imagine someone getting tricked into co-signing a transaction that appears to be safe during preview/dry-run, but then triggers different behavior when it executes for real and takes all the victim's objects?
• The sender field of the transaction will have to be a singular address. How do we choose which address? Does picking one address or the other to be the primary sender privilege that party over the other somehow?

[Sceat]

Does this have any "soft" security issues? For instance, does it enable scammers? Imagine someone getting tricked into co-signing a transaction that appears to be safe during preview/dry-run, but then triggers different behavior when it executes for real and takes all the victim's objects?

A wallet is supposed to show the moving of tokens and objects when requiring the signature ? I assume this is rather UX side

The sender field of the transaction will have to be a singular address. How do we choose which address? Does picking one address or the other to be the primary sender privilege that party over the other somehow?

The sender should stay whoever is specified as the sender, could be the initiator of the transaction. This SIP can be regarded as multiple peoples sponsoring a transaction with their own objects.

There are functions which are rewarding the sender of a transaction like withdrawing or claiming something, but then it would also show on the wallet dryrun.

[Sceat]

Hello @mystenmark, wondering if there is any update on the feasibility of the SIP ? :)

[Sceat]

@mystenmark nothing new so far ?

[mystenmark]

With the recent release of Party Objects https://docs.sui.io/concepts/object-ownership/party there is actually a way around the equivocation issues I mentioned earlier, which is probably the biggest issue.

Let me ask around internally and see what people think

[Sceat]

@mystenmark since this Sip might be difficult to add, could you please look into #58, it's the only viable alternative to enforce web2 logic on sui modules

Also made a thread on twitter with more examples, to try and bring more attention in here https://x.com/Sceat_/status/1983403407542235470

[mystenmark]

#58 does seem promising.

Anyway, we all agree this SIP would be great. But the security issues are a bit scary. Party objects, which would remedy the equivocation issues discussed above, have other gotchyas. For instance, I can send you a tx in which it appears that we swap two coin objects with each other. We both sign it. But, before it executes, I send another tx that drains my coin. Now the swap executes, and you get nothing. (This is possible because the states of party objects are not committed to by the transaction).

There are ways to fix this. For instance, in the swap case, you would want to use a SplitCoin command to prove that a given amount can be taken from the input coin. Then the transaction would abort if the inputs had been drained. But this only helps if wallets alert users that the transaction might be unsafe.

I don't think anything here is insurmountable, but this hopefully explains why we haven't been dashing ahead to ship this.

[Sceat]

I'm not sure if it make sense but conceptually the SIP would apply mostly (eventually not limited to?) simple owned object without consensus, it would concern only the parties involved and equivocation is important here.

Indeed using Party objects will solve one "problem" by introducing another :D since any tx will get executed in order instead of equivocated.

The first attack vector seems better to me than that new one, I would need to think about more example but in the case of an atomic exchange, if a malicious user causes equivocation, the server will know and can ban the user, if there is no server then the user itself will avoid trading with that specific user, that is a direct incentive of not causing harm.

Since the purpose of this SIP is to allow different entities to execute actions together as a trusted group, we could conceptually assume that bad actors CAN cause harm but doing so will jail them away from the group/system.

Any usecase involving dealing with unsafe users or in a fully public trustless environment with complete strangers is most likely better off using shared objects as usual.

Multi tenant transactions is a step forward more transparency and reducing the required trust for specific actions in a known and trusted environment, but not a replacement for shared or party objects which are more powerful to completely remove the need for trust.

Maybe those thoughts are invalid on a security/global standpoint tho