From 36a57b5093431aafe1d7a5befb14b810f1cd6f2e Mon Sep 17 00:00:00 2001 From: apenzk Date: Sat, 5 Apr 2025 22:18:31 +0200 Subject: [PATCH 1/8] init --- MD/md-n/README.md | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 MD/md-n/README.md diff --git a/MD/md-n/README.md b/MD/md-n/README.md new file mode 100644 index 00000000..7c51e870 --- /dev/null +++ b/MD/md-n/README.md @@ -0,0 +1,45 @@ +# MD-\: Define the assumptions of the L1 for the Postconfirmation Protocol + +- **Description**: Postconfirmations are an anchoring mechanisms for the L2 protocol. Safety and liveness assumptions depend thus on the L1. This desideratum defines possible assumptions and requirements that should be clearly stated when defining the Postconfirmation Protocol. +- **Authors**: [Andreas Penzkofer]() +- **Approval**: + +## Overview + +The L1 provides several properties, such as synchrony, safety, liveness, censorship resistance. However, these properties are subject to the correctness of certain assumptions. If these assumptions are violated, the L1 may not provide the desired properties and the Postconfirmation Protocol may fail. + +Protocols should describe, what are the assumptions on the L1, and how it behaves given these assumptions DO NOT hold. + +## Desiderata + +### D1: The properties of the L1 must be clearly stated + +**User journey (Operator)**: An operator wants to deploy a Postconfirmation Protocol. It must understand, what properties the L1 provides and under what conditions these properties hold. + +**Recommendations**: +Consider the following properties of the L1: + +- Synchrony +- Safety +- Liveness +- Censorship resistance + +### D2: The properties that derive from the L1 for the Postconfirmation Protocol must be clearly stated, IF the L1 does fulfill the assumptions + +**User journey (Operator)**: An operator wants to deploy a Postconfirmation Protocol. It must understand, what the implications are for the Postconfirmation Protocol, if the L1 does fulfill the assumptions. + +**Recommendations**: +Consider the following properties that derive from the L1: + +- Broadcast guarantees, such as when is a message considered broadcast and when delivered. +- Finality guarantees, such as when a message is considered final. + +### D3: The properties that derive from the L1 for the Postconfirmation Protocol must be clearly stated, IF the L1 does NOT fulfill the assumptions + +**User journey (Operator)**: An operator wants to deploy a Postconfirmation Protocol. It must understand, how the protocol behaves if the L1 does NOT fulfill one of the assumptions. + +**Recommendations**: + +- address how the guarantees explored in #D2 are impacted by the violation of the assumptions. + +## Changelog From 3e9ef023816181c1e6e6d51f47cbf430d7ff7db9 Mon Sep 17 00:00:00 2001 From: apenzk Date: Sat, 5 Apr 2025 22:50:36 +0200 Subject: [PATCH 2/8] minor edits --- MD/md-n/README.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/MD/md-n/README.md b/MD/md-n/README.md index 7c51e870..66abb5e2 100644 --- a/MD/md-n/README.md +++ b/MD/md-n/README.md @@ -1,12 +1,12 @@ -# MD-\: Define the assumptions of the L1 for the Postconfirmation Protocol +# MD-\: Define the assumptions of the L1 for the Postconfirmation protocol -- **Description**: Postconfirmations are an anchoring mechanisms for the L2 protocol. Safety and liveness assumptions depend thus on the L1. This desideratum defines possible assumptions and requirements that should be clearly stated when defining the Postconfirmation Protocol. +- **Description**: Postconfirmations are an anchoring mechanisms for the L2 protocol. Safety and liveness assumptions depend thus on the L1. This desideratum defines possible assumptions and requirements that should be clearly stated when defining the Postconfirmation protocol. - **Authors**: [Andreas Penzkofer]() - **Approval**: ## Overview -The L1 provides several properties, such as synchrony, safety, liveness, censorship resistance. However, these properties are subject to the correctness of certain assumptions. If these assumptions are violated, the L1 may not provide the desired properties and the Postconfirmation Protocol may fail. +The L1 provides several properties, such as synchrony, safety, liveness, censorship resistance. However, these properties are subject to the correctness of certain assumptions. If these assumptions are violated, the L1 may not provide the desired properties and the Postconfirmation protocol may fail. Protocols should describe, what are the assumptions on the L1, and how it behaves given these assumptions DO NOT hold. @@ -14,7 +14,7 @@ Protocols should describe, what are the assumptions on the L1, and how it behave ### D1: The properties of the L1 must be clearly stated -**User journey (Operator)**: An operator wants to deploy a Postconfirmation Protocol. It must understand, what properties the L1 provides and under what conditions these properties hold. +**User journey (Operator)**: An operator wants to deploy a Postconfirmation protocol. It must understand, what properties the L1 provides and under what conditions these properties hold. **Recommendations**: Consider the following properties of the L1: @@ -24,22 +24,23 @@ Consider the following properties of the L1: - Liveness - Censorship resistance -### D2: The properties that derive from the L1 for the Postconfirmation Protocol must be clearly stated, IF the L1 does fulfill the assumptions +### D2: The properties that derive from the L1 for the Postconfirmation protocol must be clearly stated, IF the L1 does fulfill the assumptions -**User journey (Operator)**: An operator wants to deploy a Postconfirmation Protocol. It must understand, what the implications are for the Postconfirmation Protocol, if the L1 does fulfill the assumptions. +**User journey (Operator)**: An operator wants to deploy a Postconfirmation protocol. They must understand, what properties are derived from the L1 for the Postconfirmation protocol, if the L1 does fulfill the assumptions. **Recommendations**: Consider the following properties that derive from the L1: -- Broadcast guarantees, such as when is a message considered broadcast and when delivered. +- Broadcast guarantees, such as when is a message from protocol participants considered broadcast and when delivered. - Finality guarantees, such as when a message is considered final. -### D3: The properties that derive from the L1 for the Postconfirmation Protocol must be clearly stated, IF the L1 does NOT fulfill the assumptions +### D3: The properties that derive from the L1 for the Postconfirmation protocol must be clearly stated, IF the L1 does NOT fulfill the assumptions -**User journey (Operator)**: An operator wants to deploy a Postconfirmation Protocol. It must understand, how the protocol behaves if the L1 does NOT fulfill one of the assumptions. +**User journey (Operator)**: An operator wants to deploy a Postconfirmation protocol. They must understand, how the protocol behaves if the L1 does NOT fulfill one of the assumptions for the L1 holds. **Recommendations**: - address how the guarantees explored in #D2 are impacted by the violation of the assumptions. +- what happens if the finality of the L1 is violated and the ledger reverts to a previous state. ## Changelog From 0543a9f2c012d0afbe360731c5dcf87afc32cd62 Mon Sep 17 00:00:00 2001 From: apenzk Date: Sat, 5 Apr 2025 22:54:45 +0200 Subject: [PATCH 3/8] md number --- .github/CODEOWNERS | 1 + MD/{md-n => md-118}/README.md | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) rename MD/{md-n => md-118}/README.md (96%) diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 2de60dcd..68c2b7a2 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -11,6 +11,7 @@ /MD/md-5/ @l-monninger @apenzk /MD/md-15/ @l-monninger @apenzk /MD/md-93/ @andygolay +/MD/md-118/ @apenzk ## MIPs /MIP/mip-0/ @l-monninger @apenzk diff --git a/MD/md-n/README.md b/MD/md-118/README.md similarity index 96% rename from MD/md-n/README.md rename to MD/md-118/README.md index 66abb5e2..05b90c0c 100644 --- a/MD/md-n/README.md +++ b/MD/md-118/README.md @@ -1,4 +1,4 @@ -# MD-\: Define the assumptions of the L1 for the Postconfirmation protocol +# MD-118: Define the assumptions of the L1 for the Postconfirmation protocol - **Description**: Postconfirmations are an anchoring mechanisms for the L2 protocol. Safety and liveness assumptions depend thus on the L1. This desideratum defines possible assumptions and requirements that should be clearly stated when defining the Postconfirmation protocol. - **Authors**: [Andreas Penzkofer]() From e534015731e7635101a5cf2796a7045402ef3b2b Mon Sep 17 00:00:00 2001 From: apenzk Date: Sat, 5 Apr 2025 22:56:11 +0200 Subject: [PATCH 4/8] improve header --- MD/md-118/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MD/md-118/README.md b/MD/md-118/README.md index 05b90c0c..d549844f 100644 --- a/MD/md-118/README.md +++ b/MD/md-118/README.md @@ -1,6 +1,6 @@ -# MD-118: Define the assumptions of the L1 for the Postconfirmation protocol +# MD-118: Describe the implications of L1 assumptions for the Postconfirmation protocol -- **Description**: Postconfirmations are an anchoring mechanisms for the L2 protocol. Safety and liveness assumptions depend thus on the L1. This desideratum defines possible assumptions and requirements that should be clearly stated when defining the Postconfirmation protocol. +- **Description**: Postconfirmations are an anchoring mechanisms for the L2 protocol. Safety and liveness assumptions depend thus on the L1. This desideratum requests to explain the implications of L1 assumptions for the Postconfirmation protocol. - **Authors**: [Andreas Penzkofer]() - **Approval**: From 4ad78a41bfdb2a007bfa9f2210aa72199ee8ed78 Mon Sep 17 00:00:00 2001 From: apenzk Date: Sat, 5 Apr 2025 22:57:43 +0200 Subject: [PATCH 5/8] minor edits --- MD/md-118/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MD/md-118/README.md b/MD/md-118/README.md index d549844f..fcd05af8 100644 --- a/MD/md-118/README.md +++ b/MD/md-118/README.md @@ -1,4 +1,4 @@ -# MD-118: Describe the implications of L1 assumptions for the Postconfirmation protocol +# MD-118: Implications of L1 assumptions for the Postconfirmation protocol - **Description**: Postconfirmations are an anchoring mechanisms for the L2 protocol. Safety and liveness assumptions depend thus on the L1. This desideratum requests to explain the implications of L1 assumptions for the Postconfirmation protocol. - **Authors**: [Andreas Penzkofer]() @@ -14,7 +14,7 @@ Protocols should describe, what are the assumptions on the L1, and how it behave ### D1: The properties of the L1 must be clearly stated -**User journey (Operator)**: An operator wants to deploy a Postconfirmation protocol. It must understand, what properties the L1 provides and under what conditions these properties hold. +**User journey (Operator)**: An operator wants to deploy a Postconfirmation protocol. They must understand, what properties the L1 provides and under what conditions these properties hold. **Recommendations**: Consider the following properties of the L1: From be8a18932f5179f059c7f87301c9f5b1c861ec13 Mon Sep 17 00:00:00 2001 From: apenzk Date: Sat, 5 Apr 2025 23:05:09 +0200 Subject: [PATCH 6/8] appendix A1 - message propagation --- MD/md-118/README.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/MD/md-118/README.md b/MD/md-118/README.md index fcd05af8..67ae55e3 100644 --- a/MD/md-118/README.md +++ b/MD/md-118/README.md @@ -32,7 +32,7 @@ Consider the following properties of the L1: Consider the following properties that derive from the L1: - Broadcast guarantees, such as when is a message from protocol participants considered broadcast and when delivered. -- Finality guarantees, such as when a message is considered final. +- Finality guarantees, such as when a message is considered final, see [A1](#a1-message-delivery-and-finality). ### D3: The properties that derive from the L1 for the Postconfirmation protocol must be clearly stated, IF the L1 does NOT fulfill the assumptions @@ -43,4 +43,14 @@ Consider the following properties that derive from the L1: - address how the guarantees explored in #D2 are impacted by the violation of the assumptions. - what happens if the finality of the L1 is violated and the ledger reverts to a previous state. +## Appendix + +### A1: Message delivery and finality + +The Postconfirmation protocol is run as a smart contract on the L1. Messages from validators are only considered for the state transition once they are executed on the L1. Since the L1 guarantees broadcast to all participants, accepted votes have total order broadcast properties, provided the L1 is safe. + +Votes from validators MUST not be considered as long as they are only in the mempool of the L1. The are counted as propagated once they are finalized (not the weaker form of confirmed). + +Since finality is strictly a stronger guarantee than confirmation (in e.g. a single block), broadcast has total order broadcast properties. + ## Changelog From 3a46dab8c33e01fb449fb108dbc6ab80e6d1a78a Mon Sep 17 00:00:00 2001 From: apenzk Date: Wed, 9 Apr 2025 11:54:10 +0200 Subject: [PATCH 7/8] make desiderata more concrete --- MD/md-118/README.md | 47 +++++++++++++++++++++++++++++---------------- 1 file changed, 30 insertions(+), 17 deletions(-) diff --git a/MD/md-118/README.md b/MD/md-118/README.md index 67ae55e3..4ad34da9 100644 --- a/MD/md-118/README.md +++ b/MD/md-118/README.md @@ -1,12 +1,12 @@ # MD-118: Implications of L1 assumptions for the Postconfirmation protocol -- **Description**: Postconfirmations are an anchoring mechanisms for the L2 protocol. Safety and liveness assumptions depend thus on the L1. This desideratum requests to explain the implications of L1 assumptions for the Postconfirmation protocol. +- **Description**: Postconfirmations are an anchoring mechanisms for the L2 protocol. Safety and liveness assumptions depend thus on the L1. This desideratum requests to explain the implications of L1 assumptions and requirements on the L1 for the Postconfirmation protocol. - **Authors**: [Andreas Penzkofer]() - **Approval**: ## Overview -The L1 provides several properties, such as synchrony, safety, liveness, censorship resistance. However, these properties are subject to the correctness of certain assumptions. If these assumptions are violated, the L1 may not provide the desired properties and the Postconfirmation protocol may fail. +The L1 provides several properties, such as synchrony, safety, liveness, censorship resistance. However, these properties are subject to the correctness of certain assumptions such as running a node on the L1. If these assumptions are violated, the L1 may not provide the desired properties and the Postconfirmation protocol may fail. Protocols should describe, what are the assumptions on the L1, and how it behaves given these assumptions DO NOT hold. @@ -14,43 +14,56 @@ Protocols should describe, what are the assumptions on the L1, and how it behave ### D1: The properties of the L1 must be clearly stated -**User journey (Operator)**: An operator wants to deploy a Postconfirmation protocol. They must understand, what properties the L1 provides and under what conditions these properties hold. +**User journey (Operator)**: An operator wants to deploy a Postconfirmation protocol. They must understand, what properties the L1 provides. **Recommendations**: Consider the following properties of the L1: -- Synchrony -- Safety -- Liveness -- Censorship resistance +- Synchrony: at what intervals are messages broadcasted and finalized? +- Safety: under what conditions is the L1 safe? +- Liveness: is the protocol always live? What delays should be considered? +- Censorship resistance: can the L1 censor voting messages of the Postconfirmation protocol? -### D2: The properties that derive from the L1 for the Postconfirmation protocol must be clearly stated, IF the L1 does fulfill the assumptions +### D2: The requirements on the participants must be clearly stated -**User journey (Operator)**: An operator wants to deploy a Postconfirmation protocol. They must understand, what properties are derived from the L1 for the Postconfirmation protocol, if the L1 does fulfill the assumptions. +**User journey (Operator)**: An operator wants to deploy a Postconfirmation protocol. They must understand, what requirements the operator must fulfill to use the Postconfirmation protocol. **Recommendations**: -Consider the following properties that derive from the L1: -- Broadcast guarantees, such as when is a message from protocol participants considered broadcast and when delivered. +- The operator must run a full node on the L1. The delay of reading the L1 state must be known and considered. +- The operator must run a full node on the L2. The delay of reading the L2 state must be known and considered. + +### D3: Broadcast and finality assumptions + +**User journey (Operator)**: An operator wants to deploy a Postconfirmation protocol. They must understand, when a message is considered broadcast, when delivered, when finalized. + +**Recommendations**: + +- Broadcast guarantees, such as when is a message from protocol participants considered broadcast and when delivered. It should be distinguished between + - the delivery to a validator set + - the delivery to the L1 - Finality guarantees, such as when a message is considered final, see [A1](#a1-message-delivery-and-finality). -### D3: The properties that derive from the L1 for the Postconfirmation protocol must be clearly stated, IF the L1 does NOT fulfill the assumptions +### D4: Behavior of protocol if L1 assumptions are violated. **User journey (Operator)**: An operator wants to deploy a Postconfirmation protocol. They must understand, how the protocol behaves if the L1 does NOT fulfill one of the assumptions for the L1 holds. **Recommendations**: -- address how the guarantees explored in #D2 are impacted by the violation of the assumptions. -- what happens if the finality of the L1 is violated and the ledger reverts to a previous state. +- What happens if the finality of the L1 is violated and the ledger reverts to a previous state. How does the Postconfirmation protocol behave? Are votes resubmitted? ## Appendix -### A1: Message delivery and finality +### A1: L1 and Total Order Broadcast of votes The Postconfirmation protocol is run as a smart contract on the L1. Messages from validators are only considered for the state transition once they are executed on the L1. Since the L1 guarantees broadcast to all participants, accepted votes have total order broadcast properties, provided the L1 is safe. -Votes from validators MUST not be considered as long as they are only in the mempool of the L1. The are counted as propagated once they are finalized (not the weaker form of confirmed). +Votes from validators SHOULD not be considered as long as they are only in the mempool of the L1. They impact the state of the postconfirmation protocol after they are included in a block. + +Postconfirmations should not be counted until they are finalized. Finalization typically occurs when more than 2/3 of the validators of the L1 protocol have finalized the block that contains the vote. Since we only account for postconfirmations that are finalized, votes really only matter once postconfirmations are finalized. + +> [!NOTE] We may consider that the votes have total order broadcast properties. -Since finality is strictly a stronger guarantee than confirmation (in e.g. a single block), broadcast has total order broadcast properties. +Note that here we specifically mean finalization, which is stronger than confirmations in Ethereum, where a confirmation can be inclusion in a block and which could get reverted. ## Changelog From e17cd1085fdcb0c2efe7f4bc53de248169367b39 Mon Sep 17 00:00:00 2001 From: apenzk Date: Wed, 9 Apr 2025 12:00:19 +0200 Subject: [PATCH 8/8] address review --- MD/md-118/README.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/MD/md-118/README.md b/MD/md-118/README.md index 4ad34da9..6ae6f9a4 100644 --- a/MD/md-118/README.md +++ b/MD/md-118/README.md @@ -19,8 +19,8 @@ Protocols should describe, what are the assumptions on the L1, and how it behave **Recommendations**: Consider the following properties of the L1: -- Synchrony: at what intervals are messages broadcasted and finalized? -- Safety: under what conditions is the L1 safe? +- Synchrony: how synchronous is the L1? +- Safety: under what conditions is the L1 safe? For examples, single block confirmations are not safe in Ethereum. - Liveness: is the protocol always live? What delays should be considered? - Censorship resistance: can the L1 censor voting messages of the Postconfirmation protocol? @@ -44,13 +44,14 @@ Consider the following properties of the L1: - the delivery to the L1 - Finality guarantees, such as when a message is considered final, see [A1](#a1-message-delivery-and-finality). -### D4: Behavior of protocol if L1 assumptions are violated. +### D4: Behavior of protocol if L1 assumptions are violated **User journey (Operator)**: An operator wants to deploy a Postconfirmation protocol. They must understand, how the protocol behaves if the L1 does NOT fulfill one of the assumptions for the L1 holds. **Recommendations**: - What happens if the finality of the L1 is violated and the ledger reverts to a previous state. How does the Postconfirmation protocol behave? Are votes resubmitted? +- What is the weakest set of assumptions under which a given protocol works? ## Appendix