1:我是谁？Alpha个人简历上有的。

2:技术开发者要做“天网”的创造者，用代码来铭刻信仰，用数学结构来实现管理。程序员要学会做：世界主流协议建立者，新世界协议的创造者。通过代码可以铭刻：内心深处真正的信仰。 在汹涌而来的大浪潮面前，用代码来证明自己所相信的哲学观念。

3:“Eth发行数量”与“Eth现金流资产”，多创造Eth现金流资产而不是创造COIN的发行数量。

4:多创造“Eth系列的Dapp”开发协议，让全世界的开发者通过程序的开发赚取到属于自己的Eth自然现金流。

5:底层布局将Eth作为：“所有Dapp应用”的基础支付方式。

6:EOS中心化骗局与“小网络区块链”摆脱时间戳服务器依赖，集中在某个时间戳节点上，记录区块链总账（应对超大规模应用开发场景，保持去中心化结构）

7:“没有价值的Eth”和“有价值的Eth—Dapp网络”，人群有使用Dapp的需求以此来激发起人们使用Eth的需求。（就像人们有在Eth上发行ERC20的需求一样，因为对某一互联网应用的需求，以激发起人们对于Eth的市场需求）

8:🇨🇳中国有很多人用ETH发行ERC20协议的COIN，短期内可以创造Eth的价格上涨。随着时间的推移：越来越多人掌握了发行“公链”的方式，基于模仿Eth的源代码，越来越多的“迅雷链”“华为链”“百度链”的出现，发行COIN将会成为过去式。另外一个角度来看，很多不负责任的COIN发行圈走了老百姓手中的存款，世界进入了一种大量完全没有资产对应的赌博一种COIN的概念是否未来上涨的传销游戏当中，这对于ETH最终上有害的。

9:物理世界的产品，物理世界的服务和Token合约之间的脱钩关系。通过Dapp应用建立和物理世界的产品与服务的关系，再用Token合约建立和Dapp的关系，以此完成COIN对世界的统治系统。

9:共同创建“去中心化自治组织”——加拿大🇨🇦区块链降低准入门槛公益技术基金会投资：10万Eth，然后我们投资50万——90万枚Eth（共同建立技术开发平台）

10:建立中国区的30人—100人【Dapp降低准入门槛开源应用】极客开发者小组

a：小组成员必须全职工作。

b：Github上建立最好的，最快速，最完整的开源服务方式（针对于中国区开发者）

c：打造“小网络区块链”和Eth的大网络形成共享系统。

d：Eth开源技术的中国化，以前在1年到2年才能完成普及，而未来1小时内就可以完成普及。

11：“区块链现金流游戏”，挖矿，搬砖套利，Dapp应用，收款方式，支付方式。

12：研发基于“二维码入口”的综合性区块链应用。所有的区块链应用程序都以二维码来作为主要的链接方式，而不是复制粘贴（ADDRESS）用“扫码二维码”的动作取代“复制粘贴”的动作。

13:“区块链TOKEN合约免疫共识机制”，地球上所有植物和动物都有“免疫系统”，我们生活在充满“微生物”的世界，一种COIN除了“拜占庭容错”和“君士坦丁堡”系统之外，还需要有一种在受到进攻后主动“发起反击”的机制，就像人的身体入侵了不属于自己的微生物之后，立即通过“白细胞”进行反击的机制一样，当检测到某一些特征同时为“真”就应该通过一种共识进行主动反击。比如：若检测到某一“钱包地址存在异常行为时”，就依据于该“钱包地址”生成一个新的“黑名单区块链”凡是在内的交易皆扣除10倍的交易费用（以此作为进攻该系统的处罚）

14:如何让Eth再次伟大？让Ethereum回到1000美元，冲破10000美元成为人类历史上市值最高的COIN？

15:打造分布式DAPP网络系统，让中心化的互联网公司失去统治世界的机会，减少相关部门的行政干涉，让人们在更加自由稳定的网络中畅游。减少节点故障带来的风险，帮助100万家企业开发DAPP。

15:

16:

17：

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 (blog.ethereum.org/2014/01/15/sla…). Though the algorithm is highly suboptimal, it introduced some important ideas, most particularly the use of penalties to solve the nothing at stake problem

(ethereum.stackexchange.com/questions/2402…).

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:

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 (eg. download.wpsoftware.net/bitcoin/pos.pdf). 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: medium.com/@Vlad_Zamfir/t… medium.com/@Vlad_Zamfir/t…

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 (pmg.csail.mit.edu/papers/osdi99.…) 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:

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 (eprint.iacr.org/2013/881.pdf) 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?