From 7715e09c2ba46fdc51dc77ff97bdc0133df3bda5 Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 2 Nov 2023 20:28:16 +0200 Subject: [PATCH 01/19] Update cairo-and-sierra.adoc --- .../pages/Smart_Contracts/cairo-and-sierra.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/cairo-and-sierra.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/cairo-and-sierra.adoc index 579a3eb9bc..3d0aa1209e 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/cairo-and-sierra.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/cairo-and-sierra.adoc @@ -31,7 +31,7 @@ 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. +A crucial property of every decentralized L2 is that the sequencers are guaranteed to be compensated for the 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. @@ -42,7 +42,7 @@ The obvious solution to the above predicament is to include such transactions in 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. +Cairo instruction 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 From 67542480e647bd0df777aa47a1bcb6ba127b410c Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 2 Nov 2023 20:30:09 +0200 Subject: [PATCH 02/19] Update contract-abi.adoc --- .../pages/Smart_Contracts/contract-abi.adoc | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc index 8d304eeeb6..a443f0f1db 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc @@ -373,7 +373,7 @@ For example: * It is no longer enforced that the `Event` enum variants are structs of the same name as the variant, they can now be a struct or an enum of any name. * Enum variants inside event ABI entries (entries in the abi with `"type": "event"` and `"kind": "enum"`) now have two possible kinds. Before `v2.3.0` it was always `"kind": "nested"`, now `"kind: "flat"` is also possible. -* `v2.3.0` is backwards compatible with version ≥ `2.0.0` ABI, so the same structure of the ABI is kept, while allowing flexibility. +* `v2.3.0` is backward compatible with version ≥ `2.0.0` ABI, so the same structure of the ABI is kept, while allowing flexibility. [NOTE] ==== @@ -386,7 +386,7 @@ With `v2.3.0` onwards, doing so may result in losing information. To illustrate this, consider the following example: ```rust -// high level code defining the events +//high-level code defining the events #[event] #[derive(Drop, starknet::Event)] @@ -470,7 +470,7 @@ When the contract emits the `TestCounterIncreased` event, for example by writing * One key based on the variant name: `sn_keccak(TestCounterIncreased)`. This information only appears in the `::Event` type entry in the ABI, as the name `TestCounterIncreased` does not appear in the `"kind": "struct"` ABI entry. This did not matter in previous versions when the variant name and type had to be equal. -* One data element based on the struct `CounterIncreased` which is associated to `TestCounterIncreased` via one of the `Event` type variants. +* One data element based on the struct `CounterIncreased` which is associated with `TestCounterIncreased` via one of the `Event` type variants. === Enum variants inside Event @@ -531,7 +531,7 @@ If a `TestEnum` event is being emitted via `self.emit(Event::TestEnum(MyEnum::Va When the event is emitted, the serialization to keys and data happens as follows: * Since the `TestEnum` variant has `kind` nested, add the first key: `sn_keccak(TestEnum)`, and the rest of the serialization to keys and data is done recursively via the `starknet::event` trait implementation of `MyEnum`. -* Next, you can handle a `"kind": "nested"` variant (previously it was `TestEnum`, now it’s `Var1`), which means you can add another key depending on the sub variant: `sn_keccak(Var1)`, and proceed to serialize according to the `starknet::event` +* Next, you can handle a `"kind": "nested"` variant (previously it was `TestEnum`, now it’s `Var1`), which means you can add another key depending on the sub-variant: `sn_keccak(Var1)`, and proceed to serialize according to the `starknet::event` implementation of `MyStruct`. * Finally, proceed to serialize `MyStruct`, which gives us a single data member. @@ -539,7 +539,7 @@ This results in `keys = [sn_keccak(TestEnum), sn_keccak(Var1)]` and `data=[5]` [NOTE] ==== -Allowing variants which are themselves enums (`TestEnum` is an enum variant here) means further nesting is possible. +Allowing variants that are themselves enums (`TestEnum` is an enum variant here) means further nesting is possible. ==== @@ -583,7 +583,7 @@ This will look as follows in the ABI (only the relevant parts are shown): "name": "::Event", "kind": "enum", "variants": [ - // ignoring all the other variants for berevity + // ignoring all the other variants for brevity { "name": "TestEnum", "type": "::MyEnum", @@ -621,7 +621,7 @@ As `TestEnum`, `Var1` and `Var2` are of kind `nested`, a selector should be adde === Flattened enum variants -You may not want to nest enums when serializing the event. For example, if you write an ERC20 as a component (not a contract) which is pluggable anywhere, you may not want the contract to modify the keys of known events such as `Transfer`. +You may not want to nest enums when serializing the event. For example, if you write an ERC20 as a component (not a contract) that is pluggable anywhere, you may not want the contract to modify the keys of known events such as `Transfer`. To avoid nesting, write the following high level code: @@ -761,7 +761,7 @@ In Cairo v2, a dedicated type for the contract's events was introduced. Currentl The `Event` enum variants appear in the ABI under `"type" = "event"` rather than regular structs. -For such entries, each member has an additional `kind` field which specifies how the serialization into keys and data takes place: +For such entries, each member has an additional `kind` field that specifies how the serialization into keys and data takes place: * If the kind is `key`, then this member or variant are serialized into the event's keys. * If the kind is `data`, then this member or variant are serialized into the event's data. From 7599cf730aa9ccc1283a306036cdeb35de600ac0 Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 2 Nov 2023 20:30:30 +0200 Subject: [PATCH 03/19] Update contract-address.adoc --- .../pages/Smart_Contracts/contract-address.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-address.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-address.adoc index 168414430f..899ecb0ddb 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-address.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-address.adoc @@ -28,6 +28,6 @@ A random `salt` ensures unique addresses for smart contract deployments, prevent It also thwarts replay attacks by influencing the transaction hash with a unique sender address. ==== -You can find more detail of the address computation in the https://github.com/starkware-libs/cairo-lang/blob/ed6cf8d6cec50a6ad95fa36d1eb4a7f48538019e/src/starkware/starknet/services/api/gateway/contract_address.py#L12[Cairo code repository]. +You can find more details of the address computation in the https://github.com/starkware-libs/cairo-lang/blob/ed6cf8d6cec50a6ad95fa36d1eb4a7f48538019e/src/starkware/starknet/services/api/gateway/contract_address.py#L12[Cairo code repository]. From c92b61f3c96d652710f4fffb806ba18d981fe4a5 Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 2 Nov 2023 20:31:06 +0200 Subject: [PATCH 04/19] Update contract-classes.adoc --- .../pages/Smart_Contracts/contract-classes.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-classes.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-classes.adoc index 4791f1219a..ba9b7eef02 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-classes.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-classes.adoc @@ -21,7 +21,7 @@ To deploy new instances of a previously declared class, use the `deploy` system To use the functionality of a declared class, without deploying an instance of that class, you can use the `library_call` system call. This system call is an analogue of Ethereum's low-level `delegatecall` function in the world of classes. The `library_call` system call enables you to use class code directly, instead of having a placeholder contract deployed, which is used only for its code. -== Additonal resources +== Additional resources * xref:architecture_and_concepts:Smart_Contracts/class-hash.adoc[Class hash] * xref:architecture_and_concepts:Network_Architecture/transactions.adoc#declare-transaction[`declare` transaction] From 61fdf20e748043e66afe3f0ce00fa1da0d96f451 Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 2 Nov 2023 20:31:54 +0200 Subject: [PATCH 05/19] Update contract-storage.adoc --- .../pages/Smart_Contracts/contract-storage.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-storage.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-storage.adoc index b36fc5ce2b..28f58b8a5b 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-storage.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-storage.adoc @@ -33,7 +33,7 @@ use starknet::syscalls::storage_write_syscall; [id="storage_variables"] == Storage variables -The most common way for interacting with a contract's storage is through storage variables. +The most common way to interact with a contract's storage is through storage variables. The `@storage_var` decorator declares a variable that will be kept as part of the contract storage. The variable can consist of a single felt, or it can be a mapping from multiple arguments to a tuple of felts or structs. From 24328b38d52d0f5779dcf62f137713f213c84192 Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 2 Nov 2023 20:37:08 +0200 Subject: [PATCH 06/19] Update hash-functions.adoc --- .../pages/Cryptography/hash-functions.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Cryptography/hash-functions.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Cryptography/hash-functions.adoc index 45b8a1589e..261ebf69fa 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Cryptography/hash-functions.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Cryptography/hash-functions.adoc @@ -27,7 +27,7 @@ in order to fit into a field element). [id="poseidon_hash"] == Poseidon hash -link:https://www.poseidon-hash.info/[Poseidon] is a family of hash functions designed for being very efficient as algebraic circuits. As such, they may be very useful in ZK proving systems such as STARKs and others. +link:https://www.poseidon-hash.info/[Poseidon] is a family of hash functions designed to be very efficient as algebraic circuits. As such, they may be very useful in ZK proving systems such as STARKs and others. Poseidon is a sponge construction based on the Hades permutation. Starknet's version of Poseidon is based on a three element state permutation (see exact parameters below). From ec0f1bc1e3852f96056ed6f8a570ef19ff347274 Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 2 Nov 2023 21:31:45 +0200 Subject: [PATCH 07/19] Update starknet-state.adoc --- .../pages/Network_Architecture/starknet-state.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Network_Architecture/starknet-state.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Network_Architecture/starknet-state.adoc index 266dda368a..6082c6bb77 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Network_Architecture/starknet-state.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Network_Architecture/starknet-state.adoc @@ -112,7 +112,7 @@ stem:[$path$] is an integer in stem:[$[0, 2^{length}-1\]$], and the binary expan 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). -For a node with stem:[$length>0$], following stem:[$path$] leads the highest node whose both right and left child are none empty. +For a node with stem:[$length>0$], the following stem:[$path$] leads the highest node whose both right and left child are none empty. ==== The following rules specify how the tree is constructed from a given set of leaves: From 20a1569756de44eea04681fd6df5861a052f964a Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 2 Nov 2023 21:35:19 +0200 Subject: [PATCH 08/19] Update starkli.adoc --- components/Starknet/modules/cli/pages/starkli.adoc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/components/Starknet/modules/cli/pages/starkli.adoc b/components/Starknet/modules/cli/pages/starkli.adoc index 85aa823cce..a5e9a6122b 100644 --- a/components/Starknet/modules/cli/pages/starkli.adoc +++ b/components/Starknet/modules/cli/pages/starkli.adoc @@ -3,7 +3,7 @@ [WARNING] ==== -The Starknet CLI is deprecated in favour of the xref:tools:devtools.adoc#starkli[StarkLi CLI]. +The Starknet CLI is deprecated in favor of the xref:tools:devtools.adoc#starkli[StarkLi CLI]. ==== [id="basic_command_line_syntax"] @@ -70,7 +70,7 @@ When working with the CLI, you can manually set the endpoints for the gateways t interact with Starknet, by including the following options: `--feeder_gateway_url`:: Sets the custom endpoint for read commands. -`--gateway_url`:: Sets the custom endpoint for write commands. +`--gateway_url`:: Sets the custom endpoint for writing commands. The following are the endpoints for Starknet testnet and Mainnet: @@ -210,7 +210,7 @@ $ export STARKNET_WALLET=starkware.starknet.wallets.open_zeppelin.OpenZeppelinAc [CAUTION] ==== -Using the builtin wallet providers that are part of the cairo-lang package (starkware.starknet.wallets...) is _not secure_ (for example, the private key may be kept not encrypted and without backup in your home directory). You should only use them if you’re not overly concerned with losing access to your accounts (for example, for testing purposes). +Using the built-in wallet providers that are part of the cairo-lang package (starkware.starknet.wallets...) is _not secure_ (for example, the private key may be kept not encrypted and without backup in your home directory). You should only use them if you’re not overly concerned with losing access to your accounts (for example, for testing purposes). ==== [id="starknet-estimate_fee"] @@ -387,4 +387,4 @@ The possible statuses of a transaction are: * `ACCEPTED_ON_L2` * `ACCEPTED_ON_L1` -Refer to xref:architecture_and_concepts:Network_Architecture/transaction-life-cycle.adoc[this] section for more information about the transaction lifecycle. \ No newline at end of file +Refer to xref:architecture_and_concepts:Network_Architecture/transaction-life-cycle.adoc[this] section for more information about the transaction lifecycle. From 8bd0457e7aa8f3f57a52815195b0a2a9025cc71d Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 2 Nov 2023 21:36:50 +0200 Subject: [PATCH 09/19] Update declare_a_smart_contract.adoc --- .../modules/quick_start/pages/declare_a_smart_contract.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/components/Starknet/modules/quick_start/pages/declare_a_smart_contract.adoc b/components/Starknet/modules/quick_start/pages/declare_a_smart_contract.adoc index 40f9559929..6de3a6a0c1 100644 --- a/components/Starknet/modules/quick_start/pages/declare_a_smart_contract.adoc +++ b/components/Starknet/modules/quick_start/pages/declare_a_smart_contract.adoc @@ -12,7 +12,7 @@ starkli --version scarb --version ---- -If either of the above commands fail, please visit xref:environment_setup.adoc[Setting up your environment]. +If either of the above commands fails, please visit xref:environment_setup.adoc[Setting up your environment]. == Introduction From 0f704a7aa6ad8a36edfefe0cb6895def9311f166 Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 2 Nov 2023 21:38:38 +0200 Subject: [PATCH 10/19] Update juno_versions.adoc --- .../modules/starknet_versions/pages/juno_versions.adoc | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/components/Starknet/modules/starknet_versions/pages/juno_versions.adoc b/components/Starknet/modules/starknet_versions/pages/juno_versions.adoc index ba97b36aa9..f37a4e5a2b 100644 --- a/components/Starknet/modules/starknet_versions/pages/juno_versions.adoc +++ b/components/Starknet/modules/starknet_versions/pages/juno_versions.adoc @@ -4,7 +4,7 @@ image::juno_banner.png[width=800] -Juno is a golang Starknet node implementation by https://nethermind.io/[Nethermind] with the aim of decentralising Starknet. +Juno is a golang Starknet node implementation by https://nethermind.io/[Nethermind] with the aim of decentralizing Starknet. See the official https://github.com/NethermindEth/juno[Juno GitHub repository] for more details. @@ -118,7 +118,7 @@ This release adds support for the upcoming Starknet v0.12.1 upgrade and includes === Fixed -* Resolved issues causing context cancelled errors in write RPC methods +* Resolved issues causing context canceled errors in writing RPC methods * Mapped gateway errors to write API RPC errors, improving error handling == https://github.com/NethermindEth/juno/releases/tag/v0.4.1[v0.4.1] @@ -253,7 +253,7 @@ This is Juno's first release (compatible with Starknet `v0.10.3`) with the follo * Starknet state construction and storage using a path-based Merkle Patricia trie. * Pedersen and `starknet_keccak` hash implementation over starknet field. -* Feeder gateway synchronisation of Blocks, Transactions, Receipts, State Updates and Classes. +* Feeder gateway synchronization of Blocks, Transactions, Receipts, State Updates and Classes. * Block and Transaction hash verification. * JSON-RPC Endpoints: ** `starknet_chainId` @@ -265,4 +265,4 @@ This is Juno's first release (compatible with Starknet `v0.10.3`) with the follo ** `starknet_getTransactionReceipt` ** `starknet_getBlockTransactionCount` ** `starknet_getTransactionByBlockIdAndIndex` -** `starknet_getStateUpdate` \ No newline at end of file +** `starknet_getStateUpdate` From e2d2549630c5f016e6e6dc1503a86304ad251658 Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 2 Nov 2023 21:40:29 +0200 Subject: [PATCH 11/19] Update pathfinder_versions.adoc --- .../modules/starknet_versions/pages/pathfinder_versions.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/components/Starknet/modules/starknet_versions/pages/pathfinder_versions.adoc b/components/Starknet/modules/starknet_versions/pages/pathfinder_versions.adoc index 7c34ebb57f..47c1c44395 100644 --- a/components/Starknet/modules/starknet_versions/pages/pathfinder_versions.adoc +++ b/components/Starknet/modules/starknet_versions/pages/pathfinder_versions.adoc @@ -56,7 +56,7 @@ See the official https://github.com/eqlabs/pathfinder[Pathfinder Github reposito - `starknet_estimateMessageFee` for JSON-RPC v0.3.1 to estimate message fee from L1 handler. - sync-related metrics - `current_block`: the currently sync'd block height of the node - - `highest_block`: the height of the block chain + - `highest_block`: the height of the blockchain - `block_time`: timestamp difference between the current block and its parent - `block_latency`: delay between current block being published and sync'd locally - `block_download`: time taken to download current block's data excluding classes @@ -395,4 +395,4 @@ This release includes an update to the cairo-vm embedded in pathfinder in order Since these changes are not yet live on testnet nor mainnet, this means upgrading to this release will cause deviations between what pathfinder outputs and what can be expected on the network. More specifically, `starknet_estimateFee` will compute different fees until the network has upgraded to xref:documentation:starknet_versions:version_notes.adoc#version0.10.2[Starknet v0.10.2]. If you don't need the RPC route changes, it may be pertinent to delay updating until closer to the xref:documentation:starknet_versions:version_notes.adoc#version0.10.2[v0.10.2] release dates on testnet and mainnet. The expected timeline for these upgrades is ~17/11 for testnets and ~24/11 for mainnet. -==== \ No newline at end of file +==== From f54cb02f189d8418104629d0cc203bee7abbe82c Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Thu, 2 Nov 2023 22:49:50 +0200 Subject: [PATCH 12/19] fix typo doc_guidelines.adoc --- contributing_to_docs/doc_guidelines.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contributing_to_docs/doc_guidelines.adoc b/contributing_to_docs/doc_guidelines.adoc index 9a2d4af149..f701987143 100644 --- a/contributing_to_docs/doc_guidelines.adoc +++ b/contributing_to_docs/doc_guidelines.adoc @@ -338,7 +338,7 @@ Do not include link:https://docs.asciidoctor.org/asciidoc/latest/directives/incl You can use AsciiDoc callouts in the source code file. Comment out the callout in the YAML file to ensure that file can still be parsed as valid YAML. -Asciidoctor recognises the commented callout and renders it correctly in the output. +Asciidoctor recognizes the commented callout and renders it correctly in the output. For example: [source,yaml] @@ -511,7 +511,7 @@ $ ---- root@17617744386d:/app# ./player.py ---- -* Avoid using markup in code block. If you must use any markup in code blocks, see the Asciidoctor documentation on source blocks and substitutions: +* Avoid using markup in the code block. If you must use any markup in code blocks, see the Asciidoctor documentation on source blocks and substitutions: ** link:https://docs.asciidoctor.org/asciidoc/latest/verbatim/source-blocks/[Source Code Blocks] ** link:https://docs.asciidoctor.org/asciidoc/latest/subs/[Substitutions] + From bf73fda7a9b64f894ad78a549c2dd4a028e1225f Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Wed, 15 Nov 2023 18:12:40 +0200 Subject: [PATCH 13/19] fix contract-abi.adoc Co-authored-by: Steve Goodman <39279277+stoobie@users.noreply.github.com> --- .../pages/Smart_Contracts/contract-abi.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc index a443f0f1db..73a242ddb5 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc @@ -621,7 +621,7 @@ As `TestEnum`, `Var1` and `Var2` are of kind `nested`, a selector should be adde === Flattened enum variants -You may not want to nest enums when serializing the event. For example, if you write an ERC20 as a component (not a contract) that is pluggable anywhere, you may not want the contract to modify the keys of known events such as `Transfer`. +You may not want to nest enums when serializing the event. For example, if you write an ERC-20 as a component, not a contract, that is pluggable anywhere, you might not want the contract to modify the keys of known events such as `Transfer`. To avoid nesting, write the following high level code: From 825e4648328de5b962b0f7292b287b6790611d9f Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Wed, 15 Nov 2023 18:12:52 +0200 Subject: [PATCH 14/19] fix starkli.adoc Co-authored-by: Steve Goodman <39279277+stoobie@users.noreply.github.com> --- components/Starknet/modules/cli/pages/starkli.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/components/Starknet/modules/cli/pages/starkli.adoc b/components/Starknet/modules/cli/pages/starkli.adoc index a5e9a6122b..74964aff26 100644 --- a/components/Starknet/modules/cli/pages/starkli.adoc +++ b/components/Starknet/modules/cli/pages/starkli.adoc @@ -387,4 +387,4 @@ The possible statuses of a transaction are: * `ACCEPTED_ON_L2` * `ACCEPTED_ON_L1` -Refer to xref:architecture_and_concepts:Network_Architecture/transaction-life-cycle.adoc[this] section for more information about the transaction lifecycle. +For more information, see xref:architecture_and_concepts:Network_Architecture/transaction-life-cycle.adoc[Transaction lifecycle]. From c9c93a69a8714612365fd5c79ddf26de656f241c Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Wed, 15 Nov 2023 18:13:01 +0200 Subject: [PATCH 15/19] fix declare_a_smart_contract.adoc Co-authored-by: Steve Goodman <39279277+stoobie@users.noreply.github.com> --- .../modules/quick_start/pages/declare_a_smart_contract.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/components/Starknet/modules/quick_start/pages/declare_a_smart_contract.adoc b/components/Starknet/modules/quick_start/pages/declare_a_smart_contract.adoc index 6de3a6a0c1..953df4c7a1 100644 --- a/components/Starknet/modules/quick_start/pages/declare_a_smart_contract.adoc +++ b/components/Starknet/modules/quick_start/pages/declare_a_smart_contract.adoc @@ -12,7 +12,7 @@ starkli --version scarb --version ---- -If either of the above commands fails, please visit xref:environment_setup.adoc[Setting up your environment]. +If either of the above commands fails, see xref:environment_setup.adoc[Setting up your environment]. == Introduction From b009a37c8b299b5298f164cc78b785b1fd4e3310 Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Wed, 15 Nov 2023 18:13:09 +0200 Subject: [PATCH 16/19] fix doc_guidelines.adoc Co-authored-by: Steve Goodman <39279277+stoobie@users.noreply.github.com> --- contributing_to_docs/doc_guidelines.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contributing_to_docs/doc_guidelines.adoc b/contributing_to_docs/doc_guidelines.adoc index f701987143..cffe930e5e 100644 --- a/contributing_to_docs/doc_guidelines.adoc +++ b/contributing_to_docs/doc_guidelines.adoc @@ -511,7 +511,7 @@ $ ---- root@17617744386d:/app# ./player.py ---- -* Avoid using markup in the code block. If you must use any markup in code blocks, see the Asciidoctor documentation on source blocks and substitutions: +* Avoid using markup in a code block. If you must use any markup in code blocks, see the Asciidoctor documentation on source blocks and substitutions: ** link:https://docs.asciidoctor.org/asciidoc/latest/verbatim/source-blocks/[Source Code Blocks] ** link:https://docs.asciidoctor.org/asciidoc/latest/subs/[Substitutions] + From 269da836e83b7804035a38ea39340928b11c7d4d Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Wed, 15 Nov 2023 20:45:29 +0200 Subject: [PATCH 17/19] Update starkli.adoc --- components/Starknet/modules/cli/pages/starkli.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/components/Starknet/modules/cli/pages/starkli.adoc b/components/Starknet/modules/cli/pages/starkli.adoc index 74964aff26..5ae74cb58b 100644 --- a/components/Starknet/modules/cli/pages/starkli.adoc +++ b/components/Starknet/modules/cli/pages/starkli.adoc @@ -70,7 +70,7 @@ When working with the CLI, you can manually set the endpoints for the gateways t interact with Starknet, by including the following options: `--feeder_gateway_url`:: Sets the custom endpoint for read commands. -`--gateway_url`:: Sets the custom endpoint for writing commands. +`--gateway_url`:: Sets the custom endpoint for write commands. The following are the endpoints for Starknet testnet and Mainnet: From aeb9d276ad7102f09f70c7d2ffcebb61bdd289c0 Mon Sep 17 00:00:00 2001 From: iwantanode <87604944+tudorpintea999@users.noreply.github.com> Date: Wed, 15 Nov 2023 20:47:15 +0200 Subject: [PATCH 18/19] Update cairo-and-sierra.adoc --- .../pages/Smart_Contracts/cairo-and-sierra.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/cairo-and-sierra.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/cairo-and-sierra.adoc index 3d0aa1209e..275b0f7a9d 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/cairo-and-sierra.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/cairo-and-sierra.adoc @@ -42,7 +42,7 @@ The obvious solution to the above predicament is to include such transactions in 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 cannot be proven, as it translates to polynomial constraints that are not satisfiable. Any Casm execution that contains this instruction cannot be proven. +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 From a422d4082e9e0956e534244e5f409b1dda54a7ed Mon Sep 17 00:00:00 2001 From: Steve Goodman <39279277+stoobie@users.noreply.github.com> Date: Thu, 16 Nov 2023 09:46:38 +0200 Subject: [PATCH 19/19] Update components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc --- .../pages/Smart_Contracts/contract-abi.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc index 73a242ddb5..77d4335c12 100644 --- a/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc +++ b/components/Starknet/modules/architecture_and_concepts/pages/Smart_Contracts/contract-abi.adoc @@ -621,7 +621,7 @@ As `TestEnum`, `Var1` and `Var2` are of kind `nested`, a selector should be adde === Flattened enum variants -You may not want to nest enums when serializing the event. For example, if you write an ERC-20 as a component, not a contract, that is pluggable anywhere, you might not want the contract to modify the keys of known events such as `Transfer`. +You might not want to nest enums when serializing the event. For example, if you write an ERC-20 as a component, not a contract, that is pluggable anywhere, you might not want the contract to modify the keys of known events such as `Transfer`. To avoid nesting, write the following high level code: