【大佬说】V神连发75条推文解释以太坊Casper历史以及状态

链得得注：8月14日凌晨ETH快速下跌，当天上午10点，跌至今年来的最低点251USDT。市场中不断有言论传出：以太坊至暗时刻要来了。

今日上午9点20分，以太坊创始人Vitalik Buterin发布推文称将于在Twitter上解释以太坊Casper研究的历史以及状态，问题包括FFG与CBC的战争、机制设计等。

最终，总共已经发布了75条推文，链得得App特别整理了V神的全程内容，同时这也是关于以太坊Casper最完整的发展解读。

 

以下为以太坊创始人Vitalik Buterin推特译稿，由链得得App编辑翻译：

 1。今天我将在推特上解释Ethereum公司Casper研究的历史和现状，包括FFG 和CBC战争、混合式=>全开关、随机性的作用、机制设计问题等等。

2、以太坊的研究始于2014年1月的Slasher项目（查看详情），虽然该算法不够理想，但它引入了一些重要的思想，尤其是使用惩罚来解决无关紧要的问题（查看详情）。

3、也就是说，我使用的惩罚非常小，只抵消了签约奖励。弗拉德•赞菲尔(Vlad Zamfir)是在2014年年中加入的，他很快就开始要求验钞机存入比奖励大得多的“存款”，这些钱可能会因为不当行为而被拿走。

4、这是弗拉德的复述:查看详情

5、2014年末的大部分时间里，我们都在努力应对“远程攻击”，即攻击者从主链上的存款中提取股份，并利用它创建一个具有比主链更多签名的替代“攻击链”，这样他们引导客户转而使用。

6、如果攻击链在最近的某个时间点偏离主链，这就不是问题，因为如果验证器为两个冲突链签署了两个冲突消息，这就可以作为惩罚它们和拿走它们的存款的证据。

7、但如果分歧发生在很久以前(因此，远程攻击)，攻击者可以撤回他们的存款，以防止对任何一个链。

8、我们最终发现，远程攻击是不可避免的，因为POW支持者有很多理由（查看详情），但是最后我们仍旧没有接受他们的结论。

9、我们意识到，我们可以通过引入额外的安全假设来应对远程攻击:客户至少每4个月登录一次(存款需要4个月才能取走)，而客户只是拒绝回复。

10、对于POW支持者来说，这是一种诅咒，因为这感觉像是一种信任假设:当您第一次同步时，您需要从某个可信的来源获得区块链。

11、但对我们而言，似乎不是什么大事;您需要一些可信的来源来告诉您在任何情况下区块链的一致规则是什么(不要忘记软件更新)，因此这个PoS假设所需要的额外信任并不大。

12、这是弗拉德的复述（查看详情）

13、既然我们已经解决了存款和罚金的问题，我们就必须决定这些存款和罚金是什么。我们知道我们想要一个“经济终结性”的属性，在这个属性中，验证者会以这样一种方式在块上签名……

14、. .一旦一个块被“确定下来”，那么没有一个矛盾块可以被确定下来，而不需要很大一部分验证者以区块链可以检测到的方式对与其早期消息冲突的消息进行签名。

15、我在一个称之为“打赌达成共识”的方向上做了一个很长但最终毫无成效的偏离:（查看详情）

16、通过打赌达成共识是一种有趣的构造，验证者将在哪个区块上下注，而赌注本身决定了共识支持哪条链。

17、POW也有这个属性的理论是,矿业是一个赌注,如果你押注正确的链,你获得(奖励-采矿成本),如果你赌错链,你失去了采矿成本,除了PoS我们可以推动押注的几率高得多。

18、验证者下注的几率开始会很低，但是当验证者看到彼此对一个block越来越有信心的时候，每个人下注的几率都会呈指数级增长，直到最后他们把所有的存款都押在了block上。这将是“终结”。

19、与此同时，Vlad开始大量研究机制设计，特别是着眼于使卡斯珀更能抵御寡头垄断，我们还开始研究受传统拜占庭容错理论启发的共识算法，比如Tendermint。

20、弗拉德认为，传统的BFT是站不住脚的(他尤其不喜欢硬阈值，比如PBFT和Tendermint的2/3)，他将尝试用一种他称之为“构建正确”(CBC)的方法，从零开始，有效地重新定义BFT理论。

21、这是弗拉德当时写的话：（查看详情）

22、按结构进行校正的逻辑与传统的BFT非常不同，因为“终结性”是完全主观的。在CBC逻辑中，验证者会签署消息，如果他们签署的消息与之前的消息冲突……

23、…他们必须提出一个“理由”来证明，在相关意义上，他们投票支持的新事物比他们投票支持的旧事物“拥有更多的支持”，因此他们有权转而支持旧事物。

24、为了检测终结性，客户端开始寻找模式以证明大多数验证者都可靠地投票给B区块，如果没有很大一部分验证器“非法”切换投票，他们就无法离开B区块。

25、例如，如果每个人都投票给B，那么每个人都在一个包含每个人投票给B的block上投票，这证明了他们支持B并且知道其他人都支持B，所以他们没有合法的理由去转换到B以外的东西。

26、我最终放弃了打赌达成共识的想法，因为这种方法似乎从根本上来说风险太大，所以我转而尝试理解像PBFT这样的算法是如何工作的。花了一段时间，但几个月后我明白了。

27、我设法简化了PBFT (查看详情)，并将其翻译成区块链上下文，将其描述为四个“苛刻条件”，规定了哪些消息组合是自相矛盾的，哪些是非法的（查看详情）

28、我定义了一个确定块何时被确定的规则，并证明了关键的“安全性”和“似是而非的活性”属性:(I)如果一个块被确定，那么在>= 1/3违反苛刻条件的情况下，冲突块无法被确定……

29、…(ii)如果一个块被确定下来，2/3诚实的验证器总是可以合作确定一个新的块。因此，只要> 2/3是诚实的，算法既不能“言归于好”，也不能“卡住”。

30、最后，我将最小的削减条件从4个简化为2个，然后Casper就得到了友好的结尾工具 (FFG)，它被设计成可用于任何PoW、PoS或其他区块链之上的覆盖层，以添加最后的保证。

31、终结性是一个非常重要的进步:一旦一个块完成，不管网络延迟(不像PoW中的确认)，它都是安全的，并且恢复块需要>= 1/3的验证器以一种可检测的方式欺骗，可以用来销毁它们的存款。

32、因此，恢复最后期限的成本可能高达数十亿美元。Casper CBC和Casper FFG方法都实现了这一点，尽管在技术上不同。

33、请注意，Casper CBC和Casper FFG都是“覆盖”，需要应用于一些现有的分叉选择规则之上，尽管以不同的方式工作。

34、用最简单的话说，在Casper CBC中，结尾覆盖适应了分叉选择规则，而在Casper FFG中，分叉选择规则适应了结尾覆盖。

35、Vlad最初对分叉选择规则的偏好是“最新的消息驱动的GHOST”，这是GHOST (查看详情)对proof of stake的修改，而我最初的偏好是从混合PoS开始的，使用proof of work作为基本的fork选择规则。

36、在Casper FFG的初始版本中，工作证明将逐块“运行”链条，桩的证明将紧跟在后面以确定块。卡斯帕CBC从一开始就充分证明了利害关系。

37、与此同时，我和弗拉德在共识激励理论上提出了各自的观点。

38、在这里，一个非常重要的区别是*独特的可归因错误*和*非独特的可归因错误*之间的区别，前者可以告诉你谁应该为此负责，因此可以对他们进行惩罚。

39、典型案例是一个非单一原因导致的错误：离线与审查制度，也被称为“说-听错误等效”。

40、处罚唯一可归因于的错误(如。卡斯帕FFG的苛刻条件)是容易的。对不可归责的错误进行处罚是很困难的。

41、如果你无法判断block停止，是因为少数人下线还是大多数人在删除少数人怎么办?

42、在这个问题上，基本上有三种观点:(1)惩罚双方一点、(2)惩罚双方都很严厉(Vlad的偏好)、(3)把链条分成两部分，每条链条上惩罚一方，让市场决定哪条链条更有价值(我的偏好)。

43、或者,我的认为是：(查看详情)

44、在2017年11月，Casper FFG的大幅削减条件，加上我通过“二次泄漏”机制解决“1/3下线”问题的想法，这里有一篇论文详细解释了:(查看详情)

45、当然,我非常明白吸引社会层解决51%的攻击并不是一个很好的事情,所以我开始寻找方法至少允许在线客户自动检测哪条链是“合法的”，哪条链是“攻击”。

46、这是我早期的想法之一:(查看详情)它是某种东西，但仍然不是最理想的;除非网络延迟完全为零，否则只能保证客户的怀疑分数相差最大，而不是客户完全同意。

47、与此同时，我对Vlad模式的主要批评与“令人沮丧的攻击”有关，攻击者可以可信地威胁要进行51%的攻击，导致每个人都赔钱，从而迫使其他人退出，从而以接近于零的成本控制了整个链条。

48、Vlad(和Georgios Piliouras)开始进行经济建模，以估计在他的模型下，此类攻击的实际成本。

49、值得注意的是，所有这些问题并不是利害关系证明的唯一问题。事实上，在工作证明中，人们倾向于简单地放弃，并认为阻止51%的攻击是完全不可能的，而51%的攻击是必须不惜一切代价阻止的世界末日。

50、但是，和以太坊的惯例一样，Vlad和我都没有意识到“雄心壮志”这个词可能只是一种赞美，我们一直在努力用各自不同的方法来抑制、缓解和恢复51%的攻击。

51、2018年初，Vlad在CBC的工作开始快速推进，在安全证明方面取得了很大进展。关于2018年3月的进展情况，请参见这篇长达两小时的史诗演讲:(查看详情)

52、与此同时，Casper FFG正在取得巨大的进展，我们决定跟其合作并发布到以太坊区块链平台，这使得开发变得容易。2017年12月31日23:40，我们发布了用python编写的testnet:(查看详情)

53、不幸的是，FFG的开发速度慢了下来。将FFG作为一个契约来实现的决定使一些事情变得更容易，但也使其他事情变得更困难，这也意味着最终从EVM到EWASM，从单链Casper到sharded Casper的转换将更加困难。

54、此外，团队的工作被分为“主链Casper”和“分片Casper”，很明显，Casper和分片团队之间存在大量不必要的重复工作。

55、2018年6月，我们做出了一个重大决定，放弃了“混合Casper FFG”，转而追求完全Casper作为一个独立的链，设计的方式是集成分片，因为这会更容易些。

56、转换到股份证明关系，让我开始更加认真地思考“股份证明关系”的利害。

57、Casper FFG(和CBC)都需要在每个“epoch”中都进行投票来确定块，这意味着每秒会有数十到数百个签名。BLS签名聚合使这在计算开销方面变得实用…

58、. .但我想利用所有这些额外的签名，使链更“稳定”，在几秒钟内获得“100个确认”的安全性。

59、以下是我最初的尝试:(查看详情)

60、然而，对于fork选择规则的所有这些方法都有一个缺点:它们将验证者“发起人”和“提出者”，提出者作为批量生产的关键驱动因素，具有巨大的力量。

61、这是不可取的，主要是因为它要求我们有一个强大的链上随机数生成源来公平地选择提出者。链上随机性是非常困难的，像RANDAO这样的简单方法看起来越来越成问题。

62、我和Justin Drake用两种方式解决了这个问题，Justin使用了可验证的延迟函数，它具有确定性和可验证的输出，但是需要大量不可并行的顺序时间来计算，使得提前操作变得不可能……

63、…和自己做出重大让步的崇拜弗拉德™,使用GHOST-based叉选择规则大大减少依赖提议,允许链增长不间断即使> 90%的提议是恶意,只要> 50%的证明者是友好的。

64、弗拉德很高兴，但并不完全满意:他更喜欢基于验证者最新消息的GHOST版本，而我更喜欢基于即时消息的版本:(查看详情)

65、大约在这段时间里，我还想出了一种“流水线”Casper FFG的方法，将时间从2.5个周期缩短到理论上最优的2个周期(查看详情)

66、我很高兴RPJ fork选择规则(我已经将其重新命名为“即时消息驱动的GHOST”)与Casper FFG很好地兼容，而大多数其他人都不是……

67、…而且它有一个非常重要的“稳定性”特性:选择叉是对未来叉选择的一个很好的预测。这看起来很明显，但是很容易意外地使叉选择规则不具有此属性。

68、最新的开发结果是：由于技术上的原因，最新消息驱动的GHOST可能在两轮内只提供25%的容错性，但是即时驱动的message GHOST(使用FFG或CBC)仍然提供了整整33%的容错性(目前还没有写入)

69、FFG和CBC之间的主要权衡是：CBC似乎有更好的理论属性，但FFG似乎更容易实现。

70、与此同时，在可验证的延迟函数方面取得了大量进展:(查看详情)

71、另外，我最近决定研究Leslie Lamport在1982年发表的一篇旧论文，在那篇论文中，如果假设所有节点(包括观察者)都在线且网络延迟较低，那么他的共识算法具有99%的容错能力（查看详情）

72、网络延迟假设可能使这种算法不适合作为主要的共识算法。然而，有一个用例它的工作非常好:用51%的审查检测来代替怀疑分数。

73、基本上，如果51%的联盟开始审查代码块，其他验证器和客户端就会发现正在发生这种情况，并使用99%的容错共识来同意这种情况正在发生，并协调一个少数分支。

74、本研究的长期目标是尽可能地减少对社会阶层的依赖，并尽可能地使链的不稳定成本最大化，以使回归社会阶层成为必要。

75、现在还剩下些什么?在FFG方面，考虑到安全而快速的部署，正式的证明、对规范的改进和实现的持续进展(已经由>=3个团队开始了!)在CBC方面，大部分是一样的。向前,向上!

 

以下为以太坊创始人Vitalik Buterin推特原文，由链得得App编辑整理：

1. Today I am going to make a tweet storm explaining the history and state of Ethereum's Casper research, including the FFG vs CBC wars, the hybrid => full switch, the role of randomness, mechanism design issues, and more.

2. Ethereum proof of stake research began in Jan 2014 with Slasher (The article). Though the algorithm is highly suboptimal, it introduced some important ideas, most particularly the use of penalties to solve the nothing at stake problem (The article).

3. That said, the penalties that I used were very small, only canceling out signing rewards. Vlad Zamfir joined in mid-2014, and he quickly moved toward requiring validators to put down *deposits*, much larger in size than rewards, that could be taken away for misbehavior.

4. Here's Vlad's retelling:(The article).

5. We spent much of late 2014 trying to deal with "long range attacks", where attackers withdraw their stake from deposits on the main chain, and use it to create an alternate "attack chain" with more signatures than the main chain, that they could fool clients into switching to.

6. If the attack chain diverges from the main chain at a fairly recent point in time, this is not a problem, because if validators sign two conflicting messages for the two conflicting chains this can be used as evidence to penalize them and take away their deposits.

7. But if the divergence happened long ago (hence, long range attack), attackers could withdraw their deposits, preventing penalties on either chain.

8. We eventually decided that long range attacks are unavoidable for pretty much the reasons PoW proponents say (The article).. However, we did not accept their conclusions.

9. We realized that we could deal with long range attacks by introducing an additional security assumption: that clients log on at least once every four months (and deposits take four months to withdraw), and clients simply refuse to revert further than that.

10. This was anathema to PoW proponents because it feels like a trust assumption: you need to get the blockchain from some trusted source when you sync for the first time.

11. But to us dirty subjectivists, it did not seem like a big deal; you need some trusted source to tell you what the consensus rules of the blockchain are in any case (and don't forget software updates), so the additional trust required by this PoS assumption is not large.

12. Here's Vlad's retelling:详情请看

13. Now that we settled on deposits and penalties, we had to decide what those deposits and penalties _are_. We knew that we wanted an "economic finality" property, where validators would sign on blocks in such a way that ...

14 ...once a block was "finalized", no _conflicting_ block could be finalized without a large portion of validators having to sign messages that conflict with their earlier messages in a way that the blockchain could detect, and hence penalize.

15. I went on a big long, and ultimately unproductive, tangent on a direction I called "consensus by bet":详情请看

16. Consensus by bet was an interesting construction where validators would make bets on which block would be finalized, and the bets themselves determined which chain the consensus would favor.

17. The theory was that PoW also has this property, as mining is a bet where if you bet on the right chain, you gain (reward - mining cost), and if you bet on the wrong chain, you lose the mining cost, except with PoS we could push the odds on the bets much higher.

18. The odds on validators' bets would start off low, but as validators saw each other getting more and more confident about a block, everyone's odds would rise exponentially, in parallel, until eventually they would bet their entire deposits on a block. This would be "finality".

19. In the meantime, Vlad started heavily researching mechanism design, particularly with an eye to making Casper more robust against oligopolies, and we also started looking at consensus algorithms inspired by traditional byzantine fault tolerance theory, such as Tendermint.

20. Vlad decided that traditional BFT was lame (he particularly disliked hard thresholds, like the 2/3 in PBFT and Tendermint), and he would try to effectively reinvent BFT theory from scratch, using an approach that he called "Correct by Construction" (CBC)

21. In Vlad's own words:more

22. The correct-by-construction philosophy is very different from traditional BFT, in that "finality" is entirely subjective. In CBC philosophy, validators sign messages, and if they sign a message that conflicts with their earlier message...

23 ... they have to submit a "justification" proving that, in the relevant sense, the new thing they are voting for "has more support" than the old thing they were voting for, and so they have a right to switch to it.

24. To detect finality, clients look for patterns of messages that prove that the majority of validators is reliably voting for some block B in such a way that there is no way they can switch away from B without a large fraction of validators "illegally" switching their votes.

25. For example, if everyone votes for B, then everyone votes on a block that contains everyone's votes for B, that proves that they support B and are aware that everyone else supports B, and so they would have no legitimate cause for switching to something other than B.

26. I eventually gave up on consensus-by-bet because the approach seemed too fundamentally risky, and so I switched back to trying to understand how algorithms like PBFT work. It took a while, but after a few months I figured it out.

27. I managed to simplify PBFT (The article) and translate it into the blockchain context, describing it as four "slashing conditions", rules that state what combinations of messages are self-contradictory and therefore illegal:more

28. I defined a rule for determining when a block is finalized, and proved the key "safety" and "plausible liveness" properties: (i) if a block is finalized, then there is no way for a conflicting block to get finalized without >= 1/3 violating a slashing condition ...

29. ... (ii) if a block is finalized, 2/3 honest validators can always cooperate to finalize a new block. So the algorithm can neither "go back on its word" nor "get stuck" as long as > 2/3 are honest.

30. I eventually simplified the minimal slashing conditions down from four to two, and from there came Casper the Friendly Finality Gadget (FFG), which is designed to be usable as an overlay on top of any PoW or PoS or other blockchain to add finality guarantees.

31. Finality is a very significant advancement: once a block is finalized, it is secure regardless of network latency (unlike confirmations in PoW), and reverting the block requires >= 1/3 of validators to cheat in a way that's detectable and can be used to destroy their deposits

32. Hence, the cost of reverting finality can run into the billions of dollars. The Casper CBC and Casper FFG approaches both achieve this, though in technically different ways.

33. Note that Casper CBC and Casper FFG are *both* "overlays" that need to be applied on top of some existing fork choice rule, though the abstractions work in different ways.

34. In simplest terms, in Casper CBC the finality overlay adapts to the fork choice rule, whereas in Casper FFG the fork choice rule adapts to the finality overlay.

35. Vlad's initial preference for the fork choice rule was "latest message-driven GHOST", an adaptation of GHOST (The article) to proof of stake, and my initial preference was to start off with hybrid PoS, using proof of work as the base fork choice rule.

36. In the initial version of Casper FFG, proof of work would "run" the chain block-by-block, and the proof of stake would follow close behind to finalize blocks. Casper CBC was full proof of stake from the start.

37. At the same time, Vlad and I were both coming up with our own respective schools of thought on the theory of consensus *incentivization*.

38. Here, a very important distinction is between *uniquely attributable faults*, where you can tell who was responsible and so can penalize them, and *non-uniquely attributable faults*, where one of multiple parties could have caused the fault.

39. The classic case of a non-uniquely-attributable fault is going offline vs censorship, also called "speaker-listener fault equivalence".

40. Penalizing uniquely attributable faults (eg. Casper FFG slashing conditions) is easy. Penalizing non-unquely-attributable faults is hard.

41. What if you can't tell if blocks stopped finalizing because a minority went offline or because a majority is censoring the minority?

42. There are basically 3 schools of thought on this issue: (i) Penalize both sides a little (ii) Penalize both sides hard (Vlad's preference) (iii) Split the chain into two, penalize one side on each chain, and let the market decide which chain is more valuable (my preference).

43. Or, in my words:more

44. In November 2017, the Casper FFG slashing conditions, plus my ideas for solving "the 1/3 go offline" problem through a "quadratic leak" mechanism, became a paper:more

45. Of course, I was well aware that appealing to the social layer to solve 51% attacks was not a very nice thing to do, so I started looking for ways to at least allow online clients to *automatically* detect which chain is "legitimate" and which is the "attack" in real time.

46. Here is one of my earlier ideas: The article It was something, but still suboptimal; unless network latency was exactly zero, there was only a guarantee that clients' suspicion scores would differ by at most delta, not that clients would fully agree.

47. In the meantime, my main criticism of Vlad's model had to do with "discouragement attacks", where attackers could credibly threaten to make a 51% attack that causes everyone to lose money, thereby driving everyone else to drop out, thus dominating the chain at near-zero cost

48. Vlad (along with Georgios Piliouras) started doing economic modeling to estimate the actual cost of such an attack under his model.

49. It's worth noting here that all of these issues are not unique to proof of stake. In fact, in proof of work, people tend to simply give up and assume preventing 51% attacks is outright impossible, and a 51% attack is a doomsday that must be prevented at all costs.

50. But, as is the Ethereum tradition, Vlad and I were both unaware that the word "ambitious" can be anything but a compliment, and kept on working on our separate approaches to disincentivizing, mitigating and recovering from 51% attacks.

51. In early 2018, Vlad's work on CBC started to move forward quickly, with great progess on safety proofs. For the state of progress in March 2018, see this epic two-hour presentation:more

52. In the meantime, Casper FFG was making huge progress. A decision to implement it as a contract that would be published to the Ethereum blockchain made development easy. On Dec 31, 2017 at 23:40, we released a testnet written in python:more

53. Unfortunately, development of FFG then slowed down. The decision to implement FFG as a contract made some things easier, but it made other things harder, and it also meant that the eventual switch from EVM to EWASM, and single-chain Casper to sharded Casper, would be harder.

54. In addition, the team's work was being split between "main chain Casper" and "shard chain Casper" and it was clear there was enormous unneeded duplication of effort going on between the Casper and sharding teams.

55. In June 2018, we made the fateful decision to scrap "hybrid Casper FFG as a contract", and instead pursue full Casper as an independent chain, designed in such a way that integrating sharding would be much easier.

56. The switch to full proof of stake led me to start thinking much harder about proof of stake fork choice rules.

57. Casper FFG (and CBC) both require the *entire* validator set to vote in every "epoch" to finalize blocks, meaning there would be tens to hundreds of signatures coming in every second. BLS signature aggregation makes this practical in terms of computational overhead...

58. ...but I wanted to try to take advantage of all of these extra signatures to make the chain much more "stable", getting "100 confirmations" worth of security within a few seconds.

59. Here were my initial attempts:more

60. However, all of these approaches to the fork choice rule had a weakness: they split up validators into "attesters" and "proposers", and the proposers, being the key drivers of block production, had outsized power.

61. This was undesirable, primarily because it required us to have a strong source of on-chain random number generation to fairly pick the proposers. And on-chain randomness is *hard*, with simple approaches like RANDAO looking more and more problematic(The article).

62. Justin Drake and I went off to solve this problem in two ways, Justin by using verifiable delay functions which have a deterministic and verifiable output, but take a large amount of unparallelizable sequential time to compute, making manipulation ahead of time impossible...

63. ... and myself by making a major concession to the Cult of Vlad™, using GHOST-based fork choice rules to greatly reduce the dependence on proposers, allowing the chain to grow uninterrupted even if >90% of proposers are malicious, as long as >50% of attesters are friendly.

64. Vlad was very happy, though not fully: he preferred a version of GHOST based on validators' *latest messages*, whereas I preferred a version based on *immediate* messages:(The article).

65. Around this time I also managed to come up with a way to "pipeline" Casper FFG, reducing time-to-finality from 2.5 epochs to the theoretically optimal 2 epochs:(The article).

66. I was very happy that the RPJ fork choice rule (which I have since renamed "immediate message-driven GHOST") is nicely compatible with Casper FFG in a way that most others are not...

67. ...and that it has a very important "stability" property: that the fork choice is a good prediction of the future fork choice. This seems obvious, but is very easy to accidentally make fork choice rules that do *not* have this property.

68. The most recent development of all is a result that latest message driven GHOST may, due to a technicality, only give 25% fault tolerance within two rounds, but immediate driven message GHOST (with FFG or CBC) still gives the full 33% (no writeup yet)

69. The main tradeoff between FFG and CBC is that CBC seems to have nicer theoretical properties, but FFG seems to be easier to implement.

70. In the meantime, a *lot* of progress on verifiable delay functions has been made:(The article)

71. Also, I recently decided to look into Leslie Lamport's old 1982 paper, where he had a consensus algorithm that has 99% fault tolerance if you add the assumption that all nodes, including observers, are online with low network latency:(The article)

72. The network latency assumptions arguably make this unsuitable as a primary consensus algorithm. However, there is one use case where it works *really* well: as a substitute for suspicion scores for 51% censorship detection.

73. Basically, if a 51% coalition starts censoring blocks, other validators and clients can detect that this is happening, and use the 99% fault tolerant consensus to agree that this is happening, and coordinate a minority fork.

74. The long-run goal of this research is to reduce reliance on the social layer as much as possible, and maximizing the cost of destabilizing the chain enough so that reverting to the social layer is necessary.

75. What's left now? On the FFG side, formal proofs, refinements to the specification, and ongoing progress on implementation (already started by >=3 teams!), with an eye to safe and speedy deployment. On the CBC side, much of the same. Onward and upward!