<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    
    <title>Decentralized Thoughts</title>
    
    
    <link>https://decentralizedthoughts.github.io/</link>
    <atom:link href="https://decentralizedthoughts.github.io/feed.xml" rel="self" type="application/rss+xml" />
    
    
    
      <item>
        <title>A Lower Bound for Approximate Agreement with Send Omissions</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Gilad Stern ]]></dc:creator>
        
        <description>
          
          In approximate agreement, parties start with numerical inputs in $[0,1]$. Every nonfaulty party must terminate with an output in the input range, and their outputs must differ by less than a given $\epsilon&amp;gt;0$. Define the output span of an execution as the difference between the largest and smallest nonfaulty outputs. Approximate agreement requires this span to be less than $\epsilon$. We present a modern version of Fekete’s lower bound for...
        </description>
        <pubDate>Mon, 19 Oct 2026 02:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-10-19-approximate-agreement-send-omissions-lower-bound/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-10-19-approximate-agreement-send-omissions-lower-bound/</guid>
      </item>
    
      <item>
        <title>Byzantine Approximate Agreement: Grade, Detect, Average</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Gilad Stern ]]></dc:creator>
        
        <description>
          
          The previous post gave a complete approximate agreement protocol: send the current value, remove the $f$ largest and $f$ smallest values, and take the midpoint. Each round halves the span of the honest values. Starting in $[0,1]$, reaching span less than $1/n$ takes $O(\log n)$ rounds. Ben-Or, Dolev, and Hoch improve this bound to $O(\log n / \log\log n)$. The core idea is to prevent the same Byzantine party from...
        </description>
        <pubDate>Sun, 18 Oct 2026 05:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-10-18-byzantine-approximate-agreement-grade-detect-average/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-10-18-byzantine-approximate-agreement-grade-detect-average/</guid>
      </item>
    
      <item>
        <title>Approximate Agreement with Omissions: From Midpoints to Averages</title>
        
        <dc:creator><![CDATA[ Ittai Abraham ]]></dc:creator>
        
        <description>
          
          The Byzantine approximate agreement posts start with a protocol that halves the span of honest values and repeat it to obtain a complete protocol. The Grade, Detect, Average post improves its convergence by identifying parties that cause disagreement. With omission failures, both arguments become simpler, and $n&amp;gt;2f$ parties suffice. We first give a Midpoint protocol that halves the span in each round. We then add receipt reports: a party averages...
        </description>
        <pubDate>Sun, 18 Oct 2026 02:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-10-18-approximate-agreement-with-omissions/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-10-18-approximate-agreement-with-omissions/</guid>
      </item>
    
      <item>
        <title>Byzantine Approximate Agreement: From One Round to a Complete Protocol</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Gilad Stern ]]></dc:creator>
        
        <description>
          
          The previous post showed that one round of the Robust Midpoint protocol keeps every honest value inside the old honest range and cuts the span of those values in half. Repeating this round gives approximate agreement. We do this formally in this post by specifying how many rounds to run and when parties decide. The update is the same as in the previous post: send the current value, discard the...
        </description>
        <pubDate>Sat, 17 Oct 2026 02:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-10-17-approximate-agreement-complete-protocol/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-10-17-approximate-agreement-complete-protocol/</guid>
      </item>
    
      <item>
        <title>Optimal Clock Synchronization When There Are No Failures or Drift</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Jennifer Welch ]]></dc:creator>
        
        <description>
          
          Synchronized clocks help servers coordinate. For example, servers with synchronized clocks following the same schedule can switch leaders at nearly the same time. A natural approach is for servers to exchange their current clock values and take the average. But messages take time to arrive. By the time a server receives another server’s clock value, that clock has already advanced. If the delay were known, the receiver could account for...
        </description>
        <pubDate>Tue, 13 Oct 2026 05:17:27 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-10-13-clock-synchronization-no-drift/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-10-13-clock-synchronization-no-drift/</guid>
      </item>
    
      <item>
        <title>Designated Sets in Concurrent Simplex and Alpenglow</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Clément Burgelin, Antoine Murat, Joachim Neu ]]></dc:creator>
        
        <description>
          
          Recent consensus protocols like Alpenglow or Concurrent Simplex run two confirmation paths concurrently: a “slow” path with two voting rounds, each using a small quorum, and a “fast” path with a single voting round using a large quorum. The “slow” path can actually finish first because distances are not uniform in a geographically distributed system. Some parties are nearby, often on the same continent, while others are across an ocean....
        </description>
        <pubDate>Tue, 06 Oct 2026 09:44:54 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-10-06-designated-sets/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-10-06-designated-sets/</guid>
      </item>
    
      <item>
        <title>Information Checking Protocols</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Gilad Asharov, Gilad Stern ]]></dc:creator>
        
        <description>
          
          The siege is over. The colony’s archivist brings its captain a recorded message from their founder, Hari. He predicted the attack, she says, and the choices that would let them survive. Hari is long dead. Did he foresee the siege, or did the archivist fake the recording last week? This story is inspired by Hari Seldon’s recorded messages in Isaac Asimov’s Foundation. Before the expedition leaves Earth, Hari records his...
        </description>
        <pubDate>Wed, 30 Sep 2026 05:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-09-30-information-checking-protocols/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-09-30-information-checking-protocols/</guid>
      </item>
    
      <item>
        <title>Why BFT with Byzantine and Crash Faults Needs Three Rounds</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Aniket Kate, Kartik Nayak, Nibesh Shrestha, Alberto Sonnino ]]></dc:creator>
        
        <description>
          
          How many parties do we need to decide after one proposal and one round of voting, when some faults are Byzantine and others are crashes? The answer depends on both the faults we must tolerate for eventual progress and the faults we want to tolerate on the fast path. This post is based on the elegant lower bound in the unpublished technical report of Dutta, Guerraoui, and Vukolić, 2005. A...
        </description>
        <pubDate>Sat, 26 Sep 2026 04:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-09-26-three-round-BFT-with-crashes/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-09-26-three-round-BFT-with-crashes/</guid>
      </item>
    
      <item>
        <title>Time Is Money: Incentivized Causal Transaction Ordering</title>
        
        <dc:creator><![CDATA[ Hongyin Chen, Xu Zheng, Jichen Li, Ittay Eyal ]]></dc:creator>
        
        <description>
          
          Front-running is a pervasive and costly problem on blockchains. Users earn rewards by publishing functional transactions that keeps markets efficient, such as arbitrage. But an attacker can observe such a transaction before it is ordered and publish her own ahead of it, seizing the reward and eroding users’ incentive to issue these transactions at all. The problem is well known and has drawn sustained effort from both industry and academia,...
        </description>
        <pubDate>Tue, 14 Jul 2026 12:31:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-07-14-time-is-money/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-07-14-time-is-money/</guid>
      </item>
    
      <item>
        <title>Two Round Information-Theoretic Chained BFT at n=5f-1</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Sourav Das, Yuval Efron, Jovan Komatovic, Alejandro Ranchal-Pedrosa, Gilad Stern ]]></dc:creator>
        
        <description>
          
          Information-Theoretic Kuplex gives a signature-free Simplex protocol in which quorums cannot be transferred between parties. This post makes the earlier two round BFT protocol for $n=5f-1$ signature-free in the same way. We use the Chained Simplex outer protocol: a leader extends a certified chain by one valid block. For a map of the surrounding Simplex line, see the Simplex chapter. We view this as a simple extension of IT-Kuplex. We...
        </description>
        <pubDate>Sun, 12 Jul 2026 05:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-07-12-fast-IT-BFT/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-07-12-fast-IT-BFT/</guid>
      </item>
    
      <item>
        <title>Chapter: Lower Bounds</title>
        
        <dc:creator><![CDATA[ Ittai Abraham ]]></dc:creator>
        
        <description>
          
          This post is a map of the lower-bound posts on Decentralized Thoughts. The Start Here page already lists many of these results by topic, and the lowerbound tag lists the posts themselves. Here we turn that list into a chapter: first the main fault-threshold barriers, then communication, round complexity, latency, clock synchronization, validity, privacy, and liveness. In distributed computing, an upper bound is often a condition and a protocol for...
        </description>
        <pubDate>Sun, 28 Jun 2026 05:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-06-28-chapter-lower-bounds/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-06-28-chapter-lower-bounds/</guid>
      </item>
    
      <item>
        <title>Information-Theoretic Kuplex</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Sourav Das, Yuval Efron, Jovan Komatovic, Gilad Stern ]]></dc:creator>
        
        <description>
          
          Simplex is usually stated with signed quorums that anyone can forward and verify. Here we describe an information-theoretic version. Parties have authenticated point-to-point channels, but no signatures and no transferable quorums. Each party therefore acts only on quorums of messages it received directly. The motivation is practical as well as conceptual: avoiding signatures removes signature verification from the critical path. Threshold signatures and multi-signatures can reduce this overhead in signed...
        </description>
        <pubDate>Fri, 05 Jun 2026 05:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-06-05-IT-Kuplex/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-06-05-IT-Kuplex/</guid>
      </item>
    
      <item>
        <title>Chapter: Simplex</title>
        
        <dc:creator><![CDATA[ Ittai Abraham ]]></dc:creator>
        
        <description>
          
          This post is a map of the Simplex line of posts on Decentralized Thoughts. It is meant to be read as a chapter: first the core Simplex idea, then some of the main ways to vary it. A salient property of Simplex is that parties leave a view only with a value certificate or a skip certificate. This is in contrast to protocols like PBFT, HotStuff, Casper, and Tendermint, where...
        </description>
        <pubDate>Mon, 25 May 2026 05:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-05-25-chapter-simplex/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-05-25-chapter-simplex/</guid>
      </item>
    
      <item>
        <title>Lutris: Safe Composition of Broadcast and Consensus</title>
        
        <dc:creator><![CDATA[ Lefteris Kokoris Kogias, Alberto Sonnino ]]></dc:creator>
        
        <description>
          
          TL;DR Lutris is a hybrid distributed system protocol that integrates Byzantine Consistent Broadcast with a BFT consensus DAG to minimize latency of specific types of transactions. Hybrid Consistency: Uses broadcast for single-writer operations and consensus for shared-state contention. Unified State Machine: Maintains linearizability across both paths via versioned object locking. Liveness Recovery: Solves the “eternal lock” problem of previous broadcast protocols using epoch-based reconfiguration. Hybrid Reconfiguration: Leverages the consensus path...
        </description>
        <pubDate>Wed, 20 May 2026 07:29:56 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-05-20-sui-lutris/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-05-20-sui-lutris/</guid>
      </item>
    
      <item>
        <title>From Single-Shot Simplex to Chained Simplex</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Joachim Neu ]]></dc:creator>
        
        <description>
          
          In this post we construct Chained Simplex from single-shot Simplex. The chained construction is a simple modification of the single-shot protocol and applies to any Simplex variant with the same inner certificate properties and outer proposal structure. See here for more generic constructions. For a map of the surrounding Simplex line, see the Simplex chapter. We will use the decomposition from deconstructing Simplex to make the construction explicit. That post...
        </description>
        <pubDate>Wed, 20 May 2026 02:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-05-20-from-single-shot-to-chained/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-05-20-from-single-shot-to-chained/</guid>
      </item>
    
      <item>
        <title>Fast Simplex on a Fixed View Schedule</title>
        
        <dc:creator><![CDATA[ Ittai Abraham ]]></dc:creator>
        
        <description>
          
          Simplex FVS uses fixed views of length $3\Delta$. This post gives a two round version with view length $2\Delta$, using the two round Simplex certificate structure. For a map of the surrounding Simplex line, see the Simplex chapter. The price is the usual one for two round BFT: we use $n=5f+1$ parties. A view has only one leader proposal and one round of votes. If a later leader needs to...
        </description>
        <pubDate>Sun, 17 May 2026 01:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-05-17-fast-simplex-fvs/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-05-17-fast-simplex-fvs/</guid>
      </item>
    
      <item>
        <title>Simplex on a Fixed View Schedule</title>
        
        <dc:creator><![CDATA[ Ittai Abraham ]]></dc:creator>
        
        <description>
          
          This post gives a fixed view schedule version of Simplex, called Simplex FVS, with the advantages of a fixed view schedule discussed here. For a map of the surrounding Simplex line, see the Simplex chapter. In the FVS design, the start and end times of each view are fixed in advance; this requires synchronized clocks. We number protocol views starting at $1$, and view $v$ starts at time $3v\Delta$. After...
        </description>
        <pubDate>Thu, 14 May 2026 05:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-05-14-simplex-FVS/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-05-14-simplex-FVS/</guid>
      </item>
    
      <item>
        <title>Beyond censorship resistance: hiding, simultaneous binding, and accountable last look</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Pranav Garimidi, and Joachim Neu ]]></dc:creator>
        
        <description>
          
          In a previous post we introduced strong chain quality (SCQ), which provides a strong form of censorship resistance: honest parties’ transactions are included in proportion to their share of the validator set in every block. This post considers three additional properties needed for efficient on-chain markets: hiding, simultaneous binding (SB), and accountable last look (ALL). Hiding Hiding: No information about the contents of honest parties’ inputs is revealed to the...
        </description>
        <pubDate>Mon, 27 Apr 2026 05:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-04-27-beyond-CR/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-04-27-beyond-CR/</guid>
      </item>
    
      <item>
        <title>From Simplex to Complex</title>
        
        <dc:creator><![CDATA[ Ittai Abraham ]]></dc:creator>
        
        <description>
          
          Tendermint and Simplex are both leader-based BFT protocols for partial synchrony with optimal resilience and $3\delta$ good-case latency. There is a subtle tradeoff between them: In the optimistic responsive model, Simplex obtains a worst-case view latency of $3\Delta+\delta$ while Tendermint obtains a worst-case view latency of $4\Delta+\delta$. On the other hand, Tendermint requires only a bounded number of certificates to make progress in each view, while in Simplex the number...
        </description>
        <pubDate>Sun, 26 Apr 2026 05:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-04-26-complex/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-04-26-complex/</guid>
      </item>
    
      <item>
        <title>Latency cost of censorship resistance</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Yuval Efron, and Ling Ren ]]></dc:creator>
        
        <description>
          
          This post covers our new lower bound on the latency cost of censorship resistance. In a traditional partial synchrony BFT protocol, the leader has two roles: (1) It constructs the input; and (2) It proposes the input. The natural validity property: Validity: if the leader is honest and the network is synchronous (GST=0), its input value is eventually decided by all honest parties. Moreover, it is natural to optimize for...
        </description>
        <pubDate>Thu, 23 Apr 2026 02:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-04-23-latency-of-censorship-resistance/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-04-23-latency-of-censorship-resistance/</guid>
      </item>
    
  </channel>
</rss>
