minor fixes to architecture overview

Author: LandauRaz

modules/architecture/pages/overview.adoc

@@ -4,9 +4,9 @@ Welcome to the Architecture section of the Starknet Docs! 🏛️
 
 Starknet is a coordinated system, with each element in its architecture playing a specific yet interconnected role.
 
-As with other blockchains, everything starts with an xref:accounts.adoc[account]. On Starknet, accounts are smart contracts — a model which is known as native account abstraction, and allows for flexible authorization logic like multisig, session keys, or passkey-based authentication, all without changes to the protocol itself. When users want to interact with the network, they send xref:transactions.adoc[transactions]. These can invoke contract functions, deploy new contracts, or register new classes, and may involve communication between Ethereum and Starknet — The latter are handled through xref:messaging.adoc[L1↔L2 messaging], enabling secure bridges such as xref:starkgate.adoc[].
+As with other blockchains, everything starts with an xref:accounts.adoc[account]. On Starknet, accounts are smart contracts, a model which is known as native account abstraction. This allows for flexible authorization logic like multisig, session keys, or passkey-based authentication — all without changes to the protocol itself. When users want to interact with the network, they send xref:transactions.adoc[transactions]. These can invoke contract functions, deploy new contracts, or register new classes. Some transactions may involve communication between Ethereum and Starknet, which are handled through xref:messaging.adoc[L1↔L2 messaging] and enable secure bridges such as xref:starkgate.adoc[].
 
-Periodically, transactions are collected and ordered into xref:blocks.adoc[blocks], which include a xref:cryptography.adoc[cryptographic] commitment the xref:state.adoc[state] of the network after executing them. To ensure that state transitions are valid, Starknet uses xref:sharp.adoc[SHARP] to generate and aggregate proofs of running the xref:os.adoc[SNOS] program. These proofs compress the entire block's execution into a succinct, verifiable artifact, which are submitted to Ethereum to be verified, so that Starknet's execution can be trusted without re-running it. Starknet also ensures access to the data involved in the computation through xref:data-availability.adoc[data availability], publishing compressed state diffs to Ethereum so the full state can be reconstructed and verified.
+Periodically, transactions are collected and ordered into xref:blocks.adoc[blocks], which include a xref:cryptography.adoc[cryptographic] commitment the xref:state.adoc[state] of the network after executing them. To ensure that state transitions are valid, Starknet uses xref:sharp.adoc[SHARP] to generate and aggregate proofs of running the xref:os.adoc[SNOS] program. These proofs compress the entire block's execution into a succinct artifact which are submitted to Ethereum to be verified, so that Starknet's execution can be trusted without re-running it. Starknet also ensures access to the data involved in the computation through xref:data-availability.adoc[data availability], publishing compressed state diffs to Ethereum so the full state can be reconstructed and verified.
 
 All of this — execution, proof generation, and L1 publishing — isn't free, which is where xref:fees.adoc[fees] come in. Users pay fees to cover the cost of using network resources, and these fees are paid in xref:strk.adoc[STRK], Starknet's native token. STRK is also used to power Starknet's xref:staking.adoc[staking protocol], where validators selected from STRK stakers help secure the sequencing layer and validate block production. This mechanism is designed to support decentralization and provide economic guarantees around block inclusion and ordering.