<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Posts on Liangrun Da&#39;s website</title>
    <link>/posts/</link>
    <description>Recent content in Posts on Liangrun Da&#39;s website</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Aug 2024 22:02:05 +0200</lastBuildDate>
    <atom:link href="/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Revisit CAP Theorem in Blockchain</title>
      <link>/posts/cap-blockchain/</link>
      <pubDate>Tue, 06 Aug 2024 22:02:05 +0200</pubDate>
      <guid>/posts/cap-blockchain/</guid>
      <description>I came across some articles 1 and lectures 2 that use the CAP theorem to explain the blockchain. I don&amp;rsquo;t think it is a good idea. The CAP theorem is a very specific theorem that is proved in a very specific context. It is not a general theorem that can be applied to any distributed system.
The CAP theorem came from this paper. The theorem is proved in a very restricted context, where a distributed read-write register is used for the model.</description>
    </item>
    <item>
      <title>Model Checking: Use Stateright to Formally Verify Raft Lite</title>
      <link>/posts/raft-lite-model-check/</link>
      <pubDate>Sat, 24 Feb 2024 00:00:00 +0200</pubDate>
      <guid>/posts/raft-lite-model-check/</guid>
      <description>You can find the source code of this post here.
Background of model checking Distributed system is rather complex due to the fact that the message can be lost, delayed or duplicated. It is hard to reason about the correctness of a distributed system.
Hand-written proof is a common way to verify the correctness of a distributed system. For example, the Raft paper provides a proof of safety property of Raft in Section 5.4. Many proofs seem plausible but actually could be wrong (I&amp;rsquo;m not saying the Raft paper&amp;rsquo;s proof is wrong).</description>
    </item>
    <item>
      <title>Raft Lite: An Easy-to-understand Implementation of Raft Consensus Algorithm</title>
      <link>/posts/raft-lite/</link>
      <pubDate>Tue, 02 Jan 2024 00:00:00 +0200</pubDate>
      <guid>/posts/raft-lite/</guid>
      <description>Raft Lite is a simple and easy-to-understand implementation of the Raft consensus algorithm. In this post, I will explain the internal implementation of Raft Lite. Please find the complete implementation of Raft Lite in the Raft Lite repository if you are interested.
Consensus algorithm and total order broadcast State machine replication (SMR) is a fundamental problem in distributed systems. The problem is as follows: suppose we have a set of nodes, each of which maintains a state machine.</description>
    </item>
    <item>
      <title>What&#39;s behind Automerge? (Part II)</title>
      <link>/posts/automerge-internal-2/</link>
      <pubDate>Tue, 13 Jun 2023 00:00:01 +0200</pubDate>
      <guid>/posts/automerge-internal-2/</guid>
      <description>Storage From operations to changes Before applying operations received from other actors, it&amp;rsquo;s necessary to ensure that they are causally ready. This rule applies to most Operation-based CRDTs 1.
We can use vector clocks to ensure that all operations are causally applied, but it is not Byzantine fault tolerant. Another way is to use Hash DAG 2. By recording the dependencies of each operation, other actors can determine if it is causally ready when they receive it by checking if its dependencies exist in the current OpSet.</description>
    </item>
    <item>
      <title>What&#39;s behind Automerge? (Part I)</title>
      <link>/posts/automerge-internal-1/</link>
      <pubDate>Tue, 13 Jun 2023 00:00:00 +0200</pubDate>
      <guid>/posts/automerge-internal-1/</guid>
      <description>Runtime Operation Set Operation Set (OpSet), as the name suggested, is a set of operations. It is the runtime data structure of Automerge, that enables the creation, retrieval, updating, and deletion of objects. The merging of two documents is conceptually the union of two operation sets.
Everytime we update, delete or create an object, we insert an operation into the OpSet. And the retrieval of an object is actually the retrieval of an operation of the OpSet.</description>
    </item>
    <item>
      <title>Hello</title>
      <link>/posts/hello/</link>
      <pubDate>Fri, 05 May 2023 11:30:23 +0200</pubDate>
      <guid>/posts/hello/</guid>
      <description>Hello, everyone!</description>
    </item>
  </channel>
</rss>
