基础服务解决什么问题
区块链基础服务为应用提供网络连接、数据验证、状态查询和接口访问能力。理解它可以从三个问题入手：数据怎样传来，节点怎样判断其有效，应用怎样读取验证后的结果。这些环节相互关联，但承担不同职责。以下以以太坊与比特币为例，具体实现不能直接套用于所有区块链。
节点、客户端与点对点网络
以太坊节点与客户端文档说明，节点通过运行客户端软件连接网络；执行客户端处理交易执行和状态，共识客户端处理权益证明共识。验证者软件承担额外的共识参与职责。
点对点网络负责让节点交换信息，客户端按协议检查信息。收到一个区块，并不代表已经认可它。客户端多样性则是在遵循相同规范的前提下采用不同实现，有助于降低对单一代码库的依赖。
哈希、默克尔树与共识规则
比特币开发指南介绍，区块通过前一区块头的哈希相连，交易通过默克尔树汇总到区块头；全节点独立验证规则，并在有效分支中选择累计工作量最大的链。
这些机制各有用途：哈希关联数据，默克尔证明用于核对交易是否被某区块收录，共识规则约束哪些记录可以接受。收录证明不能单独替代完整的交易有效性检查；区块高度也可能因分叉而重复，不能作为全局唯一标识。
交易模型与执行环境
比特币使用未花费交易输出，即UTXO，描述可被后续交易使用的输出，规则限制同一输出重复花费。以太坊执行客户端则在EVM中执行交易并维护状态。
因此，基础服务中的“查询数据”需要明确对象：交易记录、未花费输出和账户状态并非同一种数据。应用的数据结构与查询逻辑应匹配所连接区块链的模型。
全节点、归档节点与轻客户端
节点类型影响验证方式和数据保存范围。全节点侧重按规则验证，归档节点保留历史状态，轻客户端依靠较少的数据和证明进行验证。同步方式与数据裁剪也会影响本地可用数据。
适用条件应从查询需求判断：查询较早区块对应的账户状态，与读取当前状态有不同的存储要求。“全节点”不等于随时直接提供所有历史状态；轻客户端的验证能力也需要结合具体协议与实现理解。
访问接口与常见问题
RPC是应用向节点请求数据或提交请求的接口方式。自建节点与第三方节点接口都能支持应用接入，但接口可访问，不代表背后具备相同的验证能力、历史数据范围和服务可用性。
运行节点是否必须成为验证者？不必须，验证数据与参与出块等职责需要区分。自建节点是否意味着信息完全私密？也不是，它可以减少向接口中间方披露查询信息，但不会让公开链上的记录自动变为私密。