译者序：Eth 2.0信标链的共识协议将逐渐从PoW向PoS过渡，在这条全新的链上，如何保障其安全性和活性呢？Casper FFG 作为区块最终确定工具，为eth2带来了福音。通过这篇文章，我们可以对Casper FFG的运行规则、安全性证明和活性证明有一个初步的了解。

为了对用户负责，任何区块链都必须保证链上区块的最终确定性和链的活性，而区块链共识机制的根本就是提供这些保障。在Eth2.0中，共识过程只在信标链中进行，而Casper FFG机制则保证其运行。本文主要描述了Casper FFG机制的基本概念，举例阐释其在信标链上的作用。

Casper FFG作为一项“最终确定性工具”(finality gadget)，为区块的最终确定制定了规则，并对已被确定的区块进行检测。FFG独立于区块链本身的增长过程，可以作为一个叠加层为任何有效的区块链协议提供区块最终确定性。

就这方面而言，Casper FFG并非一项成熟的共识协议，因其本身并没有相关设置，以保证链的活性。(或许我会择时再写一篇文章阐释影响Eth2.0信标链活性的相关因素)

让我们先来看看Casper FFG机制的结构，然后深入了解其规则，从而理解FFG如何保证信标链的安全性和活性！

投票

验证者通过验证区块间的交易是否有效，给链上的区块进行投票。每记投票的格式为(S, T)，包含以下信息：

• 来源区块 (S)
• 目标区块 (T), 必须产生于S之后

实际操作中，一记投票需包含以下内容：验证者的数字签名以及相应区块信息（包括区块哈希和区块高度）。

证明&最终确定

“证明”(Justification) 和“最终确定”(finalization) 是Casper FFG机制下的两个共识执行阶段，可以类比于更为传统的拜占庭容错共识协议 (BFT) 的“准备”和“执行”阶段

2/3验证者投票证明了区块A和区块B

证明

区块B如果满足以下条件，则已被证明：

• 是创世区块，或者
• 超过2/3的验证者投出了(A，B)票，A是在B之前产生的区块，且已被证明。
  

最终确定

区块B如果满足以下条件，则已被最终确定：

• 是创世区块，或者
• B已被证明，且超过2/3的验证者投了 (B,C) 票，以及C是B的直接子区块（即C区块高度=B区块高度+1）

注意：关于Eth2.0 Casper FFG机制的最终确定规则，还有更加全面的阐释，详情请参阅此论文。上文所给的具体阐释，只是为了让本文更加通俗易懂。

Casper FFG的规则

Casper FFG机制有两条简单的规则：

验证者不可以进行以下任何一种情况中的 (S1, T1) 和 (S2, T2) 投票 1.区块高度(T1) = 区块高度(T2),或者 2.区块高度(S1) < 区块高度(S2) <区块高度(T2) < 区块高度(T1)

（译者注：这两种情况在Eth2中被描述为“双重投票”和“环绕投票”，恶意验证者会因此受到罚没。）

Violation of Casper FFG Rule 1: height(T1) = height(T2)

Violation of Casper FFG Rule 2: height(S1) < height(S2) < height(T2) < height(T1)

安全性&活性

Casper FFG的目的是保障区块最终确定这一共识执行过程的安全性和活性，下面两点具体阐述了其安全性和活性：

• 可追责安全性 (Accountable Safety) : 如果两个互相冲突的区块被最终确定，那么至少有1/3的验证者违反了Casper FFG规则，他们则会被标记下来。
• 合理的活性 (Plausible Liveness) : 不管协议处于哪一阶段，验证者都可以在不违反Casper FFG规则的前提下发起投票，对新区块进行最终确定。

尽管和传统的拜占庭容错共识机制 (BFT)文献相比，本文对FFG安全性和活性的阐释显得有些业余，但是对于大家理解区块链的最终确定机制，却刚好合适。

事实上，如果读者对BFT相关文献非常熟悉，会认为对于“plausible liveness”的解释十分荒谬。然而，由于Casper FFG只是最终确定性机制，因而说到保证系统的活性，其只需要避免以下情况的出现：诚实验证者为了继续提议或证明区块，不得不违反FFG规则。

至于安全性，可靠的安全性尤为重要，如违反规则的验证者会被标记下来，并将标记信息发送到PoS的机制上，从而对恶意验证者进行惩罚。这样做有助于协议的实现，以达到系统的平衡。

安全证明

使得两个相斥的区块A和B最终确定（且互不为对方的子区块），有两种情况：

• A区块高度=B区块高度
  • 由于A和B在被最终确定之前都需要被证明，至少2/3的验证者需要分别为目标点A和B投票。这就意味着至少有1/3的验证者违背了第一条Casper FFG的规则。
• A区块高度<B区块高度
  • 区块A要被最终确定，那么至少2/3的验证者都要对区块(A,C)投票，而区块C是A的子区块。
  • B区块要被证明，那么随着区块高度增加，区块应该按[genesis, B_0, B_1, … , B_n, B]排列，其中每个区块都能按顺序证明下一个区块，即至少2/3的验证者要做出类似(G, B_0), (B_0, B_1)的投票。假设B_m是该序列中的首个区块，且A区块高度 < B_m区块高度。
  • 需要注意的是，如果该序列中的任何区块和区块A或C的高度相同，那么形同以上第一种情况，我们已经得到了证明。
  • 在(B_n, B_m)投票中 (n = m-1)，B_m能够被证明。但由于B_n或B_m和区块A或C不在同一个区块高度，那我们就能得到区块高度的排列：B_n< A < C < B_m。
  • 因此，有2/3的验证者都违反了Casper FFG的第二条规则。

安全性证明，区块高度A<B
还要注意的是，仅通过检查所有投票集合，找到有冲突的投票并检查相应的验证者签名，我们很容易确定违反Casper FFG规则的验证者。

活性证明

• 假设P_0是经证明后的最高区块，而Q是某些验证者所认为并且投票的最高区块。
• 区块P_1作为P_0的子区块且区块高度Q< P_1。此时如果有2/3的验证者对(P_0, P_1)投票使其被证明，并没有违反Casper FFG规则。
• P_2是P_1的子区块，如果有2/3的验证者对(P_1, P_2)进行投票，并使得P_1被最终确定。这也并没有违反Casper FFG规则。

因此，至少2/3的诚实验证者总是能够对一个新区块进行最终确定，这就保证了共识机制的活性。

转载自：https://www.ethereum.cn/casper-ffg-explainer

查看geth命令行参数geth --help

--syncmode value                    Blockchain sync mode ("snap", "full" or "light") (default: snap)

参数支持"full", "snap", "light" 三种模式「原先的"fast"已被 "snap"替代」

查看官方文档，

同步模式
--syncmode <mode> 您可以使用确定网络中节点类型的参数以三种不同同步模式之一启动 Geth 。

这些是：

• Full : 下载所有区块（包括标题、交易和收据）并通过执行每个区块增量生成区块链的状态。
• Snap（默认）：与快速相同的功能，但具有更快的算法。
• Light：下载所有区块头、区块数据，并随机验证一些。

官方推荐使用快照同步，简单说就是新的算法替代原先的fast模式，

请注意，快照同步已在 Geth v1.10.0 中提供，但尚未启用。
原因是提供快照同步需要节点已经生成快照加速结构，目前还没有，因为它也在 v1.10.0 中提供。
您可以通过 手动启用快照同步--syncmode snap，
但请注意，我们预计它要在柏林之后的几周内才能找到合适的对等方。
当我们觉得有足够的对等点可以依赖它时，我们将默认启用它。

此时已设置为默认模式

举个例子，如果你想知道4,000,000区块的以太坊账户余额，那么就需要运行存档节点，然后查询这个数字。这个节点依赖于一些专门的用例，但是对区块链的安全性和信任模型来说其实并没有影响。

内容引用

https://www.ccvalue.cn/article/2011.html

前言

在Go语言中，可以使用关键字defer向函数注册退出调用，即主函数退出时，defer后的函数才被调用。defer语句的作用是不管程序是否出现异常，均在函数退出时自动执行相关代码。 所以，defer后面的函数通常又叫做延迟函数

defer规则

1.延迟函数的参数在defer语句出现时就已经确定下来了

func a() {
    i := 0
    defer fmt.Println(i)
    i++
    return
}

返回结果：0
defer语句中打印的变量i在defer出现时就已经拷贝了一份过来，所以后面对变量i的值进行修改也不会影响defer语句的打印结果

注意：对于指针类型参数，规则仍然适用，只不过延迟函数的参数是一个地址值，在这种情况下，defer后面的语句对变量的修改可能会影响延迟函数

2.defer的执行顺序与声明顺序相反

简单理解就是：定义defer类似于入栈操作，执行defer类似于出栈操作，先进后出

3.defer可操作主函数返回值

defer语句中的函数会在return语句更新返回值后在执行。因为在函数中定义的匿名函数可以访问该函数包括返回值在内的所有变量。

func deferFuncReturn() (result int) {
    i := 1
    defer func() {
       result++
    }()
    return i
}

返回结果：2
所以上面函数实际返回i++值。

defer实现原理

注意：我会把源码中每个方法的作用都注释出来，可以参考注释进行理解。

数据结构

我们先来看下defer结构体src/src/runtime/runtime2.go:_defer

type _defer struct {
    siz     int32 //defer函数的参数大小
    started bool
    sp      uintptr // sp at time of defer
    pc      uintptr //defer语句下一条语句的地址
    fn      *funcval //需要被延迟执行的函数
    _panic  *_panic //在执行 defer 的 panic 结构体
    link    *_defer //同一个goroutine所有被延迟执行的函数通过该成员链在一起形成一个链表
}

我们知道，在每一个goroutine结构体中都有一个_defer 指针变量用来存放defer单链表。
如下图所示：

defer的创建与执行

我们先来看一下汇编是如何翻译defer关键字的

    0x0082 00130 (test.go:16)   CALL    runtime.deferproc(SB)
    0x0087 00135 (test.go:16)   TESTL   AX, AX
    0x0089 00137 (test.go:16)   JNE 155
    0x008b 00139 (test.go:19)   XCHGL   AX, AX
    0x008c 00140 (test.go:19)   CALL    runtime.deferreturn(SB)

defer 被翻译两个过程，先执行 runtime.deferproc 生成 println 函数及其相关参数的描述结构体，然后将其挂载到当前 g 的 _defer 指针上。
我们先来看 deferproc 函数的实现

deferproc

// Create a new deferred function fn with siz bytes of arguments.
// The compiler turns a defer statement into a call to this.
//go:nosplit
func deferproc(siz int32, fn *funcval) { // arguments of fn follow fn
    //用户goroutine才能使用defer
    if getg().m.curg != getg() {
        // go code on the system stack can't defer
        throw("defer on system stack")
    }
    //也就是调用deferproc之前的rsp寄存器的值
    sp := getcallersp()
    // argp指向defer函数的第一个参数
    argp := uintptr(unsafe.Pointer(&fn)) + unsafe.Sizeof(fn)
    // 存储的是 caller 中，call deferproc 的下一条指令的地址
    // deferproc函数的返回地址
    callerpc := getcallerpc()

    //创建defer
    d := newdefer(siz)
    if d._panic != nil {
        throw("deferproc: d.panic != nil after newdefer")
    }
    //需要延迟执行的函数
    d.fn = fn
    //记录deferproc函数的返回地址
    d.pc = callerpc
    //调用deferproc之前rsp寄存器的值
    d.sp = sp
    switch siz {
    case 0:
        // Do nothing.
    case sys.PtrSize:
        *(*uintptr)(deferArgs(d)) = *(*uintptr)(unsafe.Pointer(argp))
    default:
        //通过memmove拷贝defered函数的参数
        memmove(deferArgs(d), unsafe.Pointer(argp), uintptr(siz))
    }

    // deferproc通常都会返回0
    return0()
}

比较关键的就是 newdefer

func newdefer(siz int32) *_defer {
    var d *_defer
    sc := deferclass(uintptr(siz))
    //获取当前goroutine的g结构体对象
    gp := getg()
    if sc < uintptr(len(p{}.deferpool)) {
        pp := gp.m.p.ptr()//与当前工作线程绑定的p
        if len(pp.deferpool[sc]) == 0 && sched.deferpool[sc] != nil {
            // Take the slow path on the system stack so
            // we don't grow newdefer's stack.
            systemstack(func() {//切换到系统栈
                lock(&sched.deferlock)
                //从全局_defer对象池拿一些到p的本地_defer对象池
                for len(pp.deferpool[sc]) < cap(pp.deferpool[sc])/2 && sched.deferpool[sc] != nil {
                    d := sched.deferpool[sc]
                    sched.deferpool[sc] = d.link
                    d.link = nil
                    pp.deferpool[sc] = append(pp.deferpool[sc], d)
                }
                unlock(&sched.deferlock)
            })
        }
        if n := len(pp.deferpool[sc]); n > 0 {
            d = pp.deferpool[sc][n-1]
            pp.deferpool[sc][n-1] = nil
            pp.deferpool[sc] = pp.deferpool[sc][:n-1]
        }
    }
    //如果p的缓存中没有可用的_defer结构体对象则从堆上分配
    if d == nil {
        // Allocate new defer+args.
        //因为roundupsize以及mallocgc函数都不会处理扩栈，所以需要切换到系统栈执行
        systemstack(func() {
            total := roundupsize(totaldefersize(uintptr(siz)))
            d = (*_defer)(mallocgc(total, deferType, true))
        })
        if debugCachedWork {
            // Duplicate the tail below so if there's a
            // crash in checkPut we can tell if d was just
            // allocated or came from the pool.
            d.siz = siz
            //把新分配出来的d放入当前goroutine的_defer链表头
            d.link = gp._defer
            gp._defer = d
            return d
        }
    }
    d.siz = siz
    d.link = gp._defer
    //把新分配出来的d放入当前goroutine的_defer链表头
    gp._defer = d
    return d
}

在函数deferproc中，

• 先获得调用deferproc之前的rsp寄存器的值，后面进行deferreturn时会通过这个值去进行判断要执行的defer是否属于当前调用者
• 通过newdefer 函数分配一个 _defer 结构体对象并放入当前 goroutine 的 _defer 链表的表头
• 然后会将参数部分拷贝到紧挨着defer对象后面的地址：deferArgs(d)=unsafe.Pointer(d)+unsafe.Sizeof(*d)
• 执行return0函数，正常情况下返回0，经过test %eax,%eax检测后继续执行业务逻辑。异常情况下会返回1，并且直接跳转到deferreturn

deferreturn

// 编译器会在调用过 defer 的函数的末尾插入对 deferreturn 的调用
// 如果有被 defer 的函数的话，这里会调用 runtime·jmpdefer 跳到对应的位置
// 实际效果是会一遍遍地调用 deferreturn 直到 _defer 链表被清空
// 这里不能进行栈分裂，因为我们要该函数的栈来调用 defer 函数
func deferreturn(arg0 uintptr) {
    gp := getg()
    // defer函数链表
    // 也是第一个defer
    d := gp._defer
    if d == nil {
        //由于是递归调用，
        //递归终止
        return
    }
    //获取调用deferreturn时的栈顶位置
    sp := getcallersp()
    // 判断当前栈顶位置是否和defer中保存的一致
    if d.sp != sp {
        //如果保存在_defer对象中的sp值与调用deferretuen时的栈顶位置不一样，直接返回
        //因为sp不一样表示d代表的是在其他函数中通过defer注册的延迟调用函数，比如:
        //a()->b()->c()它们都通过defer注册了延迟函数，那么当c()执行完时只能执行在c中注册的函数
        return
    }

    //把保存在_defer对象中的fn函数需要用到的参数拷贝到栈上，准备调用fn
    //注意fn的参数放在了调用调用者的栈帧中，而不是此函数的栈帧中
    switch d.siz {
    case 0:
        // Do nothing.
    case sys.PtrSize:
        *(*uintptr)(unsafe.Pointer(&arg0)) = *(*uintptr)(deferArgs(d))
    default:
        memmove(unsafe.Pointer(&arg0), deferArgs(d), uintptr(d.siz))
    }
    fn := d.fn
    d.fn = nil
    // 指向 defer 链表下一个节点
    gp._defer = d.link
     // 进行释放，归还到相应的缓冲区或者让gc回收
    freedefer(d)
    //执行defer中的func
    jmpdefer(fn, uintptr(unsafe.Pointer(&arg0)))
}

在函数deferreturn中

• 判断当前goroutine上是否还有绑定的defer，若没有，直接return。若有，则获取链表头部的defer
• 通过判断当前defer中存储的sp是否和调用者的sp一致，来证明当前defer不是在此调用函数中声明的。
• 将保存在_defer对象中的fn函数需要用到的参数拷贝到栈上，准备调用defer后的函数
• 释放defer
• 通过jmpdefer函数执行defer后的func

总结

• 在编译在阶段，声明defer处插入了函数deferproc()，在函数return前插入了函数deferreturn()
• defer定义的延迟函数参数在defer语句出时就已经确定下来了
• defer定义顺序与实际执行顺序相反
• 对匿名函数采用defer机制，可以使其观察函数的返回值

转载自：https://www.jianshu.com/p/387ad32c6441

自两年多前发布 EOSIO 2.0 以来，EOS 网络没有进行过重大升级。从那时起，block.one 产生了 EOSIO 2.1 和 EOSIO 2.2 的候选版本；然而，由于各种原因，Clarionos 团队和更广泛的 EOS 社区不希望所有代码都与最新版本捆绑在一起。

展望未来，Clarionos 团队会将 EOSIO 代码库分叉到一个新的代码库中，我们称之为 Mandel（Mandelbrot 的缩写）。在所有 EOSIO 驱动的区块链之间达成更广泛的共识之前，Mandel 名称是一个占位符。

Mandel 的第一个版本将是 3.0，并将从 EOSIO 2.0 派生，同时从 EOSIO 2.1 和 EOSIO 2.2 中挑选一些最有价值的增强功能。Mandel 3.0 还将引入两个新的硬分叉：合同支付、增强的可配置区块链参数。此外，它将从 EOSIO 2.1 中挑选可配置的 WASM 限制硬分叉。

虽然 EOS 区块生产者大部分仍使用 EOSIO 2.0，但一些 EOS 基础设施节点和其他下游软件已升级到 EOSIO 2.1。在迁移到 Mandel 3.0 之前要求这些节点“降级”到 EOSIO 2.0 可能会造成不必要的短期负担；因此，Clairionos 还将发布源自 EOSIO 2.1 的 Mandel 2.3 版本，该版本对 Mandel 3.0 启用的新硬分叉支持精选支持。EOSIO 2.1 节点应该能够无缝升级到 Mandel 2.3，同时与网络保持同步。
Clarionos 的目标是将尽可能多的 EOSIO 2.1 增强功能迁移到 Mandel 3.0，而不会延迟关键硬分叉的交付。

即将推出的硬分叉功能

1. 可配置的 WASM 限制

这种硬分叉允许区块生产者增加可以部署的智能合约的规模，这将允许部署更大、更强大的合约。出于安全目的，EOSIO 必须限制各种 wasm 参数，例如内存、函数数量等。一旦合约达到这些限制之一，开发人员就被迫将其代码划分为多个合约。早在 EOSVM 为 EOS 带来巨大的性能提升之前，就已经建立了最初的限制。我们现在认为增加这些限制是安全的。我们没有一次性增加，而是使它们可配置。这使网络有能力在未来扩展或在攻击者以某种方式利用额外容量时对其进行调整。

2. 合同支付

开发人员面临的最具挑战性的事情之一是使他们的应用程序易于使用。要求用户从网络租用 CPU、NET 和 RAM 资源以便与应用程序交互是一个主要的可用性障碍。在理想的世界中，智能合约将支付合约用户所需的所有资源。
当今存在的 EOS 要求每笔交易都必须由至少一个密钥签名，并且每个权限级别的阈值至少为 1。这限制了合约获取用户所需资源的潜力。
我们开发了一种不需要硬分叉的合同支付方法，但“黑客”涉及发布任何人都可以签名的“私人”密钥。当我们可以简单地允许相同的交易发生而没有任何密钥对其进行签名时，这会给网络带来不必要的负担。
在没有任何密钥的情况下可能发生的操作的一个示例是合约需要执行一些维护任务。合约愿意支付自己的维护费用，它不关心谁授权了交易。如果没有要执行的维护，那么合约将简单地拒绝交易并避免任何资源使用。维护任务的一个示例可能是当前由已弃用的延迟事务执行的许多任务。
通过合约支付，可以实现与比特币交易结构相同的交易。这消除了那些只想将 EOS 用作货币的人的帐户创建成本。它还将使实施 隐私令牌成为可能，而不会让您的隐私受到资源系统的损害。虽然这些事情将通过合同支付成为可能，但它们超出了当前路线图的范围。

有关合同付款的更多信息，请点击此处。

3. 增强的可配置区块链参数

这个硬分叉功能使添加/删除/配置未来的目标功能变得更加容易。不必为每个新功能或可配置参数添加新的本机内在函数，合约可以调用一个内在函数。这允许合约根据特征的存在或配置参数的值进行有条件的操作。此功能主要在 EOSIO 2.1 中实现，但经过审查，Clarionos 团队得出结论，需要进行一些小调整以确保更一致的操作。

系统合约升级

Clarionos 团队对 EOS 系统联系人有一个拉取请求，该请求将通过发布“私钥”来启用合同支付功能。这将允许应用程序在等待硬分叉生效的同时开发增强的用户体验。硬分叉后也需要利用该特性。

时间线

以下时间表是理想的，可能会随着发展的变化而变化。

• 2022 年 1 月 31 日— Mandel 3.0 的候选版本
• 2022 年 2 月— Mandel 3.0 测试网络启动和社区验证
• 2022 年 3 月 1 日— Mandel 3.0 最终版本
• 2022 年 3 月 2 日——网络部署 Contract Pays 系统合约
• 2022 年 4 月 1 日——Mandel 2.3 发布
• 2022 年 4 月 9 日——下一次伊甸园选举
• 2022 年 5 月 19 日——硬分叉激活。（2022年的黄金分割率）

这将标志着 EOS 独立于 block.one 的象征性完成，因为这将是 EOS 网络第一次运行不是由 block.one 开发或发布的软件版本。
资金
EOS 网络基金会已与 Clarionos 达成协议（待区块生产者批准），在 Mandel 3.0 候选版本交付后（2022 年 1 月 31 日）向 Clarionos 支付 200,000 EOS。然后，Clarionos 将支持社区修复在测试阶段发现的任何错误。

未来方向

该路线图是 EOS 独立的最短路径，也是振兴 EOS 多年计划的第一步。您将在下一次路线图更新中看到的一些项目包括：3 秒确定性、加速 EVM 支持的内在函数以及加速隐私应用程序的内在函数。
EOS 即将以多年未见的速度加快发展速度。

原文地址：https://medium.com/edenoneos/eos-mandel-to-takeover-eosio-in-2022-2e25bf5451f0