第一层第一篇。很多人一开始就学 Solidity，但真正的高手计算机基础扎实。 本篇不讲"如何用"，讲为什么这些东西存在、不懂会在套利机器人上踩什么坑。 结构对齐 notes/README.md §1 的写作规范：一句话本质 → 怎么产生的 → 核心关键点 → 前置名词 → 完整过程走一遍 → 常见误区 → 与套利实践对应 → 自检。

0. 一句话本质

钱包 → RPC → 节点 → 区块链，这条链路的每一跳都可能是你机器人失败的地方。 网络协议决定"消息怎么可靠地跑过去"，Linux 决定"机器人怎么 7×24 小时不崩着跑"， Git 决定"你的策略改坏了能不能退回去"。三者都不是"选修"，是套利系统的地基。

1. 网络：为什么钱包调用链路会失败

1.1 完整链路 

Wallet（你的私钥签名）
   ↓ 发送已签名交易
RPC（Remote Procedure Call，你和节点对话的协议）
   ↓
Node（全节点/轻节点，维护链上状态）
   ↓
Blockchain（P2P 网络最终把交易打包进区块）

以后学 LayerZero、Wormhole 这类跨链协议，本质上也是"RPC 通信 + 消息传递"的变体—— 理解这条基础链路，就理解了后面所有"协议"的骨架。

1.2 核心协议逐个讲清楚

协议 是什么 套利视角为什么重要
TCP/IP 传输层保证字节流可靠、有序到达 RPC/HTTP/WebSocket 全部跑在 TCP 之上；TCP 握手 + 重传本身有延迟，这是"为什么同城机房比跨国延迟低"的物理原因
HTTP 请求-响应模型，每次调用都要新建/复用连接、带完整 header 传统 eth_call 大多走 HTTP；慢在于它是"一问一答"，每次都有 TCP+TLS 握手开销（若不复用连接）
HTTPS HTTP + TLS 加密 节点服务商（Alchemy/Infura/QuickNode）强制 HTTPS，握手比 HTTP 多一轮 RTT，但保证 API Key 不被中间人窃取
WebSocket 一次握手后建立持久双向连接，服务端可主动推送 订阅新区块/新交易（eth_subscribe）必须用 WebSocket；HTTP 只能你去"问"，WebSocket 是节点"主动通知你"——这就是延迟差的根源
RPC "像调用本地函数一样调用远程服务"的统称模式 以太坊的 JSON-RPC 就是这一模式的具体实现
JSON-RPC 用 JSON 编码请求/响应的 RPC 规范，以太坊节点对外暴露的标准接口（eth_call、eth_sendRawTransaction、eth_getBlockByNumber…） 你的机器人唯一和链交互的方式就是拼 JSON-RPC 请求；读懂它的 error code（如 -32000 execution reverted）是排障第一步
GraphQL 客户端指定要哪些字段的查询语言 The Graph 等链上数据索引服务用它；比起自己维护全节点索引事件，GraphQL 子图能大幅降低你自建数据管道的成本

1.3 必须搞懂的三个"为什么"

为什么 RPC 会失败？

  • 节点侧限流（免费 RPC 通常有 QPS 上限，超了直接 429）
  • 节点没同步到最新区块（eth_blockNumber 落后主网，导致你的模拟基于旧状态）
  • 网络抖动/超时（TCP 连接中断，需要重试 + 指数退避，而不是死等）
  • 内存池节点看到的 pending tx ≠ 别的节点看到的（mempool 本身是"局部视图"，见 notes/14-mempool与PBS.md）

为什么 WebSocket 延迟更低？

  • HTTP 轮询：你每隔 N 毫秒问一次"有新块吗" → 有效信息之外全是无效往返
  • WebSocket：节点有新块主动推给你，没有轮询间隔，理论延迟 = 节点广播延迟，不受你的轮询频率限制
  • 套利场景：抢跑/backrun 需要"新交易一进 mempool 立刻反应"，轮询 HTTP 会让你系统性慢好几百毫秒——这几百毫秒往往就是抢跑者和你的差距

为什么 HTTP 慢？

  • 短连接：每次请求可能新建 TCP+TLS（虽可用 keep-alive 缓解，但仍是请求-响应模式，无法"被动接收"）
  • 请求排队：多数免费 RPC 对单连接有并发限制，批量调用会互相排队
  • 结论：热路径（价格监听、mempool 监听）用 WebSocket；冷路径（历史查询、偶发调用）用 HTTP 足够

2. Linux：机器人 7×24 小时运行的操作系统层

套利机器人不是"写完跑一次就结束"的脚本，是要在服务器上不间断运行、自愈、留痕的进程。 这一节的价值不是"记住命令"，是理解每个工具解决的具体运维问题。

工具 解决什么问题
ssh 远程登录服务器的加密通道（基于 §2 密码学的 RSA/Ed25519 密钥对）
tmux / screen 让一个终端会话在你断开 SSH 后继续运行——不然你一关电脑，机器人就被杀了
systemctl 把你的脚本注册成系统服务，崩溃自动重启（Restart=always），开机自启
journalctl 查看 systemctl 管理进程的日志——机器人半夜崩了，早上起来第一件事就是看这个
crontab 定时任务（比如每天固定时间做一次余额对账、清理旧日志）
docker / docker compose 把机器人 + 依赖打包成镜像，"在我电脑上能跑"变成"在任何服务器上都一样跑"；多个机器人（不同链、不同策略）用 compose 编排
top / htop 实时看 CPU/内存占用——机器人内存泄漏（比如 mempool 缓存没清）会先在这里发现
iotop 看磁盘 I/O——日志写太猛、本地数据库频繁刷盘会在这里暴露
netstat / lsof 看端口占用、看某个进程打开了哪些文件/连接——排查"RPC 连接为什么没释放"必备

2.1 为什么这些不是"可选技能"

一个真实场景：你的套利机器人凌晨 3 点因为一次未捕获异常崩溃了。

  • 没有 systemctl + Restart=always：机器人从 3 点到你 9 点起床，6 小时空转，机会全丢。
  • 没有 journalctl：你不知道它是几点崩的、崩溃前最后打印了什么，只能盲猜。
  • 没有 tmux：你甚至可能一开始就没让它脱离终端跑，SSH 一断连它就没了。

这就是为什么"Linux 部署"排在 Solidity 之前——代码写得再对，运维层面崩了，利润是 0。

3. Git：策略版本管理

套利策略会不断迭代（调整滑点容忍度、换路径搜索算法、修风控参数）。没有版本管理：

  • 一次"手滑"改坏了风控阈值，可能直接爆仓，且不知道改动前的版本是什么。
  • 多个策略并行开发，不用分支管理，代码互相覆盖。
Git 操作 套利场景对应
branch 每个策略/每次实验开一个分支，不污染主干（跑生产环境的那份代码）
merge 实验验证有效后，合并回生产分支
rebase 保持提交历史线性，方便回溯"哪次改动导致了哪次利润变化"
stash 生产环境紧急修 bug 时，先把手头没提交完的实验代码暂存
tag 给"上线并跑赚钱了的版本"打标签，出问题能秒级回滚到已验证版本

策略版本 = 生产事故responders 的救命稻草：出问题第一反应应该是 git log + git diff， 而不是回忆"我昨天改了什么"。

4. 完整过程走一遍：一次 eth_call 到底发生了什么

  1. 你的机器人（Wallet 层）构造一个 JSON-RPC 请求 {"method":"eth_call","params":[...]}。
  2. 通过 HTTPS（或 WebSocket）经 TCP 连接发到 RPC 节点服务商的负载均衡器。
  3. 负载均衡把请求路由到某台真实全节点。
  4. 节点在本地状态（Storage，见 03-EVM原理.md）上模拟执行这次调用，不落块、不花 gas。
  5. 返回结果（或 revert 错误）沿原路返回。
  6. 全程可能经历：DNS 解析、TCP 握手、TLS 握手、节点排队、节点执行、序列化返回—— 任何一环延迟都会让你的报价"看起来对，实际已经过期"。

这就是为什么专业团队会自建节点（消除节点服务商排队 + 就近部署降低物理延迟）， 这也是本模块与 notes/05-节点与网络.md"为什么自建节点是壁垒"的呼应点。

5. 前置名词小词典

  • QPS：Queries Per Second，每秒请求数，RPC 服务商限流的核心指标。
  • RTT：Round-Trip Time，一来一回的网络延迟。
  • 负载均衡（Load Balancer）：把请求分发到多台后端节点的中间层。
  • 守护进程（Daemon）：在后台运行、不依赖终端会话的进程，systemctl 管理的就是这类。
  • 幂等（Idempotent）：同一操作重复执行结果不变；网络重试必须建立在"这个 RPC 调用是幂等的"这一前提上，否则重试会导致重复发送交易。

6. 常见误区

  • ❌ "RPC 报错就是我代码写错了" → 很多时候是节点限流/延迟/未同步，先看 error code 再排查代码。
  • ❌ "用免费公共 RPC 也能跑套利" → 免费 RPC 排队 + 延迟，专业竞争对手都是自建节点或付费低延迟节点。
  • ❌ "机器人跑在我笔记本上就行" → 笔记本合盖、断网、重启都会让机器人停摆，必须上服务器 + systemctl。
  • ❌ "Git 只是用来备份代码" → Git 真正的价值是可回溯性，尤其在生产事故复盘时。

7. 与套利实践的对应 / 自检问题

对应：本模块是 11-量化套利系统.md 中"RPC 集群""事件监听"两个组件的前置知识； 也是 12-系统架构设计.md 底层"RPC Cluster""Executor 7×24 运行"的基础设施依赖。

自检（答不出就先别学模块 ②）：

  1. 为什么监听 mempool 新交易必须用 WebSocket 而不是轮询 HTTP？
  2. 你的机器人进程崩溃后，如何在 5 分钟内知道"它崩了、什么时候崩的、崩溃前在做什么"？
  3. systemctl 的 Restart=always 和你自己写一个 while true 循环重启脚本，本质区别是什么？
  4. 一次策略参数改动导致亏损，你会用哪几条 Git 命令定位"是哪一次提交引入的问题"？

── Q&A / 更正记录区（按日期追加）──

原始讨论记录见 Q&A/（按日期归档，保留完整来回过程）；本节是同步后的结论摘要， 只增不删——若后续发现本篇正文表述不准确，按更正记录追加在此，不删改正文， 保留"原来写的是什么 → 后来发现哪里不准 → 更正为什么"的轨迹。规范见 Q&A/README.md。

  • (2026-07-26 建立。暂无 Q&A——后续围绕本篇的提问/质疑/更正在此累积。)