6.6 比特币地址、余额和其他抽象

6.6 比特币地址、余额和其他抽象

我们在本章开头发现，交易的“幕后”看起来与钱包、区块链浏览器和其他面向用户的应用程序中呈现的非常不同。前几章中的许多简单而熟悉的概念，例如比特币地址和余额，似乎并没有出现在交易结构中。我们看到交易本身不包含比特币地址，而是通过一个脚本来操作，该脚本锁定和解锁离散的比特币值。余额也不存在于系统中的任何地方，但每个钱包应用程序都会明确显示用户钱包的余额。

现在我们已经探索了比特币交易中实际包含的内容比特币账户余额截图，我们可以研究如何从交易的看似原始的组件中派生出更高级别的抽象。

让我们再看一下 Alice 在普通区块浏览器中呈现的交易（下图 6-8）：

图 6-8 Alice 与 Bob's Cafe 的交易

在交易的左侧，区块链浏览器将 Alice 的比特币地址显示为“发送者”。事实上，这些信息本身并不在交易中。当区块链浏览器检索交易时，它还会检索输入中引用的先前交易，并从该旧交易中提取第一个输出。在该输出中是一个锁定脚本，它将 UTXO 锁定到 Alice 的公钥哈希（P2PKH 脚本）。区块链浏览器提取公钥哈希并使用 Base58Check 编码对其进行编码，以生成和显示代表该公钥的比特币地址。

同样，在右侧，区块链浏览器显示了两个输出：第一个输出到 Bob 的比特币地址，第二个输出到 Alice 的比特币地址（作为零钱）。为了创建这些比特币地址，区块链浏览器再次从每个输出中提取锁定脚本，将其标识为 P2PKH 脚本，从中提取公钥哈希。最后，区块链浏览器使用 Base58Check 重新编码公钥哈希，生成并显示比特币地址。

如果点击 Bob 的比特币地址，区块链浏览器会显示 Bob 的比特币地址余额，如下图 6-9 所示：

图 6-9 Bob 的比特币地址余额

区块链浏览器显示 Bob 的比特币地址的余额。但比特币系统中并没有“平衡”的概念。这里显示的余额实际上是由区块链浏览器构建的，如下所示：

为了构建“总收入”数量，区块链浏览器首先解码比特币地址的 Base58Check 编码，检索编码在地址中的 Bob 公钥的 160 位哈希。然后，区块链浏览器使用包含 Bob 公钥哈希的 P2PKH 锁定脚本搜索交易数据库以查找输出。通过聚合所有输出的值，区块链浏览器得出总接收量。

构建当前余额（显示为“最终余额”）需要更多工作。区块链浏览器维护一个单独的数据库，即 UTXO 集，其中包含当前未使用的输出。为了维护这个数据库，区块链浏览器必须实时监控比特币网络中未确认的交易，添加新创建的 UTXO 并删除已使用的 UTXO。这是一个复杂的过程，它依赖于在交易传播时跟踪交易，以及与比特币网络保持共识以确保遵循正确的主链。区块链浏览器有时也无法保持同步，导致它们对 UTXO 集的跟踪扫描不完整或不正确。

从 UTXO 集合中，区块链浏览器汇总所有引用 Bob 的公钥哈希的未使用输出的数量，以得出显示给用户的“最终余额”值。

要生成这张图片，要获得这两个“余额”，区块链浏览器必须索引和搜索十、数百甚至数十万笔交易。

总之，钱包应用程序、区块链浏览器和其他比特币用户界面呈现给用户的信息通常由更高级别的抽象组成，这些抽象源自对许多不同交易的搜索、检查其内容以及操纵其中包含的内容。从数据中得出。通过呈现比特币交易的这种简单视图（类似于从一个发送者到一个接收者的银行支票）比特币账户余额截图，这些应用程序必须抽象出许多底层细节。他们主要关注常见的交易类型：每个输入都带有 SIGHASH_ALL 签名的 P2PKH 交易。因此，虽然比特币应用程序以易于阅读的格式呈现所有交易的 80% 以上，但它有时会受到偏离规范的交易的困扰。对于包含更复杂锁定脚本的事务，

每天有数百笔不包含 P2PKH 输出的交易在区块链上得到确认。区块链浏览器经常给他们一个红色警告信息，地址无法被解码。以下链接包含最近无法完全解码的“奇怪交易”：

正如我们将在下一章中看到的，这些不一定是奇怪的交易。它们是包含比普通 P2PKH 更复杂的锁定脚本的事务。接下来我们将学习如何解码和理解更复杂的脚本及其支持的应用程序。