Create sui-move-diffs.md #693
Conversation
Convert Programming Model doc to Why Sui? page describing differences from core Move
Add links to subsections from summary list
Clay-Mysten
requested review from
lxfind,
awelc,
huitseeker,
sblackshear,
velvia and
666lcz
Needs close review Added reason for no global storage (cost) TODO calls for similar reasoning in each item
Noting module initializers must be private
Renaming title
Renaming title to "How Sui Move differs from Core Move"
Adding white paper and How Sui works to the Conclusion.
Fix silly error in link
| But on-chain storage is expensive and limited (not optimized for storage and indexing). Current blockchains cannot scale to handle storage-heavy applications such as marketplaces and social apps. | ||
|
|
||
| TODO: Review/edit the impetus above and include similar reasoning for each item below. | ||
|
|
||
| So there is no global storage in Sui Move. None of the global storage-related operations are allowed in Sui Move. (We have a bytecode verifier for this to detect violations.) Instead, storage happens exclusively within Sui. When we publish a module, the newly published module is stored in Sui storage, instead of Move storage. Similarly, newly created objects are stored in Sui storage. _This also means that when we need to read an object in Move, we cannot rely on global storage operations but instead Sui must explicitly pass all objects that need to be accessed into Move._ |
There was a problem hiding this comment.
I think the issue with this paragraph is that it speaks about data layout, and that's not really what the problem is. Instead, I think we should reformulate in terms of data access, and tie this with parallel execution & up-to-date-ness requirement on execution.
Why this doesn't quite resonate
Ethereum has a storage model that's fully account-based. Every piece of data is stored in some account storage as well:
https://ethereum.org/en/developers/docs/accounts/#an-account-examined
There is no state outside accounts, so you could say that there's no "globally-stored" data.
Now, scalability issues of blockchains are indeed in some respects due to this storage model, but that's not due to account-centric storage, it's because there's no notion of "just accessing one account" (whether that's for reads, writes, or being up-to date prior to any of those 2 ops). in other terms, you're always "touching global storage" even if the semantics of the operation you are actually performing do much less.
What this could indeed focus on
- object storage is on-chain, but it's independent for each object,
- in particular, there is no need to order operations on one object with respect to all of the others,
- we have an opt-in causal model: if there are needs to order an operation on a target object with respect to updates on a other dependent objects, we ask users to specify those dependents explicitly, and only make sure we're up to date with respect to that handful of dependents, not the whole world.
In other terms, we have parcimonious per-object access.
Then we can explain to storage layout, i.e. flat objects, which is now a deduction from the above difference in approaches.
Does this help?
There was a problem hiding this comment.
Sure. Do you want to send a suggested change to the text? Or work with Xun to refactor this material, since he drafted it?
I'm still working on drafting How Sui Works based upon our meeting Tuesday...
| In Move, there is a special _address_ type. This type is used to represent account addresses in core Move. Core Move needs to know the address of an account when dealing with the global storage. The _address_ type is 16 bytes, which is sufficient for the core Move security model. | ||
|
|
||
| In Sui, since we don’t support global storage in Move, we don’t need the _address_ type to represent user accounts. Instead, we use the _address_ type to represent the Object ID. Refer to the [ID.move](https://github.com/MystenLabs/fastnft/blob/main/sui_programmability/framework/sources/ID.move) file in Sui framework for an understanding of address use. |
There was a problem hiding this comment.
I think this paragraph might go over much more easily once we've explained the notion of ownership. In particular, we could mention something along the lines of:
- ownership in Move is expressed through a storage location, materialized as an account address,
- ownership in Sui is an attribute,
And then we can move on to how we reuse the account address type, which no longer has meaning given our data layout.
... or we could reuse any way of tying this paragraph to the previous one, because it's really a deduction of the difference in storage layouts.
|
|
||
| ## Object with key ability, globally unique IDs | ||
|
|
||
| We need a way to distinguish between objects that are internal to Move and objects that can be passed across the Move-Sui boundary (i.e. objects that can be stored in Sui storage). This is important because we need to be able to serialize/deserialize objects in the Move-Sui boundary, and this process makes assumptions on the shape of the objects. |
There was a problem hiding this comment.
First, could we define what "internal" object are and what they are used for?
We have established in the prior paragraphs that there are "toplevel" objects in Sui, that are the basis of storage and storage access. Those "other" non-key Move objects, are they something the programmer is likely to encounter? In what cases?
Then we explain we'll use the "key" ability to mark those top-level transferrable Sui objects we've been talking about. Cool.
But then conversely, what's the Sui meaning of being non-key? What are the semantics of non-Sui ojbects and what might I use them for?
|
Xun, Francois is seeking clarification and offering to help. |
|
@huitseeker: thanks for this feedback, I think you raise a lot of good points that we can use to improve this section! I think it will take some time to address these points, and my understanding from @Clay-Mysten is that we would like to land this so we can add it to the staging for dev docs. Thus:
|
Convert Programming Model doc to Why Sui? page describing differences from core Move