From 357f79d4cb86b0ec56939d56e7fde5ae3d9012c5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jan=20Bene=C5=A1?= <janbenes1234@gmail.com>
Date: Fri, 8 Mar 2024 11:47:44 +0100
Subject: [PATCH] WIP

---
 yellow-paper/docs/rollup-circuits/index.md       | 16 ++++++++--------
 yellow-paper/docs/rollup-circuits/root-rollup.md |  2 +-
 yellow-paper/docs/rollup-circuits/tree-parity.md | 14 +++++++-------
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/yellow-paper/docs/rollup-circuits/index.md b/yellow-paper/docs/rollup-circuits/index.md
index 8386d696606..c9554c7e0e6 100644
--- a/yellow-paper/docs/rollup-circuits/index.md
+++ b/yellow-paper/docs/rollup-circuits/index.md
@@ -23,9 +23,9 @@ For transactions we have:
   - Merges two `merge` rollup proofs
 
 And for the message parity we have:
-- The `root` circuit
-  - Merges `N` `root` or `leaf` proofs
-- The `leaf` circuit
+- The `root_parity` circuit
+  - Merges `N` `root` or `base_parity` proofs
+- The `base_parity` circuit
   - Merges `N` l1 to l2 messages in a subtree 
 
 In the diagram the size of the tree is limited for demonstration purposes, but a larger tree would have more layers of merge rollups proofs. 
@@ -91,10 +91,10 @@ graph BT
 
     R((RootParity))
 
-    T0[LeafParity]
-    T1[LeafParity]
-    T2[LeafParity]
-    T3[LeafParity]
+    T0[BaseParity]
+    T1[BaseParity]
+    T2[BaseParity]
+    T3[BaseParity]
 
     T0_P((RootParity 0))
     T1_P((RootParity 1))
@@ -371,7 +371,7 @@ class MergeRollupInputs {
 MergeRollupInputs *-- ChildRollupData: left
 MergeRollupInputs *-- ChildRollupData: right
 
-class LeafParityInputs {
+class BaseParityInputs {
     msgs: List~Fr[2]~
 }
 
diff --git a/yellow-paper/docs/rollup-circuits/root-rollup.md b/yellow-paper/docs/rollup-circuits/root-rollup.md
index 93ce32ba95f..712b4769170 100644
--- a/yellow-paper/docs/rollup-circuits/root-rollup.md
+++ b/yellow-paper/docs/rollup-circuits/root-rollup.md
@@ -132,7 +132,7 @@ class ChildRollupData {
 ChildRollupData *-- BaseOrMergeRollupPublicInputs: public_inputs
 
 
-class LeafParityInputs {
+class BaseParityInputs {
     msgs: List~Fr[2]~
 }
 
diff --git a/yellow-paper/docs/rollup-circuits/tree-parity.md b/yellow-paper/docs/rollup-circuits/tree-parity.md
index 19bfdda5615..ce136726f04 100644
--- a/yellow-paper/docs/rollup-circuits/tree-parity.md
+++ b/yellow-paper/docs/rollup-circuits/tree-parity.md
@@ -11,17 +11,17 @@ As SHA256 is not snark-friendly, weak devices would not be able to prove inclusi
 This circuit is responsible for converting the tree such that users can easily build the proofs.
 We essentially use this circuit to front-load the work needed to prove the inclusion of messages in the tree.
 As earlier we are using a tree-like structure.
-Instead of having a `base`, `merge` and `root` circuits, we will have only `leaf` and `root` parity circuits.
+Instead of having a `base`, `merge` and `root` circuits, we will have only `base` and `root` parity circuits.
 We only need these two, since what would have been the `merge` is doing the same as the `root` for this case.
 
 ```mermaid
 graph BT
     R((RootParity))
 
-    T0[LeafParity]
-    T1[LeafParity]
-    T2[LeafParity]
-    T3[LeafParity]
+    T0[BaseParity]
+    T1[BaseParity]
+    T2[BaseParity]
+    T3[BaseParity]
 
     T0_P((RootParity 0))
     T1_P((RootParity 1))
@@ -91,7 +91,7 @@ class RootParityInput {
 }
 RootParityInput *-- ParityPublicInputs: public_inputs
 
-class LeafParityInputs {
+class BaseParityInputs {
     msgs: List~Fr[2]~
 }
 ```
@@ -101,7 +101,7 @@ If each just take 2 inputs, the overhead of recursing through the layers might b
 Recall that all the inputs are already chosen by the L1, so we don't need to worry about which to chose.
 
 ```python
-def base_parity_circuit(inputs: LeafParityInputs) -> ParityPublicInputs:
+def base_parity_circuit(inputs: BaseParityInputs) -> ParityPublicInputs:
     sha_root = MERKLE_TREE(inputs.msgs, SHA256);
     converted_root = MERKLE_TREE(inputs.msgs, SNARK_FRIENDLY_HASH_FUNCTION);
     return ParityPublicInputs(sha_root, converted_root)