v0.14.0 SNOS (#1633)

* init

* minor fix

* minor fixes

Author: LandauRaz

components/Starknet/modules/architecture/pages/os.adoc

@@ -1,16 +1,21 @@
 [id="sn_os"]
 = SNOS (Starknet operating system)
 
-[IMPORTANT]
+== Overview
+
+As an L2 validity rollup, Starknet's state on Ethereum can't be updated without proving that all the blocks between the current state and the new state are valid. SNOS is xref:what_is_snos?[the key element in Starknet's architecture] that xref:how_does_snos_work?[verifies the validity of Starknet blocks] and is required for xref:using_snos_to_update_starknets_state[
+updating Starknet's state]. SNOS has two xref:implementations[implementations], a fully-open source one in Rust and a partially open-source one in Python.
+
+[NOTE]
 ====
-SNOS is a key element in Starknet's architecture, but also one of its more complicated components. This page's aim is to gradually walk you through what SNOS is, how does it work and interact with the Starknet Core contract, and where its implementations can be found. Some parts may require reading more than once, but don't hesitate to https://github.com/starknet-io/starknet-docs/issues/new?assignees=landauraz&title=Feedback%20for%20%22The%20Starknet%20operating%20system%22[reach out^] if you feel further clarification is needed. 
+SNOS is a key element in Starknet's architecture, but also one of its more complicated components. Some parts may require reading more than once, but don't hesitate to https://github.com/starknet-io/starknet-docs/issues/new?assignees=landauraz&title=Feedback%20for%20%22The%20Starknet%20operating%20system%22[reach out^] if you feel further clarification is needed. 
 ====
 
-== What is the SNOS?
+== What is SNOS?
 
-As an L2 validity rollup, Starknet's state on Ethereum can't be updated without proving that all the blocks between the current state and the new state are valid. But what does "proving that a block is valid" mean exactly? Technically, only statements of the form "_Cairo program stem:[P] ran successfully with output stem:[O]_" can be proven, which means that the statement "_Blocks stem:[B] is valid_" needs to expressed in the form of a Cairo program.
+In Cairo, only statements of the form _"a specific Cairo program with specific inputs and produced specific outputs"_ can be proven, which means that the statement _"A Starknet block is valid"_ needs to expressed in the form of a Cairo program, inputs, and outputs.
 
-This is where SNOS comes in: it is a Cairo Zero program that verifies the validity of blocks by getting an initial state stem:[S] and a list of transactions (i.e., block) stem:[B] as input and outputting the state that is the result of applying stem:[B] on stem:[S].
+This is where SNOS comes in: it is a Cairo Zero program that verifies the validity of blocks by getting an initial state and a list of transactions as input and outputting the state that is the result of applying these transactions on the initial state.
 
 SNOS is the program required for updating Starknet's state on Ethereum (xref:#os-and-core-contract[up to some caveats]). As such, is it also the final arbiter on what does it mean for a transaction to execute correctly. For example, while a malicious sequencer can deviate from xref:architecture:transactions.adoc#transaction_flow[the `INVOKE` transaction's behavior] by skipping the execution of `+__validate__+` before `+__execute__+` in the calling account contract, this specification is https://github.com/starkware-libs/cairo-lang/blob/8e11b8cc65ae1d0959328b1b4a40b92df8b58595/src/starkware/starknet/core/os/execution/execute_transactions.cairo#L390[enforced by SNOS^] and therefore this sequencer will not be able to produce the proof for the block in which this transaction was included. 
 
@@ -38,7 +43,7 @@ Contract calls are in fact done non-deterministically, i.e. the contract's respo
 
     * State updates are accumulated in the global state updates dictionary
 . Verifying that the new commitment corresponds to applying the updates accumulated in the global state updates dictionary to the old commitment (for more details, see the link:https://github.com/starkware-libs/cairo-lang/blob/8e11b8cc65ae1d0959328b1b4a40b92df8b58595/src/starkware/starknet/core/os/state/state.cairo#L40[`state_update` function in `state.cairo`^]).
-. Encoding the state diff and adding it to the output segment for xref:data-availability.adoc[data availability] purposes (for more details, see the link:https://github.com/starkware-libs/cairo-lang/blob/8e11b8cc65ae1d0959328b1b4a40b92df8b58595/src/starkware/starknet/core/os/output.cairo#L71[`serialize_os_output` function in `output.cairo`^])
+. Encoding the state diff and adding it to the output segment for xref:network-architecture/data-availability.adoc[data availability] purposes (for more details, see the link:https://github.com/starkware-libs/cairo-lang/blob/8e11b8cc65ae1d0959328b1b4a40b92df8b58595/src/starkware/starknet/core/os/output.cairo#L71[`serialize_os_output` function in `output.cairo`^])
 
 [id="syscall-mechanism"]
 === Syscall mechanism
@@ -58,8 +63,13 @@ Therefore, when running the OS, we already know what is going to happen: the blo
 
 It's worth noting that in the first execution, the sequencer can run in whatever way he chooses. In fact, he doesn't even have to run through the Cairo VM at all, but rather https://github.com/lambdaclass/cairo_native[precompile contracts to machine code and run them natively^]. Moreover, sequencers can also impose restrictions that are not enforced by SNOS. Such discrepancy between the two executions may seem like a bug, but as long as these restrictions only protect the sequencers themselves, rather than the correctness of execution, there is no reason for SNOS to enforce them. A good example for such restriction is the xref:architecture:accounts#limitations_of_validation[limits on validation functions] that protect the sequencer from DoS attacks. It is crucial, however, that both executions agree on the execution semantics, since, as mentioned in xref:#introduction[What is SNOS?], SNOS is the final arbiter and if it disagrees on the validity of the block, the sequencer will not be able to produce a proof for that block (and the only way forward would be a reorg on Starknet).
 
-[id="os-and-core-contract"]
-== SNOS and the Starknet Core contract
+=== Multiblock input
+
+Starting from Starknet version 0.14.0, block times on Starknet will be substantially shorter, leading to more frequent but also smaller blocks. As every run of SNOS on a single block incurs a fixed cost which is independent of the size of the block, producing e.g. twice as many blocks also doubles this fixed cost.
+
+To mitigate this, SNOS will be modified in version 0.14.0 to receive multiple blocks as inputs. This also amortizes other non-negligible costs over a larger number of blocks: For example, if both block 10 and 11 use the same contract, SNOS loads and hashes its code only once instead of twice.
+
+== Using SNOS to update Starknet's state
 
 The Starknet Core contract is the contract responsible for storing and updating Starknet's state on Ethereum. As of Starknet v0.13.2 and as part of https://community.starknet.io/t/starknet-v0-13-2-pre-release-notes/114223#starknet-applicative-recursion-3[SHARP's applicative recursion feature^], proofs of SNOS's execution are not enough to update the Starknet Core contract. Instead, it is required to submit an "applicative proof" of a different program called https://github.com/starkware-libs/cairo-lang/blob/8e11b8cc65ae1d0959328b1b4a40b92df8b58595/src/starkware/cairo/bootloaders/applicative_bootloader/applicative_bootloader.cairo#L15[the applicative bootloader^].