数据节点ckb钱包本地运行节点什么检测是否损坏

本期秘猿科技区块链小课堂将会僦 PoW 共识的突破进行展开带宽实际上是区块链吞吐量的最大限制,在秘猿科技研究员张韧从「带宽利用率」角度分析了诸多共识协议的效率和可行性。

理解本文需要以下知识储备:
以太坊共识协议基本概念
孤块、叔块、自私挖矿等概念

秘猿科技区块链小课堂第 29 期


当然如果伱熟悉 Bart Preneel 的话会知道他是 RIPEMD 160 的设计者。RIPEMD 160 是比特币公钥转化为比特币地址时使用的哈希算法

Nervos CKB 是一个公有链,能够支持各种编程语言的智能合約以及各种各样的 Layer 2 协议。在 Nervos CKB 上你可以用任意资产支付交易手续费在 Nervos CKB 中智能合约的执行和验证是分离的,从而达到更好的隐私和性能朂后,在 Nervos CKB 中采用了 NC-Max ——一个 Nakamoto Consensus 的变体——作为共识协议拥有更高的吞吐量。

这里是我本次分享的大纲首先我会告诉你为什么我们会那么囍欢 Nakamoto Consensus(也就是比特币的共识协议,以下简称 NC包含一组规则,如最长链规则、激励规则、增发规则等)然后我会给出我们为什么不采用其他共识协议的理由。最后我会给出我们 Nervos CKB 的共识协议 NC-Max 的设计思路

为什么我们喜欢比特币的 NC?

先来回答一个问题为什么我们喜欢比特币嘚 Nakamoto Consensus(NC)?

有很多的理由首先 NC 的性能优化做的非常好,它能够节约每一个传输的每一个字节以及每个计算周期。举例来说它使用Compact Block来加赽区块的传播,可能在未来使用 Minisketch (一个用于在分布式系统不同节点之间同步信息时降低带宽需求的软件库)来节省交易广播所需要的带寬资源。同时比特币的开发者提出了 Graftroot(关系到比特币上开发智能合约以及隐私性的一项提案)你可以认为它能够通过压缩比特币上的智能合约从而获得更好的隐私性和更好的性能。或许我们还能够看到签名聚合技术(Signature Aggregation)应用在比特币之上

知识点:Compact Block Relay,在比特币改进协议(BIP)152 中提出能够减少 P2P 网络节点广播区块所需的带宽数量。Compact block 是完整区块的「概要」包含下面三部分信息:
3、发送方节点预测的但是接收节點不具备的完整交易
接收方会尝试根据收到的信息以及在其内存池中的交易来重新构建完整区块。若仍然缺失某些交易它将会请求广播節点。

喜欢 NC 的另一个理由是它的通用性UTXO 模型加上全局交易顺序能够支持各种分片技术和 Layer 2 方案,以及复杂的智能合约

相比来看,以太坊嘚 Account 模型进行分片的难度更高;并且如果你没有一个全局交易顺序的话比如像许多 DAG 类型协议那样,那么就很难支持复杂的智能合约关于這一部分会在后面谈 DAG 的时候详细描述。

我们也喜欢比特币 NC 的安全性比特币网络经历了很多的攻击,还是稳定ckb钱包本地运行节点了十年洏且严格意义上来说,目前没有任何一个已知的工作量证明共识机制在整体上超越 NC如果你对这个话题感兴趣,可以看这里

然而在 NC 中有兩个地方我们希望做出一些改变。首先在带宽利用方面比特币的 NC 在采用隔离见证之后,人为设定了最大为每十分钟 4Mb 的吞吐量然而现实凊况是,比特币公共节点的带宽水平在过去的几年里获得了大幅度的提升

对于 NC 我们有哪些地方需要做出改变?

如同上图中这个研究所指絀的链接到网络中的比特币 IPv4 节点在 2016 年时带宽中位数为 33Mbit/s,在 2017 年 2 月这个数字达到了 56Mbit/s。

我们很容易想到的改进方式就是协议自身是否能够動态地调节吞吐量来适应带宽水平的变化?

Bitcoin Unlimited 做了一个糟糕的尝试它希望能够动态地调节比特币的吞吐量,但是它失败了引入了多种新嘚攻击方式让它的协议变得不安全。上面是在 Coindesk 上发布的一篇关于 Bitcoin Unlimited 安全性研究(链接:)我也是这项研究的参与者之一。

另一个我们希望茬 NC 中做出改变的是它的激励问题也就是出现自私挖矿攻击的问题。自私挖矿攻击者会扣留发现的区块希望在网络中获得更大的领先优勢。当其他诚实矿工发现区块的时候攻击者会向网络广播这个被扣留的区块,寄希望于这个被广播的扣留区块会在诚实区块之前被大蔀分诚实矿工接收到。如果攻击者足够幸运下一个块是在攻击者的块上面进行挖矿的,那么诚实的块将会成为孤块如果攻击者运气好箌能够连续挖到多个区块,那么它将能够非常安全地让一个诚实矿工的区块失效因为攻击者会有更长的链。

为什么自私挖矿是有利可图嘚呢我们举一个具体的例子,假设自私挖矿攻击者有全网 30% 的算力诚实矿工控制剩下的 70%。如果没有自私挖矿攻击出现那么攻击者在 10 个區块中能够找到 3 个,诚实矿工找到 7 个大家都拿到应有的报酬。如果攻击者发动自私挖矿攻击那么它能够找到 3 个区块,诚实矿工只能找箌 4 个区块因为另外 3 个诚实矿工找到的区块经过前面提到的攻击方式变成了孤块,原本能够产生 10 个区块的时间现在只产生了 7 个区块主链增长速度减慢。

在下一个难度调整周期由于协议发现主链增长速度减慢,会降低挖矿难度从而攻击者能够用同样大的算力获得更多的獎励,这是自私挖矿有利可图的原理要注意的是,矿工获得的收益是根据单位时间内获得的币的数量而不是获得币的比例来计算的在丅一个难度调整周期,由于链增长的速度下降协议会降低挖矿难度,此时矿工在单位时间能够获得更多的币才有收益。因此自私挖礦在第一个难度调整周期中是没有收益的,只有在挖矿难度调整之后自私挖矿才会有收益

那我们为什么不选择其他替代性的共识协议呢?

目前有三种替代 NC 的方式它们分别是 PoS(Proof of Stake,权益证明)DAG 和两种区块类型的共识协议。注意这三种方式并不是相互排斥的是有可能同时應用它们之中的 2-3 种的。下面我们来进一步分析这些协议的安全性、功能性和吞吐量

首先是 PoS,实际上所有的 PoS 协议引入了新的安全前提拿 Algorand 舉例来说,它要求大部分诚实用户发送的消息能够被大部分其他诚实用户在一个已知的时间范围内里面接收到这意味着当你持有 Algorand 的 Token 时,根据协议最初的设计你需要时刻保持在线来接收消息如果你不在线你就不是一个合格的 Token 持有者。

Cardano 的共识协议 Ouroboros 则假设所有用户有一个弱同步的时钟并且所有消息都能够在一定时间间隔内被送达。这实际上是提出了一个非常强的假设有很多攻击方式能够让你的挖矿设备,伱的公共节点或者手机上的时钟产生偏差并且这个方案在现实环境中实现起来也非常困难。

当这些安全性假设被违反会为这些 PoS 协议带來灾难性的后果。并且 PoS 协议引入了一些新的攻击方式如 Nothing-at-stake Attack,Grinding AttackLong-range Attack,这些攻击方式在 PoW 协议中是不存在的在这里我不对这些攻击方式进行详细描述。

那么 DAG 协议怎么样呢

所有 DAG 协议都有交易排序的问题,如像 DAG 协议那样让区块同步产生那么不同的矿工或不同的公共节点对交易顺序嘚判断会有不一致:我认为这一些交易被确认了,但是其他人可能认为另一组交易是被确认的这时候你会有两种解决问题的思路。

一种昰在区块链拓扑排序完成之后对交易进行排序这意味着你需要等待很长的交易确认时间。

另一种是不去确认交易顺序合约的输入需要铨局的交易顺序,如果不同矿工判断的交易顺序不同那么每个矿工对合约逻辑执行顺序的理解就是不一样的,特别是对于复杂的合约這会限制合约的功能性,复杂合约不能执行合约中包含的 Token 会卡在合约中。

那么那些有两种区块类型的协议如何呢两种区块类型的协议,顾名思义它采用一种和 NC 中的区块一样的关键区块(Key Block)来保障交易确认的安全,同时在两个关键区块之间广播微区块(Micro Block)来提高吞吐量

这些协议通常和 DAG 协议一样会有较长的确认延迟。Bitcoin NG 就采用了上述的方案在 Bitcoin NG 的论文中明确表明,若用户需要确保交易确认在 Bitcoin NG 中他们就需偠等待数个关键区块的确认,忍受较长的交易延迟

(原本在分享过程中张韧提到 Byzcoin 也有类似的问题。但是经过进一步分析发现问题并不类姒若对 Byzcoin 感兴趣可以点击「阅读原文」在论坛进一步讨论 )。

所有采用这些替代性共识协议的项目都声称它们有很高的吞吐量那么这些項目的吞吐量究竟如何呢?(下面这一段建议观看视频约在 15:30 部分,现场非常精彩 )

Solana 声称能够每秒能够处理 710000 笔交易如果你能够有这么大嘚突破,理应获得图灵奖我迫不及待地想听到他们获奖的消息。

还有这个名为 NKN 的协议他们声称他们能够在全网拥有 10000 个节点的同时每秒處理 100 万笔交易,目前我还不知道他们是如何做到的但是我对他们实现的方式非常好奇。

我也很好奇为什么 Stellar 和 Ripple 也将自己的协议归类为 NC我吔非常好奇 10000 个节点如何实现每秒处理 100 万笔交易的。

而如果你想做个梦的话你最好做一个伟大的梦,比如这个协议它声称能够在低于 1 秒嘚最终确认时间内拥有 0TPS 。

嗯我真的觉得地球对他们而言已经不够大了,他们真的需要另找一个更大的星球来部署他们的协议

我们要注意的是,自称的 TPS 是没有可比性的因为它们是在不同的网络环境中做模拟,某些模拟甚至使用 1Gbit/s 的带宽显然这和现实网络情况相差甚远。

並且这些协议都忽略了真实的情况他们之中没有一个考虑到交易的同步。对它们来说似乎所有的交易都是已经在区块中同步好的一样囲识协议只是用来对交易进行排序的。而且一些模拟假设委员会成员(节点)之间有直接的连接但事实是,在公有链网络中所有的消息嘟是通过广播进行的而广播消息会占用公共节点的带宽。

知识点:Fresh Transaction为什么说要考虑交易的同步呢?要认识到在比特币中一个用户从錢包客户端发起的交易并不是被所有矿工都接受到,而是相邻的几个矿工这些矿工在接受到用户发起的交易的时候会对交易进行验证才能放到交易池中,以便在未来将这些交易打包出块因此若一个矿工成功挖到一个块并广播 Compact Block,其他矿工在检查 Compact Block 中交易 ID 的时候若发现对应的囿些交易并不在自己的交易池中则需要向发送方请求完整交易进行验证来保障区块中所有交易都是合法的,这些交易就是「Fresh Transaction」若不进荇验证就在收到区块之后挖矿,一旦完整区块广播后被发现有非法交易将不会被矿工认可,在这个非法区块之后挖出的区块都会作废Fresh Transaction 嘚概念我们会在后面用到。

这里我们有一个评估 TPS 的模型如图所示,首先我们相信所有公共节点的带宽是有一个上限的最多能够使用 100% 的帶宽,你不能使用超过 100% 的带宽在这里带宽的占用有三个组成部分。

如上图所示第一部分是用于同步最终确认的交易所占用的带宽比例,这一部分是真正的 TPS(This is the real TPS)交易首先要被同步,之后才能进行交易确认第二部分是被共识协议「浪费」的带宽所占的比例。第三部分是未被利用的带宽

所以如果想要提高 TPS,能够做的只有两件事

1、降低共识协议占用的带宽比例
2、降低未被利用部分的带宽比例

能做的只有這两件事情,对没有其他的方式了,并且对于 Layer 1 的协议带宽占用不能超过 100%

那我们先来看看其他替代性共识协议的带宽占用。

事实上很哆协议将它们珍贵的带宽资源浪费在委员会成员之间的通信上。

Algorand 存储区块证书以此来向新用户证明一个区块被提交每个区块证书的大小昰 300KB ,独立于区块容量限制之外如果你按照一个区块 1MB 的大小来计算,那么这意味着大约 25% 的带宽会永远被用于同步这些证书因此我非常好渏为什么它们声称他们的吞吐量比 NC 更好,这根本不合理

另外一种在共识协议中浪费带宽的方式是区块型 DAG 和孤块中的冗余交易。如上图的論文中所说如果所有的节点在区块中选择包含同样的一组子交易,任何两个平行创建的区块将可能出现冲突并且吞吐量就不会很高。

洏目前所有的区块型 DAG 协议对这种情况视若罔闻

如何突破中本聪共识困境?

从上面的分析中看到显然目前的吞吐量不能满足我们,因此Nervos CKB 的共识协议 NC-Max 对 NC 做了一些改进:

NC-Max 有三个主要的创新

  • 采用两步交易确认来降低孤块率
  • 动态调整区块间隔和区块奖励来更好的提升带宽利用率
  • 茬难度调整的时候考虑周期中的所有区块,来抵御自私挖矿攻击

接下来我会进行详细解释。

NC 有一个天然的吞吐量限制因为想要提高 NC 中嘚吞吐量,只能做两件事情:

第二件是降低出块间隔

但是由于区块广播需要时间,广播期间若其他节点发现区块并广播会和正在广播嘚区块产生竞争,其中之一会成为孤块更大的区块会需要更长时间广播,降低出块间隔实际上是降低出块难度节点更容易发现区块。這两种方案容易带来的结果是孤块率变高了这些孤块占用更多的带宽,但是它们并不为交易确认做出贡献当孤块率提高时,系统的安铨性会降低并且吞吐量也会降低因此对于这两种方案最终会达到一个平衡,当区块大小或出块间隔调节到一定程度时孤块率会高到一萣程度,即使你进一步增加区块大小或者降低出块间隔吞吐量也不会得到提高。

为什么太多的孤块会对网络的安全和性能产生负面影响呢在上图中我们能够看到,当孤块率非常高时攻击者能够非常轻易地私自构建一条更长链。攻击者只需要拥有比全网算力的 51% 低很多的算力就能够覆盖掉区块链。并且孤块会消耗公共节点大量的带宽这会对整个系统的吞吐量造成很大的负面影响。

那我们如何打破 NC 吞吐量的限制呢经过上面分析,如果我们想要打破这个限制就必须降低孤块率。如果孤块率下降那么网络的安全性和吞吐量都能够提高。

如何降低孤块率呢孤块的出现是由于区块广播的延迟,若在一个区块广播的过程中有另一个区块被发现,那么其中一个区块就注定會成为孤块如果区块广播能够瞬间完成,自然不会有孤块出现那我们如何确保区块能够足够快速地被广播出去呢?

比特币的开发者已經投入了非常多的资源和精力来加快区块的广播速度我们需要进一步找出哪些区块的广播速度较慢,或是出了问题

我们来详细看看这昰如何发生的,请看下图

目前的比特币网络,如果一切顺利的话一个区块是通过一个Compact Block 中继协议来广播的。

当节点 A 广播 Compact Block 给节点 B 的时候節点 B 检查这些交易 ID ,如果对于节点 B 这些交易都不是 Fresh Transaction(也就是节点 B 的交易池中包含这些交易)节点 B 能够立刻转发这些 Compact Block 给相邻节点,这种情況非常棒过程很顺利。

然而如果在 Compact Block 中有 Fresh Transaction节点 B 将首先需要从节点 A 那边同步 Fresh Transaction,然后验证这些交易的签名这些步骤都很耗费时间。只有当整个区块都经过验证无误之后节点 B 才能继续广播这个区块。这个过程避免收到的区块非法这样矿工才会在这个区块之后挖矿并广播,若不经过验证万一之后发现是非法区块那么在这个非法区块之后的区块都是无效的。同步 Fresh Transaction 的过程是比特币区块广播延迟的主要原因

所鉯,以太坊是一个糟糕的尝试我来分析一下他们是怎么做的。以太坊简单地缩短了出块间隔但是以太坊有一个问题,就是它不能够在收到区块之前验证交易的有效性因为在以太坊中一个交易的有效性依赖于区块中交易的顺序,因此如果你想要验证一个交易的有效性你必须等到整个区块都被接收到才行这样的话每一个区块实际上都是 Fresh Transaction。

并且以太坊的网络协议维护得非常差自从 2015 年开始就没有任何的迭玳。

而且在交易广播过程中也有大量的冗余以太坊客户端会将同一笔交易向不同的节点广播 7 次,这意味着每一个节点将会收到同一笔交噫 7 次(以太坊有不同的客户端,如 Parity EthereumGeth 等)而且不同类型的客户端之间有不一致性,两个主要的以太坊客户端之间基本都是独立的

因此能够链接两个不同的网络的节点非常少,这也是为什么以太坊孤块率有时会高达 30%并且交易吞吐量非常低。

而且大矿工没有加快区块广播速度的激励因为如果我的区块能够更慢地广播出去,意味着我实际上能够实现「自私挖矿」(这里大矿工并不扣留区块只是区块广播仳较慢,在这个过程中出现了其他的竞争块而因为我是大矿工有较大的概率在和其他竞争块竞争过程中胜出)。这对我来讲是好事为什么我要加速区块广播呢?

以太坊中的叔块奖励也没有提供任何帮助毕竟如果产生了的孤块,矿工还是能够获得奖励因此小矿工会采鼡先广播区块头和空块的方式,因为广播区块头的速度会快很多并且由于不知道下一个区块中会包含哪些交易,因此矿工通常会挖一个涳块来确保区块中不会包含和之前区块交易产生冲突的交易这非常糟糕,因为空块并不为交易确认做出贡献

下面是我们的设计,来缓解上面提到的一些问题

这张图是区块的结构,我们在比特币区块结构的基础上增加了几个字段

上图是我们的完整区块的区块结构。首先我们有一个交易提案区(青色区域)只有交易提案区可包含 Fresh Transaction,而传统的交易确认区(橙色区域)只能包含前几个区块的交易提案区的茭易若当前区块高度是 h 的话,那么就是 h-m 到 h-n 区块的交易提案区内的交易只有这些交易能够被确认,Fresh Transaction 不能被交易确认区确认交易提案区鈈包含完整的交易,只包含交易 ID(Truncated Transaction ID)因此交易提案区会非常小。

在叔块头区可以包含任意数量的叔块(紫色区域)叔块应该包含它们嘚区块头和交易提案区。叔块头区不计入区块大小因而不受区块大小的限制,所以不会限制矿工添加叔块

下面我进一步来解释交易提案区。这个区域非常小因为它只包含交易 ID。完整的交易与区块同步广播因为这是一个并行的过程,所以交易的广播不会影响到区块的廣播并且节点在收到广播的交易后只需要验证哈希,不会影响区块的验证过程

尽管这意味着在交易提案区可能会有无效的交易,双花茭易以及矿工可能不愿意接受的交易但是这都没有关系。

类比之前提到的比特币区块广播过程在我们的协议中,发现区块的节点会先廣播 Compact Block(也就是区块头和交易的 ID)Compact Block 较比特币的稍微大一点,包含交易提案区和若干叔块的区块头和叔块的交易提案区但由于 Compact Block 本身足够小通常会立刻广播给相邻的节点。

新提出的交易如果有一部分不在节点的交易池中,它们会在发出 Compact Block 之后进行广播这些都是并行过程,不會相互影响节点收到交易,经过哈希验证后广播给相邻的节点

这很自然地会有几个问题:

  • 如果矿工拒绝提供提案交易的完整版本怎么辦?
  • 我把这个交易放到我的交易提案区但是当你问我要完整的交易的时候,我装作不知道

实际上这个对区块广播不会有影响,因为不論交易提案区是否有 Fresh Transaction区块都能够广播。

并且其他矿工也会继续挖矿因为总是有足够的提案交易需要确认。该矿工也没有必要挖空块洇为之前区块的交易提案区包含了它将打包的这些交易 ID,已经被发现的区块在 Compact Block 中都广播了打包进的交易确认区的交易 ID矿工都知道哪些交噫被打包了哪些没有,不会选择和被发现区块交易确认区内相冲突的交易因此矿工会选择继续打包交易出块并获得手续费,为交易确认莋贡献

那么如果矿工在他们最新的区块中包含了这些提出但未广播的交易,以获得一个类似自私挖矿的优势怎么办

在比特币的 NC 中,矿笁减慢区块广播速度可以获得挖矿优势矿工通常能够在挖出一个区块时,只广播区块头而在广播完整区块的时候放慢动作。在这个过程中只有该矿工能够挖矿(因为只有他知道下一个区块的信息能够基于这个新块挖矿,这个过程类似扣留区块)

但是在我们的协议中,采用这种方式只会减慢 n 个区块之后的区块广播速度因为提出但未广播的交易只有自私矿工知道,也只有自私矿工能以此作为优势然洏这个不能被用在下一个区块中,因为在我们的协议中只能挖 n 个区块之前提案区中包含交易中间需要有一个间隔。

矿工只能够挖 h-m 至 h-n 个区塊内的提案交易但是不能挖前一个区块的提案交易,除非这个区块也是被攻击者挖到的

如图所示,这是我们的共识协议和比特币 NC 的对仳在比特币 NC 中当自私的矿工找到区块 h, 它能够立刻开始挖区块 h+1此时诚实矿工只能够在收到完整的区块 h 之后才能开始挖矿,因为其他矿笁需要知道区块包含的完整的交易并验证来确定区块是合法的而自私矿工能够通过减慢区块 h 传输的速度来让其他矿工更晚收到区块。在區块广播期间就是自私挖矿者的优势期

然而在我们的协议中当一个自私矿工找到一个区块 h,广播了包含区块头和交易 ID 的 Compact Block诚实矿工能够竝刻开始挖 h+1。如果自私矿工想要利用这些提出但未广播的交易它必须找到 n 个区块之后的区块(这些区块才能包含这些提出但未广播的交噫),这样他们才能利用这个优势然而这很难发生,你不能确定在 n 个块之后的那个块是你挖出来的这个非常难预测。

为了更好地利用帶宽我们的协议使用了另一种不同的难度调整机制,设定一个固定的孤块率(根据上一个难度调节期的叔块数来计算)

如果孤块率在仩一个难度调整周期低于设定的孤块率,挖矿难度会降低出块间隔将降低,吞吐量会提高也就是说,更少的孤块意味着当前的网络状態实际上有能力更快地同步交易我们能够在提高吞吐量的同时不损害网络的去中心化。

反过来看如果难度提高那么出块间隔会增加,吞吐量也会降低如果孤块率很高那么意味着当前的网络在这个难度调整周期内并不能处理那么多的交易,那么协议就会降低吞吐量

同時出块奖励会和 1/(预期出块间隔)成正比,因此在每个难度调整周期中预期的总出块奖励是固定的

这意味着假设我们每十分钟出一个块,每个块中有 12.5 个比特币如果难度调节变成每 5 分钟出一个块的时候,每个块会有 6.125 个比特币因此货币的发行率也是保持恒定的。

最后抵忼自私挖矿攻击。前面我们提到我们的协议和 NC 的一个区别在于我们的难度调整机制是根据难度调整区间中出现的所有区块来计算的,在估计总算力的时候也会包含叔块

在 NC-Max 中,假设攻击者占总算力的 30%诚实矿工 70%,如果没有自私挖矿攻击在 10 个区块中攻击者能够找到 3 个区块,诚实矿工找到 7 个如果进行自私挖矿,攻击者在 7 个区块中能够找到 3 个区块诚实矿工找到 4 个,3 个诚实区块会成为孤块主链会增长缓慢。

前面也提到自私挖矿在第一个难度调整周期内是没有收益的那么在第二个难度调整周期会出现什么?

在下一个难度调整周期难度会保持不变(因为难度会根据所有区块计算,包含孤块)攻击者并不能用同样的算力找到更多的区块,因此自私挖矿不再有利可图

也就昰说,我们假设币价在短时间内维持稳定由于自私挖矿攻击者是短视的,他们的奖励是根据单位时间内获得的奖励来定义可以等价于哃样的电力消耗能够获得的奖励。在比特币中自私挖矿攻击者能够通过降低链增长速度,「迫使」协议降低出块难度从而在难度调整の后单位时间内能够获得更多的奖励。而在 NC-Max 协议设计中出块难度会根据所有区块来计算,包括孤块攻击者让诚实矿工的区块成为孤块,却并不能「迫使」协议降低出块难度以在单位时间内获得更高奖励。

最后总结一下我们的协议会很好地利用孤块:

我们希望能够通過两步交易验证来降低孤块数量,在孤块数量降低之后我们利用孤块率作为一个带宽利用水平的指标来动态地调节吞吐量。

并且孤块信息被写在了区块链中我们在挖矿难度调整算法中利用这个信息从而让自私挖矿无利可图。

}

2、下载完之后解压缩把原来(舊版本)备份的privkey拷贝到解压之后的文件夹里。

3、比如将解压缩后的文件夹存放在桌面路径为C:\Users\ray\Desktop\ckb_v0.25.1_x86_64-pc-windows-msvc(如保存在其他文件夹,可打开文件夹从丅图所示位置获取文件夹路径,路径中不能有中文)

然后输入 ckb run再回车,CKB 节点就开始ckb钱包本地运行节点了并自动进行数据同步,窗口不偠关闭转账时需要节点保持在线。

其中--privkey-path后面是你的privkey存放路径;输入的命令里应用“/”;收款地址可以是交易所提供的钱包地址。

转账金额和手续费单位为 CKB注意:这里的转账金额和手续费单位和上面查询余额显示的单位不一致。建议先用少量币测试

完成后等待入账即鈳。查看转账进度可以访问区块浏览器:https://explorer.nervos.org/,搜索转账的hash或钱包地址关注余额变化

需注意,钱包余额应大于等于61个CKB否则无法转出。

}

我要回帖

更多关于 ckb钱包本地运行节点 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信