From fe9e69b70a0570959c098661d34dfbb869381d26 Mon Sep 17 00:00:00 2001 From: Daniel Cason Date: Fri, 21 Jun 2024 15:07:28 +0200 Subject: [PATCH] spec/english: adding issues to be addressed --- specs/english/proofs_scheduling.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/specs/english/proofs_scheduling.md b/specs/english/proofs_scheduling.md index 10057e71e..90d9a5a3d 100644 --- a/specs/english/proofs_scheduling.md +++ b/specs/english/proofs_scheduling.md @@ -301,4 +301,20 @@ So, if `|unproven(s)| > P`, then the proposer of **any round** of a height `H`, where `strand(H) == s`, can only produce and propose a block if it includes `expected_proof(H)`. +## Issues to Address + +- https://github.com/informalsystems/malachite/issues/245: refers to the last + scenario described in this [section](#proposers-and-provers), when a block + can only be committed if it includes the expected proof. + If the proof is not available, and has to start being computed during the + height, we should expect a `L` latency for the height, which can be in the + order of minutes. +- https://github.com/informalsystems/malachite/issues/246: the validator set + may change at the end of each epoch. The validator set of the next epoch is + know, although not yet installed. The validator set is the input used to + compute the proposer for each round and height, therefore needs to be known a + priori. + We must discuss the relation between `E`, the epoch lenght, and `K`, the + number of strands. + [starkprover]: https://docs.starknet.io/architecture-and-concepts/network-architecture/starknet-architecture-overview/#provers