From 7f10031ccc8a9a605ff27c6c0cc717793bd1b829 Mon Sep 17 00:00:00 2001 From: George Knee Date: Mon, 9 Sep 2024 14:13:36 +0100 Subject: [PATCH] Some tweaks to the batch derivation spec (#365) * replace "window" with "channel" "window" is not defined * remove implication that a frame from the next channel will be bigger than the final fram of the previous channel this is contradicted by the diagram * move section referencing "channel identification feature" This is jarring to read as no channel identification material is in scope in this section. * do not render sentence as footnote This looks wrong when I run `just serve` (it displays the footnote in place instead of at the bottom of the document). * change L2 tx pool -> L1 tx pool I don't believe the batcher is concerned with the L2 tx pool * change blocks -> batches staying true to the "subtle but important" distinction * lint * remove empty file * remove speculative paragraph --- specs/protocol/derivation.md | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/specs/protocol/derivation.md b/specs/protocol/derivation.md index bc3cc2cb4..02d97daa4 100644 --- a/specs/protocol/derivation.md +++ b/specs/protocol/derivation.md @@ -244,15 +244,9 @@ into chunks known as [channel frames][g-channel-frame]. A single batcher transac This design gives use the maximum flexibility in how we aggregate batches into channels, and split channels over batcher transactions. It notably allows us to maximize data utilization in a batcher transaction: for instance it allows us to -pack the final (small) frame of a window with large frames from the next window. +pack the final (small) frame of one channel with one or more frames from the next channel. -In the future this channel identification feature also allows the [batcher][g-batcher] to employ multiple signers -(private keys) to submit one or multiple channels in parallel (1). - -(1) This helps alleviate issues where, because of transaction nonce values affecting the L2 tx-pool and thus inclusion: -multiple transactions made by the same signer are stuck waiting on the inclusion of a previous transaction. - -Also note that we use a streaming compression scheme, and we do not need to know how many blocks a channel will end up +Also note that we use a streaming compression scheme, and we do not need to know how many batches a channel will end up containing when we start a channel, or even as we send the first frames in the channel. And by splitting channels across multiple data transactions, the L2 can have larger block data than the