Lemonshark: Asynchronous DAG-BFT With Early Finality

Abstract

DAG-Rider popularized a new paradigm of DAG-BFT protocols, separating dissemination from consensus: all nodes disseminate transactions as blocks that reference previously known blocks, while consensus is reached by electing certain blocks as leaders. This design yields high throughput but confers optimal latency only to leader blocks; non-leader blocks cannot be committed independently. We present Lemonshark, an asynchronous DAG-BFT protocol that reinterprets the DAG at a transactional level and identifies conditions where commitment is sufficient -- but not necessary -- for safe results, enabling nodes to finalize transactions before official commitment, without compromising correctness. Compared to the state-of-the-art asynchronous BFT protocol, Lemonshark reduces latency by up to 65\%.

Figures (19)

• Figure 1: An example of latency disparities in Bullshark. Only critical pointers are shown for clarity. Red blocks denote steady leaders, purple blocks denote fallback leaders, with crowns indicating committed leaders. The steady leader at round $r+1$ commits upon obtaining sufficient votes, while the green block at round $r$ must await inclusion in a future leader's causal history, incurring 8 additional rounds of delay. Were the green block itself a steady leader, it would commit at round $r+1$.
• Figure 2: Both $\hat{b}$ and $\tilde{b}$ contain transactions conflicting with those in $b$. This figure demonstrates that Bullshark requires commitment to resolve ordering uncertainty for such blocks.
• Figure 3: Blue blocks represent the causal history of $b$---excluding previously committed blocks. Blocks are ordered via breadth-first traversal by ascending round number, terminating at $b$. (a) Executing blocks in this order ($b_1,\dots,b$) yields the execution prefix $b'\langle b\rangle$.
• Figure 4: Orange blocks represent all uncommitted blocks from rounds prior to $b$'s round that might impact the finalized outcome of $b$. The totally ordered list of committed leaders is generated by the DAG consensus core (\ref{['subsec:bullshark']}).
• Figure 5: Consider a scenario where all blocks before round $1$ has committed. The blue and green blocks are in-charge of two distinct shards ($k_1,k_2$), and the red blocks $b',b"$ are leader blocks. Suppose both $b_1^4,b_2^4$ persists in round $5$. For $b_2^4$, it has all uncommitted blue blocks as part of its causal history; however, each block does not point to the block of the same shard in the previous round. The block outcome of $b_2^4$ will execute blue blocks in the order of: $(b^1_2,b^2_2,b^3_2,b_2^4)$. However, if $b^2_2 \in H_{b'}, b^1_2,b^3_2 \notin H_{b'}$ and $b'$ is committed, then the final order is $b^2_2,b^1_2,b^3_2,b_2^4$; therefore, $b_2^4$ does not have SBO. In contrast, suppose $b_1^3$ has SBO, and $b_1^4$ points to it and persists in round $5$, its BO will execute the green blocks in the order: $(b^1_1,b^2_1,b^3_1,b_1^4)$. Regardless of which subset of green blocks is in $H_{b'}$, the block outcome of $b_1^4$ will always be equivalent to the execution prefix $b" \langle b_1\rangle$.

Theorems & Definitions (67)

• Definition 4.1: (Sorted) Causal History of a Block
• Definition 4.2: Transaction Outcome (TO)
• Definition 4.3: Block Outcome (BO)
• Definition 4.4: Execution Prefix (Block)
• Definition 4.5: Execution Prefix (Transactions)
• Definition 4.6: Safe Transaction Outcome (STO)
• Definition 4.7: Safe Block Outcome (SBO)
• Definition 4.8: Early Finality
• Definition A.1: Rounds and Waves
• Definition A.2: Blocks and Pointers