实现数字货币双花攻击的方式方法有哪些？央行推动央行数字货币发行势在必行

1. 工作量证明和双花攻击

2008年，中本聪提出了一种完全通过点对点技术实现的电子现金系统，使在线支付可以由一方直接发起并支付给另一方，中间没有任何金融机构。 虽然数字签名部分解决了这个问题，但如果仍然需要第三方的支持来防止双花，那么这样的系统就失去了它的价值。 比特币的工作量证明机制（PoW）的本质是让现金系统在点对点的环境中运行，防止双花攻击。

工作量证明机制的原理如下：网络中的每个区块都包含当前网络中的交易和前一个区块的区块头哈希。 当一个新区块产生时，其区块头哈希必须满足工作量证明条件（需要进行大量的哈希计算）。 整个网络将满足工作量证明的哈希链连接起来形成区块链。 除非攻击者重做整个工作证明，否则生成的交易记录将是不可变的。 最长的区块链不仅可以作为观察到的交易顺序的证明，也可以看作是来自最大人群的共识。 只要全网绝大部分算力不打算协同攻击全网，诚实节点就会生成超越攻击者的最长链，从而实现抵御双花攻击。

双花攻击实际上是一个后果。 如果攻击者 A 同时向两个用户 B 和 C 支付相同的比特币，并且用户 B 和 C 都批准了这笔交易。 那么我们就说 A 花费了比特币两次，A 实现了双花攻击。 在针对工作量证明机制的双花攻击中，51%攻击是讨论最多的攻击形式。 但是，针对工作量证明机制的双花攻击实际上有多种形式，包括 Fanny 攻击、竞争攻击和 Vector76 攻击。 这些攻击其实已经引起了足够的重视和讨论，本文不再赘述。 事实上，还有许多其他形式的实用数字货币双花攻击。 下面，我们将通过我们发现的多个安全漏洞，讨论造成多次数字货币双花攻击的各种原因，并提出有效的缓解措施。

2. 双花攻击新分类

智能合约平台本质上是在全网共享一个账本。 这可以被视为分布式状态机复制问题。 我们可以将当前分类帐状态视为 State_n。 当新的交易Tx_产生时，Tx_会对State_n产生影响。 因此 State_n 状态转换到 State_ 状态。 我们可以用一个公式来表达这个过程：

State_n × Tx_{n+1} → State_{n+1}

智能合约平台的共识机制本质上是将所有的交易按顺序应用到初始的State_0，让整个网络始终保持相同的状态。 区块链中的每个区块实际上是将交易序列依次拆分为不同的区块Block1和Block2，并将它们依次链接起来。 在复制全网状态机的过程中，如果由于某种原因导致全网状态不一致，我们可以认为全网发生了分叉。 分叉被攻击者利用，可以进一步实现双花攻击。

在本文中，我们将发现的这些双花攻击漏洞分为 3 类：

验证不严引起的双花攻击。

状态机State_n × Tx_{n+1}→State_{n+1}执行不一致导致的双花攻击。

共识机制引起的双花攻击。

验证不严导致双花攻击的主要原因在于逻辑验证问题的执行。 比特币的漏洞CVE-2018-17144其实就是这样一个漏洞。

状态机执行不一致造成的双花攻击央行基于以太坊发行数字货币，主要是由于智能合约虚拟机由于各种原因导致直接结果不一致，从而造成全网分叉，造成双花攻击.

共识机制的漏洞可能导致全网分叉，进一步引发双花攻击。 人们常说的51%攻击，其实是PoW共识机制的分叉漏洞。

3. 验证不严引起的双花攻击

验证不严导致双花攻击的主要原因在于逻辑验证问题的执行。 这里我们介绍两个与绑定区块和交易时验证不严有关的漏洞，导致双花攻击。

在区块链项目中，一笔交易Tx_1在某个区块Block_1中的打包方式是这样的：先计算交易Tx_1的哈希值Hash_1，然后将Hash_1与其他交易的哈希值Hash_2...Hash_n合并形成 Merkle Hash Tree。 计算哈希树的根节点root，然后将root打包到Block_1中。 这样，一个交易就绑定了一个区块。 一般来说，除非攻击者能够破解哈希函数的抗碰撞性，否则不可能破解交易与区块的绑定。 如果攻击者能够将交易与区块的绑定打包，攻击者就可以通过造成全网分叉来实现双花攻击。 下面我们介绍一下我们在NEO上发现的两个双花攻击漏洞：

3.1 NEO虚拟机GetInvocationScript双花攻击漏洞：

在区块链项目中，一笔交易一般由未签名部分（UnsignedTx，交易中要执行的内容）和已签名部分（交易的见证）组成。 在比特币这样的区块链项目中，交易的哈希计算实际上包括了交易的签名部分。 在NEO、ONT等各种区块链平台中央行基于以太坊发行数字货币，交易计算公式为hash=SHA256(UnsignedTx)。 也就是说，交易的哈希是从未签名的部分计算出来的，与交易的见证无关。 NEO智能合约执行时，可以通过Transaction_GetWitnesses方法从一笔交易中获取交易的见证人。 其具体实现如下：

合约交易在获得自己的witness后，还可以通过Witness_GetVerificationScript方法获取witness中的验证脚本。 如果攻击者针对同一个未签名交易 UnsignedTx1，则可以构建两个不同的验证脚本。 它可能导致合同执行不一致。 一般情况下，合约的VerificationScript由合约的输入等信息决定，攻击者无法构造不同的验证脚本并通过验证。 但是我们发现在VerifyWitness方法中，当VerificationScript.length=0时，系统会调用EmitAppCall来执行目标脚本hash。

因此，当VerificationScript=0，或VerificationScript等于目标脚本时，即可满足witness验证条件。 也就是说，攻击者可以为同一个未签名交易UnsignedTx_1构造两个不同的VerificationScript。 攻击者利用这一特性对 NEO 智能合约上的所有代币资产进行双花攻击。 具体攻击场景如下：

第一步：攻击者构造智能合约交易Tx_1（未签名内容UnsignedTx_1，验证脚本为VerficationScript_1）。 在UnsignedTx_1的合约执行中，合约会判断自己的VerficationScript是否为VerficationScript_1。 如果是VerficationScript_1，选择发送令牌给用户A。如果VerficationScript为空，则发送令牌给用户B。

第 2 步：Tx_1 被打包到块 Block_1 中。

第三步：攻击者收到Block_1后，将Tx_1替换为Tx_2（Tx_1与Tx_1具有相同的未签名内容UnsignedTx_1，但验证脚本为空）形成Block_2。 攻击者将 Block_1 发送给用户 A，将 Block_2 发送给用户 B。

第四步：当用户A收到Block_1时，发现自己收到了攻击者发送的token。 当用户B收到Block_2时，他也会发现自己收到了攻击者发送的token。 双花攻击完成。

可见，该漏洞的利用门槛非常低，可以对NEO智能合约上的所有代币资产进行双花攻击。 危险非常严重。

3.2 NEO MerlkeTree绑定绕过导致交易双花攻击漏洞：

智能合约交易和区块的绑定通常是通过 MerkleTree 完成的。 如果攻击者可以绕过此绑定，他们就可以双花任何交易。 下面我们看一下NEO的MerkleTree的实现如下：

在 MerkleTreeNode 函数中，NEO 执行从 MerkleTree 叶子节点到父节点的计算。 但是这里有个问题，当leaves.length为奇数n时。 NEO的MerkleTree会把最后一个叶子节点复制一次，加入到MerkleTree的计算中。 也就是说，当n为奇数时，以下两组交易的MerkleRoot值将相等：

其中 Tx_= Tx_n

利用这个特性，攻击者可以对任何 NEO 资产实施双花攻击。 具体攻击场景如下：

步骤 1：假设一个正常的合法 Block_1 包含一个交易列表。 攻击者收到Block_1后，将交易列表替换为 ，形成Block_2。 然后将 Block_2 发布到网络。

第二步：普通节点收到Block_2后，会验证Block_2的合法性。 然而，因为它与 具有相同的 MerkleRoot。 因此，Block_2可以通过区块合法性验证，从而进入区块持久化过程。 NEO 原生取消了普通节点（信任多个共识节点）对合法区块中交易的验证。 那么Tx_n交易可以被普通节点执行两次，双花攻击执行成功。

可见该漏洞的利用门槛非常低，可以对NEO上的所有资产进行双花攻击。 危险非常严重。

4、虚拟机执行不一致

智能合约平台的共识机制本质上是将所有的交易按顺序应用到初始的State_0，让整个网络始终保持相同的状态。 在状态机复制期间，我们要求 State_n × Tx_èState_ 是确定性的。 State_n × Tx_èState_本质上是智能合约虚拟机对Tx_的执行过程。 如果智能合约虚拟机存在设计或实现漏洞，将导致虚拟机执行不一致（对于相同的输入State_n和Tx_，输出State_不一致）。 那么攻击者就可以利用这个问题在网络中产生分叉，进行双花攻击。 下面介绍我们在EOS和NEO上发现的几个虚拟机不一致执行漏洞及其成因。

4.1 EOS虚拟机内存损坏RCE漏洞：

此前，我们发布了《EOS节点远程代码执行漏洞——EOS WASM合约函数表数组越界》一文（）。 在本文中，我们发现了 EOS WASM 虚拟机中的内存越界写入漏洞。 我们针对该漏洞编写的利用程序可以成功利用该漏洞使EOS虚拟机执行任意指令，从而完全控制所有EOS出块节点和验证节点。 .

本质上就是State_n×Tx_{n+1}→State_{n+1}的过程。 攻击者可以让EOS虚拟机完全脱离原来的执行路径，执行任意指令，自然而然地完成双花攻击。 攻击过程如下：

第一步：攻击者构造一个能够实现RCE的恶意智能合约，并将合约发布到EOS网络中。

第二步：EOS超级节点解析合约后触发漏洞，执行攻击者自定义的任意指令。

第三步：攻击者实施双花攻击。

该漏洞危害非常严重，是智能合约平台首次遭受远程代码执行攻击。 读者可以阅读文章了解相关细节，这里不再赘述。

4.2 EOS虚拟机内存未初始化导致双花攻击：

在编写“EOS节点远程代码执行漏洞——EOS WASM合约函数表数组越界”漏洞利用程序的过程中，我们也利用了当时EOS中一个未公开的未初始化内存漏洞。 在内存损坏攻击中，未初始化的内存漏洞通常会导致进一步的信息泄露、类型混淆等问题，从而帮助我们绕过ASLR等现代二进制程序的缓解措施，进一步实现攻击。 但是在智能合约虚拟机中，有更直接的方式利用未初始化内存漏洞，可以直接造成双花攻击。 以下是我们在 EOS RCE 中利用的一个内存未初始化漏洞的详细信息，该漏洞可用于直接对 EOS 智能合约代币资产实施双花攻击。

当 WASM 虚拟机使用 grow_memory 伪代码申请新内存时。 在EOS WASM grow_memory的初始实现中，申请的内存并没有被清除。 这块内存的空间实际上是随机的（取决于合约执行机器的内存状态）。 然后攻击者可以构造恶意合约，实现对EOS上任意合约资产的双花攻击。 攻击过程如下：

第一步：攻击者构造恶意智能合约。 通过合约中的 grow_memory 获取新的内存地址。

第二步：合约读取地址中某位的内容（此时该位可能为0或1，取决于合约执行机器的状态）。

第三步：合约判断比特的内容。 如果为1，则将令牌发送给用户A，如果为0，则将令牌发送给用户B，从而实现双花攻击。

4.3 EOS虚拟机内存越界读取导致双花攻击：

在传统的内存破坏中，内存越界读取漏洞主要会导致信息泄露，从而辅助我们绕过ASLR等现代二进制程序的缓解措施，进一步与其他漏洞一起实现攻击。 但是在智能合约虚拟机中，有更直接的方式利用内存越界读取漏洞，可以直接造成双花攻击。 下面是我们发现的一个EOS内存越界读漏洞，我们可以利用这个漏洞来实现双花攻击。

EOS WASM 在将一个偏移量转换为 WASM 内部内存地址时，其边界检查过程如下：

这里是 |ptr| 的类型实际上是I32类型，可以是负数。 那么当：

-sizeof(T) < ptr < 0，ptr+sizeof(T)是一个很小的数，可以通过边界检查。 在下面的寻址中，我们看到了代码：

T &base = (T)(getMemoryBaseAddress(mem)+ptr);

|基地|的地址会超出WASM的内存基地址，从而使智能合约实现越界内存读取（读取内存地址的内容取决于虚拟机当前的执行状态，可以认为是随机的）。 攻击者可利用该漏洞实施双花攻击。 攻击过程如下：

第一步：攻击者构造恶意智能合约。 合约利用内存越界读取漏洞读取WASM内存基地址之外的某一位）此时该位可能为0或1，取决于合约执行机器的状态）。

Step 2：合约判断bit的内容。 如果为1，则将令牌发送给用户A，如果为0，则将令牌发送给用户B，从而实现双花攻击。

4.4 标准功能实现不一致导致双花攻击：

总结以上两个双花攻击实例的本质，其实是EOS合约在执行过程中，由于一些内存泄漏，读取了随机变量，从而破坏了原有虚拟机执行的一致性，造成双花攻击。 事实上，合约执行的不一致性并不一定完全取决于随机性。 这里介绍一个由于标准C函数在各个平台（版本）上的实现不一致导致的双花攻击。

在C语言标准定义中，要求memcmp函数的返回值是：小于0，等于0，或者大于0。但是在各个C版本的实现中，具体的返回值可能不同（但还是符合C 标准）。 攻击者可以利用该标准的不一致性，导致运行在不同系统上的EOS虚拟机执行结果不一致，进而实现双花攻击。 攻击过程如下：

第一步：攻击者构造恶意智能合约，调用合约中的memcmp函数，获取返回值。

第二步：此时，不同平台、不同版本实现的Memcmp返回值不一致（即使EOS虚拟机的二进制代码相同）。 恶意合约判断Memcmp的返回值，决定转钱给A或B，从而完成双花。

该漏洞具体修复如下：

EOS 通过强制将 memcmp 的返回值转换为 0、-1 或 1 来抵制这种不一致的执行。

Memcmp的问题是同一种语言对同一种标准实现不一致造成的。 事实上，同一个区块链项目往往会有不同版本语言的多种实现。 不同语言对同一标准的实现往往存在偏差。 例如，我们发现由于标准定义的不一致实现而导致的不一致执行之一是 ECDSA 函数。 ECDSA签名标准要求私钥x不能为0，例如python和JS中的多个密码学库都严格执行这个标准，但是我们发现golang的一些ECDSA库允许私钥x=0来进行签名和验证计算。 区块链平台的不同版本实现（如golang实现和python实现）通过不一致的结构来执行恶意合约，从而进一步完成双花攻击。

4.5 版本不一致导致双花攻击：

同一个区块链项目往往有不同版本编程语言的多种实现。 不同编程语言的实现，对于这种不一致的执行，也存在着各种可能性。 上面的 ECDSA 就是一个例子。 大整数的算术也是一个常见的例子。 比如在NEO的C#版本和python版本的实现上，央行推动发行央行数字货币势在必行。 系统实验研究》，详细描述了央行数字货币（以下简称“CBDC”）原型系统的实验研究。

与大多数人理解的数字货币不同，央行拟发行的数字货币实际上是一种“数字法币”，本质上还是中心化的。

通俗地说，凡是使用数字技术创造出来的货币，都称为数字货币，例如游戏中的金币、腾讯的Q币等，而加密货币也属于数字货币。 加密货币是指基于区块链技术（密码学、加密算法等）的货币，如比特币、以太坊等。

显然，中央银行没有发行加密货币。 虽然它结合了区块链技术，但它完全由国家控制，不像比特币这样的去中心化货币。

央行为什么要发行数字货币？

一方面，纸币信息技术含量低，安全性低，使用成本高。 另一方面，随着互联网的发展，电子结算方式逐渐成为世界范围内流行的支付方式。 此外，央行发行数字货币，也是为了更好地控制数字货币的流通，规范市场。

中央银行数字货币如何运作？

央行的CBDC发行模式与纸币发行模式相同，是“央行-商业银行”的双元模式。 央行将共同维护数字货币发行流通体系的正常运行。

CBDC的运作分为3层：

（1）以央行和商业银行为主体，涉及央行CBDC的发行、提取和商业银行之间的划转，保证央行货币发行总量不变；

（二）商业银行对个人或企业用户的CBDC存取款，商业银行图书馆和个人或企业数字货币钱包中CBDC的转账；

（3）CBDC在个人或企业用户之间流通，CBDC在个人或企业数字货币钱包之间转移。

简单来说，你只需要按照上图划分的三个区域来理解三层即可。 目前央行原型系统一期主要是解决第一层的问题。

CBDC加密字符串携带了哪些信息？

CBDC 实际上是一串加密的字符串。 理想的CBDC模型包括发行人、发行数量、流通要求、时间限制、智能合约等信息，不可重复、匿名、不可伪造、系统独立。 、安全性、可转移性、可追溯性、可分割性和可编程性。

CBDC 包含最基本的四个要素：数量、数量、所有者和发行人签名。 不可重复的数字代表了 CBDC 的唯一性。

四大基本要素的概念比较容易理解，如何应用应用扩展和可编程脚本呢？

一般而言，可以将新的应用属性添加到应用扩展存储中，例如名称、位置和时间，作为ATTR中的附加属性。 可编程脚本适用于定制化需求比较大的开发者。 商业银行、用户钱包等系统可以对数字货币进行编程，以适应相应的应用场景。 可编程脚本更加灵活。

如何发行、提取和转让CBDC？

CBDC 发行是指中央银行生产 CBDC 并将其发送给商业银行的过程。 发行阶段扣除商业银行存款准备金，等量发行CBDC。 提现过程是指商业银行存入CBDC，央行作废的过程。 商业银行存入CBDC后，等量增加存款准备金。 CBDC的发行和归还流程如下：

（点击查看大图）

传输过程是 CBDC 加密字符串的转换。 它是使源货币（即旧货币）失效并生成目的货币（即新货币）的过程。 CBDC的转账可分为直接转账、合并转账和拆分转账。

如下图所示，直接传输是指CBDC的加密字符串以数据包的形式在发送方（所有者A）和接收方（所有者B）的系统之间传输； 合并转账是指所有者 B 串 2 的 CBDC 和 CBDC 串 3 合并转账生成 CBDC 串 4，数量等于串 2 和串 3 的数量之和。合并转账的源币可以是任何数字； 拆分转账是指所有者C的CBDC字符串4在转账过程中拆分为所有者D对应的CBDC字符串5，CBDC字符串6（转出的金额余额）对应身份的CBDC业主C。

说英语！ 直接转账可以类比为A直接给B发50元纸币，合并转账就是B手上的50元加上一张50元给C，但是C收到的是原来的两张纸币，数量上来说货币，是一个字符串，金额加起来是100元。 分期转账，类似于找零钱，​​C要付给D 80元，D给C找零20元。 在数字货币支付找零的过程中，变成一个字符串，直接给D一个具体的金额，余额可以生成一个新的字符串。

目前央行原型系统一期CBDC转​​账主要是商业银行之间的转账，但未来面向用户终端，转账过程将主要以小额、高频、真实为特征。 - 时间零售业务，这也是未来 CBDC 可以实用的。 性和竞争力的关键。

一种货币，两个仓库，三个中心

论文梳理了央行数字货币体系的核心要素：一币指CBDC，两行指央行发行库和商业银行银行库，包括CBDC用户的数字货币钱包在流通市场； 三中心指认证中心、注册中心和大数据分析中心。 目前，原型系统一期建设不涉及数字货币钱包和大数据分析中心。

央行发行数字货币势在必行，专利数量已达86项

除了论文之外，央行数字货币的研发也取得了长足的进步。 莲湖财经从国家知识产权局官网查询专利检索分析。 截至今年7月6日，以中国人民银行数字货币研究所为申请人的公开专利申请共有46件。 此外，中钞信用卡业发展有限公司和中国人民银行分别申请了18项和22项印刷科技研究专利，中央银行管辖的机构申请了一项专利。共有86项与数字货币相关的专利。

（截图来自国家知识产权局专利检索

)

此前，姚前对媒体表示，央行发行法定数字货币的原型方案已经完成两轮修改，未来有望在票据市场等相对封闭的应用场景进行测试，但目前尚无定论。目前尚无明确的推出时间表。

然而，正如论文开篇所指出的，数字货币被视为货币形态的又一次重大革命，有望成为数字经济时代的主流货币和重要的金融基础设施。 央行推动发行央行数字货币势在必行。