[1/x][move] Expose Clock to Move code

[amnn]

Expose a shared object to read time from -- Clock -- that is created during genesis, and an accessor for move. This commit does not introduce the system transaction that updates the timestamp held in this object, so its timestamp will remain at 0, except in tests which are free to increment it.

Also introduces a sui-specific verification rule that entry functions may only accept a Clock by immutable reference (not by value or mutable reference). This is to complement RWLock work:

• RWLock eases contention on shared objects that are read much more often than they are written, but it does not prevent people from taking a mutable reference to the shared object even if they only need to read it.

• Only the system transaction legitimately needs to take the Clock by mutable reference, so the new verification rule prevents the creation of entry functions that could cause unnecessary contention on the Clock, intentionally or otherwise.

• Validators will also prevent the signing of transactions that accept the Clock by mutable reference (excluding the system transaction to update it), as a further precaution -- not part of this commit.

Breaking Changes

• New Sui Framework Module sui::clock,
• New genesis object 0x6: sui::clock::Clock (requires re-genesis).

Test Plan

New verifier and genesis snapshot tests:

sui$ cargo nextest run

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

4 Ignored Deployments

Name	Status	Preview	Comments	Updated
explorer	⬜️ Ignored (Inspect)			Feb 13, 2023 at 5:00PM (UTC)
explorer-storybook	⬜️ Ignored (Inspect)			Feb 13, 2023 at 5:00PM (UTC)
frenemies	⬜️ Ignored (Inspect)			Feb 13, 2023 at 5:00PM (UTC)
wallet-adapter	⬜️ Ignored (Inspect)			Feb 13, 2023 at 5:00PM (UTC)

[bmwill]

RWLock eases contention on shared objects that are read much more often than they are written, but it does not prevent people from taking a mutable reference to the shared object even if they only need to read it.

I haven't followed the discussion around RWLock, but I find i'm having trouble wrapping my head around how such a concept would even work with Sui. Even if you take an object with an immutable reference that object still needs to have its version updated, effectively "mutating" and leading to txns that all access the clock having the requirement that they are serially executed. Of course perhaps this has been relaxed a bit with the discussions around RWLock?

[amnn]

I will need @andll's help to explain how RWLocks get implemented!

[andll]

Even if you take an object with an immutable reference that object still needs to have its version updated, effectively "mutating" and leading to txns that all access the clock having the requirement that they are serially executed.

This was the case previously, where all consensus references were effectively write references (regardless of move argument type).

However, with RWLocks we do not increment object version when transaction specifies that object reference is immutable(via mutable flag) - no new object version is created and transactions referencing same versions can truly execute in parallel. To implement this we leverage MVCC approach where transaction references specific version of an object which resolves concurrent access problem. There are more details in the notion doc (apologies to public who do not have access to mysten notion).

[andll]

The PR looks good in terms of rust changes(which aren't too many), but I'll leave to someone on move team to accept