Adding the blockchain chapter (#1149)

* rewriting the execution chapter - first draft

* Fixed images + re-organized chapters + fixed typos + re-formulated parts

* Fixed typos + improved flow

* saving

* making it slightly clearer

* Improved some wording

* Update docs/architecture/blockchain.md

Co-authored-by: Philipp Gackstatter <PhilippGackstatter@users.noreply.github.com>

* Update docs/architecture/blockchain.md

Co-authored-by: Philipp Gackstatter <PhilippGackstatter@users.noreply.github.com>

* Update docs/architecture/blockchain.md

Co-authored-by: Philipp Gackstatter <PhilippGackstatter@users.noreply.github.com>

* Update docs/architecture/blockchain.md

Co-authored-by: Philipp Gackstatter <PhilippGackstatter@users.noreply.github.com>

* Update docs/architecture/blockchain.md

Co-authored-by: Philipp Gackstatter <PhilippGackstatter@users.noreply.github.com>

* Update docs/architecture/blockchain.md

Co-authored-by: Philipp Gackstatter <PhilippGackstatter@users.noreply.github.com>

* Improve wording of  intro + removed real-time proving

* Moved ephemeral to note.md + applied phil + mirko reviews

* Improving intro and verifying blocks

* Improving block production

* Improving batching

* Update docs/architecture/blockchain.md

Co-authored-by: Mirko <48352201+Mirko-von-Leipzig@users.noreply.github.com>

* Update docs/architecture/blockchain.md

Co-authored-by: Mirko <48352201+Mirko-von-Leipzig@users.noreply.github.com>

* Update docs/architecture/note.md

Co-authored-by: Mirko <48352201+Mirko-von-Leipzig@users.noreply.github.com>

* Minor fixes + improvement of ephemeral note section

* Applied Bobbinth comments

* Update docs/architecture/blockchain.md

Co-authored-by: Philipp Gackstatter <PhilippGackstatter@users.noreply.github.com>

* Applied Phillipps comments

* Fix grammar and typos

* adding more protocol rules

* adding more info to the ephemeral note section

* removing ephemeral notes from note.md

* Change can to could

* changing ephemeral notes => erasable notes

---------

Co-authored-by: Paul-Henry Kajfasz <kajfaszph@gmail.com>
Co-authored-by: Paul-Henry Kajfasz <42912740+phklive@users.noreply.github.com>
Co-authored-by: Philipp Gackstatter <PhilippGackstatter@users.noreply.github.com>
Co-authored-by: Mirko <48352201+Mirko-von-Leipzig@users.noreply.github.com>

docs/architecture/blockchain.md

@@ -0,0 +1,87 @@
+# Blockchain
+
+The Miden blockchain protocol describes how the [state](state.md) progresses through `Block`s, which are containers that aggregate account state changes and their proofs, together with created and consumed notes. `Block`s represent the delta of the global state between two time periods, and each is accompanied by a corresponding proof that attests to the correctness of all state transitions it contains. The current global state can be derived by applying all the `Block`s to the genesis state.
+
+Miden's blockchain protocol aims for the following:
+
+- **Proven transactions**: All included transactions have already been proven and verified when they reach the block.
+- **Fast genesis syncing**: New nodes can efficiently sync to the tip of the chain.
+
+<p style="text-align: center;">
+    <img src="../img/architecture/blockchain/execution.png" style="width:70%;" alt="Execution diagram"/>
+</p>
+
+## Batch production
+
+To reduce the required space on the blockchain, transaction proofs are not directly put into blocks. First, they are batched together by verifying them in the batch producer. The purpose of the batch producer is to generate a single proof that some number of proven transactions have been verified. This involves recursively verifying individual transaction proofs inside the Miden VM. As with any program that runs in the Miden VM, there is a proof of correct execution running the Miden verifier to verify transaction proofs. This results into a single batch proof.
+
+<p style="text-align: center;">
+    <img src="../img/architecture/blockchain/batching.png" style="width:50%;" alt="Batch diagram"/>
+</p>
+
+The batch producer aggregates transactions sequentially by verifying that their proofs and state transitions are correct. More specifically, the batch producer ensures:
+
+1. **Ordering of transactions**: If several transactions within the same batch affect a single account, the correct ordering must be enforced. For example, if `Tx1` and `Tx2` both describe state changes of account `A`, then the batch kernel must verify them in the order: `A -> Tx1 -> A' -> Tx2 -> A''`.
+2. **Uniqueness of notes in a single batch**: The batch producer must ensure the uniqueness of all notes across transactions in the batch. This will prevent the situation where duplicate notes, which would share identical nullifiers, are created. Only one such duplicate note could later be consumed, as the nullifier will be marked as spent after the first consumption. It also checks for double spends in the set of consumed notes, even though the real double spent check only happens at the block production level.
+3. **Expiration windows**: It is possible to set an expiration window for transactions, which in turn sets an expiration window for the entire batch. For instance, if transaction `Tx1` expires at block `8` and transaction `Tx2` expires at block `5`, then the batch expiration will be set to the minimum of all transaction expirations, which is `5`.
+4. **Note erasure of erasable notes**: Erasable notes don't exist in the Notes DB. They are unauthenticated. Accounts can still consume unauthenticated notes to consume those notes faster, they don't have to wait for notes being included into a block. If creation and consumption of an erasable note happens in the same batch, the batch producer erases this note.
+
+## Block production
+
+To create a `Block`, multiple batches and their respective proofs are aggregated. `Block` production is not parallelizable and must be performed by the Miden operator. In the future, several Miden operators may compete for `Block` production. The schema used for `Block` production is similar to that in batch production—recursive verification. Multiple batch proofs are aggregated into a single `Block` proof.
+
+The block producer ensures:
+
+1. **Account DB integrity**: The Block `N+1` Account DB commitment must be authenticated against all previous and resulting account commitments across transactions, ensuring valid state transitions and preventing execution on stale states.
+2. **Nullifier DB integrity**: Nullifiers of newly created notes are added to the Nullifier DB. The Block `N+1` Nullifier DB commitment must be authenticated against all new nullifiers to guarantee completeness.
+3. **Block hash references**: Check that all block hashes references by batches are in the chain.
+4. **Double-spend prevention**: Each consumed note’s nullifier is checked against prior consumption. The Block `N` Nullifier DB commitment is authenticated against all provided nullifiers for consumed notes, ensuring no nullifier is reused.
+5. **Global note uniqueness**: All created and consumed notes must be unique across batches.
+6. **Batch expiration**: The block height of the created block must be smaller or equal than the lowest batch expiration.
+7. **Block time increase**: The block timestamp must increase monotonically from the previous block.
+8. **Note erasure of erasable notes**: If an erasable note is created and consumed in different batches, it is erased now. If, however, an erasable note is consumed but not created within the block, the batch it contains is rejected. The Miden operator's mempool should preemptively filter such transactions.
+
+In final `Block` contains:
+- The commitments to the current global [state](state.md).
+- The newly created nullifiers.
+- The commitments to newly created notes.
+- The new state commitments for affected private accounts.
+- The full states for all affected public accounts and newly created notes.
+
+The `Block` proof attests to the correct state transition from the previous `Block` commitment to the next, and therefore to the change in Miden's global state.
+
+<p style="text-align: center;">
+    <img src="../img/architecture/blockchain/block.png" style="width:90%;" alt="Block diagram"/>
+</p>
+
+> **Tip: Block Contents**
+>
+> - **State updates**: Contains only the hashes of updated elements. For example, for each updated account, a tuple is recorded as `([account id], [new account hash])`.
+> - **ZK Proof**: This proof attests that, given a state commitment from the previous `Block`, a set of valid batches was executed that resulted in the new state commitment.
+> - The `Block` also includes the full account and note data for public accounts and notes. For example, if account `123` is a public account that has been updated, you would see a record in the **state updates** section as `(123, 0x456..)`, and the full new state of this account (which should hash to `0x456..`) would be included in a separate section.
+
+## Verifying blocks
+
+To verify that a `Block` corresponds to a valid global state transition, the following steps must be performed:
+
+1. Compute the hashes of public accounts and note states.
+2. Ensure that these hashes match the records in the **state updates** section.
+3. Verify the included `Block` proof using the following public inputs and output:
+   - **Input**: Previous `Block` commitment.
+   - **Input**: Set of batch commitments.
+   - **Output**: Current `Block` commitment.
+
+These steps can be performed by any verifier (e.g., a contract on Ethereum, Polygon AggLayer, or a decentralized network of Miden nodes).
+
+## Syncing from genesis
+Nodes can sync efficiently from genesis to the tip of the chain through a multi-step process:
+
+  1. Download historical `Block`s from genesis to the present.
+  2. Verify zero-knowledge proofs for all `Block`s.
+  3. Retrieve current state data (accounts, notes, and nullifiers).
+  4. Validate that the downloaded state matches the latest `Block`'s state commitment.
+
+This approach enables fast blockchain syncing by verifying `Block` proofs rather than re-executing individual transactions, resulting in exponentially faster performance. Consequently, state sync is dominated by the time needed to download the data.
+
+## Consensus and decentralization
+Miden will start as a centralized L2 on the Ethereum network. Over time, Miden will decentralize, but this part of the protocol, especially consensus is not yet set.

docs/architecture/note.md

@@ -72,18 +72,11 @@ As with [accounts](accounts.md), `Note`s can be stored either publicly or privat
 - **Public mode:** The `Note` data is stored in the [note database](https://0xpolygonmiden.github.io/miden-base/architecture/state.html#notes-database), making it fully visible on-chain.
 - **Private mode:** Only the `Note`’s hash is stored publicly. The `Note`’s actual data remains off-chain, enhancing privacy.
 
-#### Ephemeral note
-
-These specific `Note`s can be consumed even if not yet registered on-chain. They can be chained together into one final proof. This can allow for example sub-second communication below blocktimes by adding additional trust assumptions.
-
 ### Note validation
 
 Once created, a `Note` must be validated by a Miden operator. Validation involves checking the transaction proof that produced the `Note` to ensure it meets all protocol requirements.
 
-- **Private Notes:** Only the `Note`’s hash is recorded on-chain, keeping the data confidential.
-- **Public Notes:** The full `Note` data is stored, providing transparency for applications requiring public state visibility.
-
-After validation, `Note`s become “live” and eligible for discovery and eventual consumption.
+After validation `Note`s become “live” and eligible for consumption. If creation and consumption happens within the same block, there is no entry in the Notes DB. All other notes, are being added either as a commitment or fully public.
 
 ### Note discovery
 

docs/architecture/transaction.md

@@ -41,7 +41,7 @@ A `Transaction` requires several inputs:
 
 1. **Prologue**
 
-   Executes at the beginning of a transaction. It validates on-chain commitments against the provided data. This is to ensure that the transaction executes against a valid on-chain recorded state of the account and to be consumed notes. Notes to be consumed must be registered on-chain — except for [ephemeral notes](note.md) which can be consumed without block inclusion.
+   Executes at the beginning of a transaction. It validates on-chain commitments against the provided data. This is to ensure that the transaction executes against a valid on-chain recorded state of the account and to be consumed notes. Notes to be consumed must be registered on-chain — except for [erasable notes](note.md) which can be consumed without block inclusion.
 
 2. **Note processing**
 
@@ -119,7 +119,7 @@ The ability to facilitate both, local and network `Transaction`s, **is one of th
 
 > **Good to know**
 >
-> - Usually, notes that are consumed in a `Transaction` must be recorded on-chain in order for the `Transaction` to succeed. However, Miden supports **ephemeral notes** which are notes that can be consumed in a `Transaction` before being registered on-chain. For example, one can build a sub-second order book by allowing its traders to build faster transactions that depend on each other and are being validated or erased in batches.
+> - Usually, notes that are consumed in a `Transaction` must be recorded on-chain in order for the `Transaction` to succeed. However, Miden supports **erasable notes** which are notes that can be consumed in a `Transaction` before being registered on-chain. For example, one can build a sub-second order book by allowing its traders to build faster transactions that depend on each other and are being validated or erased in batches.
 >
 > - There is no nullifier check during a `Transaction`. Nullifiers are checked by the Miden operator during `Transaction` verification. So at the local level, there is "double spending." If a note was already spent, i.e. there exists a nullifier for that note, the block producer would never include the `Transaction` as it would make the block invalid.
 >