<?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>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. We will use the decomposition from deconstructing Simplex to make the construction explicit. That post separates Simplex into: an inner protocol, which produces value certificates, decision certificates,...
        </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. 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 skip the view, it does not wait for a skip vote sent...
        </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. 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 a view ends, parties no longer sign new messages for it, but...
        </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>
    
      <item>
        <title>Deconstructing Simplex</title>
        
        <dc:creator><![CDATA[ Ittai Abraham ]]></dc:creator>
        
        <description>
          
          In a previous post we decomposed PBFT into an outer shell and an inner shell consisting of two building blocks: Locked-Broadcast (LB) and Recover-Max-Lock. Here we similarly decompose Simplex into an outer shell and an inner shell consisting of a single building block: Graded-Broadcast (GB). The model is partial synchrony with $f&amp;lt;n/3$ Byzantine failures, and the goal is single-shot provable consensus with external validity. Single-shot Provable Consensus with External Validity...
        </description>
        <pubDate>Thu, 23 Apr 2026 01:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-04-23-deconstructing-simplex/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-04-23-deconstructing-simplex/</guid>
      </item>
    
      <item>
        <title>Strong Chain Quality</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Pranav Garimidi, Joachim Neu ]]></dc:creator>
        
        <description>
          
          Chain Quality (CQ) is a core blockchain property. Roughly speaking, it says: Owning $3\%$ of the stake gives you inclusion rights over valid inputs of your choice in roughly $3\%$ of the blockspace over time. For Nakamoto style chains, this is called Ideal CQ (see here). Chain quality was sufficient for early generations of blockchains that had low throughput, but modern blockchains have much higher bandwidth and can commit many...
        </description>
        <pubDate>Mon, 23 Mar 2026 01:00:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-03-23-strong-chain-quality/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-03-23-strong-chain-quality/</guid>
      </item>
    
      <item>
        <title>Synchronized Clocks, Fixed View Schedules, and Simultaneous Agreement</title>
        
        <dc:creator><![CDATA[ Ittai Abraham ]]></dc:creator>
        
        <description>
          
          Most modern blockchain protocols use partial synchrony-based BFT protocols that proceed in views. Each view has a designated block proposer (leader). This naturally leads to the following design question: How should parties synchronize the transition from view $i$ to view $i+1$? Dwork, Lynch, Stockmeyer, Consensus in the Presence of Partial Synchrony considered two models: one with synchronized clocks, and one with unbounded clock drift pre-GST. We argue that the former...
        </description>
        <pubDate>Sat, 07 Mar 2026 17:59:27 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-03-07-simultaneous-agreement/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-03-07-simultaneous-agreement/</guid>
      </item>
    
      <item>
        <title>Mysticeti: Revolutionizing Consensus on Sui</title>
        
        <dc:creator><![CDATA[ Lefteris Kokoris Kogias, Alberto Sonnino, George Danezis ]]></dc:creator>
        
        <description>
          
          TL;DR Mysticeti is a novel Byzantine consensus protocol deployed on the Sui blockchain that revolutionizes transaction processing. Eliminates explicit certification, reducing good-case latency to the theoretical minimum. Crash-fault masking, avoiding head-of-line blocking for pipelined rounds. 40% CPU usage reduction for consensus in production. 80% latency reduction compared to Bullshark on Sui Mainnet (from ~1.9s to ~400ms). Mysticeti is a novel Byzantine consensus protocol recently deployed on the Sui blockchain. It...
        </description>
        <pubDate>Fri, 06 Mar 2026 00:00:00 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-03-06-mysticeti-revolutionizing-consensus-on-sui/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-03-06-mysticeti-revolutionizing-consensus-on-sui/</guid>
      </item>
    
      <item>
        <title>Beyond Latency and Communication Complexity - A Tutorial on the Pipes Model</title>
        
        <dc:creator><![CDATA[ Andrew Lewis-Pye, Kartik Nayak, Nibesh Shrestha ]]></dc:creator>
        
        <description>
          
          Traditionally, protocol performance is summarized using two metrics: latency (measured in rounds), and communication complexity (measured asymptotically, e.g., $O(n^2)$). If both are small, we might expect the protocol to perform well in practice. But this intuition is incomplete. When Low Latency and Low Communication Aren’t Enough Consider two protocols: Protocol A: 3-round good-case latency and $O(n^4)$ communication. Protocol B: 5-round good-case latency and $O(n^3)$ communication. These are the asymptotics for...
        </description>
        <pubDate>Fri, 13 Feb 2026 00:00:00 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-02-13-pipes/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-02-13-pipes/</guid>
      </item>
    
      <item>
        <title>Partial Synchrony Progress Cheat Sheet</title>
        
        <dc:creator><![CDATA[ Kartik Nayak ]]></dc:creator>
        
        <description>
          
          A walkthrough of this progress is available on the TheCoordinate podcast. A downloadable PDF is available here. The PBFT line of work A: Comparing PBFT, SBFT, Tendermint, HotStuff, and HotStuff-2: post1, post2 B: Explaining the core ideas behind PBFT: principles, PBFT C: Comparing the protocols Tendermint and Simplex, a lecture video explaining Tendermint D: Comparing the communication complexity of PBFT/Tendermint and Simplex under harsh conditions The Simplex line of work...
        </description>
        <pubDate>Mon, 02 Feb 2026 09:06:00 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-02-02-ps-cheat-sheet/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-02-02-ps-cheat-sheet/</guid>
      </item>
    
      <item>
        <title>Concurrent 2-round and 3-round BFT protocols under granular synchrony</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Kartik Nayak, and Alejandro Ranchal-pedrosa ]]></dc:creator>
        
        <description>
          
          Consensus protocols for $n=3f+1$ can tolerate $f$ Byzantine faults under partial synchrony. However, they also require a latency of 3 rounds in the good-case when the leader is non-faulty, and the system is synchronous. Can we get a protocol with better latency, or tolerate more faults, if we assume $n=3f+2p+1$? Better latency: If the actual number of Byzantine faults in an execution are fewer, then the protocol can commit faster....
        </description>
        <pubDate>Sat, 24 Jan 2026 01:00:00 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-01-24-two-round-ps/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-01-24-two-round-ps/</guid>
      </item>
    
      <item>
        <title>Simple Payment Systems with Unlinkability</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Gilad Stern, and Alin Tomescu ]]></dc:creator>
        
        <description>
          
          In this post, we discuss payment systems. There is a set of users who wish to pay each other. We start with perhaps the simplest form, which is based just on digital signatures and a single bank. We then show how the bank can be implemented as a fault tolerant distributed system with $n$ servers. Finally, we show a modern version of ecash, where blind signatures are used to obtain...
        </description>
        <pubDate>Wed, 21 Jan 2026 02:00:00 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-01-21-simple-payment/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-01-21-simple-payment/</guid>
      </item>
    
      <item>
        <title>Blind and Threshold Blind Signatures</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Gilad Stern, and Alin Tomescu ]]></dc:creator>
        
        <description>
          
          A blind signature scheme allows a user to obtain a valid signature on a message while ensuring that the signer learns nothing about the message. The user blinds the message, the signer signs the blinded value, and the user unblinds the response to obtain a valid signature on the original message. Importantly, the signer still retains full control over whether to participate in the protocol, it only gives up visibility...
        </description>
        <pubDate>Wed, 21 Jan 2026 01:00:00 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2026-01-21-blind-and-threshold/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2026-01-21-blind-and-threshold/</guid>
      </item>
    
      <item>
        <title>Partial Synchrony variants</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Yuval Efron, Kartik Nayak, and Ling Ren ]]></dc:creator>
        
        <description>
          
          In this post we observe three variants of Partial Synchrony (PS) and how they affect (or not) popular BFT protocols like PBFT, Tendermint, and especially the recent Simplex protocol. Many modern systems use the following definition of Partial Synchrony: Bounded Partial Synchrony (BPS): A message sent at time $t$ arrives by time at most $\max{t, GST}+\Delta$ This definition implicitly assumes that messages sent before $GST$ are delayed but not lost,...
        </description>
        <pubDate>Fri, 19 Dec 2025 23:00:00 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2025-12-19-cc-under-harsh-ps/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2025-12-19-cc-under-harsh-ps/</guid>
      </item>
    
      <item>
        <title>DPaaS - Improving Decentralization by Removing Relays in Ethereum PBS</title>
        
        <dc:creator><![CDATA[ Chenyang Liu, Ittai Abraham, Matthew Lentz, Kartik Nayak ]]></dc:creator>
        
        <description>
          
          In this blog post, we will explain the core ideas of Decentralized Proposer-as-a-Service (DPaaS), a side-car protocol that removes centralized and unconditionally trusted relays in current Ethereum Proposer-Builder Separation (PBS). The full paper is on the eprint. PBS and MEV-Boost Proposer-Builder Separation (PBS) was proposed to mitigate the validator centralization brought by the inequality of mining MEV. PBS is inherently a trade between the proposer and builder, requiring fair exchange...
        </description>
        <pubDate>Fri, 12 Dec 2025 07:00:00 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2025-12-12-dpaas/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2025-12-12-dpaas/</guid>
      </item>
    
      <item>
        <title>Scalable Agreement - Near Linear Communication and Constant Expected Time</title>
        
        <dc:creator><![CDATA[ Ittai Abraham ]]></dc:creator>
        
        <description>
          
          Agreement needs quadratic communication and linear time in the worst case. Scalable Agreement aims for near linear communication and constant time in expectation. In this post, we show scalable agreement against a weak adaptive adversary that can cause omission failures. This will be the basis for the Byzantine case that we will explore in future posts. This post can be seen as followup to the posts that solve binary consensus...
        </description>
        <pubDate>Fri, 12 Dec 2025 06:00:00 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2025-12-12-scalable-agreement/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2025-12-12-scalable-agreement/</guid>
      </item>
    
  </channel>
</rss>
