From fac6020540b1d87e83c964741145514890189c1b Mon Sep 17 00:00:00 2001 From: ArielElp Date: Mon, 12 Jun 2023 20:23:27 +0300 Subject: [PATCH 01/10] add contract syntax page --- .../pages/Contracts/contract-syntax.adoc | 221 ++++++++++++++++++ 1 file changed, 221 insertions(+) create mode 100644 components/StarkNet/modules/architecture_and_concepts/pages/Contracts/contract-syntax.adoc diff --git a/components/StarkNet/modules/architecture_and_concepts/pages/Contracts/contract-syntax.adoc b/components/StarkNet/modules/architecture_and_concepts/pages/Contracts/contract-syntax.adoc new file mode 100644 index 0000000000..584e1b755b --- /dev/null +++ b/components/StarkNet/modules/architecture_and_concepts/pages/Contracts/contract-syntax.adoc @@ -0,0 +1,221 @@ +# Cairo 1 Contract Syntax + +With the link:https://github.com/starkware-libs/cairo/releases/tag/v2.0.0-rc0[v2.0.0 release] of the Cairo compiler, the contract syntax has evolved. +This affects how external functions, storage, and events are organized inside the contract. We summarize here the technical steps required to migrate from the old syntax +(for a comperhensive treatment of the changes, see the link:https://community.starknet.io/t/cairo-1-contract-syntax-is-evolving/94794[community forum post]). + +## How do I migrate + +Given a contract written with the previous compiler version (v1.1.0), you can follow the steps below in order to make it compatible with the new syntax: + +* Anotate the `Storage` struct with the `#[storage]` attribute + +[tabs] +==== +old:: ++ +[source,rust] +---- +struct Storage { + counter: u128, + other_contract: IOtherContractDispatcher +} +---- +new:: ++ +[source,rust] +---- +#[storage] +struct Storage { + counter: u128, + other_contract: IOtherContractDispatcher +} +---- +==== + +* Gather your contract’s external/view function signatures under a trait anotated with `#[starknet::interface]` +** Add a generic parameter to the trait, here we use the name `TContractState` as it stands for the state of your contract +** For view functions, add the `self: TContractState` argument +** For external functions, add the `self: @TContractState` argument +** Static functions that do not touch storage or emit events do not require an addition argument + +[tabs] +==== +old:: ++ +[source,rust] +---- +#[contract] +mod CounterContract { + #[external] + fn increase_counter(amount: u128) { ... } + #[external] + fn decrease_counter(amount: u128) { ... } + #[view] + fn get_counter() -> u128 { ... } +} +---- + +new:: ++ +[source,rust] +---- +#[starknet::interface] +trait ICounterContract { + fn increase_counter(ref self: TContractState, amount: u128); + fn decrease_counter(ref self: TContractState); + fn get_counter(self: @TContractState) -> u128; +} + +#[starknet::contract] +mod CounterContract { + ... +} +---- +==== + +* Replace the `#[abi]` attribute with `#[starknet::interface]` (while it doesn't affecting the generated code, we recommended adding to the trait a generic parameter `T` representing the contract's state, +and adding the `ref self: T` argument to external functions and `self: @T` argument for view functions) + +[tabs] +==== +old:: ++ +[source,rust] +---- +#[abi] +trait IOtherContract { + fn decrease_allowed() -> bool; +} +---- +new:: ++ +[source,rust] +---- +#[starknet::interface] +trait IOtherContract { + fn decrease_allowed(self: @TContractState) -> bool; +} +---- +==== + +* Add the external/view function bodies under an impl of the above trait, and mark the impl with the `[external(v0)]` attribute + +[tabs] +==== +old:: ++ +[source,rust] +---- +#[contract] +mod CounterContract { + #[external] + fn increase_counter(amount: u128) { ... } + #[external] + fn decrease_counter(amount: u128) { ... } + #[view] + fn get_counter() -> u128 { ... } +} +---- + +new:: ++ +[source,rust] +---- +#[starknet::interface] +trait ICounterContract { + fn increase_counter(ref self: TContractState, amount: u128); + fn decrease_counter(ref self: TContractState); + fn get_counter(self: @TContractState) -> u128; +} + +#[starknet::contract] +mod CounterContract { + #[external(v0)] + impl CounterContract of super::ICounterContract { + fn increase_counter(amount: u128) { ... } + fn decrease_counter(amount: u128) { ... } + fn get_counter() -> u128 { ... } + } +} +---- +==== + +* Modify storage accesses to happen through `ContractState` or `@ContractState` (none external functions in the contract that access storage also need to get it as an argument) + +[tabs] +==== +old:: ++ +[source,rust] +---- +let current = counter::read(); +---- +new:: ++ +[source,rust] +---- +let current = self.counter.read(); +---- +==== + +* Unify all the contract's events under the `Event` enum, and add a corresponding struct for every variant (all the structs must derive the `Event` trait, +and each member type has to implement the `Serde` trait) + +[tabs] +==== +old:: ++ +[source,rust] +---- +#[event] +fn counter_increased(amount: u128) {} +#[event] +fn counter_decreased(amount: u128) {} +---- +new:: ++ +[source,rust] +---- +#[event] +#[derive(Drop, starknet::Event)] +enum Event { + CounterIncreased: CounterIncreased, + CounterDecreased: CounterDecreased +} + +#[derive(Drop, starknet::Event)] +struct CounterIncreased { + amount: u128 +} + +#[derive(Drop, starknet::Event)] +struct CounterDecreased { + amount: u128 +} +---- +==== + +* Emit events via the `ContractState` type + +[tabs] +==== +old:: ++ +[source,rust] +---- +fn increase_counter(amount: u128) { + ... + counter_increased(amount); +} +---- +new:: ++ +[source,rust] +---- +fn increase_counter(amount: u128) { + ... + self.emit(Event::CounterIncreased(CounterIncreased { amount })); +} +---- +==== From f829428a1f7b2a974f82db5051c4d59560843c4f Mon Sep 17 00:00:00 2001 From: ArielElp Date: Mon, 12 Jun 2023 22:57:28 +0300 Subject: [PATCH 02/10] add subtitles --- .../pages/Contracts/contract-syntax.adoc | 90 +++++++++++-------- .../architecture_and_concepts/nav.adoc | 1 + 2 files changed, 54 insertions(+), 37 deletions(-) diff --git a/components/StarkNet/modules/architecture_and_concepts/pages/Contracts/contract-syntax.adoc b/components/StarkNet/modules/architecture_and_concepts/pages/Contracts/contract-syntax.adoc index 584e1b755b..b6a50c603b 100644 --- a/components/StarkNet/modules/architecture_and_concepts/pages/Contracts/contract-syntax.adoc +++ b/components/StarkNet/modules/architecture_and_concepts/pages/Contracts/contract-syntax.adoc @@ -4,11 +4,13 @@ With the link:https://github.com/starkware-libs/cairo/releases/tag/v2.0.0-rc0[v2 This affects how external functions, storage, and events are organized inside the contract. We summarize here the technical steps required to migrate from the old syntax (for a comperhensive treatment of the changes, see the link:https://community.starknet.io/t/cairo-1-contract-syntax-is-evolving/94794[community forum post]). -## How do I migrate +## New contract syntax - concrete steps for migrating -Given a contract written with the previous compiler version (v1.1.0), you can follow the steps below in order to make it compatible with the new syntax: +Given a contract written with the previous compiler version (v1.1.0), you can follow the steps below in order to make it compatible with the new syntax. -* Anotate the `Storage` struct with the `#[storage]` attribute +### Storage Anotation + +Anotate the `Storage` struct with the `#[storage]` attribute [tabs] ==== @@ -33,11 +35,14 @@ struct Storage { ---- ==== -* Gather your contract’s external/view function signatures under a trait anotated with `#[starknet::interface]` -** Add a generic parameter to the trait, here we use the name `TContractState` as it stands for the state of your contract -** For view functions, add the `self: TContractState` argument -** For external functions, add the `self: @TContractState` argument -** Static functions that do not touch storage or emit events do not require an addition argument +### Contract Interface + +Gather your contract’s external/view function signatures under a trait anotated with `#[starknet::interface]`: + +* Add a generic parameter to the trait, here we use the name `TContractState` as it stands for the state of your contract +* For view functions, add the `self: TContractState` argument +* For external functions, add the `self: @TContractState` argument +* Static functions that do not touch storage or emit events do not require an addition argument [tabs] ==== @@ -74,32 +79,9 @@ mod CounterContract { ---- ==== -* Replace the `#[abi]` attribute with `#[starknet::interface]` (while it doesn't affecting the generated code, we recommended adding to the trait a generic parameter `T` representing the contract's state, -and adding the `ref self: T` argument to external functions and `self: @T` argument for view functions) +### Add Interface Impl -[tabs] -==== -old:: -+ -[source,rust] ----- -#[abi] -trait IOtherContract { - fn decrease_allowed() -> bool; -} ----- -new:: -+ -[source,rust] ----- -#[starknet::interface] -trait IOtherContract { - fn decrease_allowed(self: @TContractState) -> bool; -} ----- -==== - -* Add the external/view function bodies under an impl of the above trait, and mark the impl with the `[external(v0)]` attribute +Add the external/view function bodies under an impl of the interface trait, and mark the impl with the `[external(v0)]` attribute [tabs] ==== @@ -141,7 +123,37 @@ mod CounterContract { ---- ==== -* Modify storage accesses to happen through `ContractState` or `@ContractState` (none external functions in the contract that access storage also need to get it as an argument) +### Replace the `abi` attribute with `starknet::interface` + +These attributes are responsible for generating the dispatcher type, used to call the contract. +Replace the `#[abi]` attribute with `#[starknet::interface]`. While it doesn't affect the generated code, we recommended adding to the trait a generic parameter `T` representing the contract's state, +and adding the `ref self: T` argument to external functions and `self: @T` argument for view functions. + +[tabs] +==== +old:: ++ +[source,rust] +---- +#[abi] +trait IOtherContract { + fn decrease_allowed() -> bool; +} +---- +new:: ++ +[source,rust] +---- +#[starknet::interface] +trait IOtherContract { + fn decrease_allowed(self: @TContractState) -> bool; +} +---- +==== + +### Storage Accesses + +Modify storage accesses to happen through `ContractState` or `@ContractState` (none external functions in the contract that access storage also need to get it as an argument) [tabs] ==== @@ -159,7 +171,9 @@ let current = self.counter.read(); ---- ==== -* Unify all the contract's events under the `Event` enum, and add a corresponding struct for every variant (all the structs must derive the `Event` trait, +### Events Definition + +Unify all the contract's events under the `Event` enum, and add a corresponding struct for every variant (all the structs must derive the `Event` trait, and each member type has to implement the `Serde` trait) [tabs] @@ -196,7 +210,9 @@ struct CounterDecreased { ---- ==== -* Emit events via the `ContractState` type +### Events Emition + +Emit events via the `ContractState` type [tabs] ==== @@ -213,7 +229,7 @@ new:: + [source,rust] ---- -fn increase_counter(amount: u128) { +fn increase_counter(ref self: ContractState, amount: u128) { ... self.emit(Event::CounterIncreased(CounterIncreased { amount })); } diff --git a/components/Starknet/modules/architecture_and_concepts/nav.adoc b/components/Starknet/modules/architecture_and_concepts/nav.adoc index 4f97226162..8b76fd2672 100644 --- a/components/Starknet/modules/architecture_and_concepts/nav.adoc +++ b/components/Starknet/modules/architecture_and_concepts/nav.adoc @@ -12,6 +12,7 @@ *** xref:Contracts/contract-address.adoc[Contract address] *** xref:Contracts/contract-storage.adoc[Contract storage] *** xref:Contracts/contract-abi.adoc[Contract ABI] +*** xref:Contracts/contract-syntax.adoc[Contract Syntax] ** Blocks and transactions *** xref:Blocks/header.adoc[Block structure] From 5190a25f1e8e116b67cb511921d2df0fd82eb932 Mon Sep 17 00:00:00 2001 From: ArielElp Date: Tue, 13 Jun 2023 10:27:33 +0300 Subject: [PATCH 03/10] rearrang Cairo 1 pages under a new section --- .../pages/{Contracts => Cairo_on_Starknet}/contract-syntax.adoc | 0 components/Starknet/modules/architecture_and_concepts/nav.adoc | 1 + 2 files changed, 1 insertion(+) rename components/StarkNet/modules/architecture_and_concepts/pages/{Contracts => Cairo_on_Starknet}/contract-syntax.adoc (100%) diff --git a/components/StarkNet/modules/architecture_and_concepts/pages/Contracts/contract-syntax.adoc b/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc similarity index 100% rename from components/StarkNet/modules/architecture_and_concepts/pages/Contracts/contract-syntax.adoc rename to components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc diff --git a/components/Starknet/modules/architecture_and_concepts/nav.adoc b/components/Starknet/modules/architecture_and_concepts/nav.adoc index 8b76fd2672..ceb6d988cc 100644 --- a/components/Starknet/modules/architecture_and_concepts/nav.adoc +++ b/components/Starknet/modules/architecture_and_concepts/nav.adoc @@ -29,6 +29,7 @@ ** xref:Hashing/hash-functions.adoc[Hash functions] ** System Calls +*** xref:Contracts/system-calls-cairo0.adoc[Cairo 0] *** xref:Contracts/system-calls-cairo1.adoc[Cairo 1.0] *** xref:Contracts/system-calls-cairo0.adoc[Cairo 0] From c0f94d4fdec561abed5d2ac2650424c143efafd6 Mon Sep 17 00:00:00 2001 From: JameStark Date: Tue, 13 Jun 2023 15:48:00 +0100 Subject: [PATCH 04/10] Initial wording changes and fix broken links --- .../pages/Cairo_on_Starknet/contract-syntax.adoc | 12 +++++++++--- .../pages/Fees/fee-mechanism.adoc | 2 +- .../pages/State/starknet-state.adoc | 8 +++++--- 3 files changed, 15 insertions(+), 7 deletions(-) diff --git a/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc b/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc index b6a50c603b..4808f162d1 100644 --- a/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc +++ b/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc @@ -1,8 +1,14 @@ # Cairo 1 Contract Syntax -With the link:https://github.com/starkware-libs/cairo/releases/tag/v2.0.0-rc0[v2.0.0 release] of the Cairo compiler, the contract syntax has evolved. -This affects how external functions, storage, and events are organized inside the contract. We summarize here the technical steps required to migrate from the old syntax -(for a comperhensive treatment of the changes, see the link:https://community.starknet.io/t/cairo-1-contract-syntax-is-evolving/94794[community forum post]). +With the link:https://github.com/starkware-libs/cairo/releases/tag/v2.0.0-rc0[v2.0.0 release] of +the Cairo compiler, the Starknet contract syntax has evolved. This affects how external +functions, storage, and events are organized inside the contract. + +This page highlights the technical steps required to migrate from the old Starknet contract +syntax to the new. + +For a comprehensive breakdown of the changes, see the link:https://community.starknet +.io/t/cairo-1-contract-syntax-is-evolving/94794[community forum post]. ## New contract syntax - concrete steps for migrating diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Fees/fee-mechanism.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Fees/fee-mechanism.adoc index 320832f7ae..466eaff637 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Fees/fee-mechanism.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Fees/fee-mechanism.adoc @@ -15,7 +15,7 @@ The only limitation on the sequencer (enforced by the Starknet OS) is that the a Presently, the sequencer only takes into account L1 costs involving proof submission. There are two components affecting the L1 footprint of a transaction: * xref:computation[Computational complexity]: the heavier the transaction, the larger its portion in the proof verification cost. -* xref:_on_chain_data[On chain data]: L1 calldata cost originating from xref:Data_Availability/on-chain-data.adoc[data availability] and L2→L1 messages. +* xref:on-chain-data[On chain data]: L1 calldata cost originating from xref:../Data_Availability/on_chain_data.adoc[data availability] and L2→L1 messages. == Fee units diff --git a/components/Starknet/modules/architecture_and_concepts/pages/State/starknet-state.adoc b/components/Starknet/modules/architecture_and_concepts/pages/State/starknet-state.adoc index 0e05a7f4bb..0b7df5a1ff 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/State/starknet-state.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/State/starknet-state.adoc @@ -35,10 +35,10 @@ In Starknet, the commitment combines the roots of two binary xref:#merkle_patric Where: -* stem:[$h$] is the xref:../Hashing/hash-functions.adoc#poseidon_hash[Poseidon] hash function * `STARKNET_STATE_V0` is a constant prefix string encoded in ASCII (and represented as a field element). * `contracts_tree_root` is the root of the Merkle-Patricia tree whose leaves are the contracts states, see xref:#contracts_tree[below] * `classes_tree_root` is the root of the Merkle-Patricia tree whose leaves are the compiled class hashes, see xref:#classes_tree[below] +* stem:[$h$] is the xref:../Hashing/hash-functions.adoc#poseidon_array_hash[Poseidon] hash function [id="contracts_tree"] === The contracts tree @@ -73,11 +73,13 @@ Where: * stem:[$h$] is the xref:../Hashing/hash-functions.adoc#poseidon_hash[Poseidon] hash function * `CONTRACT_CLASS_LEAF_V0` is a constant prefix string encoded in ASCII (and represented as a field element). * `compiled_class_hash` is the hash of the Cairo assembly resulting from compiling the given class via the Sierra→Casm compiler +* stem:[$h$] is stem:[$poseidon_2$] defined xref:../Hashing/hash-functions.adoc#poseidon_hash[here] [NOTE] ==== Cairo 1.0 classes that are part of the commitment are defined with Sierra, an intermediate representation between Cairo 1.0 and Cairo assembly (see xref:architecture_and_concepts:Contracts/system-calls-cairo1.adoc[here] for more information). +Cairo 1.0 classes that are part of the commitment are defined with Sierra, an intermediate representation between Cairo 1.0 and Cairo assembly (see xref:architecture_and_concepts:Contracts/cairo-1-and-sierra.adoc[here] for more information). However, the prover only deals with Cairo assembly. This means that unless we want the compilation from Sierra to Casm to be part of every block in which the class is used, the commitment must have some information about the associated Cairo assembly. @@ -100,8 +102,8 @@ stem:[$path$] is an integer in stem:[$[0, 2^{length}-1\]$], and the binary expan [NOTE] ==== -The reason that length is specified and cannot be deduced from stem:[$path$] is that we're -dealing with field elements of fixed size (251 bits each). +You must specify length. You cannot deduce it from stem:[$path$] because +field elements have a fixed size of 251 bits. For a node with stem:[$length>0$], following stem:[$path$] leads the highest node whose both right and left child are none empty. ==== From d954aa2e82f70b6e38396b19df006759c4a02cd4 Mon Sep 17 00:00:00 2001 From: ArielElp Date: Mon, 12 Jun 2023 20:23:27 +0300 Subject: [PATCH 05/10] add contract syntax page --- .../Cairo_on_Starknet/cairo-1-and-sierra.adoc | 106 ++++++++++++++++++ .../Cairo_on_Starknet/contract-syntax.adoc | 42 +++++-- .../architecture_and_concepts/nav.adoc | 3 - .../pages/Fees/fee-mechanism.adoc | 27 +++-- .../pages/State/starknet-state.adoc | 3 +- 5 files changed, 157 insertions(+), 24 deletions(-) create mode 100644 components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/cairo-1-and-sierra.adoc diff --git a/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/cairo-1-and-sierra.adoc b/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/cairo-1-and-sierra.adoc new file mode 100644 index 0000000000..06ee81763a --- /dev/null +++ b/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/cairo-1-and-sierra.adoc @@ -0,0 +1,106 @@ +[id="sierra"] += Cairo 1.0 and Sierra + +Up until xref:documentation:starknet_versions:upcoming_versions.adoc[Starknet Alpha v0.11.0] users would write contracts in Cairo 0 and compile them locally to Cairo assembly (or Casm for short). +Next, the user would submit the compilation output (the xref:documentation:architecture_and_concepts:Contracts/contract-classes.adoc[contract class]) to the Starknet sequencer via a `declare` transaction. + +With Cairo 1.0, the contract class resulting from xref:documentation:architecture_and_concepts:Contracts/class-hash.adoc#cairo1_class[compiling Cairo 1.0] does not include Casm. Instead of Casm, it includes instructions in an intermediate representation called Sierra (Safe Intermediate Representation). +This new contract class is then compiled by the sequencer, via the Sierra → Casm compiler, to generate the Cairo assembly associated with this class. + +== Why do we need Casm? + +Starknet is a validity rollup, which means that the execution inside every block needs to be proven, and this is where STARKs come in handy. +However, STARK proofs can address statements that are formulated in the language of polynomial +constraints, and have no knowledge of smart contract execution. +To overcome this gap, we developed link:https://github.com/starknet-io/starknet-stack-resources/blob/main/Cairo/Cairo%20%E2%80%93%20a%20Turing-complete%20STARK-friendly%20CPU%20architecture.pdf[Cairo]. + +Cairo instructions (which we referred to previously by Casm) are translated to polynomial constraints that enforce the correct execution of a program (according to the Cairo semantics defined in the paper). + +Thanks to Cairo, we can formulate the statement "this Starknet block is valid" in a way that we can prove. +Note that we can only prove things about Casm. That is, regardless of what the user sends to the Starknet sequencer, what's proven is the correct Casm execution. + +This means that we need a way to translate Sierra into Casm, and this is achieved with the Sierra +→ +Casm compiler. + + +== Why do we need Sierra? + +To understand why we chose to add an additional layer between the code that the user writes (Cairo 1.0) and the code that is being proven (Casm), +we need to consider more components in the system, and the limitations of Cairo. + +=== Reverted transactions, unsatisfiable AIRs, and DOS attacks + +A crucial property of every decentralized L2 is that the sequencers are guaranteed to be compensated for work they do. +The notion of reverted transactions is a good example: even if the user's transaction failed mid execution, the sequencer should be able to include it in a block and charge execution fees up to the point of failure. + +If the sequencer cannot charge for such transactions, then sending transactions that will eventually fail (after a lot of computation steps) is an obvious DOS attack on the sequencer. +The sequencer cannot look at a transaction and conclude that it would fail without actually doing the work (this is equivalent to solving the halting problem). + + +The obvious solution to the above predicament is to include such transactions in the block, similar to Ethereum. However, this may not be as simple to do in a validity rollup. +With Cairo 0, there is no separating layer between user code and what is being proven. + +This means that users can write code which is unprovable in some cases. In fact, such code is very easy to write, e.g. `assert 0=1` is a valid +Cairo instruction that cannot be proven, as it translates to polynomial constraints that are not satisfiable. Any Casm execution that contains this instruction cannot be proven. +Sierra is the layer between user code and the provable statement, that allows us to make sure all transactions are eventually provable. + +=== Safe Casm + +The method by which Sierra guarantees that user code is always provable is by compiling Sierra instructions to a subset of Casm, which we call "safe Casm". +The important property that we require from safe Casm is being provable for all inputs. A canonical example for safe Casm is using `if/else` instructions instead of `assert`, that is, making sure all failures are +graceful. + +To better understand the considerations that go into designing the Sierra → Casm compiler, +consider the `find_element` function from the common library of Cairo 0: + +[source,cairo] +---- +func find_element{range_check_ptr}(array_ptr: felt*, elm_size, n_elms, key) -> (elm_ptr: felt*) { + alloc_locals; + local index; + %{ + ... + %} + assert_nn_le(a=index, b=n_elms - 1); + tempvar elm_ptr = array_ptr + elm_size * index; + assert [elm_ptr] = key; + return (elm_ptr=elm_ptr); +} +---- + +[NOTE] +==== +Below we abuse the "Casm" notation by not distinguishing Cairo 0 from Casm and referring to the +above as Casm (while we actually refer to the compilation result of the above). +==== + +For brevity, we have omitted the hint in the above snippet, but it's clear that this function can only execute correctly if the requested element exists in the array (otherwise it would fail for every possible hint - +there is nothing we can substitute `index` for, that makes the following lines run successfully). + +Such Casm cannot be generated by the Sierra→Casm compiler. +Furthermore, simply replacing the assertion with an if/else statement doesn't do, as this results in non-deterministic execution. That is, for the same input, different hint values can yield different results. +A malicious prover can use this freedom to harm the user - in this example, they are able to make it seem as if an element isn't part of the array, even though it actually is. + +The safe Casm for finding an element in an array behaves like the above snippet in the happy flow (element is there): an index is given in a hint, and we verify that the array at the hinted index contains the requested element. +However, in the unhappy flow (element isn't there), we *must* go over the entire array to verify this. + +This was not the case in Cairo 0, as we were fine with certain paths not being provable (in the above snippet, the unhappy flow in which the element isn't in the array is never provable). + +[NOTE] +==== +Sierra's gas metering adds further complications to the above example. Even looking through the array to verify that the element isn't there may leave some flexibility to the prover. + +If we take gas limitations into consideration, the user may have enough gas for the happy flow, but not for the unhappy one, making the execution stop mid-search, and allowing the prover to get away with lying about the element not being present. + +The way we plan to handle this is by requiring the user to have enough gas for the unhappy flow before actually calling `find_element`. +==== + +=== Hints in Cairo 1.0 + +Smart contracts written with Cairo 1.0 cannot contain user defined hints. This is already true with Cairo 0 contracts (only whitelisted hints are accepted), but with Cairo 1.0 the hints in use are +determined by the Sierra → Casm compiler. Since this compilation is there to ensure that only +"safe" Casm is generated, there is no room for hints that are not generated by the compiler. + +In the future, native Cairo 1.0 may contain hint syntax similar to Cairo 0, but it will not be available in Starknet smart contracts (link:https://medium.com/starkware/fractal-scaling-from-l2-to-l3-7fe238ecfb4f[L3s] on top of Starknet may make use of such functionality). +Note that this is currently not part of Starknet's roadmap. diff --git a/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc b/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc index 4808f162d1..43a980e46a 100644 --- a/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc +++ b/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc @@ -1,4 +1,4 @@ -# Cairo 1 Contract Syntax +# Contract Syntax - Migration Guide With the link:https://github.com/starkware-libs/cairo/releases/tag/v2.0.0-rc0[v2.0.0 release] of the Cairo compiler, the Starknet contract syntax has evolved. This affects how external @@ -14,6 +14,32 @@ For a comprehensive breakdown of the changes, see the link:https://community.sta Given a contract written with the previous compiler version (v1.1.0), you can follow the steps below in order to make it compatible with the new syntax. +### Contract Anotation + +Outside the contract module, Starknet related attributes are expected to have the `starknet::` prefix. + +[tabs] +==== +old:: ++ +[source,rust] +---- +#[contract] +mod CounterContract { + ... +} +---- +new:: ++ +[source,rust] +---- +#[starknet::contract] +mod CounterContract { + ... +} +---- +==== + ### Storage Anotation Anotate the `Storage` struct with the `#[storage]` attribute @@ -46,8 +72,8 @@ struct Storage { Gather your contract’s external/view function signatures under a trait anotated with `#[starknet::interface]`: * Add a generic parameter to the trait, here we use the name `TContractState` as it stands for the state of your contract -* For view functions, add the `self: TContractState` argument -* For external functions, add the `self: @TContractState` argument +* For view functions, add the `self: @TContractState` argument +* For external functions, add the `ref self: TContractState` argument * Static functions that do not touch storage or emit events do not require an addition argument [tabs] @@ -74,7 +100,7 @@ new:: #[starknet::interface] trait ICounterContract { fn increase_counter(ref self: TContractState, amount: u128); - fn decrease_counter(ref self: TContractState); + fn decrease_counter(ref self: TContractState, amount: u128); fn get_counter(self: @TContractState) -> u128; } @@ -113,7 +139,7 @@ new:: #[starknet::interface] trait ICounterContract { fn increase_counter(ref self: TContractState, amount: u128); - fn decrease_counter(ref self: TContractState); + fn decrease_counter(ref self: TContractState, amount: u128); fn get_counter(self: @TContractState) -> u128; } @@ -121,9 +147,9 @@ trait ICounterContract { mod CounterContract { #[external(v0)] impl CounterContract of super::ICounterContract { - fn increase_counter(amount: u128) { ... } - fn decrease_counter(amount: u128) { ... } - fn get_counter() -> u128 { ... } + fn increase_counter(ref self: ContractState, amount: u128) { ... } + fn decrease_counter(ref self: ContractState, amount: u128) { ... } + fn get_counter(self: @ContractState) -> u128 { ... } } } ---- diff --git a/components/Starknet/modules/architecture_and_concepts/nav.adoc b/components/Starknet/modules/architecture_and_concepts/nav.adoc index ceb6d988cc..c498a1c14e 100644 --- a/components/Starknet/modules/architecture_and_concepts/nav.adoc +++ b/components/Starknet/modules/architecture_and_concepts/nav.adoc @@ -12,7 +12,6 @@ *** xref:Contracts/contract-address.adoc[Contract address] *** xref:Contracts/contract-storage.adoc[Contract storage] *** xref:Contracts/contract-abi.adoc[Contract ABI] -*** xref:Contracts/contract-syntax.adoc[Contract Syntax] ** Blocks and transactions *** xref:Blocks/header.adoc[Block structure] @@ -31,8 +30,6 @@ ** System Calls *** xref:Contracts/system-calls-cairo0.adoc[Cairo 0] *** xref:Contracts/system-calls-cairo1.adoc[Cairo 1.0] -*** xref:Contracts/system-calls-cairo0.adoc[Cairo 0] - ** Cairo on Starknet *** xref:Cairo_on_Starknet/cairo-1-and-sierra.adoc[Cairo 1.0 and Sierra] diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Fees/fee-mechanism.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Fees/fee-mechanism.adoc index 466eaff637..3468c27b92 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Fees/fee-mechanism.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Fees/fee-mechanism.adoc @@ -1,4 +1,4 @@ -= Fee mechanism += Fee Mechanism :--auto-ids: :stem: latexmath @@ -15,15 +15,19 @@ The only limitation on the sequencer (enforced by the Starknet OS) is that the a Presently, the sequencer only takes into account L1 costs involving proof submission. There are two components affecting the L1 footprint of a transaction: * xref:computation[Computational complexity]: the heavier the transaction, the larger its portion in the proof verification cost. -* xref:on-chain-data[On chain data]: L1 calldata cost originating from xref:../Data_Availability/on_chain_data.adoc[data availability] and L2→L1 messages. +<<<<<<< HEAD +* xref:on-chain-data[On chain data]: L1 calldata cost originating from xref:Data_Availability/on-chain-data.adoc[data availability] +and L2→L1 messages. +======= +* xref:_on_chain_data[On chain data]: L1 calldata cost originating from xref:_on_chain_data[data availability] and L2→L1 messages. +>>>>>>> add subtitles -== Fee units +== Fee Units The fee is denominated in ETH (this may change in future versions). Each transaction is associated with a gas estimate (explained below), and combining this with the gas price yields the estimated fee. == How much fee is charged? High-level overview -[id="computation"] === Computation Let's analyze the correct metric for measuring transaction complexity. For simplicity, we will ignore Cairo's builtins for the sake of the explanation, and later see how to address them. @@ -55,7 +59,7 @@ Suppose, for example, that a transaction uses 10,000 Cairo steps and 500 Pederse Notice we completely ignored the number of Cairo steps in this transaction performance estimation, as it is not the limiting factor (since 500,000,000/10,000 > 20,000,000/500). With this example in mind, we can now formulate the exact fee associated with L2 computation. -==== General case +==== General Case For each transaction, the sequencer calculates a vector `CairoResourceUsage` holding: @@ -89,16 +93,15 @@ The weights are: | 10.24 gas/application |=== -[id="_on_chain_data"] -=== On-chain data +=== On Chain Data -The on-chain data associated with a transaction is composed of three parts +The on chain data associated with a transaction is composed of three parts * Storage updates * L2→L1 messages * Deployed contracts -==== Storage updates +==== Storage Updates Whenever a transaction updates a key at the storage of some contract, the following xref:Data_Availability/on-chain-data.adoc[data] reaches L1: @@ -131,7 +134,7 @@ For example, if different transactions within the same block update the same sto ==== -==== L2→L1 messages +==== L2→L1 Messages When a transaction that raises the `send_message_to_l1` syscall is included in a state update, the following xref:../Data_Availability/on-chain-data.adoc[data] reaches L1: @@ -149,7 +152,7 @@ Consequently, the fee associated with a single L2→L1 message is: where stem:[$c_w$] is the calldata cost (in gas) per 32-byte word. -==== Deployed contracts +==== Deployed Contracts When a transaction that raises the `deploy` syscall is included in a state update, the following xref:../Data_Availability/on-chain-data.adoc#format[data] reaches L1: @@ -165,7 +168,7 @@ Consequently, the fee associated with a single deployment is: where stem:[$c_w$] is the calldata cost (in gas) per 32-byte word. -== Overall fee +== Overall Fee The fee for a transaction with: diff --git a/components/Starknet/modules/architecture_and_concepts/pages/State/starknet-state.adoc b/components/Starknet/modules/architecture_and_concepts/pages/State/starknet-state.adoc index 0b7df5a1ff..225d61a366 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/State/starknet-state.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/State/starknet-state.adoc @@ -79,7 +79,8 @@ Where: ==== Cairo 1.0 classes that are part of the commitment are defined with Sierra, an intermediate representation between Cairo 1.0 and Cairo assembly (see xref:architecture_and_concepts:Contracts/system-calls-cairo1.adoc[here] for more information). -Cairo 1.0 classes that are part of the commitment are defined with Sierra, an intermediate representation between Cairo 1.0 and Cairo assembly (see xref:architecture_and_concepts:Contracts/cairo-1-and-sierra.adoc[here] for more information). +Cairo 1.0 classes that are part of the commitment are defined with Sierra, an intermediate +representation between Cairo 1.0 and Cairo assembly (see xref:Cairo_on_Starknet/cairo-1-and-sierra.adoc[here] for more information). However, the prover only deals with Cairo assembly. This means that unless we want the compilation from Sierra to Casm to be part of every block in which the class is used, the commitment must have some information about the associated Cairo assembly. From a5c23821bf572346a7dceab2c29995188082c2dc Mon Sep 17 00:00:00 2001 From: JameStark Date: Thu, 15 Jun 2023 08:36:06 +0100 Subject: [PATCH 06/10] Fix link --- .../pages/Cairo_on_Starknet/contract-syntax.adoc | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc b/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc index 43a980e46a..e80662a865 100644 --- a/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc +++ b/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc @@ -7,8 +7,7 @@ functions, storage, and events are organized inside the contract. This page highlights the technical steps required to migrate from the old Starknet contract syntax to the new. -For a comprehensive breakdown of the changes, see the link:https://community.starknet -.io/t/cairo-1-contract-syntax-is-evolving/94794[community forum post]. +For a comprehensive breakdown of the changes, see the link:https://community.starknet.io/t/cairo-1-contract-syntax-is-evolving/94794[community forum post]. ## New contract syntax - concrete steps for migrating From 078d8b62fb83963eb0bb98583e8737f71b96e461 Mon Sep 17 00:00:00 2001 From: JameStark Date: Thu, 15 Jun 2023 13:15:29 +0100 Subject: [PATCH 07/10] Peer review changes --- .../Cairo_on_Starknet/contract-syntax.adoc | 80 +++++++++++-------- 1 file changed, 47 insertions(+), 33 deletions(-) diff --git a/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc b/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc index e80662a865..e3511ded4a 100644 --- a/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc +++ b/components/StarkNet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc @@ -1,21 +1,18 @@ -# Contract Syntax - Migration Guide += Contract syntax - migration guide With the link:https://github.com/starkware-libs/cairo/releases/tag/v2.0.0-rc0[v2.0.0 release] of -the Cairo compiler, the Starknet contract syntax has evolved. This affects how external -functions, storage, and events are organized inside the contract. +the Cairo compiler, the Starknet contract syntax has evolved, affecting the organization of +functions, storage, and events. -This page highlights the technical steps required to migrate from the old Starknet contract -syntax to the new. +For more information on the latest syntax changes, see the link:https://community.starknet.io/t/cairo-1-contract-syntax-is-evolving/94794[community forum post]. -For a comprehensive breakdown of the changes, see the link:https://community.starknet.io/t/cairo-1-contract-syntax-is-evolving/94794[community forum post]. - -## New contract syntax - concrete steps for migrating +== New contract syntax - concrete steps for migrating Given a contract written with the previous compiler version (v1.1.0), you can follow the steps below in order to make it compatible with the new syntax. -### Contract Anotation +1 . Change the contract annotation from `#[contract]` to `#[starknet::contract]`. -Outside the contract module, Starknet related attributes are expected to have the `starknet::` prefix. +For example: [tabs] ==== @@ -39,9 +36,9 @@ mod CounterContract { ---- ==== -### Storage Anotation -Anotate the `Storage` struct with the `#[storage]` attribute + +2 . Annotate the `Storage` struct with the `#[storage]` attribute: [tabs] ==== @@ -66,14 +63,16 @@ struct Storage { ---- ==== -### Contract Interface +3 . Gather your contract’s external and view function signatures under a trait annotated with +`#[starknet::interface]` by completing the following: -Gather your contract’s external/view function signatures under a trait anotated with `#[starknet::interface]`: +* Add a generic parameter to the trait. In this example, the name `TContractState` is used as it +stands for the state of your contract. +* For view functions, add the `self: @TContractState` argument. +* For external functions, add the `ref self: TContractState` argument. +* Static functions that do not touch storage or emit events do not require an addition argument. -* Add a generic parameter to the trait, here we use the name `TContractState` as it stands for the state of your contract -* For view functions, add the `self: @TContractState` argument -* For external functions, add the `ref self: TContractState` argument -* Static functions that do not touch storage or emit events do not require an addition argument +For example: [tabs] ==== @@ -110,9 +109,8 @@ mod CounterContract { ---- ==== -### Add Interface Impl - -Add the external/view function bodies under an impl of the interface trait, and mark the impl with the `[external(v0)]` attribute +4 . Add the external and view function bodies under an `impl` of the interface trait, and mark the +`impl` with the `[external(v0)]` attribute: [tabs] ==== @@ -154,11 +152,18 @@ mod CounterContract { ---- ==== -### Replace the `abi` attribute with `starknet::interface` - These attributes are responsible for generating the dispatcher type, used to call the contract. -Replace the `#[abi]` attribute with `#[starknet::interface]`. While it doesn't affect the generated code, we recommended adding to the trait a generic parameter `T` representing the contract's state, -and adding the `ref self: T` argument to external functions and `self: @T` argument for view functions. + +5 . Replace the `#[abi]` attribute with `#[starknet::interface]`. + +[TIP] +==== +While it doesn't affect the generated code, adding to the trait a generic parameter `T` representing the contract's state, +and adding the `ref self: T` argument to external functions and `self: @T` argument for view +functions makes the implementation more complete. +==== + +For example: [tabs] ==== @@ -182,9 +187,14 @@ trait IOtherContract { ---- ==== -### Storage Accesses +6 . Modify storage accesses to happen through `ContractState` or `@ContractState`. + +[NOTE] +==== +No external functions in the contract that access storage also need to get it as an argument. +==== -Modify storage accesses to happen through `ContractState` or `@ContractState` (none external functions in the contract that access storage also need to get it as an argument) +For example: [tabs] ==== @@ -202,10 +212,16 @@ let current = self.counter.read(); ---- ==== -### Events Definition +7 . Unify all the contract's events under the `Event` enum, and add a corresponding struct for every +variant. -Unify all the contract's events under the `Event` enum, and add a corresponding struct for every variant (all the structs must derive the `Event` trait, -and each member type has to implement the `Serde` trait) +[NOTE] +==== +All the structs must derive the `Event` trait, +and each member type has to implement the `Serde` trait. +==== + +For example: [tabs] ==== @@ -241,9 +257,7 @@ struct CounterDecreased { ---- ==== -### Events Emition - -Emit events via the `ContractState` type +8 . Emit events via the `ContractState` type: [tabs] ==== From b6e486824325de051e7e860a8d6b189cb1f27b43 Mon Sep 17 00:00:00 2001 From: ArielElp Date: Thu, 15 Jun 2023 13:15:07 +0300 Subject: [PATCH 08/10] fix changes in fee-mechanism.adoc --- .../architecture_and_concepts/pages/Fees/fee-mechanism.adoc | 5 ----- 1 file changed, 5 deletions(-) diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Fees/fee-mechanism.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Fees/fee-mechanism.adoc index 3468c27b92..0851205276 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Fees/fee-mechanism.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Fees/fee-mechanism.adoc @@ -15,12 +15,7 @@ The only limitation on the sequencer (enforced by the Starknet OS) is that the a Presently, the sequencer only takes into account L1 costs involving proof submission. There are two components affecting the L1 footprint of a transaction: * xref:computation[Computational complexity]: the heavier the transaction, the larger its portion in the proof verification cost. -<<<<<<< HEAD -* xref:on-chain-data[On chain data]: L1 calldata cost originating from xref:Data_Availability/on-chain-data.adoc[data availability] -and L2→L1 messages. -======= * xref:_on_chain_data[On chain data]: L1 calldata cost originating from xref:_on_chain_data[data availability] and L2→L1 messages. ->>>>>>> add subtitles == Fee Units From 071facaf0ab36da2b9993ca9a45857b19472a7f6 Mon Sep 17 00:00:00 2001 From: Steve Goodman Date: Wed, 12 Jul 2023 15:45:01 +0300 Subject: [PATCH 09/10] Edited Contract migration guide --- .../Cairo_on_Starknet/contract-syntax.adoc | 119 +++++++++--------- 1 file changed, 62 insertions(+), 57 deletions(-) diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc index 31b0cc4c34..6b875b3285 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc @@ -1,22 +1,19 @@ -# Contract syntax - migration guide += Migrating syntax from Cairo 0 to Cairo With the link:https://github.com/starkware-libs/cairo/releases/tag/v2.0.0-rc0[v2.0.0 release] of -the Cairo compiler, the Starknet contract syntax has evolved. This affects how external -functions, storage, and events are organized inside the contract. +the Cairo compiler, the Starknet contract syntax has evolved, affecting the organization of +functions, storage, and events. -This page highlights the technical steps required to migrate from the old Starknet contract -syntax to the new. +For more information on the latest syntax changes, see the link:https://community.starknet.io/t/cairo-1-contract-syntax-is-evolving/94794[community forum post]. -For a comprehensive breakdown of the changes, see the link:https://community.starknet.io/t/cairo-1-contract-syntax-is-evolving/94794[community forum post]. +.Prerequisites -## New contract syntax - concrete steps for migrating +* A contract written with the compiler v1.1.0 -Given a contract written with the previous compiler version (v1.1.0), you can follow the steps below in order to make it compatible with the new syntax. - -### Contract anotation - -Outside the contract module, Starknet related attributes are expected to have the `starknet::` prefix. +.Procedure +. Change the contract annotation from `\#[contract]` to `#[starknet::contract]`. For example:: ++ [tabs] ==== old:: @@ -38,11 +35,8 @@ mod CounterContract { } ---- ==== - -### Storage anotation - -Anotate the `Storage` struct with the `#[storage]` attribute - + . Annotate the `Storage` struct with the `#[storage]` attribute. For example: ++ [tabs] ==== old:: @@ -66,15 +60,17 @@ struct Storage { ---- ==== -### Contract interface - -Gather your contract’s external and view function signatures under a trait annotated with `#[starknet::interface]`: - -* Add a generic parameter to the trait, here we use the name `TContractState` as it stands for the state of your contract -* For view functions, add the `self: @TContractState` argument -* For external functions, add the `ref self: TContractState` argument -* Static functions that do not touch storage or emit events do not require an addition argument - +. Gather your contract’s `external` and `view` function signatures under a trait annotated with +`#[starknet::interface]` as follows: ++ +* Add a generic parameter to the trait. In the following example, the name `TContractState` +represents the state of your contract. +* For view functions, add the `self: @TContractState` argument. +* For external functions, add the `ref self: TContractState` argument. +* Static functions that do not touch storage or emit events do not require an additional argument. ++ +For example: ++ [tabs] ==== old:: @@ -91,7 +87,6 @@ mod CounterContract { fn get_counter() -> u128 { ... } } ---- - new:: + [source,rust] @@ -102,7 +97,6 @@ trait ICounterContract { fn decrease_counter(ref self: TContractState, amount: u128); fn get_counter(self: @TContractState) -> u128; } - #[starknet::contract] mod CounterContract { ... @@ -110,10 +104,11 @@ mod CounterContract { ---- ==== -### Add interface `Impl` - -Add the external and view function bodies under an impl of the interface trait, and mark the impl with the `[external(v0)]` attribute - +. Add the external and view function bodies under an `impl` of the interface trait, and mark the +`impl` with the `[external(v0)]` attribute, which generates the type of dispatcher that is used to call the contract. ++ +For example: ++ [tabs] ==== old:: @@ -130,7 +125,6 @@ mod CounterContract { fn get_counter() -> u128 { ... } } ---- - new:: + [source,rust] @@ -141,7 +135,6 @@ trait ICounterContract { fn decrease_counter(ref self: TContractState, amount: u128); fn get_counter(self: @TContractState) -> u128; } - #[starknet::contract] mod CounterContract { #[external(v0)] @@ -154,12 +147,17 @@ mod CounterContract { ---- ==== -### Replace the `abi` attribute with `starknet::interface` - -These attributes are responsible for generating the dispatcher type, used to call the contract. -Replace the `#[abi]` attribute with `#[starknet::interface]`. While it doesn't affect the generated code, we recommended adding to the trait a generic parameter `T` representing the contract's state, -and adding the `ref self: T` argument to external functions and `self: @T` argument for view functions. - +. Replace the `\#[abi]` attribute with `#[starknet::interface]`. ++ +[TIP] +==== +While it doesn't affect the generated code, adding to the trait a generic parameter `T` representing the contract's state, +and adding the `ref self: T` argument to external functions and `self: @T` argument for view +functions makes the implementation more complete. +==== ++ +For example: ++ [tabs] ==== old:: @@ -182,11 +180,16 @@ trait IOtherContract { ---- ==== -### Storage access - -Modify storage access to happen through `ContractState` or `@ContractState` (none external -functions in the contract that access storage also need to get it as an argument). - +. Modify storage accesses to happen through `ContractState` or `@ContractState`. ++ +[NOTE] +==== +No external functions in the contract that access storage also need to get it as an argument. +// Get what as an argument? Storage? +==== ++ +For example: ++ [tabs] ==== old:: @@ -203,11 +206,17 @@ let current = self.counter.read(); ---- ==== -### Events definition - -Unify all the contract's events under the `Event` enum, and add a corresponding struct for every variant (all the structs must derive the `Event` trait, -and each member type has to implement the `Serde` trait) - +. Unify all the contract's events under the `Event` enum, and add a corresponding struct for every +variant. ++ +[NOTE] +==== +All the structs must derive the `Event` trait, +and each member type must implement the `Serde` trait. +==== ++ +For example: ++ [tabs] ==== old:: @@ -229,12 +238,10 @@ enum Event { CounterIncreased: CounterIncreased, CounterDecreased: CounterDecreased } - #[derive(Drop, starknet::Event)] struct CounterIncreased { amount: u128 } - #[derive(Drop, starknet::Event)] struct CounterDecreased { amount: u128 @@ -242,10 +249,8 @@ struct CounterDecreased { ---- ==== -### Events emition - -Emit events via the `ContractState` type - +. Emit events via the `ContractState` type. For example: ++ [tabs] ==== old:: @@ -263,7 +268,7 @@ new:: ---- fn increase_counter(ref self: ContractState, amount: u128) { ... - self.emit(CounterIncreased { amount }); + self.emit(Event::CounterIncreased(CounterIncreased { amount })); } ---- ==== From 43fa2208440d8399f612b48b7aa651968903031f Mon Sep 17 00:00:00 2001 From: Steve Goodman Date: Thu, 20 Jul 2023 13:44:08 +0300 Subject: [PATCH 10/10] Changed title of page. --- .../Starknet/modules/architecture_and_concepts/nav.adoc | 2 +- .../pages/Cairo_on_Starknet/contract-syntax.adoc | 9 ++++----- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/components/Starknet/modules/architecture_and_concepts/nav.adoc b/components/Starknet/modules/architecture_and_concepts/nav.adoc index c498a1c14e..a6855116ae 100644 --- a/components/Starknet/modules/architecture_and_concepts/nav.adoc +++ b/components/Starknet/modules/architecture_and_concepts/nav.adoc @@ -33,4 +33,4 @@ ** Cairo on Starknet *** xref:Cairo_on_Starknet/cairo-1-and-sierra.adoc[Cairo 1.0 and Sierra] -*** xref:Cairo_on_Starknet/contract-syntax.adoc[Contract Syntax - Migration Guide] +*** xref:Cairo_on_Starknet/contract-syntax.adoc[Migrating a contract from Cairo 0 to Cairo] diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc index 6b875b3285..1384439c42 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Cairo_on_Starknet/contract-syntax.adoc @@ -1,14 +1,13 @@ -= Migrating syntax from Cairo 0 to Cairo += Migrating a contract from Cairo 0 to Cairo -With the link:https://github.com/starkware-libs/cairo/releases/tag/v2.0.0-rc0[v2.0.0 release] of -the Cairo compiler, the Starknet contract syntax has evolved, affecting the organization of -functions, storage, and events. +With the link:https://github.com/starkware-libs/cairo/releases/tag/v2.0.0-rc0[v2.0.0 release] of the Cairo compiler, the Starknet contract syntax has evolved, affecting the organization of functions, storage, and events. For more information on the latest syntax changes, see the link:https://community.starknet.io/t/cairo-1-contract-syntax-is-evolving/94794[community forum post]. .Prerequisites -* A contract written with the compiler v1.1.0 +* A contract written with the Cairo compiler v1.1.0 +* The most recent version of the Cairo compiler .Procedure