地址监控的基本含义
区块链监控地址，是持续读取某个区块链网络中的公开数据，观察与特定地址相关的余额、交易或状态变化。监控程序通常需要连接节点，节点负责提供区块、交易和链上状态等数据。应用可以直接调用节点接口，也可以通过封装接口的开发库发起请求。
“地址发生变化”需要结合具体链的记账方式理解。以太坊查询重点通常是账户余额、交易计数、合约代码和合约存储等状态；比特币则要追踪交易的输入与输出，因为比特币实际在交易之间转移，钱包地址更多是对相关交易输出的组织方式。
节点、RPC与数据分类
以太坊客户端普遍实现JSON-RPC接口，使应用能够用统一的方法向节点请求数据。JSON-RPC是一种无状态、轻量的远程过程调用协议，数据采用JSON表示，并可通过不同传输方式承载。地址监控服务可以据此读取区块高度、账户余额、交易信息和交易收据等内容。
节点数据可以按用途分为三类。Gossip类方法用于了解链头和网络中传播的新交易、新区块；State类方法用于查询当前状态，例如余额、交易计数、合约代码和存储；History类方法用于读取历史区块、交易及交易收据。监控程序需要根据目标选择接口：查看当前余额偏向状态查询，追溯地址活动则需要结合历史区块和交易记录。
查询区块链状态时，区块参数决定读取哪个高度的状态。以太坊相关接口可以使用具体区块号，也可以使用earliest、latest、safe、finalized或pending等标识。不同标识对应的链上视图不同，因此监控结果必须注明读取的是哪一种状态。
以太坊地址监控涉及的概念
在以太坊中，地址监控常见的基础数据包括余额、交易计数、合约代码和合约存储。余额反映某个区块状态下的账户资产数量；交易计数可用于判断账户交易序列的推进情况；合约代码和存储则帮助区分普通账户与具有链上程序状态的账户。
以太坊数据还需要区分执行客户端接口与共识客户端接口。执行相关查询主要面向交易执行和账户状态；共识客户端接口可以提供信标区块、信标状态等共识层信息。监控应用应先确定要观察的是执行层地址活动，还是共识层数据，再选择相应节点和接口。
JSON-RPC中的数量与字节数组都使用十六进制编码，但格式要求不同。数量采用以0x开头的紧凑形式，字节数组、地址、哈希和字节码则按字节使用两位十六进制字符表示。解析这些字段时，不能把数量格式和固定字节数据格式混为一谈。
比特币地址监控涉及的概念
比特币区块链是按顺序排列并带有时间信息的交易公共账本。每个完整节点会保存由自身验证的区块链副本，节点遵循共识规则来判断区块和交易是否有效。监控地址时，数据来源应以已验证的区块和交易为基础。
比特币采用UTXO模型。交易输入引用此前交易产生的输出，尚未被后续交易使用的输出称为未花费交易输出，也就是UTXO。地址余额因此不能简单理解为一个持续更新的账户字段，而需要统计与地址相关、仍处于未花费状态的交易输出。交易输出一旦被使用，就不能再次作为有效输入，否则会构成双重花费。
比特币交易由交易标识符TXID关联，区块则通过区块头哈希与前一区块连接。区块中的交易哈希还会构成默克尔树，并在区块头中留下默克尔根。该结构支持根据区块头和中间哈希验证某笔交易是否被纳入区块。
确认数、分叉与监控边界
看到一笔交易并不等于它已经稳定地写入链上。比特币网络可能在相同高度暂时出现多个区块，节点随后会根据共识规则选择更强的链，较短分支上的区块可能成为过时区块。因此地址监控需要区分待确认交易、已纳入区块的交易，以及在分叉后仍位于当前有效链上的交易。
区块高度可以帮助定位区块，但在出现分叉时，同一高度可能对应多个区块，所以高度不适合作为区块的全球唯一标识。实际记录监控事件时，还应保存区块哈希、交易标识符和相关输出或状态所在的区块信息。
以太坊查询同样要关注链头状态和确认语义。latest、safe、finalized等区块标识代表不同程度的链状态，监控程序不能只保存一个“当前结果”，还应保留查询所依据的区块标识，方便处理状态变化和重复检查。
适用条件与常见问题
这类技术概念适用于需要读取公开链上数据的浏览器、审计工具、资产记录系统和内部监控服务。使用前应明确目标网络、节点接口、数据更新频率、历史范围，以及对待确认交易和链分叉的处理规则。不同客户端可能支持的接口和返回字段有所差异，具体实现仍需以对应客户端文档为准。
常见问题一：只查询余额能否完整监控地址？不能。余额适合反映某个区块状态下的资产数量，但无法单独说明资金来源、流向、交易是否待确认，或比特币某个UTXO是否已经被花费。常见问题二：交易出现在节点返回结果中是否代表最终有效？不一定，还要查看其所在区块及后续链状态。常见问题三：以太坊和比特币能否用同一种余额算法？不能。以太坊侧重账户状态查询，比特币需要从交易输出和UTXO集合推导相关余额。