我们关注数据在比特币数据库中的存储方式以及更新此数据库的交易结构。
比特币交易
图1 展示了一个比特币交易。它可以有一个或多个输入,以及一个或多个输出:
- 交易输出:在数据库中创建一行新记录。它与一组币和一个脚本相关联。
- 交易输入:识别数据库中的一行并提供应满足支出脚本的证据。如果有效,数据库中的该行将被删除。
UTXO模型代表未花费交易输出,数据库只是未花费交易输出的列表。
比特币的数据库
图2展示了比特币数据库的列和行:
- ID:创建此数据库条目的交易输出的唯一标识符。它是交易哈希和输出编号的连接。
- 脚本(script):一个类似Forth的脚本,必须满足才能花费这些币。
- 币(coin):与此数据库条目相关联的比特币(BTC)数量。
在本文撰写时(2022年 3 月),大约有 ~7900万行数据库记录,每行都与一组币相关联。
更新数据库
图3展示了一个比特币交易如何处理以检查其有效性并更新数据库的示例。关键点:
- 数字签名:所有有意义的脚本都需要用户的数字签名。
- 输出可以有不同的脚本:币可以在同一交易中发送给一个或多个方。
- 币可以在输出之间拆分:币可以在交易中拆分和组合。
- 发送者可能需要一个“找零”输出:所有输入的币总和必须在此交易中花费。如果输入的币超过签名者想要花费的数量,那么他们需要将剩余的币返回到他们控制的脚本中。
- 交易费是隐含的:我们的示例奖励区块生产者0.2 BTC,读者可以自行计算如何实现。
- UTXO管理:与账户系统不同,用户可能有一个或多个未花费交易输出(每次收到付款都会创建一个新的UTXO)。
比特币交易可以被视为一个脚本环境。没有有状态的账户系统或共享状态。交易只是消耗脚本并生成新脚本。用户可能有多个他们控制的脚本,脚本与数据库中的币相关联。
UTXO模型有一些特点:
- 比特币地址标准:比特币地址是脚本的哈希。为网络上的用户引入一个新的标准脚本会导致一种新的比特币地址样式。这导致了钱包恢复问题,因为用户不了解地址类型的细微差别以及他们的钱包软件支持什么。
- 币选择算法:用户将拥有一个或多个币(uxto)集合。是他们的软件决定在向另一个用户发送资金时花费哪些币。如果不小心,策略可能会泄露用户在网络上的隐私。你可以在这里了解更多。
- 调和UTXO权衡:只有当网络费用不超过其价值时,UTXO才能被花费。如果用户不小心,他们可能会遇到与Coinbase相同的问题,Coinbase有265个比特币分布在150万个UTXO中,但花费它们已不再经济。这引发了一个问题:这是Coinbase的错误(技术无能)还是UTXO模型的错误?
- 并行执行:UTXO不在共享状态上执行,可以独立执行交易的所有输入。
实际中脚本是什么样的?
图4: “支付到公钥哈希”(P2PKH)交易的执行记录。
比特币脚本是一种类似Forth的脚本语言。随着脚本的进展,构建并执行一个小的内存栈。栈上的最终项应为true,以使最终执行被认为是有效的。
图4提供了“支付到公钥哈希”脚本的示例。它要求公钥的所有者提供数字签名以领取他们的币。完整的脚本有两个部分:
- Redeem 赎回脚本(输入): 满足UTXO脚本的证据。
- 支出脚本(先前输出): 据库中的币相关联的脚本。
输入脚本在未花费交易输出中存储的脚本之前运行。在示例脚本中,输入用签名和公钥填充栈。输出脚本检查栈中的公钥是否与所有者的公钥匹配。如果匹配,它将验证所有者的签名。
这引发了一些我们留作作业的问题:
- 如果哈希已经存储在UTXO中,为什么输入需要有公钥的副本?
- 为什么UTXO存储的是公钥的哈希而不是公钥?
- 是否可以在交易的输入中揭示整个支出条件脚本?
希望你喜欢对UTXO模型的基本介绍。我们不会在课程中尝试实现比特币脚本,因为没有真正好的工具来实现它。
有一个有趣的笑话是开发者在比特币脚本中只有基本工具:
- 验证签名
- 验证哈希的前映像(pre-image)
- If语句
- 在时间T之前或之后执行操作
没有循环,脚本语言非常受限。社区的理念是将计算移到链下。但即使有这些基本工具,你仍然可以实现像闪电网络这样的东西。
我建议阅读隔离见证、Taproot和潜在的契约升级。
我是 AI 翻译官,为大家转译优秀英文文章,如有翻译不通的地方,在这里修改,还请包涵~
-
翻译
- 学分: 94
- 分类: 比特币
- 标签:
UTXO