一、先明确讨论范围
区块链量化交易技术涉及哪些技术概念，可以先从程序如何获取和理解链上数据入手。这里讨论数据接入与验证基础，不延伸到模型效果或具体策略。以太坊与比特币采用不同的数据组织方式，不能把一种网络的接口和交易规则直接套用到另一种网络。
二、节点与远程调用接口
以太坊应用通过节点读取链上信息或提交交易。JSON-RPC 是使用 JSON 表达数据的无状态远程调用协议，开发库可以对这些调用进行封装。执行客户端接口、共识客户端接口和客户端之间的 Engine API 服务于不同用途。
对数据系统而言，接口连接成功只是接入条件，不代表数据已经完整或及时。节点同步状态、客户端支持的方法以及请求错误，都属于需要单独识别的技术问题。
三、状态、历史与查询时点
余额、合约存储属于状态数据，区块和交易回执属于历史记录。以太坊部分状态查询可以指定区块高度，或使用 latest、safe、finalized、pending 等标签。数量与字节数据虽然都可以采用十六进制表示，编码规则却不相同。
适用条件是先明确分析需要哪个时点的数据。比较不同记录时，若一项来自指定区块，另一项来自待处理状态，就可能混入不同时间口径。字段外观相似也不代表含义相同，解析时仍需区分数值和原始字节。
四、UTXO、哈希与共识
比特币以未花费交易输出，即 UTXO，组织可供后续交易使用的资金。区块通过前一区块头的哈希连接，默克尔树用于组织交易哈希。全节点按共识规则验证区块，工作量证明参与链的选择；发生分叉时，同一高度可能对应多个区块。
因此，资金记录不能一概理解为账户余额变化，区块高度也不能充当全局唯一标识。整理历史数据时，需要保留区块哈希及其关联关系，才能区分高度相同但归属不同分支的记录。
五、常见问题与适用边界
拿到交易记录是否意味着结果已经稳定？不能仅凭记录可见就作判断，还需要区分待处理、已进入区块及相应确认状态。取得默克尔包含证明，也不等于完成了对整条链所有规则的验证。
这些概念解决的是数据来自哪里、怎样解释以及如何判断其链上归属。接口可用、编码正确或历史记录可验证，都不能直接证明量化模型有效，更不能推导未来表现。