8000 SIP-16: Add more tx_context by EasonC13 · Pull Request #16 · sui-foundation/sips · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

SIP-16: Add more tx_context #16

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

< 8000 div class="flex-auto text-right d-block d-md-none"> Jump to bottom
Merged
merged 10 commits into from
Nov 6, 2024
Merged

SIP-16: Add more tx_context #16

merged 10 commits into from
Nov 6, 2024

Conversation

EasonC13
Copy link
Contributor
@EasonC13 EasonC13 commented Jan 20, 2024 •
edited by wriches
Loading

No description provided.

sblackshear
sblackshear reviewed Jan 21, 2024
View reviewed changes
sips/sip-temporary_title.md Outdated

`tx_context::is_signed_by(ctx, address)` return `boolean`.

`tx_context::signers(ctx)` return `vector<address>`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of edge cases to think about here:

  • What order does it return the addresses in? I would vote for gas sender last, but it doesn't matter as long as it's clear/consistent
  • This should always consist of distinct addresses, right

Copy link
Contributor Author
@EasonC13 EasonC13 Jan 21, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What order does it return the addresses in?

At SDK, When we run executeTransactionBlock we pass in signatures as an array. Maybe the order can be the same as the array.

Or just ascending/descending order.

result = await suiClient.executeTransactionBlock({
        transactionBlock: sponsorSignedTxBlockBytes,
        signature: [sponsorSignature, clientSignature],
        options: {
          showEffects: true,
          showEvents: true,
          showObjectChanges: true,
        },
      });

@longbowlu
Copy link

Therefore, we aim to delete objects that have been sponsored to create by us in order to collect storage rebates and prevent individuals from abusing sponsored transactions to create objects with sponsor and then deleting them using their own addresses to get rebate from sponsor.

Could you elaborate on how these new context would be used to achieve this motivation? an example function will be very helpful. thanks

@admin-aftermath
Copy link
Contributor
admin-aftermath commented Jan 21, 2024 •
edited
Loading

The ability to retrieve the signer (or signers) is something we have been looking for as well!

Could you elaborate on how these new context would be used to achieve this motivation?

I assume a flow like this would get their job done:

// During creation
if (is_sponsored(...)) {
    set_creator(OBJECT, option::some(SPONSOR));
} else {
    set_creator(OBJECT, option::none());
};

// During deletion
if (option::is_some(creator(OBJECT))) {
    assert(option::extract(creator(OBJECT)) == tx_context::sender(ctx), EInvalidSender);
};

@EasonC13
Copy link
Contributor Author

The ability to retrieve the signer (or signers) is something we have been looking for as well!

Could you elaborate on how these new context would be used to achieve this motivation?

I assume a flow like this would get their job done:

// During creation
if (is_sponsored(...)) {
    set_creator(OBJECT, option::some(SPONSOR))
} else {
    set_creator(OBJECT, option::none())
}

// During deletion
if (option::is_some(creator(OBJECT))) {
    assert(option::extract(creator(OBJECT)) == tx_context::sender(ctx), EInvalidSender
}

Thank you, that is a good example

@lxfind
Copy link
lxfind commented Jan 30, 2024

I would probably name the "gas_sender" function "gas_owner" instead, but otherwise, the new list of APIs sounds reasonable to me.

@EasonC13
Copy link
Contributor Author

I would probably name the "gas_sender" function "gas_owner" instead, but otherwise, the new list of APIs sounds reasonable to me.

Agreed, gas_owner is better.

@nathanramli
Copy link

Is there a scenario where multiple signers, aside from the sender and gas_owner, might be involved?

@EasonC13
Copy link
Contributor Author
EasonC13 commented Feb 5, 2024

Is there a scenario where multiple signers, aside from the sender and gas_owner, might be involved?

Yes if we use multisig feature:

https://docs.sui.io/concepts/cryptography/transaction-auth/multisig

@lxfind
Copy link
lxfind commented Feb 5, 2024

Yes if we use multisig feature

Note that even with multisig, there is still one sender address which is the combined address.
Today we only support at most two signers in a transaction, the sender and gas owner.

@SA124
Copy link
Contributor
SA124 commented Feb 6, 2024

@EasonC13

Thanks for your SIP proposal. In order to process the SIP, the SIP Editor requires write access to the forked repository in order to change the status and add additional information.

Could you please grant write access on the forked repository to the following GitHub accounts?

SA124
hyd628

Once this has been completed, we can move the proposal forward.

Best regards,
Shereen

@EasonC13
Copy link
Contributor Author
EasonC13 commented Feb 6, 2024

@EasonC13

Thanks for your SIP proposal. In order to process the SIP, the SIP Editor requires write access to the forked repository in order to change the status and add additional information.

Could you please grant write access on the forked repository to the following GitHub accounts?

SA124 hyd628

Once this has been completed, we can move the proposal forward.

Best regards, Shereen

Invite sent.

@nathanramli
Copy link

Yes if we use multisig feature

Note that even with multisig, there is still one sender address which is the combined address. Today we only support at most two signers in a transaction, the sender and gas owner.

Yes, this is what I meant. Even if we can obtain the list of signers, the sender and the signers could be different. The sender isn't necessarily a signer, although currently, we treat the sender as a signer.

@tnowacki
Copy link
tnowacki commented Feb 22, 2024 •
edited
Loading

Just as a quick update, we plan on adding gas_sender, but are still debating some of the details for something like is_signed_by or signers. We definitely could see something like those APIs landing though!

hyd628
hyd628 reviewed Mar 6, 2024
View reviewed changes
Copy link
Member
@hyd628 hyd628 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Moving to Review status.

hyd628
hyd628 previously approved these changes Mar 6, 2024
View reviewed changes
@wriches wriches dismissed hyd628’s stale review March 6, 2024 23:59

SIP not yet finalised

@EasonC13
Copy link
Contributor Author
EasonC13 commented Apr 6, 2024

Hi, want to know the follow up about this.

@wriches wriches added the active Active SIPs that are either in Draft, Review, Fast Track or Last Call status. label May 1, 2024
@wriches wriches changed the title More tx_context in Move Smart Contract SIP-16: Add more tx_context May 1, 2024
@wriches wriches added stagnant SIPs that have been inactive for a long period of time. Can be revived by the SIP Author. and removed active Active SIPs that are either in Draft, Review, Fast Track or Last Call status. labels Aug 8, 2024
@wriches
Copy link
Member
wriches commented Aug 8, 2024

Status changed to Stagnant due to inactivity. The SIP can be revived at a later date.

@wriches wriches closed this Aug 8, 2024
@Euraxluo
Copy link

I would like to ask if you can add a signature, such as zklogin for a special identity

@wriches wriches reopened this Nov 6, 2024
@wriches wriches added withdrawn SIPs that have been officially withdrawn. and removed stagnant SIPs that have been inactive for a long period of time. Can be revived by the SIP Author. labels Nov 6, 2024
@wriches wriches merged commit 4ea8401 into sui-foundation:main Nov 6, 2024
@wriches
Copy link
Member
wriches commented Nov 6, 2024

SIP withdrawn due to delay. A new SIP can be resubmitted in the future.

@Sceat
Copy link
Sceat commented Nov 21, 2024

What would be needed to land this SIP ? @wriches what do you mean by delay ?

@Sceat
Copy link

@EasonC13 maybe you could re-submit the SIP ?

@Sceat Sceat mentioned this pull request Dec 2, 2024
Open
@Sceat Sceat mentioned this pull request Jun 15, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@sblackshear sblackshear sblackshear left review comments

@wriches wriches wriches approved these changes

@hyd628 hyd628 hyd628 left review comments

Assignees
No one assigned
Labels
withdrawn SIPs that have been officially withdrawn.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
0