From 02d755e26dd60811c16c137a1ef07ace4df3d3a1 Mon Sep 17 00:00:00 2001
From: Marco Realacci <marco@marcorealacci.me>
Date: Mon, 31 Mar 2025 10:02:33 +0200
Subject: [PATCH] vault backup: 2025-03-31 10:02:33

---
 Concurrent Systems/notes/9 - Consensus.md | 24 +++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/Concurrent Systems/notes/9 - Consensus.md b/Concurrent Systems/notes/9 - Consensus.md
index 52a2860..313e5c1 100644
--- a/Concurrent Systems/notes/9 - Consensus.md	
+++ b/Concurrent Systems/notes/9 - Consensus.md	
@@ -168,3 +168,27 @@ Three possible ways!
 3. reuse the same consensus object: for all k, `CONS[k]` not only chooses the list of invocations, but also the final state of every invocation
 	- the proposals should also pre-calculate the next state and propose one
 
+### Binary vs Multivalued Consensus
+Binary consensus: just two possible proposals (say, 0 and 1)
+
+##### Multivalued consensus (with unbounded values)
+IDEA:
+- we have n processes and n binary consensus rounds
+- at round k, all processes propose 1 if $p_k$ has proposed something, 0 otherwise
+- if the decided value is 1, then decide $p_k$'s proposal; otherwise, go to the next round.
+
+```
+PROP[1..n] array of n proposals, all init at ⊥
+BC[1..n] array of n binary consensus objects
+
+mv_propose(i,v) :=
+	PROP[i] <- v
+	for k=1 to n do
+		if PROP[k] ≠ ⊥ then
+			res <- BC[k].propose(1)
+		else
+			res <- BC[k].propose(0)
+		if res = 1 then
+			return PROP[k]
+	wait forever
+```