<?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>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>
    
      <item>
        <title>Finality Is in the Eye of the Behodler</title>
        
        <dc:creator><![CDATA[ Ittai Abraham, Vitalik Buterin, and Luca Zanolini ]]></dc:creator>
        
        <description>
          
          Finality is a belief that some things will not change in the future (are final). Finality in blockchains matters because it gives us confidence that transactions or protocol decisions, will remain permanent and immutable. This ability to commit is what makes Blockchains so powerful as a coordination mechanism. Consider the following situations: You received coins in the genesis block of Ethereum You received bitcoins three months ago, and three months...
        </description>
        <pubDate>Sun, 23 Nov 2025 03:00:00 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2025-11-23-finality/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2025-11-23-finality/</guid>
      </item>
    
      <item>
        <title>Why BFT Needs Three Rounds</title>
        
        <dc:creator><![CDATA[ Ittai Abraham and Kartik Nayak ]]></dc:creator>
        
        <description>
          
          Many modern BFT protocols share a common structural pattern. PBFT uses preprepare and prepare. Tendermint uses prevote and precommit. CasperFFG and Simplex use notarization and finalization. HotStuff uses a QC on top of another QC. Notice the pattern? Each of these protocols begins with a proposal followed by two voting rounds. This raises a natural question: Is one round of proposing followed by two rounds of voting actually necessary? This...
        </description>
        <pubDate>Sat, 22 Nov 2025 09:00:00 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2025-11-22-three-round-BFT/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2025-11-22-three-round-BFT/</guid>
      </item>
    
      <item>
        <title>From Benign Simplex to Byzantine Simplex</title>
        
        <dc:creator><![CDATA[ Ittai Abraham ]]></dc:creator>
        
        <description>
          
          In this post we present a Simplex protocol that solves single shot consensus and is resilient to $f &amp;lt; n/3$ Byzantine failures, under partial synchrony. In a previous post we showed how to move from Tendermint to Simplex. In this post we show how to move from Benign Simplex to Simplex. Benign Simplex is resilient to $f&amp;lt;n/2$ omission failures in the same setting. Moving from omission failures to Byzantine failures...
        </description>
        <pubDate>Sat, 15 Nov 2025 04:30:00 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2025-11-15-simplex-from-benign/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2025-11-15-simplex-from-benign/</guid>
      </item>
    
      <item>
        <title>Benign Simplex</title>
        
        <dc:creator><![CDATA[ Ittai Abraham ]]></dc:creator>
        
        <description>
          
          The goal of this post is to describe a single-shot consensus protocol that is resilient to f &amp;lt; n/2 omission failures, under partial synchrony. This protocol is inspired by the multi-shot Simplex for crash faults protocol and our earlier posts on Chained Raft, Benign HotStuff, and Log Paxos. Single-Shot Consensus Each party starts with an input value. We denote by $\bot$ a special value that is not an input value....
        </description>
        <pubDate>Sat, 08 Nov 2025 04:30:00 -0500</pubDate>
        <link>https://decentralizedthoughts.github.io/2025-11-08-benign-simplex/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2025-11-08-benign-simplex/</guid>
      </item>
    
      <item>
        <title>Test your understanding of the basics of fault tolerant distributed computing</title>
        
        <dc:creator><![CDATA[ Ittai Abraham ]]></dc:creator>
        
        <description>
          
          The goal of this post is to motivate you to learn the basics of distributed computing by providing a set of simple questions that test your understanding of the basic definitions. In 2025, LLM-based chatbots score 100 on this test, so that’s what you should aim for. The questions cover the standard models and fault assumptions you encounter in the first lectures of any distributed computing course. The first questions...
        </description>
        <pubDate>Wed, 22 Oct 2025 05:30:00 -0400</pubDate>
        <link>https://decentralizedthoughts.github.io/2025-10-22-quiz-basics/</link>
        <guid isPermaLink="true">https://decentralizedthoughts.github.io/2025-10-22-quiz-basics/</guid>
      </item>
    
  </channel>
</rss>
