CKB 的出块奖励 - v0.15.0 更新中的矿工须知

中文 矿工酒馆
1

我们已经迎来了 CKB 的再一次更新（v0.15.0），这次更新会对矿工有一些影响 ~ 一句话描述影响：当矿工挖出高度为 N 的区块时，出块奖励会在 Block N+11 通过 Cellbase Tx 发放。大家出块的时候可千万别着急哦，等几分钟奖励就到手！

脑壳疼地读了 CKB 的共识机制以及目前的出块奖励的设置，下文抛砖引玉地讨论下 CKB 的出块奖励，有任何问题欢迎大家指出讨论~ 简而言之，目前 CKB 的出块奖励可以区分为 3 个部分，Base Reward、Proposal Reward 、Commit Reward，未来还会将与经济模型相关的增发奖励增加到出块奖励中。这三部分的奖励是遵循 CKB 共识机制的【两步交易确认】与【动态难度调节机制】而最终确定的。

Base Reward - 动态难度调整机制

Base Reward 的发放与动态难度调节机制密切相关。Base Reward 与比特币的 Block Reward 类似，属于最新铸币。不同于 Bitcoin 固定数量的发放数量以及固定的2016个区块难度调整。“CKB 共识协议修改了Nakamoto 共识难度调整机制，以便: (1) 自私挖矿不再有利可图; (2) 根据网络的带宽和延迟动态调整吞吐量。实现目标1, 我们的协议在计算上一个时期的调整后的哈希率估计时包含所有块而不是仅主链, ，其确定每个奖励单元的下一个时期所需的计算工作量. 实现目标2, 我们的协议计算下一个时期中具有最后一个时期的孤儿率的主链块的数量。然后通过组合这些结果来计算块奖励和目标。”（Copy 自 CKB 共识协议译稿 ）

通过上述方法(在共识白皮书有详尽的公式)可以获得下个周期的周期长度（Epoch Length）与周期总奖励（Epoch Reward）。通过这两个数据可以得到周期内每一个的出块奖励，其计算方法为：一个 epoch 的奖励是固定的 R，如果这个 Epoch 有 L 个 blocks，前 R%L 个 block 的 block reward 是 floor(R/L) + 1，后 L - (R%L) 个 block 的 block reward 是 floor(R/L)。简单来说，假设某个 Epoch Reward 为 100 shannon，Epoch Length 为11，计算 100/11 取整数为 9 ，余数为1。余数以每个区块 1 shannon 的方式从该 Epoch 的第一个区块进行分发，直到分完为止。因此，由于余数仅为1，第一个 Base Reward 为[9+1]shannon，其他区块的 Base Reward 为整数 9 shannon。若总奖励为107 shannon，则余数为8，该 Epoch 的前8个区块的矿工就能够比后面的矿工多分到 1 shannon 。

Commit Reward & Proposal Reward - 两步交易确认

两部交易确认是为了消除区块传播瓶颈，共识协议的分析如下：“当区块间隔缩短时，区块传播延迟的瓶颈就是传递新的交易，这些新交易是在生成最新块时，尚未完成广播到网络的新广播交易。没有收到这些交易的节点必须在将块转发给其他节点之前请求它们。由此产生的延迟不仅限制了区块链的性能，而且还可以在自私挖矿攻击中被利用，攻击者故意在其块中嵌入新的交易，希望较长的传播延迟使他们有机会找到下一个块来获取更多奖励。与此研究结果不同，我们的协议通过将NC的交易确认分解为两个单独的步骤来消除瓶颈：提案和提交。一笔交易如果将其截断的散列即txid发布到区块或叔块（由区块引用的孤立块）中，则打包到提案区。新提案的交易既不影响区块有效性也不影响区块的传播，因为节点可以在接收这些事务之前已经开始将区块传送到其他节点。如果交易在提案后的几个的周期中出现在提交区中，则打包该交易。这个两步确认规则既消除了块传播瓶颈，因为新块中的已提交事务已被所有节点接收并在提交时进行验证。新规则还通过限制攻击时间周期有效地减轻了自私挖矿攻击。”（Copy 自 CKB 共识协议译稿 ）

从两步交易确认的原则出来，一笔 CKB 交易的生命周期是：1）用户发送交易；2）交易进入交易池；3）交易进入区块结构的提案区（Proposal zone）；4）交易进入区块结构的提交区（Commitment zone）（既一般意义的交易打包进入区块）。针对一笔非 Cellbase 交易，最早将交易放置入提案区的矿工将获得该交易的交易费的 40%，而将交易放置入提交区的矿工将获得该交易的交易费的 60%。

在 v0.15.0 发布的版本中，Block N Proposal 的交易只能在之后的2到10个区块之间进入提交区并最终在区块链中确定。因此，Block N Proposal 的收入只有在 Block N+11 才能够真正算清：在 Block N+2 至 Block N+10 所 Commit 的交易中，找到 Block N 首次 Proposal 的交易并获得其交易费的 40%。这解释了为什么 Block N 的挖矿收入最终要在 Block N+11 发放，因为之前是无法计算出来！

Commit Reward 非常易于理解：既 Block N 所打包进入提交区（Commitment zone）的交易的交易费的60%。其他的40%用于支付之前区块 Proposal 这些交易的工作。

最终，Block N 的矿工将获得 Base Reward、Proposal Reward、Commit Reward，并通过一笔 Cellbase Tx 获得这笔收入。

5 Likes
2

有点蒙:joy:

3

其实核心信息是：当矿工挖出高度为 N 的区块时，出块奖励会在 Block N+11 通过 Cellbase Tx 发放。后面关于 reward 的信息，我想想怎么更清楚些

4

大概明白意思了:stuck_out_tongue_closed_eyes:

1 Like
5

所以一笔 tx 发送是为了防止出现大量微小的 Cell 占用存储空间，能够将之前的 Cell 用一个 Output 合起来，因此针对矿工收入，需要等 10 个区块之后才能发送，然后需要进一步等到区块确认，可能等待的时间会更长。

这里其实有点疑问，具体是如何实现的？
是区块提交区内的交易，去搜索这笔交易是之前哪一个区块提案区 propose 的，然后确定奖励对象，还是说每一笔交易都带一个标记，表示奖励对象？

6

已 Block N 为例。Blokc N 挖矿成功，在提案区已 TxID 的形式 Proposal 一个交易集合，同时 Commit 之前的 Block N-10 到 N -2 所 Proposal 的且未 Commit 的交易（由矿工根据一定的规则去筛选，譬如交易费）。Commit 交易的交易费在区块打包后即可算出来，为所有 Commit 交易的交易费的 60%。而关于 Proposal 的交易，我们在文中谈到，Block N Proposal 的交易必须在 Block N+2 到 N+10 被 Commit ；因此，在 Block N+11 的时候，我们获取 Block N+2 到 N+10 的所有交易，确定这些交易是否由 Block N 第一次 Proposal。假设为真，则获取这些交易的交易费的 40%。这两部分费用相加则为该 Block N 获得的交易费。

7

another question… Block N 的奖励在 Block N + 11 的时候发送，那 Block N 的 Cell Base 交易实际上是 Block N - 11 的 Block Reward，Block N + 11 的 Cell Base 交易实际上是 Block N 的 Block Reward 是吗？

也就是说，Cell Base Transaction 发往的地址不是这个挖到这个区块的矿工的地址？

8

是的，Block N 的矿工地址会放在 witness 里。然后 Block N+11 的时候会将 Cellbase Tx 的 Output 地址填写为 Block N 的矿工。

1 Like
9

是像下面这样理解么？

Block N+11 会将 Cellbase Tx 的 Output 地址填写为 Block N 的矿工，给到 Block N 矿工的奖励包括了：

  • Base Reward：基础出块奖励
  • Commit Reward：Block N-2 ~ Block N-10 中实现 Proposal 并最终在 Block N 中完成 Commit 的交易手续费的 60%
  • Proposal Reward：在 Block N 中实现了 Proposal，并在 Block N+2 ~ Block N+10中完成 Commit 的交易手续费的 40%

这样的设计会对区块链浏览器的设计和 Block Reward 数据分析这一块造成什么影响么？比如这一整个 Cellbase Tx 发放的奖励可以再被拆分并算出其中各个奖励来自哪里么？会不会使得对于 Block Reward 的数据分析变得非常复杂。

10

嗯嗯，浏览器已经针对此进行开发上线了，可以查看 Block 页面与 Address 页面。对于 Block Reward 的分析肯定会更加复杂。未来还要增加二级增发的。

11

目前从挖到的块看，commit reward 和 proposal reward 都是0，点解？正常吗

12

目前现状来说，很少有交易会付交易费，所以我们基本看到的都为 0 。但是，如果付了交易费，Commit 和 Poposal 都不为0

13

我看到一个 witness 的 data 数据有两行，第二行是 N - 11 那个块的矿工地址，但是第一行是个长得多的 hex，理论上应该能解出 N 这个块的矿工地址吧？求方法

witnesses:
  - data:
      - 0x94334bdda40b69bae067d84937aa6bbccf8acd0df6626d4b9ac70d4612a11933
      - 0x95006587a511a885b8657733f1613485845e0652
14

是的是的！在 Block N，witness 会存入 Block N 的矿工信息，以便后续构造 Block N+11 的 Cellbase 交易。

如果是工具层面，那就是使用我们的 SDK 就可以通过两者产生地址啦！长的是 Code Hash，短的是 args

如果是理论层面，我按照我的理解谈下地址是如何产生的哈 ~

目前测试网采用的地址方案是 P2PH：Pay to Public Key Hash。Bitcoin 签名算法是固定的：ECDSA-SECP256k1。所以 P2PH 地址就是 Public Key Hash 通过 base58 而得，Bitcoin 的 P2SH 地址的产生仅需要 Public Key Hash 的信息。

在CKB 的 P2PH 下，地址的产生需要有2部分信息：1）签名算法；2）公钥哈希。这里需要解答为什么会比 Bitcoin 多了签名算法信息：由于 CKB 的灵活特性，CKB 可以采用任意的签名算法，因此需要在地址中明确该地址采用的签名算法，避免解锁失败。

我们可以参考下目前 CKB 的交易。在构造交易的时候，我们需要在 Output 填写 Code Hash 和 Args。我们可以认为 Code Hash 代表着签名算法，Args 代表着签名哈希。当我们想要使用该 Cell 的时候，我们就需要使用 Code Hash 的签名算法对交易进行签名，并解锁该 Cell。通过这种方式，不同的签名算法的交易功能就可以在 CKB 实现。

其实我们知道在区块链的交易结构中，是没有地址的。地址更像是一个应用层的工具（譬如供钱包使用），其作用首先是方便用户使用，其次是能够通过解码地址去组装交易。因此，在 CKB 的情况下，地址必然地需要包含：签名算法与公钥哈希。如果不确定具体的签名算法，解锁 Cell 必然是失败的。

上述两部分对应着 Cell 的 Lock Script ：第一个是 Code Hash，签名算法存在 Cell A 的 Data 中，Code hash 则是 Cell A 的 Data 部分的 hash（blake2b）；（可以在浏览器的地址页面找到 Code Hash）在目前的情况下，几乎所有的 Code Hash 是一样的，应该存有 SECP256k1 算法。

第二个是 args , args 目前是 blake160（Public key），这个比较好理解，公钥哈希取前20位（Hex）。

有了这两个 Payload，采用 Bench32（BIP173）的规则，两者就可以获得我们的地址啦~

目前 CKB 的地址方案正在不断完善中，大家可以去 RFC 的 PR 去看下 ~

1 Like
15

感谢感谢，这得准备了好久吧~

我看了下第一行确实是这次的 code_hash ，是我没注意到，辛苦啦！

1 Like