-
Notifications
You must be signed in to change notification settings - Fork 11.3k
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.
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
[kiosk] Kiosk+ (again) #9709
[kiosk] Kiosk+ (again) #9709
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 3 Ignored Deployments
|
Also includes the changes from #9604 by @nmboavida. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the change overall, but have some questions (inline) on how the witnesses that kiosk actions produce are intended to be used!
crates/sui-framework/packages/sui-framework/sources/collectible/kiosk.move
Outdated
Show resolved
Hide resolved
assert!(object::id(self) == cap.for, ENotOwner); | ||
self.item_count = self.item_count + 1; | ||
dof::add(&mut self.id, Item { id: object::id(&item) }, item) | ||
dof::add(&mut self.id, Item { id: object::id(&item) }, item); | ||
PlacedWitness {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Asking because it popped into my head: Is it worth including the placed item's id
in the witness?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed with Ashok--unless the type in question is a singleton, I think we will always need to remember the ID/check it. Otherwise, it seems hard to avoid issues where someone "reuses" a witness for a different instance of T
(+ hard to reason about what the consequences might be).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ID in the witness won't be much help - we don't have the ID of the item in the TransferRequest so there's no way to compare it. TransferPolicy relies solely on type, and creating IDs everywhere can lead to "abuse of power" on the creator end.
|
||
#[test] | ||
#[expected_failure(abort_code = sui::witness_policy::ERuleNotFound)] | ||
fun test_wrong_proof() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this policy supposed to be used with the witnesses that come from Kiosk
? If so I still don't quite see how we can prevent someone from creating a witness from actions on one instance and then using it as proof on another witness.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question.
Given that TransferPolicy affects all items of a type T, and kiosk witnesses are also returned "typed", only an item of type T can result in KioskWitness. To cheat on this system, one has to put / list another item T. And that is okay.
While implementing I considered two main applications:
-
TransferPolicy has "allow_taking" set to "false". Once placed into the Kiosk, items can't be taken. The only thing that can happen to them is list-sell (simple) or PurchaseCap-grab (more complex). However, we can't lock items in the
purchase
function - its signature ispurchase() :(T, TransferRequest<T>)
. Hence we need to find a way to "force" user to put it into kiosk - and the "PlacedWitness" in the Kiosk allows us to achieve that. -
We issue a "key-only" type, eg
Collectible has key
. To sell the Collectible, we need to turn it into a transferable type "TradableCollectible" - but we need a guarantee that it was listed / placed into the Kiosk. PlacedWitness or ListedWitness again help. Once sold, we can issue a rule for a TransferPolicy which will force theTradableCollectible
to be turned into non-transferable Collectible again.
/// performed (eg item was put back to the `Kiosk` after a sell). | ||
/// | ||
/// Defaults to `true`. | ||
allow_taking: bool |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a specific witness_policy
we can recommend here for someone that wants very strict enforcement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed this part completely in favor of "kiosk::has_item" check. Should be better and more understandable to execute.
assert!(object::id(self) == cap.for, ENotOwner); | ||
self.item_count = self.item_count + 1; | ||
dof::add(&mut self.id, Item { id: object::id(&item) }, item) | ||
dof::add(&mut self.id, Item { id: object::id(&item) }, item); | ||
PlacedWitness {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed with Ashok--unless the type in question is a singleton, I think we will always need to remember the ID/check it. Otherwise, it seems hard to avoid issues where someone "reuses" a witness for a different instance of T
(+ hard to reason about what the consequences might be).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! (@damirka and I chatted offline about paring this down to a minimal feature set, explaining the new red lines)
Description
item: ID
to the TransferRequestmetadata: Bag
as redundant and rather complicated to managetake
functionTest Plan
Type of Change (Check all that apply)
Release notes
Kiosk
andTransferPolicy
modules