写点什么

漫话比特币(一):基于交易的记账系统

  • 2020-11-30
  • 本文字数:6352 字

    阅读完需:约 21 分钟

漫话比特币(一):基于交易的记账系统

自 2008 年中本聪发布比特币白皮书《比特币:一种点对点的电子现金系统》至今已十年有余,弹指一挥间,比特币从技术极客的玩具发展到现如今体量接近 3000 亿美元的抗通胀价值存储,比特币底层依赖的区块链技术更是在各行各业遍地开花。


在这十年间,关于比特币的媒体报道从未停止过,见诸报端的,时而是一夜造富的神话;时而是庞氏骗局、击鼓传花的警告,更有垂直网站在过去十年间无数次地宣告:比特币已死。


那么,比特币到底是什么?它是一种货币吗?它到底是何方神圣、亦或是蛊惑人心的妖孽?溯本清源,要追寻这些问题的答案,咱们还是得从比特币系统的原理说起。如果说熙熙攘攘的数字货币市场是繁华的闹市,那么我们不如退隐山林,做个与世无争的山中居士,静静地翻开比特币的白皮书,沉下心来去了解比特币系统乃至区块链技术是如何工作的。

为此,InfoQ 与 FreeWheel 技术专家吴磊独家合作了系列专栏《漫话比特币》,与各位读者一同探索比特币及区块链技术的奥秘。


在开始之前,咱们先来澄清两个紧密相连而又有所区别的概念:比特币系统与比特币代币。


o  比特币系统(Bitcoin)


o  比特币代币(BTC)


比特币系统,指代的是基于点对点分布式网络、区块链存储、计算机安全等技术实现的去中心化交易系统。比特币代币,是由比特币系统‘发行’、附赠的加密数字货币(CryptoCurrency),大家平时听到的“比特币又涨了!”通常指代的都是比特币代币。在不同的场合与上下文语境中,比特币一词被频繁地交叉引用,时而指代比特币系统,时而指代比特币代币。因此,为了避免概念的混淆,在探讨比特币的过程中,我们对不同的名词与概念的对应关系做如下约定:


o  比特币系统:Bitcoin,比特币,比特币电子现金系统,比特币交易系统


o  比特币代币:BTC


换句话说,在咱们的专栏里,Bitcoin、比特币、比特币系统、比特币交易系统以及比特币电子现金系统指代的都是比特币系统层面的概念;而比特币 Token 或 BTC 指代比特币代币,也就是数字货币市场中带价格属性的 BTC。


言归正传,说起比特币,就不得不提中本聪(Satoshi Nakamoto)的白皮书《比特币:一种点对点的电子现金系统》。


顾名思义,比特币是一种现金系统。说起现金,最容易想到的是生活中的现金与支票。虽然现金与支票听上去有些古老,但在互联网移动支付与刷卡支付流行以前,我们大部分人其实都是用现金进行交易的。比如说,笔者的发小李雷,他去菜市场买十斤西红柿,需要花 13 块钱,这 13 块钱的现金就从李雷的手里流转到了菜市场王老板的手中。随后王老板又从便利店买了盒烟,这 13 块钱又从他的手里流转到便利店李老板的账下。


我们说某人有多少钱,通常是指他‘拥有’多少个单位的法币(如人民币)。比如,大家都说李雷的老爸特别有钱,多有钱呢?他‘拥有’1 亿元人民币。但实际上,法币由国家发行,国家根据经济运行情况适量印发法币,换句话说,国家才拥有法币。


从交易流转的角度来看待现金,我们会发现个人并不拥有现金,而是拥有‘支配若干单位法币’的合法权利,该权利由国家赋予并提供保障。就李雷的老爸来说,他并不拥有那 1 亿元人民币,而是拥有‘支配 1 亿个单位人民币’的合法权利。


换句话说,所谓有钱,本质上是有‘花钱的权利’,这项权利由国家赋予且不可动摇。说回比特币,在比特币现金系统中,赋予你花‘钱’(比特币代币)权利的主体,不是任何一个国家、机构或个人,而是你的公钥和数字签名,至于公钥和数字签名如何做到这一点,咱们稍后再进行展开。


在任何一个现金系统中,都需要一本账簿来记录每一笔现金的流转,俗称记账。之所以要记账,一方面是保证经济社会生活的基本运转,另一方面只有通过记账我们才能知道每个人手里还剩多少钱(Balance),或者说,还有多少钱是有权利花出去的。


记账通常有两种方式,一种是基于账户(AccountBased)的记账方式,另一种则是基于交易(Transaction Based)的记账方式。


基于账户的记账方式很好理解,在现实生活中,银行普遍采用这种记账方式。银行为每一个人设立一个(或多个)账户,账户的形式通常是存折或借记卡。开通账户通常需要详实的个人信息(PII,PersonalIdentifiable Information),如姓名、年龄、身份证号、手机号码等。账户开通后,由存折或借记卡保存余额,银行后台数据库系统则存储该账户收入、支出的每一笔交易明细。基于交易的记账方式则完全不同,在这种记账方式中,彻底抹去了账户的概念。采用基于交易记账的现金系统,只保存交易明细,不存储任何账户或可识别的 PII 信息。比特币的实现采用后者,是一种基于交易的记账系统。


基于账户的记账方式,简单、直接、易懂,生活中大家都是这么记账的,每个家庭对于家庭财务支出的记录,也都自然地采用这种记账方式。比特币采用基于交易的记账方式,目的是什么呢?换句话说,用这样的记账方式,相比基于账户的记账方式,能带来哪些额外的收益呢?


回到比特币的白皮书《比特币:一种点对点的电子现金系统》,首先,比特币是现金系统。在任何一个法币系统中,现金本身是匿名的,现金一直在流转,它不属于任何个人或者团体,现金(法币)归国家所有。


同理,比特币现金系统中的‘现金’也需要具备匿名性,而基于交易的记账方式为比特币现金系统的匿名性提供了良好的设计基础。


再者,从分布式系统实现的角度来看,基于交易的记账系统需要存储和处理的信息量更少。传统的基于账户的记账方式,与账户有关的信息在系统中占据了较大比例的数据存储,每一笔交易的计算与处理,都需要账户信息参与其中。基于交易的记账系统,节省了与账户有关的所有存储和计算,从系统设计角度来看,更加地简单、高效。

比特币交易


 一图胜千言,咱们来直观地了解一下比特币的交易记录,看看基于交易的比特币是如何记账的。在下图中,有 3 条交易记录,分别是 tx-00825,tx-00901 和 tx-00963。仔细观察每一条交易记录,发现它们和现实生活中的支票及其相似,都记录着资金从贷方到借方的流转。咱们来逐条地讲解这些交易记录,来看看这些交易记录如何帮助比特币系统记账。



示意图:比特币系统中的 3 条交易记录


o  tx-00825 :交易记录主要由两部分信息构成,即贷方信息(出款人)和借方信息(收款人)。与支票不同,比特币交易记录中的贷方不是姓名,也不是银行账户,而是数字签名。


在 tx-00825 中,李雷将 1 个单位的比特币代币转账给韩梅梅,他必须用私钥提供数字签名,才能行使支付的权利,从而完成转账。再来看借方,同样,借方不是韩梅梅的姓名,也不是她的银行账户,而是她的公钥。tx-00825 很好地诠释了基于交易的记账方式,在交易记录中,关于贷方与借方,没有关于他们的任何个人敏感信息(PII,PersonalIdentifiable Information),如姓名、性别、账户、身份、职业、职位、住址、婚否等,与贷方有关的唯一信息是其数字签名,与借方有关的唯一信息是其公钥。


在比特币系统中,贷方的术语叫作交易输入(TransactionInput),借方的术语称为交易输出(Transaction Output),从交易记录的数据结构来看,贷方的放款明细是输入数据,而借方的收款明细是输出数据。交易记录术语与借贷的类比如下表。


生活类比

比特币交易

贷方(出款人)

交易输入(Transaction input)

借方(收款人)

交易输出(Transaction output)

交易的生活化类比


o  tx-00901:tx-00901 与上一个交易有着明显的不同,在借方部分,我们发现有多个借款人,对于 1.8 个单位的比特币代币,笔者把 0.5 个比特币代币转账给韩梅梅,剩余的 1.3 个单位‘找零’给自己。大家也许会好奇,比特币代币数额怎么出现了小数?在这里,我们需要说明一下比特币代币的单位,比特币代币的常用度量单位是 BTC,1 个 BTC 代表一个单位的比特币代币。


不过,比特币代币的最小度量单位并不是 BTC,而是‘聪’(Satoshi),‘聪’与 BTC 的换算关系是:1BTC = 100,000,000 Satoshi,也即 1 个 BTC 等于 1 亿个‘聪’,因此比特币代币以 BTC 为单位出现小数数额也就不足为怪了。值得注意的是,在一个交易记录中,每个借方都标有交易序号,该序号从零开始编号,根据借方的个数自动增加,如找零的交易序号是 0,转账给韩梅梅的交易序号是 1,假如还有第三个借方,那么它的交易序号就是 2,以此类推。


o  tx-00963:在 tx-00963 中,我们又发现了新的不同——贷方也可以有多个。在这个交易中,韩梅梅想转账 1.2 个 BTC 给中本聪,不过她兜儿里只有两份比特币代币,一份面额是 1BTC,另一份面额是 0.5BTC,需要凑在一起才有支付 1.2BTC 的权利。这与我们去菜市场买菜没什么两样,假设西红柿的价钱是 1.3 元/斤,我们兜里只有面额 5 元和 1 元的纸币,那么自然需要拿两张 5 元和三张 1 元凑数来购买十斤西红柿。需要注意的是,韩梅梅的代币来自之前的交易 tx-00825 和 tx-00901。


在贷方信息中,韩梅梅的 1 个 BTC 来源于 tx-00825 中序号为 0 的交易输出,也就是李雷转给她的 1 个 BTC;而 0.5 个 BTC 来源于 tx-00901 中序号为 1 的交易输出。tx-00963 再一次诠释了基于交易的记账方式,韩梅梅的比特币代币余额(Balance),并不是记录在某个账户中,而是存储在一个又一个这样的交易输出中,只要交易输出印有她的公钥,她就拥有支配的权利。韩梅梅的比特币代币余额,是通过汇总计算所有这些交易输出中的比特币代币数额得到的。


这样的交易输出在比特币中有个专门的术语,叫作 UTXO(UnspentTransaction Output,未花费的交易输出),在 tx-00963 中,韩梅梅花费的是属于她的两个 UTXO。UTXO 的字面翻译‘未花费的交易输出’比较拗口,叫作‘现金的支配权利’也许更直观一些。


在 tx-00963 中,韩梅梅消费了两个 UTXO,一个面额是 1BTC,另一个是 0.5BTC,加起来总共 1.5BTC,她有消费这 1.5 个 BTC 的权利,因为这两个 UTXO 都记录有她的公钥信息。对于任何一条交易记录,在交易输入部分需要提供 UTXO 标识来识别和定位不同的 UTXO,不过,UXTO 本身并没有 ID,它的标识由交易 ID+ 交易编号构成。所以我们看到,在贷方信息中,不仅需要指定交易来源(交易 ID),还需要指定交易序号,通过这两者唯一地确定一个 UTXO。


现实生活中,我们花 13 元钱购买十斤西红柿,那么这 13 元钱的‘支配权利’就流转给了菜市场王老板。对于这 13 元钱,我们已经用它交换了十斤西红柿,因此也就不再享有支配的权利。在比特币中也是一样,对于韩梅梅的两个 UTXO:tx-00825/交易序号 0 和 tx-00901/交易序号 1,在 tx-00963 中,她将 1.2BTC 转账给中本聪,自己找零 0.3BTC。


那么,韩梅梅对于已经花出去的 BTC 自然不再有支配权,也就是说,tx-00825 中交易编号为 0 的交易输出和 tx-00901 中交易编号为 1 的交易输出,此时都从 UTXO(未花费的交易输出)转变为‘已花费的交易输出’。之所以区别 UTXO 与‘已花费的交易输出’,是因为在统计每个人的比特币代币余额时,只有 UTXO 才纳入计算,道理很简单,印有你的公钥且还未行使支付权利的‘现金’,才是真正属于你的。

房间的类比

对于基于交易的记账系统这个新概念,理解起来确实比较困难。用生活化的例子来类比,理解起来也许会更轻松一些。让我们把比特币的每一笔交易记录想象成一个房间,那么自然,每个房间都有一个房间号。每个房间都有 3 种类型的门:


o  房门入口:付款人的数字签名


o  打开的房门出口:收款人的公钥


o  封闭的房门出口:收款人的公钥



比特币交易记录与房间的类比


对应于比特币交易记录中的转账,实际上就是把比特币代币从一个房间的出口‘搬运’到另一个房间的出口,当然,把‘钱’从一个房间挪到另一个房间,自然要从下一个房间的入口进去。例如,对于交易 tx-00901 中的转账,就是把房间-00015 出口的比特币代币‘搬运’到房间-00901 的两个房门出口。


注意房间-00901 的两个房门出口,上面的是封闭的,下面的是打开的,下面的这个房门出口的比特币代币又被搬运到别的房间了(房间-00963)。


基于交易的记账系统,看上去酷似数据结构中的‘树’(Tree)。每一笔交易的来源,都来自之前交易的 UTXO 或是其组合,上一笔交易的 UTXO 与下一笔交易的 TransactionInput 之间通过公钥与数字签名链接起来,前后两笔交易之间存在‘父子’关系;交易与交易之间通过这种不断衍生的方式构筑了一个类似于‘树’的结构。


在这棵‘树’中,UTXO 是树中的叶子节点(封闭的房门出口),一旦 UTXO 被花费(打开的房门出口),即在新的交易中被当作交易输入,那么该 UTXO 自然不再是叶子节点,新交易中的交易输出取而代之成为新的叶子节点。


因此从数据结构的角度来看,只有交易‘树’的叶子节点才具备‘支付的权利’。在房间的例子中,只有封闭的房门出口,才有打开的机会、才具有‘支付的权利’;说出去的话,泼出去的水,已经打开的房门出口都是‘花出去的钱’。

UTXO Set

对于任何一个记账系统来说,计算余额都是其重要的核心功能之一。


从比特币交易记录的构成中我们不难发现,在比特币基于交易的记账系统中,余额的计算就是对不同公钥下的 UTXO 进行汇总,一把公钥对应一个主人,而这把公钥下 UTXO 的总额就是这个人的比特币代币余额(的一部分)。


之所以说是余额的一部分,原因很简单,一个人可能同时持有多把公钥,严格来说,这个人的比特币代币余额是所有这些公钥下 UTXO 的总和。


在比特币中,寻找 UTXO 的过程相当于是从每颗‘树’结构的根节点一直遍历至所有叶子节点,访问效率可想而知。在通过 UTXO 汇总计算比特币代币余额时,如果每次都需要这样的遍历过程,那么计算成本实在是太高了。


为了解决这个问题,比特币系统采用 UTXOSet(UTXO 内存缓存)来持续更新、维护所有的 UTXO,从而避免每次都需要从头开始遍历交易历史。当有新的交易请求时,比特币系统只需要查找这个缓存在内存中的 UTXO 集合,就可以判断这笔交易的交易输入是否‘合法’、有效;在新交易执行完毕后,比特币系统再次更新 UTXO 集合,本次交易 TransactionInput 中的 UTXO 会从该集合中剔除,而本次交易产生的新的 UTXO 会被录入到 UTXO 集合中。



管家遍历一次房间并用小本本记录房间号+UTXO 出口号


回到房间的类比中,要想找出哪些出口是 UTXO,哪些出口是‘已经花出去的钱’,很显然,房间的管家(Housekeeper)需要一间挨一间地去查看每一个房间,然后记录下来有封闭出口的房间号和 UTXO 出口位置。


虽然我们还不清楚比特币系统到目前为止交易记录的总量具体是多少,不过根据比特币诞生于 2008 年、每秒处理 7 个交易来看,这样的‘房间’数量一定是相当惊人的。如果每次需要查询 UTXO 时,这位管家都是从头至尾搜索所有的房间,那么这位老兄要么是太闲,要么就是脑袋瓜不够机灵。


聪明的管家自然是在第一次遍历所有房间的同时,就拿一个小本本边检查边记录下相应的房间号和 UTXO 出口位置。当有新的房间出现时,也就是比特币系统中有新的转账交易,管家只要拿着他的小本本去搜索就好了。这个小本本,就是 UTXOSet。

Postscript

本篇是《漫话比特币》科普系列的第一篇,该科普系列面向所有具备计算机基础知识的读者,尽可能地采用生活化类比和示例来帮助读者更好地理解、消化技术内幕中涉及的关键知识点,如哈希算法、非对称加密、交易的结构、区块链的构成,等等。


为了让读者能够专注于比特币系统的整体实现,本系列隐去了一些技术细节,如哈希算法的工作流程、椭圆曲线加密的工作原理等,更多地从每一个技术点的特性、特点、用途出发,逐渐勾勒出比特币系统的全貌。笔者学浅才疏、疏漏难免,还请广大读者朋友批评、指正,更欢迎您一起参与探讨比特币、区块链的相关话题。


在本篇中,我们首先介绍了基于账户的记账系统与基于交易的记账系统之间的区别,随后以 3 个比特币交易记录为例展开讲解比特币如何通过交易进行记账,并通过房间的生活化类比进一步解释,最后简单提及了用于快速计算余额的 UTXOSet。


不难发现,在比特币现金系统中能否成功转账的关键在于 UTXO 中的公钥与 Transaction Input 中的数字签名是否匹配,毕竟,在比特币系统中‘支付的权利’由配对的公钥与数字签名赋予。那么问题来了,什么是公钥?什么是数字签名?非对称加密是什么黑魔法?哪些特性让非对称加密技术能强大到‘赋予’人们‘支付的权利’?关于这些问题的答案,我们将在下一期《漫话比特币—— 信息安全中的黑科技》一一揭晓,敬请期待。

2020-11-30 09:153222

评论 3 条评论

发布
用户头像
本来挺通俗的概念,让你解释的…… 呵呵
2021-03-18 14:36
回复
用户头像
看似一本正经, 但有些概念好像说的不太对
2021-01-06 11:22
回复
用户头像
能把 BTC 说称是代币,也是不容易
2020-11-30 17:33
回复
没有更多了
发现更多内容

火山引擎DataTester推出可视化数据集成方案

字节跳动数据平台

数据集成 ab测试 A/B 测试 可视化开发 企业号 3 月 PK 榜

吐血整理!互联网大厂最常见的1120道Java面试题(带答案)整理

架构师之道

Java 面试

Nautilus Chain 首个生态基础设施 Poseiswap,公布空投规则

威廉META

Nautilus Chain 首个生态基础设施 Poseiswap,公布空投规则

鳄鱼视界

互联网工程师1480道Java面试题及答案整理( 2023年 整理版)

Java你猿哥

Java 面试 面经 春招 Java八股文

聊聊不太符合常规思维的动态规划算法

华为云开发者联盟

人工智能 华为云 华为云开发者联盟 企业号 3 月 PK 榜

Mac版cad2024发布 AutoCAD 2024 注册机

Rose

Mac软件 cad cad2024激活版 Autodesk AutoCAD

警惕看不见的重试机制:为什么使用RPC必须考虑幂等性

做梦都在改BUG

开源即巅峰!《Java程序性能优化实战》GitHub三小时标星已超34k

做梦都在改BUG

Java 性能优化 性能调优

夜莺n9e监控配置支持电话短信报警

外滩运维专家

夜莺监控 电话报警 短信报警 夜莺监控电话

面试必问:JVM 如何确定死亡对象?

做梦都在改BUG

Java 面试 JVM

SQL Chat - 基于 ChatGPT 的对话式交互 SQL 客户端

Bytebase

sql database ChatGPT

Vue+Spring-Security前后端分离登录实现

做梦都在改BUG

阿里P7架构师的独家分享——SpringCloud 微服务实战笔记

Java你猿哥

Java 架构 微服务 Spring Boot 面经

MobTech 秒验|防控羊毛党

MobTech袤博科技

DaVinci Resolve Studio 18(达芬奇调色剪辑)中文版

Rose

达芬奇18破解版

MobTech MobLink|场景分享的原理

MobTech袤博科技

解密COUNT(*)与COUNT(1):SQL查询你选哪个更高效?

Java你猿哥

Java sql 后端 ssm Java工程师

灵魂拷问:你写的SQL一般有几个JOIN ?​

Java你猿哥

Java sql 后端 ssm join

裸辞跳槽底气!字节在职大佬“Java面试总汇2023”大厂都在考

Java你猿哥

Java 面试 ssm 面经 Java工程师

视频下载出来为网页格式?如何将视频转换为mp4格式?

Rose

视频格式转换 Mac视频格式转换 视频下载出来为网页

龙蜥白皮书精选:面向异构计算的加速器 SDK

OpenAnolis小助手

开源 sdk 异构计算 加速器 龙蜥白皮书

连接 AI,NebulaGraph Python ORM 项目 Carina 简化 Web 开发

NebulaGraph

Python ORM 图数据库

Github上获赞59.8K的面试神技—1658页《Java面试突击核心讲》

Java你猿哥

Java 架构 面试 面经 春招

无人机巡检场景小目标检测与量化加速部署方案详解

飞桨PaddlePaddle

人工智能 无人机 目标检测 飞桨 PaddlePaddle

玩转 ChatGPT+极狐GitLab|分分钟丝滑迁移Jenkins到极狐GitLab CI

极狐GitLab

ci DevOps jenkins CI/CD 极狐GitLab

如何使用责任链默认优雅地进行参数校验?

做梦都在改BUG

工作10年,面试超过300人想进阿里的同学,总结出的java面试69题

三十而立

Java java面试

苹果发布macOS Ventura 13.3正式版更新

Rose

mac系统 苹果最新系统 macOS Ventura 13.3

mac电脑能恢复安卓手机丢失的数据吗?

Rose

mac电脑 安卓数据恢复

GitHub上架即巅峰!《Spring Cloud微服务架构实战》标星已超30k

做梦都在改BUG

Java 架构 微服务 Spring Cloud

漫话比特币(一):基于交易的记账系统_区块链_吴磊_InfoQ精选文章