diff --git a/yellow-paper/docs/contract-deployment/classes.md b/yellow-paper/docs/contract-deployment/classes.md index bb658c380dc..33f14c27100 100644 --- a/yellow-paper/docs/contract-deployment/classes.md +++ b/yellow-paper/docs/contract-deployment/classes.md @@ -12,7 +12,7 @@ Read the following discussions for additional context: - [Abstracting contract deployment](https://forum.aztec.network/t/proposal-abstracting-contract-deployment/2576) - [Implementing contract upgrades](https://forum.aztec.network/t/implementing-contract-upgrades/2570) - [Contract classes, upgrades, and default accounts](https://forum.aztec.network/t/contract-classes-upgrades-and-default-accounts/433) - ::: +::: ## Structure diff --git a/yellow-paper/docs/cross-chain-communication/da.md b/yellow-paper/docs/cross-chain-communication/da.md index 22ec850e0ab..fe94d32b4f3 100644 --- a/yellow-paper/docs/cross-chain-communication/da.md +++ b/yellow-paper/docs/cross-chain-communication/da.md @@ -22,7 +22,7 @@ Security is often used quite in an unspecific manner, "good" security etc, witho - **Liveness**: Eventually something good will happen. - **Safety**: Nothing bad will happen. - ::: +::: In the context of blockchain, this _security_ is defined by the confirmation rule, while this can be chosen individually by the user, our validating light node (L1 bridge) can be seen as a user, after all, it's "just" another node. For the case of a validity proof based blockchain, a good confirmation rule should satisfy the following sub-properties (inspired by [Sreeram's framing](https://twitter.com/sreeramkannan/status/1683735050897207296)): diff --git a/yellow-paper/docs/cross-chain-communication/index.md b/yellow-paper/docs/cross-chain-communication/index.md index 804f1ebb77a..61e15a9cc0b 100644 --- a/yellow-paper/docs/cross-chain-communication/index.md +++ b/yellow-paper/docs/cross-chain-communication/index.md @@ -11,7 +11,7 @@ The purpose of the L1 contracts are simple: - Facilitate cross-chain communication such that L1 liquidity can be used on L2 - Act as a validating light node for L2 that every L1 node implicitly run - ::: +::: ## Overview diff --git a/yellow-paper/docs/decentralization/block-production.md b/yellow-paper/docs/decentralization/block-production.md index bbc5d9f7a35..88195545bb3 100644 --- a/yellow-paper/docs/decentralization/block-production.md +++ b/yellow-paper/docs/decentralization/block-production.md @@ -29,7 +29,7 @@ We should probably introduce the PXE somewhere - **Network**: 40KB for a transaction with proof (see [P2P network](./p2p-network.md#network-bandwidth)). Assuming gossiping grows the data upload/download 10x, ~400KB per tx. With 10 tx/s that's 4MB/s or 32mb/s. - **Storage**: [~1548 bytes per transaction](../cross-chain-communication/da.md#aztec-specific-data) + tree overhead, ~ 0.4 TB per year. - **RAM**: Help - ::: +::: ### Sequencers @@ -113,7 +113,7 @@ Anyone ->> Network: eligible as a sequencer - In Diagram - add a dedicated timeline from the block production's PoV - get rid of "pre-confirmed" - ::: +::: ![Governance Summary Image](./images/Aztec-Block-Production-1.png) diff --git a/yellow-paper/sidebars.js b/yellow-paper/sidebars.js index 307be521a04..9158b71eb08 100644 --- a/yellow-paper/sidebars.js +++ b/yellow-paper/sidebars.js @@ -21,35 +21,55 @@ const sidebars = { yellowPaperSidebar: [ "intro", { - "Addresses & keys": [ - "addresses-and-keys/index", + label: "Addresses & Keys", + type: "category", + link: { type: "doc", id: "addresses-and-keys/index" }, + items: [ "addresses-and-keys/specification", "addresses-and-keys/precompiles", "addresses-and-keys/diversified-and-stealth", ], - State: [ - "state/index", + }, + { + label: "State", + type: "category", + link: { type: "doc", id: "state/index" }, + items: [ "state/tree-implementations", "state/archive", "state/note-hash-tree", "state/nullifier-tree", "state/public-data-tree", ], - Transactions: [ - "transactions/index", + }, + { + label: "Transactions", + type: "category", + link: { type: "doc", id: "transactions/index" }, + items: [ "transactions/local-execution", "transactions/public-execution", "transactions/tx-object", "transactions/validity", ], - Bytecode: ["bytecode/index"], - "Contract Deployment": [ - "contract-deployment/index", - "contract-deployment/classes", - "contract-deployment/instances", - ], - Calls: [ - "calls/index", + }, + { + label: "Bytecode", + type: "category", + link: { type: "doc", id: "bytecode/index" }, + items: [], + }, + { + label: "Contract Deployment", + type: "category", + link: { type: "doc", id: "contract-deployment/index" }, + items: ["contract-deployment/classes", "contract-deployment/instances"], + }, + { + label: "Calls", + type: "category", + link: { type: "doc", id: "calls/index" }, + items: [ "calls/sync-calls", "calls/enqueued-calls", "calls/batched-calls", @@ -58,32 +78,62 @@ const sidebars = { "calls/unconstrained-calls", "calls/public-private-messaging", ], - "Cross-chain communication": [ - "cross-chain-communication/index", - "cross-chain-communication/da", - ], - Logs: ["logs/index"], - "Private Message Delivery": [ - "private-message-delivery/index", + }, + { + label: "Cross-chain communication", + type: "category", + link: { type: "doc", id: "cross-chain-communication/index" }, + items: ["cross-chain-communication/da"], + }, + { + label: "Logs", + type: "category", + link: { type: "doc", id: "logs/index" }, + items: [], + }, + { + label: "Private Message Delivery", + type: "category", + link: { type: "doc", id: "private-message-delivery/index" }, + items: [ "private-message-delivery/private-msg-delivery", // renamed to avoid routing problems "private-message-delivery/note-discovery", "private-message-delivery/encryption-and-decryption", "private-message-delivery/registry", "private-message-delivery/send-note-guidelines", ], - "Gas & Fees": ["gas-and-fees/gas-and-fees"], - Decentralization: [ + }, + { + label: "Gas & Fees", + type: "category", + link: { type: "doc", id: "gas-and-fees/gas-and-fees" }, + items: [], + }, + { + label: "Decentralization", + type: "category", + link: { type: "doc", id: "decentralization/governance" }, + items: [ "decentralization/governance", "decentralization/block-production", "decentralization/p2p-network", ], - Cryptography: [ + }, + { + label: "Cryptography", + type: "category", + link: { type: "doc", id: "cryptography/performance-targets" }, + items: [ "cryptography/performance-targets", "cryptography/protocol-overview", ], - // Protocol Statements? - Circuits: [ - "circuits/high-level-topology", + }, + // Protocol Statements? + { + label: "Circuits", + type: "category", + link: { type: "doc", id: "circuits/high-level-topology" }, + items: [ "circuits/private-function", "circuits/private-kernel-initial", "circuits/private-kernel-inner", @@ -93,14 +143,22 @@ const sidebars = { "circuits/public-kernel-inner", "circuits/public-kernel-tail", ], - "Rollup Circuits": [ - "rollup-circuits/index", + }, + { + label: "Rollup Circuits", + type: "category", + link: { type: "doc", id: "rollup-circuits/index" }, + items: [ "rollup-circuits/base-rollup", "rollup-circuits/merge-rollup", "rollup-circuits/root-rollup", ], - "Public VM": [ - "public-vm/avm", + }, + { + label: "Public VM", + type: "category", + link: { type: "doc", id: "public-vm/avm" }, + items: [ "public-vm/alu", "public-vm/bytecode-validation-circuit", "public-vm/control-flow",