Merge branch 'dev' into steve/devtools/add_table

CHANGELOG.md

@@ -2,6 +2,8 @@
 
 All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.
 
+### [0.1.326](https://github.com/starknet-io/starknet-docs/compare/v0.1.324...v0.1.326) (2023-09-26)
+
 ### [0.1.325](https://github.com/starknet-io/starknet-docs/compare/v0.1.324...v0.1.325) (2023-09-20)
 
 ### [0.1.324](https://github.com/starknet-io/starknet-docs/compare/v0.1.323...v0.1.324) (2023-09-20)

components/Starknet/modules/ROOT/pages/index.adoc

@@ -5,4 +5,3 @@ Starknet is a permissionless, decentralized validity rollup, also known as a zer
 compromising Ethereum’s composability and security - thanks to Starknet’s reliance on the safest and most scalable cryptographic proof system: STARK.
 
 Starknet contracts and the Starknet OS are written in Cairo – supporting the deployment and scaling of any use case, whatever the business logic.
-w

components/Starknet/modules/architecture_and_concepts/pages/Accounts/introduction.adoc

@@ -3,46 +3,50 @@
 
 An account represents a user onchain, and enables that user to interact with the blockchain.
 
-Through an account, you may send transactions and interact with other contracts. To "own" an onchain asset (e.g. ERC20 token or an NFT), it has to be associated with your account address.
+Through an account, you can send transactions and interact with other contracts. In order for you to own an onchain asset, such as an ERC-20 token or an NFT, that asset must be associated with your account address.
 
 [id="ethereum_account_structure"]
 == Ethereum account structure
 
 Within Ethereum individual user accounts are known as Externally Owned Accounts (EOAs). 
 
-EOAs differ from smart contracts in that they are not controlled by code. An EOA is determined by a pair of private and public keys. 
+EOAs differ from smart contracts in that EOAs are not controlled by code, but rather by a pair of private and public keys.
 
 The account's address is derived from those keys and only by possessing the private key can you initiate transactions from an account. While Ethereum contracts are _passive_, that is, they can only change if they were called inside a transaction, EOAs can initiate transactions.
 
-While simple, EOAs have a major drawback – there's no flexibility in the account behavior, i.e. the
-Ethereum protocol dictates what it means for a transaction initiated by an EOA to be valid (the
-signature scheme is fixed). In particular, control over the private key gives complete control over
-the account. Although this is theoretically a secure method of account management, in practice it has some drawbacks, such as requiring you to keep your seed phrase secure yet accessible to you and limited flexibility surrounding wallet functionality.
+While simple, because the signature scheme is fixed, EOAs have some drawbacks, including the following:
 
-EIP-4337, a design proposal for Ethereum outlines _account abstraction_ whereby all accounts are managed via a dedicated smart contract on the Ethereum network, as a way to increase flexibility and usability. You can add custom logic on top of the basic EOA functionality, thereby bringing account abstraction into Ethereum.
+* Control over the private key gives complete control over
+the account, so you must keep your seed phrase secure yet accessible.
+* Limited flexibility surrounding wallet functionality
+
+EIP-4337 is a design proposal for Ethereum that outlines _account abstraction_, whereby all accounts are managed via a dedicated smart contract on the Ethereum network, as a way to increase flexibility and usability. You can add custom logic on top of the basic EOA functionality, thereby bringing account abstraction into Ethereum.
 
 [id="account_abstraction"]
 == What is Account Abstraction?
 
-The idea behind account abstraction is to allow more flexibility in the management of accounts rather than have their behavior determined at the protocol level. This can be achieved by introducing account contracts - smart contracts with programmable logic that determines the user's account.
+Account abstraction enables more flexible account management. Rather than the protocol determining an account's behavior, an _account contract_, which is a smart contract with programmable logic, defines a user's account.
 
 Using account abstraction you can now program how your account functions. 
 
 For example, you can:
 
-*   Determine what it means for a signature to be valid or what contracts your account is allowed to interact with. This is known as "signature abstraction"
+* Determine what it means for a signature to be valid, or what contracts your account is allowed to interact with. This is known as _signature abstraction_.
 
-*   Pay transaction fees in different tokens - this is sometimes known as "fee abstraction"
+* Pay transaction fees in different tokens. This is known as _fee abstraction_.
 
-*   Design your own replay protection mechanism and allow sending multiple uncoupled transactions in parallel. Compare this to the sequential nonce solution used in Ethereum, which results in transactions being inherently sequential, i.e., even if you want to send two transactions in parallel, you must wait for some confirmation on the first before sending the second. Otherwise, the second transaction may be rejected due to an invalid nonce. With account abstraction, one can discuss different solutions that bypass the need for a sequential nonce. This is known as "nonce abstraction"
+* Design your own replay protection mechanism and allow sending multiple uncoupled transactions in parallel.
++
+In Ethereum, you cannot send two transactions in parallel, you must wait for confirmation of the first before sending the second. Otherwise, the second transaction can be rejected due to an invalid nonce. With account abstraction, a sequential nonce is not required. This is known as _nonce abstraction_.
 
-Today, Starknet offers signature abstraction. In the future, we will enrich the current account abstraction design (see e.g. the https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781[paymaster proposal] for fee abstraction).
+Today, Starknet offers signature abstraction. In the future, we will enrich the current account abstraction design. For example, see the link:https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781[paymaster proposal] for fee abstraction in the Starknet Community Forum.
 
 [id="examples"]
 == Examples of customizing account functionality
 
 Two examples of how you might program an account to function using account abstraction are:
 
+[horizontal]
 Social recovery:: A process where if you lose your wallet, you are able to retrieve it via a selected social network, vastly improving the typical experience of wallet recovery.
 
-Operating your account via facial recognition:: With signature abstraction, you can use your phone's native hardware to sign transactions, making it practically impossible to take control of another user's account (even in the case of the phone itself being stolen).
+Operating your account via facial recognition:: With signature abstraction, you can use your phone's native hardware to sign transactions, making it practically impossible to take control of another user's account, even if your phone is stolen.

components/Starknet/modules/architecture_and_concepts/pages/Network_Architecture/token-bridge.adoc

@@ -7,7 +7,7 @@ StarkGate is the Ethereum↔Starknet token bridge developed by StarkWare. Each s
 
 A bridge enables you to fund your L2 wallet with ETH and ERC-20 tokens that reside on L1.
 
-Terms such as _deposit_, _transact_, and _transfer_ refer to operations using a bridge, but be aware that ETH and ERC-20 tokens never actually leave Ethereum.
+For simplicity, we use terms such as _deposit_, _transact_, and _transfer_ to refer to various operations involving a bridge, even though ETH and ERC-20 tokens never actually leave Ethereum.
 
 [id="starkgate_alpha_limitations"]
 == StarkGate Alpha limitations

contributing_to_docs/starknet_docs_style_guide.adoc

@@ -107,7 +107,7 @@ If a term doesn't appear here, refer to the following guides, in order:
 [#D]
 === D
 
-==== Drop-down
+==== drop-down
 
 Use the guidance for link:https://developers.google.com/style/word-list#drop-down[_drop-down_ in the _Google developer documentation style guide_].
 
@@ -117,10 +117,10 @@ Use the guidance for link:https://developers.google.com/style/word-list#drop-dow
 [#T]
 === T
 
-==== Transaction (Tx)
+==== transaction
 
-"Tx" can be used as an abbreviation for the word "Transaction".
+The default is to use the full word _transaction_ in normal text. You can use _tx_ as an abbreviation for the word _transaction_ if it improves readability.
 
-*Reasoning:* This word is used frequently and warrants a short form equivalent.
+*Reasoning:* This abbreviation is well known in the industry.