Change the spelling of "StarkNet" to "Starknet" (#557)

* fix: link (#545)

* change StarkNet to Starknet

---------

Co-authored-by: Eric Nordelo <eric.nordelo39@gmail.com>

README.md

@@ -3,7 +3,7 @@
 [![Tests and linter](https://github.com/OpenZeppelin/cairo-contracts/actions/workflows/coverage.yml/badge.svg)](https://github.com/OpenZeppelin/cairo-contracts/actions/workflows/coverage.yml)
 [![codecov](https://codecov.io/github/OpenZeppelin/cairo-contracts/branch/main/graph/badge.svg?token=LFSZH8RPOL)](https://codecov.io/github/OpenZeppelin/cairo-contracts)
 
-**A library for secure smart contract development** written in Cairo for [StarkNet](https://starkware.co/product/starknet/), a decentralized ZK Rollup.
+**A library for secure smart contract development** written in Cairo for [Starknet](https://starkware.co/product/starknet/), a decentralized ZK Rollup.
 
 ## Usage
 
@@ -126,14 +126,14 @@ Check out the [full documentation site](https://docs.openzeppelin.com/contracts-
 
 ### Cairo
 
-- [StarkNet official documentation](https://www.cairo-lang.org/docs/hello_starknet/index.html#hello-starknet)
+- [Starknet official documentation](https://www.cairo-lang.org/docs/hello_starknet/index.html#hello-starknet)
 - [Cairo language documentation](https://www.cairo-lang.org/docs/hello_cairo/index.html#hello-cairo)
 - Perama's [Cairo by example](https://perama-v.github.io/cairo/by-example/)
 - [Cairo 101 workshops](https://www.youtube.com/playlist?list=PLcIyXLwiPilV5RBZj43AX1FY4FJMWHFTY)
 
 ### Nile
 
-- [Getting started with StarkNet using Nile](https://medium.com/coinmonks/starknet-tutorial-for-beginners-using-nile-6af9c2270c15)
+- [Getting started with Starknet using Nile](https://medium.com/coinmonks/starknet-tutorial-for-beginners-using-nile-6af9c2270c15)
 - [How to manage smart contract deployments with Nile](https://medium.com/@martriay/manage-your-starknet-deployments-with-nile-%EF%B8%8F-e849d40546dd)
 
 ## Development

docs/modules/ROOT/pages/access.adoc

@@ -388,7 +388,7 @@ bytes32 public constant SOME_ROLE = keccak256("SOME_ROLE")
 These identifiers take up 32 bytes (256 bits).
 
 Cairo field elements store a maximum of 252 bits.
-Even further, a declared _constant_ field element in a StarkNet contract stores even less (see https://github.com/starkware-libs/cairo-lang/blob/release-v0.6.1/src/starkware/cairo/lang/cairo_constants.py#L1[cairo_constants]).
+Even further, a declared _constant_ field element in a Starknet contract stores even less (see https://github.com/starkware-libs/cairo-lang/blob/release-v0.6.1/src/starkware/cairo/lang/cairo_constants.py#L1[cairo_constants]).
 With this discrepancy, this library maintains an agnostic stance on how contracts should create identifiers.
 Some ideas to consider:
 

docs/modules/ROOT/pages/accounts.adoc

@@ -2,13 +2,13 @@
 
 = Accounts
 
-Unlike Ethereum where accounts are directly derived from a private key, there's no native account concept on StarkNet.
+Unlike Ethereum where accounts are directly derived from a private key, there's no native account concept on Starknet.
 
 Instead, signature validation has to be done at the contract level.
 To relieve smart contract applications such as ERC20 tokens or exchanges from this responsibility, we make use of Account contracts to deal with transaction authentication.
 
-For a general overview of the account abstraction, see StarkWare's https://medium.com/starkware/starknet-alpha-0-10-0-923007290470[StarkNet Alpha 0.10].
-A more detailed discussion on the topic can be found in https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781[StarkNet Account Abstraction Part 1].
+For a general overview of the account abstraction, see StarkWare's https://medium.com/starkware/starknet-alpha-0-10-0-923007290470[Starknet Alpha 0.10].
+A more detailed discussion on the topic can be found in https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781[Starknet Account Abstraction Part 1].
 
 == Table of Contents
 
@@ -47,7 +47,7 @@ A more detailed discussion on the topic can be found in https://community.starkn
 
 The general workflow is:
 
-. Account contract is deployed to StarkNet.
+. Account contract is deployed to Starknet.
 . Signed transactions can now be sent to the Account contract which validates and executes them.
 
 In Python, this would look as follows:
@@ -125,7 +125,7 @@ Where:
 * `calldata_len` is the number of calldata parameters.
 * `calldata` is an array representing the function parameters.
 
-NOTE: The scheme of building multicall transactions within the `\\__execute__` method will change once StarkNet allows for pointers in struct arrays.
+NOTE: The scheme of building multicall transactions within the `\\__execute__` method will change once Starknet allows for pointers in struct arrays.
 In which case, multiple transactions can be passed to (as opposed to built within) `\\__execute__`.
 
 There's a fourth canonical entrypoint for accounts, the `\\__validate_deploy__` method. It is **only callable by the protocol** during the execution of a `DeployAccount` type of transaction, but not by any other contract. This entrypoint is for counterfactual deployments.
@@ -238,7 +238,7 @@ To simplify Account management, most of this is abstracted away with `MockSigner
 
 The `MockSigner` class in {test-signers}[signers.py] is used to perform transactions on a given Account, crafting the transaction and managing nonces.
 
-NOTE: StarkNet's testing framework does not currently support transaction invocations from account contracts. `MockSigner` therefore utilizes StarkNet's API gateway to manually execute the `InvokeFunction` for testing.
+NOTE: Starknet's testing framework does not currently support transaction invocations from account contracts. `MockSigner` therefore utilizes Starknet's API gateway to manually execute the `InvokeFunction` for testing.
 
 A `MockSigner` instance exposes the following methods:
 
@@ -582,7 +582,7 @@ Each preset differs on the signature type being used by the Account.
 
 === Account
 
-The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.1/src/openzeppelin/account/presets/Account.cairo[`Account`] preset uses StarkNet keys to validate transactions.
+The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.1/src/openzeppelin/account/presets/Account.cairo[`Account`] preset uses Starknet keys to validate transactions.
 
 === Eth Account
 
@@ -593,10 +593,10 @@ The https://github.com/OpenZeppelin/cairo-contracts/blob/release-v0.6.1/src/open
 Certain contracts like ERC721 or ERC1155 require a means to differentiate between account contracts and non-account contracts.
 For a contract to declare itself as an account, it should implement https://eips.ethereum.org/EIPS/eip-165[ERC165] as proposed in https://github.com/OpenZeppelin/cairo-contracts/discussions/100[#100].
 
-To be in compliance with ERC165 specifications, we calculate the account contract ID as the XOR of ``IAccount``'s equivalent EVM selectors (not StarkNet selectors).
+To be in compliance with ERC165 specifications, we calculate the account contract ID as the XOR of ``IAccount``'s equivalent EVM selectors (not Starknet selectors).
 This magic value has been tracking the changes of the still evolving Account interface standard, and **its current value is `0xa66bd575`**.
 
-Our ERC165 integration on StarkNet is inspired by OpenZeppelin's Solidity implementation of https://docs.openzeppelin.com/contracts/4.x/api/utils#ERC165Storage[ERC165Storage] which stores the interfaces that the implementing contract supports.
+Our ERC165 integration on Starknet is inspired by OpenZeppelin's Solidity implementation of https://docs.openzeppelin.com/contracts/4.x/api/utils#ERC165Storage[ERC165Storage] which stores the interfaces that the implementing contract supports.
 In the case of account contracts, querying `supportsInterface` of an account's address with the `IAccount` magic value should return `TRUE`.
 
 NOTE: For Account contracts, ERC165 support is static and does not require Account contracts to register.
@@ -605,15 +605,15 @@ NOTE: For Account contracts, ERC165 support is static and does not require Accou
 
 Account contracts can be extended by following the xref:extensibility.adoc#the_pattern[extensibility pattern].
 
-To implement custom account contracts, it's required by the StarkNet compiler that they include the three entrypoint functions `\\__validate__`, `\\__validate_declare__`, and `\\__execute__`.
+To implement custom account contracts, it's required by the Starknet compiler that they include the three entrypoint functions `\\__validate__`, `\\__validate_declare__`, and `\\__execute__`.
 
 `\\__validate__` and `\\__validate_declare__` should include the same signature validation method; whereas, `\\__execute__` should only handle the actual transaction. Incorporating a new validation scheme necessitates only that it's invoked by both `\\__validate__` and `\\__validate_declare__`.
 
 This is why the Account library comes with different flavors of signature validation methods like `is_valid_eth_signature` and the vanilla `is_valid_signature`.
 
 Account contract developers are encouraged to implement the https://github.com/OpenZeppelin/cairo-contracts/discussions/41[standard Account interface] and incorporate the custom logic thereafter.
 
-IMPORTANT: Due to current inconsistencies between the testing framework and the actual StarkNet network, extreme caution should be used when integrating new Account contracts.
+IMPORTANT: Due to current inconsistencies between the testing framework and the actual Starknet network, extreme caution should be used when integrating new Account contracts.
 Instances have occurred where account functionality tests pass and transactions execute correctly on the local node; yet, they fail on public networks.
 For this reason, it's highly encouraged that new account contracts are also deployed and tested on the public testnet.
 See https://github.com/OpenZeppelin/cairo-contracts/issues/386[issue #386] for more information.

docs/modules/ROOT/pages/erc1155.adoc

@@ -1,7 +1,7 @@
 = ERC1155
 
 The ERC1155 multi token standard is a specification for https://docs.openzeppelin.com/contracts/4.x/tokens#different-kinds-of-tokens[fungibility-agnostic] token contracts.
-The ERC1155 library implements an approximation of https://eips.ethereum.org/EIPS/eip-1155[EIP-1155] in Cairo for StarkNet.
+The ERC1155 library implements an approximation of https://eips.ethereum.org/EIPS/eip-1155[EIP-1155] in Cairo for Starknet.
 
 == Table of Contents
 
@@ -80,7 +80,7 @@ namespace IERC1155 {
 
 === ERC1155 Compatibility
 
-Although StarkNet is not EVM compatible, this implementation aims to be as close as possible to the ERC1155 standard in the following ways:
+Although Starknet is not EVM compatible, this implementation aims to be as close as possible to the ERC1155 standard in the following ways:
 
 * It uses Cairo's `uint256` instead of `felt`.
 * It returns `TRUE` as success.
@@ -202,9 +202,9 @@ In order to be sure a contract can safely accept ERC1155 tokens, said contract m
 Methods such as `safeTransferFrom` and `safeBatchTransferFrom` call the recipient contract's `onERC1155Received` or `onERC1155BatchReceived` method.
 If the contract fails to return the correct magic value, the transaction fails.
 
-StarkNet contracts that support safe transfers, however, must also support xref:introspection.adoc#erc165[ERC165] and include `supportsInterface` as proposed in https://github.com/OpenZeppelin/cairo-contracts/discussions/100[#100].
+Starknet contracts that support safe transfers, however, must also support xref:introspection.adoc#erc165[ERC165] and include `supportsInterface` as proposed in https://github.com/OpenZeppelin/cairo-contracts/discussions/100[#100].
 Transfer functions require a means of differentiating between account and non-account contracts.
-Currently, StarkNet does not support error handling from the contract level;
+Currently, Starknet does not support error handling from the contract level;
 therefore, the current ERC1155 implementation requires that all contracts that support safe ERC1155 transfers (both accounts and non-accounts) include the `supportsInterface` method.
 Further, `supportsInterface` should return `TRUE` if the recipient contract supports the `IERC1155Receiver` magic value `00x4e2312e0` (which invokes `onERC1155Received` and `onERC1155BatchReceived`).
 If the recipient contract supports the `IAccount` magic value, `supportsInterface` should return `TRUE`.

docs/modules/ROOT/pages/erc20.adoc

@@ -1,7 +1,7 @@
 = ERC20
 
 The ERC20 token standard is a specification for https://docs.openzeppelin.com/contracts/4.x/tokens#different-kinds-of-tokens[fungible tokens], a type of token where all the units are exactly equal to each other.
-The `ERC20.cairo` contract implements an approximation of https://eips.ethereum.org/EIPS/eip-20[EIP-20] in Cairo for StarkNet.
+The `ERC20.cairo` contract implements an approximation of https://eips.ethereum.org/EIPS/eip-20[EIP-20] in Cairo for Starknet.
 
 == Table of Contents
 
@@ -66,7 +66,7 @@ namespace IERC20 {
 
 === ERC20 compatibility
 
-Although StarkNet is not EVM compatible, this implementation aims to be as close as possible to the ERC20 standard, in the following ways:
+Although Starknet is not EVM compatible, this implementation aims to be as close as possible to the ERC20 standard, in the following ways:
 
 * It uses Cairo's `uint256` instead of `felt`.
 * It returns `TRUE` as success.
@@ -112,7 +112,7 @@ erc20 = await starknet.deploy(
 )
 ----
 
-As most StarkNet contracts, it expects to be called by another contract and it identifies it through `get_caller_address` (analogous to Solidity's `this.address`).
+As most Starknet contracts, it expects to be called by another contract and it identifies it through `get_caller_address` (analogous to Solidity's `this.address`).
 This is why we need an Account contract to interact with it.
 For example:
 

docs/modules/ROOT/pages/erc721.adoc

@@ -1,7 +1,7 @@
 = ERC721
 
 The ERC721 token standard is a specification for https://docs.openzeppelin.com/contracts/4.x/tokens#different-kinds-of-tokens[non-fungible tokens], or more colloquially: NFTs.
-The `ERC721.cairo` contract implements an approximation of https://eips.ethereum.org/EIPS/eip-721[EIP-721] in Cairo for StarkNet.
+The `ERC721.cairo` contract implements an approximation of https://eips.ethereum.org/EIPS/eip-721[EIP-721] in Cairo for Starknet.
 
 == Table of Contents
 
@@ -88,7 +88,7 @@ namespace IERC721 {
 
 === ERC721 Compatibility
 
-Although StarkNet is not EVM compatible, this implementation aims to be as close as possible to the ERC721 standard in the following ways:
+Although Starknet is not EVM compatible, this implementation aims to be as close as possible to the ERC721 standard in the following ways:
 
 * It uses Cairo's `uint256` instead of `felt`.
 * It returns `TRUE` as success.
@@ -128,7 +128,7 @@ Use cases go from artwork, digital collectibles, physical property, and many mor
 
 To show a standard use case, we'll use the `ERC721Mintable` preset which allows for only the owner to `mint` and `burn` tokens.
 To create a token you need to first deploy both Account and ERC721 contracts respectively.
-As most StarkNet contracts, ERC721 expects to be called by another contract and it identifies it through `get_caller_address` (analogous to Solidity's `this.address`).
+As most Starknet contracts, ERC721 expects to be called by another contract and it identifies it through `get_caller_address` (analogous to Solidity's `this.address`).
 This is why we need an Account contract to interact with it.
 
 Considering that the ERC721 constructor method looks like this:
@@ -232,9 +232,9 @@ In order to be sure a contract can safely accept ERC721 tokens, said contract mu
 Methods such as `safeTransferFrom` and `safeMint` call the recipient contract's `onERC721Received` method.
 If the contract fails to return the correct magic value, the transaction fails.
 
-StarkNet contracts that support safe transfers, however, must also support xref:introspection.adoc#erc165[ERC165] and include `supportsInterface` as proposed in https://github.com/OpenZeppelin/cairo-contracts/discussions/100[#100].
+Starknet contracts that support safe transfers, however, must also support xref:introspection.adoc#erc165[ERC165] and include `supportsInterface` as proposed in https://github.com/OpenZeppelin/cairo-contracts/discussions/100[#100].
 `safeTransferFrom` requires a means of differentiating between account and non-account contracts.
-Currently, StarkNet does not support error handling from the contract level;
+Currently, Starknet does not support error handling from the contract level;
 therefore, the current ERC721 implementation requires that all contracts that support safe ERC721 transfers (both accounts and non-accounts) include the `supportsInterface` method.
 Further, `supportsInterface` should return `TRUE` if the recipient contract supports the `IERC721Receiver` magic value `0x150b7a02` (which invokes `onERC721Received`).
 If the recipient contract supports the `IAccount` magic value `0x50b70dcb`, `supportsInterface` should return `TRUE`.
@@ -256,7 +256,7 @@ namespace IERC721Receiver {
 
 === Supporting Interfaces
 
-In order to ensure EVM/StarkNet compatibility, this ERC721 implementation does not calculate interface identifiers.
+In order to ensure EVM/Starknet compatibility, this ERC721 implementation does not calculate interface identifiers.
 Instead, the interface IDs are hardcoded from their EVM calculations.
 On the EVM, the interface ID is calculated from the selector's first four bytes of the hash of the function's signature while Cairo selectors are 252 bytes long.
 Due to this difference, hardcoding EVM's already-calculated interface IDs is the most consistent approach to both follow the EIP165 standard and EVM compatibility.

docs/modules/ROOT/pages/extensibility.adoc

@@ -21,7 +21,7 @@ Therefore writing complex smart contracts is a delicate task.
 
 One of the best approaches to minimize introducing bugs is to reuse existing, battle-tested code, a.k.a.
 using libraries.
-But code reutilization in StarkNet's smart contracts is not easy:
+But code reutilization in Starknet's smart contracts is not easy:
 
 * Cairo has no explicit smart contract extension mechanisms such as inheritance or composability.
 * Using imports for modularity can result in clashes (more so given that arguments are not part of the selector), and lack of overrides or aliasing leaves no way to resolve them.

docs/modules/ROOT/pages/index.adoc

@@ -1,6 +1,6 @@
 = Contracts for Cairo
 
-*A library for secure smart contract development* written in Cairo for https://starkware.co/product/starknet/[StarkNet], a decentralized ZK Rollup.
+*A library for secure smart contract development* written in Cairo for https://starkware.co/product/starknet/[Starknet], a decentralized ZK Rollup.
 
 == Usage
 

docs/modules/ROOT/pages/introspection.adoc

@@ -33,7 +33,7 @@ using `IERC165_ID` instead of `0x01ffc9a7`.
 
 === Interface calculations
 
-In order to ensure EVM/StarkNet compatibility, interface identifiers are not calculated on StarkNet.
+In order to ensure EVM/Starknet compatibility, interface identifiers are not calculated on Starknet.
 Instead, the interface IDs are hardcoded from their EVM calculations.
 On the EVM, the interface ID is calculated from the selector's first four bytes of the hash of the function's signature while Cairo selectors are 252 bytes long.
 Due to this difference, hardcoding EVM's already-calculated interface IDs is the most consistent approach to both follow the EIP165 standard and EVM compatibility.