diff --git a/lecture2.md b/lecture2.md
index 3f2abd9..f1404fe 100644
--- a/lecture2.md
+++ b/lecture2.md
@@ -671,6 +671,23 @@ Assuming a crash-stop process abstraction, the **perfect detector** encapsulates
 
 ???
 
+Degrees of completeness
+The degrees of completeness depend on the number of crashed process is suspected by a failure detector in a certain period.[5]
+
+- Strong completeness: "every faulty process is eventually permanently suspected by every non-faulty process."[6]
+- Weak completeness: "every faulty process is eventually permanently suspected by some non-faulty process."[6]
+
+Degrees of accuracy
+The degrees of accuracy depend on the number of mistakes that a failure detector made in a certain period.[5]
+
+- Strong accuracy: "no process is suspected (by anybody) before it crashes."[6]
+- Weak accuracy: "some non-faulty process is never suspected."[6]
+- Eventual strong accuracy: "no non-faulty process is suspected after some time since the end of the initial period of chaos as the time at which the last crash occurs."[6]
+- Eventual weak accuracy: "after some initial period of confusion, some non-faulty process is never suspected."[6]
+
+
+<br>
+
 - PFD1. Strong completeness: liveness
 - PFD2. Strong accuracy: safety
 
diff --git a/lecture3.md b/lecture3.md
index de4bb84..98f7639 100644
--- a/lecture3.md
+++ b/lecture3.md
@@ -292,6 +292,12 @@ class: middle
 
 .exercise[Show that eager reliable broadcast is correct.]
 
+???
+
+Hence, RB can be implemented in asynchronous systems (see Lecture 2, slide 23).
+
+Insist on the fact that different distributed system models assumptions lead to distinct implementations.
+
 ---
 
 # Uniformity
@@ -439,7 +445,7 @@ causally preceding messages `mpast`.
 
 ???
 
-.exercise[Show the correctness of the algorithm.]
+Every process $p$ maintains a vector clock $V$ such that entry $V [ rank (q)]$ represents the number of messages that $p$ has crb-delivered from process $q$.
 
 ---
 
diff --git a/lecture7.md b/lecture7.md
index b83ff54..e9b8903 100644
--- a/lecture7.md
+++ b/lecture7.md
@@ -411,7 +411,7 @@ class: middle
 
 The distance between two identifiers is defined as $$d(x, y) = x \oplus y.$$
 - XOR is a valid, albeit non-Euclidean metric.
-- XOR captures the notion of distance between two identifiers: in a fully-populated binary tree of 160-bit IDs, it is the height of the smallest subtree containing them both.
+- XOR captures the notion of distance between two identifiers: in a fully-populated binary tree of 160-bit IDs, the magnitude of the distance is the height of the smallest subtree containing them both.
 - XOR is symmetric.
 - XOR is unidirectional.
 
@@ -433,13 +433,8 @@ class: middle
 
 ## Node state
 
-- For every prefix of size $0 \leq i < 160$, every node keeps a list, called a **k-bucket**,  of (IP address, Port, ID) for nodes of distance between $2^i$ and $2^{i+1}$ of itself.
+- For each $0 \leq i < 160$, every node keeps a list, called a **k-bucket**,  of (IP address, Port, ID) for nodes of distance between $2^i$ and $2^{i+1}$ of itself.
 - Every k-bucket is sorted by time last seen (least recently seen first).
-- When a node receives a message, it updates the corresponding k-bucket for the sender's identifier. If the sender already exists, it is moved to the tail of the list.
-  - If the k-bucket is full, the node pings the **least recently** seen node and checks if it is still available.
-        - Only if the node is **not available** it will replace it.
-        - If available, the node is pushed back at the end of the bucket.
-  - Policy of replacement only when a nodes leaves the network $\rightarrow$ prevents Denial of Service (DoS) attacks (e.g., flushing routing tables).
 
 ---
 
@@ -562,6 +557,18 @@ The routing table is an (unbalanced) binary tree whose leaves are $k$-buckets.
 
 class: middle
 
+## Update
+
+When a node receives a message, it updates the corresponding k-bucket for the sender's identifier. If the sender already exists, it is moved to the tail of the list.
+- If the k-bucket is full, the node pings the **least recently** seen node and checks if it is still available.
+      - Only if the node is **not available** it will replace it.
+      - If available, the node is pushed back at the end of the bucket.
+- Policy of replacement only when a nodes leaves the network $\rightarrow$ prevents Denial of Service (DoS) attacks (e.g., flushing routing tables).
+
+---
+
+class: middle
+
 ## Dynamic construction of the routing table
 
 - The routing tables are allocated dynamically as node receive requests.