Be consistent about on-chain and off-chain

docs/tutorials/security.md

@@ -13,15 +13,15 @@ Users can interact directly with the blockchain network without any third-party
 
 On the other hand, cryptography, especially hashing, ensures that the data is never altered or removed without agreement from the supporting network. Clients do not have to trust a centralized provider; implicit trust is built into the blockchain.
 
-### Off chain attacks
+### Off-chain attacks
 
-Offchain attacks are a serious threat to the security and reliability of decentralized applications. They can exploit various vulnerabilities in the design, implementation, or deployment of smart contracts or user interfaces. Some examples of offchain attacks are:
+Off-chain attacks are a serious threat to the security and reliability of decentralized applications. They can exploit various vulnerabilities in the design, implementation, or deployment of smart contracts or user interfaces. Some examples of off-chain attacks are:
 
 - Bugs: A bug is a flaw or error in the code or logic of a smart contract or a frontend. For instance, a frontend may point to a non-existent smart contract address or invoke an entrypoint with incorrect parameters. This can result in loss of funds, incorrect execution, or denial of service. Bugs can be avoided by proper testing, auditing, and maintenance of the code.
 - Impersonation: An impersonation attack is when an attacker pretends to be someone else, such as a legitimate service provider, a trusted party, or a user. For example, an attacker may create a phishing UI that mimics the appearance and functionality of a real frontend, but sends the user's funds or data to the attacker's address. Alternatively, an attacker may deploy a copy of a contract on the network, with slight modifications that benefit the attacker. Impersonation attacks can be prevented by verifying the identity and authenticity of the parties involved, such as using digital signatures, checksums, or domain verification.
 - Replay attacks: A replay attack is when an attacker reuses a valid transaction from one context to another, without the consent or knowledge of the original sender. For example, an attacker may copy a L1 transaction to a L2 transaction, and execute it on a different chain or layer. This can result in double-spending, unauthorized actions, or inconsistent states. Replay attacks can be mitigated by introducing nonce and chain_id fields in the transactions, which ensure that each transaction is unique and valid for a specific context. Alternatively, a timestamp can be used as a nonce, which makes it easy to detect outdated or replayed transactions.
-- Trusting and no verifying: This situation occurs when a user or a contract blindly accepts or relies on data or information from an offchain source without verifying its accuracy or integrity. For example, a user may trust an offchain API that provides market data from an oracle or an exchange without checking if the data is correct, manipulated, or even inexistent. Similarly, a user may sign a transaction payload from a wallet without inspecting its content or destination. Trust and no verification can lead to false assumptions, incorrect decisions, or malicious actions. Trust and no verification can be avoided by applying the principle of "trust but verify," which means that any offchain data or information should be validated by multiple sources, cross-checked with onchain data, or confirmed by the user before using it.
-- FrontRunning and MEV (Maximum Extractable Value): MEV is an economic phenomenon that can be exploited by miners, validators, and sequencers who can arbitrarily include, exclude, or re-order transactions within the blocks they produce. MEV strategies involve executing a set of on-chain interactions prepared by offchain actors like humans or bots.
+- Trusting and no verifying: This situation occurs when a user or a contract blindly accepts or relies on data or information from an off-chain source without verifying its accuracy or integrity. For example, a user may trust an off-chain API that provides market data from an oracle or an exchange without checking if the data is correct, manipulated, or even inexistent. Similarly, a user may sign a transaction payload from a wallet without inspecting its content or destination. Trust and no verification can lead to false assumptions, incorrect decisions, or malicious actions. Trust and no verification can be avoided by applying the principle of "trust but verify," which means that any off-chain data or information should be validated by multiple sources, cross-checked with on-chain data, or confirmed by the user before using it.
+- FrontRunning and MEV (Maximum Extractable Value): MEV is an economic phenomenon that can be exploited by miners, validators, and sequencers who can arbitrarily include, exclude, or re-order transactions within the blocks they produce. MEV strategies involve executing a set of on-chain interactions prepared by off-chain actors like humans or bots.
   It can be done by the baker itself because the list is known in advance at each period, or by any bots listening to the gossip network.
   Examples of common MEV strategies:
 
@@ -35,9 +35,9 @@ Offchain attacks are a serious threat to the security and reliability of decentr
   - Reordering of transactions can be tackled through honest bakers or using Flashbots/Flashbake. Flashbake is proposing a private, off-chain system to send a transaction to a baker. It benefits the Tezos network and its users in a few ways: less mempool congestion and quicker inclusion of not publicly visible transactions.
   - Place an encrypted order, and reveal/execute it later time, or use a feature of Tezos named TimeLock. The goal is the same: hide the transaction until the last moment so no one can place an order ahead of it. This requires a smart contract to handle this kind of order and keep track of previous data to be able to execute the transaction. Anterior currency pairs history values in the context of a swap, for example.
 
-### Onchain attacks
+### On-chain attacks
 
-This training session will cover the topic of On-chain attacks, which are cyberattacks that target the blockchain network and its components. On-chain attacks can exploit various types of vulnerabilities, such as:
+This training session will cover the topic of on-chain attacks, which are cyberattacks that target the blockchain network and its components. On-chain attacks can exploit various types of vulnerabilities, such as:
 
 - Programming errors that affect the security and functionality of smart contracts, which are self-executing agreements that run on the blockchain. Smart contracts can have a larger attack surface than traditional applications, as they interact with other contracts and users on the network and so are subject to higher interest from hackers in draining funds.
 - Different kinds of leaks:

docs/tutorials/security/part-3.md

@@ -23,8 +23,8 @@ One of the challenges of designing and deploying a smart contract is to define t
   - Verification: By design, everyone can verify the code. Sometimes the code is audited and a report is available.
     → **SOLUTION**: Read the audit if available or verify the code yourself. However, the code deployed is in Michelson and the reverse engineering is not easy. Tools are missing for how to reverse engineer contracts; nevertheless if the contract is TZIP16-compliant it can refer to the LIGO source code, so you can recompile and compare the outputs.
 - Who can resolve disputes or enforce penalties in case of contract violations?
-  If the contract itself does not contain a function to resolve it, no resolution can happen onchain.
-  → **SOLUTION**: Use onchain dispute if available, or off-chain dispute but this latter introduces additional complexities such as Know Your Customer (KYC) regulations and legal considerations. KYC regulations require businesses to verify the identity of their clients. This can be difficult in the context of blockchain transactions, which are often pseudonymous. Legal considerations can also be complex, especially in cross-border transactions where different jurisdictions may have different laws.
+  If the contract itself does not contain a function to resolve it, no resolution can happen on-chain.
+  → **SOLUTION**: Use on-chain dispute if available, or off-chain dispute but this latter introduces additional complexities such as Know Your Customer (KYC) regulations and legal considerations. KYC regulations require businesses to verify the identity of their clients. This can be difficult in the context of blockchain transactions, which are often pseudonymous. Legal considerations can also be complex, especially in cross-border transactions where different jurisdictions may have different laws.
 
 ## Lambda, mutable code, and dynamic entrypoints
 
@@ -44,8 +44,8 @@ Blockchain oracles are third-party services that provide smart contracts with ex
 
 An Oracle is made of two parts:
 
-- Offchain: The data collector that pushes data to the onchain contract
-- Onchain: The contract that stores the data and exposes it to other contracts. Generally, a call for information involves monetization and so, some fees apply.
+- Off-chain: The data collector that pushes data to the on-chain contract
+- On-chain: The contract that stores the data and exposes it to other contracts. Generally, a call for information involves monetization and so, some fees apply.
 
 Who controls the oracle?
 A single company or person may control the oracle. In this case, they can manipulate the data, be hacked, or the service can go down and block the full flow of execution.