This page visualizes the consequences of different values of L = between 2 and 200. L is the sum 3×Lhdr + Lvote + Ldiff from the Linear Leios specification.
One calculation we've often considered is the probability of the leader schedule itself preventing an EB from succeeding: Linear Leios allows an EB to be certified only by the subsequent RB and only if that RB arises at least L slots later. Before we introduce the math, a corresponding clarification is due.
While we do often refer to the "leader schedule" as the limiting factor, that habit tacitly assumes the adversary is not attacking Praos. In other words, it assumes that the density of the RBs on the best Praos chain are determined by the leader schedule. The relevant parameter is f = 5%, the Praos active slot coefficient.
When not under attack, f causes the Praos chain to grow by one block every 1/f=20 seconds, on average. When under attack, however, the honest parties will be unable to communicate as effectively, and so some of their elections in the leader schedule will be wasted on short forks instead of them all contributing as growth of the best single chain. We introduce a variable g = between 1% and f=5% to model this. When g = f = 5%, the adversary is not interfering with Praos. When g < f, they are, and the difference determines the degree of their success—this numeric quantity is ad-hoc, but useful enough for our other calculations in this memo.
P(too dense | L=) = 1 − (1 − g)L = 1 − = .
A g-chain will, on average, need to announce N = (1 − g)−L = EBs for g to allow one of them to succeed. That's the N for which N × (1 − P(too dense | L=)) = 1.
A g-chain will, on average, announce one EB per 1/g= seconds. Therefore, on average, there will be N ÷ g = seconds between EBs not prevented by g.
Beyond just the average N ÷ g, we can also calculate the whole probability mass function of that duration. The model is tosses of a (1−g):g biased coin, where every run of at least L heads terminated by a tails is an EB that g didn't prevent, which is a "jump" in that "renewal process" and therefore delineates the "holding time" since the previous jump. Here it's shown for the shortest durations whose cumulative probability is at least 95% along with select quantiles.
For a given positive maximum EB size MaxSize = , we can calculate the throughput capacity offered by the successful EBs on an average g-chain. If we optimistically assume that every EB that g doesn't prevent is both successful and full, then the average capacity will be MaxSize ÷ (N ÷ g) = bytes per second. Here it's shown for possible values of L from 0 to ⌈L×4÷3⌉.
Also shown in orange is the average rate at which EBs are announced. Note that as L increases or g decreases, the capacity decreases but the amount of announcements doesn't change—it's still one per 1/f=20 seconds. MaxSize can be increased to bring the capacity back up, but that also proportionally increases the size of each announced EB. It's therefore important to acknowledge that adversarial RBs are able to announce any EB they want, and the whole network will diffuse it—they can choose to always announce full EBs, even if no EB has succeeded for a long while.
Suppose the adversary controls a percentage of the total stake A = between 0 and 50%. (If A is large, the adversary could severely reduce g well below f=5%, for example, by simply withholding their own blocks. But whether to do so is that adversary's prerogative, and so the variables can be tuned independently.) This adversary leads each slot with a probability of φf(A) = 1 − (1 − f)A = . Thus, the ratio of the network utilization the adversary can steadily cause versus the average g-chain capacity is (N ÷ g) ÷ (1 ÷ φf(A)) = —and that's even assuming the adversary is choosing to include certs in its RBs. If they instead omit Leios certs from their RBs, then the ratio worsens by some factor like 1 ÷ (1 − A) to .
If the adversary is causing mempool fragmentation, then the honest announced EBs could also be full even when no EBs are succeeding. In the most extreme case, the ratio would worsen to (N ÷ g) ÷ (1 ÷ f) = or even something like 1 ÷ (1 − A) times worse at if the adversary omits Leios certs in their RBs.
Three caveats.
Finally, a question related to how quickly the Mempools would need to be able to refill. If EBs are succeeding too quickly, back-to-back, then TxSubmission might not be able to replenish the Mempools to saturate the unusually high density of successful EBs on the g-chain.
The following plot has x-axis from k=0 to k=30×L. It plots the probability that there will be at most M additional EBs allowed by g within the k slots starting immediately after some jump.
CIP-0164 recommends a Mempool containing enough transactions for two full EBs. Thus, the M=1 line captures the probability that a Mempool that was full before the initiating EB would suffice even if it wasn't refilled at all. The M=2 line, therefore, indicates how soon the Mempool would need to refill one EB's worth of transactions to avoid not being able to fill the thirrd EB in a short timeframe. The higher M curves would demand that much faster refilling.