重放攻击问题
比特币靠不同的地址前缀可以规避重放攻击问题。
以太坊可以靠 EIP155 钱包来规避重放攻击问题。
何为重放攻击问题？
一个区块链有若干个测试网络。如果一套公私钥可以在不同的网络上通用，则可以恶意地把在测试网络中出现的 transaction 播放到主网上。如果在测试网络上有人从账户 A 转了一笔钱到账户 B，而账户 B 是一个傻瓜测试账户，私钥是由类似123456之类的种子生成的话。那么只要账户 A 在主网中的余额大于这笔钱，心怀恶意者就能把主网中 A 的钱财转走，从主网中的账户 B 里把钱取出来。即使心怀恶意者没有 B 的取款方法，也能让账户 A 蒙受资金损失。
所以不要跨网使用相同的公私钥对。
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2018-01-27
比特币小细节
收款地址是公钥的hash。 区块结构： 数据项 描述 长度 Magic No 魔数 总是 0xD9B4BEF9 4 字节（定长） BlockSize 区块大小 到区块结束的字节长度 4字节（定长） BlockHeader 区块头 包含六个数据项 80字节（定长） Transaction Counter 交易计数器 正整数 VI=VarInt 1-9字节（变长） BlockHeader 区块头 包含六个数据项 80字节（定长） Transactions 交易 交易列表（非空） 由Transaction Counter 描述的长度（变长） 由此表可见，只有交易计数器和交易明细列表是变长的。 比特币使用 SHA256 算法，它的结果哈希值大小为 256 位。也就是说，只要输入超过2的256次方个数，就一定会发生碰撞，即使只有2的255次方个数，也有百分之九十九的几率发生碰撞（为什么？）。 当前（这一百年内），每个区块都至少包含一个 Transaction，它被称为生产交易，或者coinbase交易，用于给生成这个区块的矿工以奖励，它经常是区...
2018-03-08
UTXO 与 account balance 模型
UTXO 简介 UTXO 的全称的 unspent transaction output，就是没有被人用过的可用资金。 这个模型是比特币首创的，被其他货币所模仿。以太坊天然的模型不是 UTXO 而是 account balance。 UTXO 必须配平，UTXO 的输入者必须上一个 UTXO 的输出者： 这就把一个一个账户型数据库，转成了链式的交易数据库，交易要靠 merge 整个数据库的相关节点。 UTXO 的好处是： 更加好的隐私模型 更加强的并发范型（因为不会触发间隙锁了吗？） ZCash 的 UTXO ZCash 也一样有 UTXO，但它的 UTXO 是加密过的，而且每个矿工那里还有一个专门的 UTXO 作废数据库。具体情况见《不是程序员也能看懂的ZCash零知识证明》。 ##以太坊中的 account 模型## 以太坊没有使用 UTXO 模型，而使用 account balance 模型，他们把 account balance 模型称为 world state。account balance 模型比 UTXO 模型更加容易实现智能合约，...
2018-03-08
重新学习 Solidity
以下内容还是从 Solidity 文档里摘出来的。 智能合约入门/介绍 第一个基本的例子 12345678910111213pragma solidity ^0.4.0;contract SimpleStorage { uint storedData; function set(uint x) public { storedData = x; } function get() public constant returns (uint) { return storedData; }} 一个 contract 可以被认为是一个类型。 默认的 unint 就是256位的。 storedData 可以被认为是 state variable，状态变量。在 Solidity 的概念里面，这个东西可以被认为是数据库里面的一个槽，可以被函数查询和修改。注意看它不是 public 的，所以没有合成方法。 访问状态变量不需要用 this前缀（在什么 scope 下都不需要吗？）。 ...
2026-10-05
区块链（17）：执行、共识客户端与验证者怎样拼成一个节点
钱包发送交易到执行客户端（EL）的 RPC，不表示共识客户端（CL）已经选它所在的链头。EL 负责 EVM 执行、状态和交易入口；CL 负责共识网络、头选择与最终性判断；验证者客户端持有签名职责并参加提议/投票。两端通过 Engine API 协作：共识端请求构建执行载荷，并让执行端验证收到的载荷，不能只启动其中一个进程就称作完整的 PoS 节点。 先修区块链（16）：Gasper 中链头与终局是两次不同判断。在私网里还须冻结执行与共识客户端的兼容版本、chain ID、genesis、fork 时间表、认证材料、验证者存款与网络连接；否则“节点同步”可能只是一端准备就绪，甚至连接了另一条链。Engine API 的认证材料是本地进程凭据，不可纳入博客素材。 sequenceDiagram participant U as 钱包/应用 participant EL as 执行客户端 participant CL as 共识客户端 participant V as 验证者 U->>EL: 提交签名交易 CL->>EL: Engine ...
2026-10-05
区块链（18）：EVM 执行后哪些状态进入状态根
Bitcoin 的输入消耗产生新输出；EVM 的世界状态主要描述账户的 nonce、余额、代码与存储承诺。合约调用携带发送者、目标、value、calldata 与可用 gas，在给定初始状态和规则版本下按确定性执行产生新状态、日志、gas 消耗及成功或失败结果。区块链（17）：执行、共识客户端与验证者怎样拼成一个节点的 CL 不替 EL 重演每一步执行，但最终能否认可载荷依赖执行验证。 flowchart LR I[前状态根 + 签名交易 + fork 规则] --> E[EVM: 栈、内存、storage 与调用帧] E --> A[账户余额/nonce/代码/存储变化] A --> R[后状态根] E --> L[日志与回执: 单独承诺对象] E --> X[revert: 调用帧效果撤销，费用另算] 栈用于操作数，内存是调用期间的临时字节区域，storage 是合约持久化的键值空间；一次调用的中间值不自动变成永久链上状态。外部调用可以转移执行控制，必须区分调用失败返回与 revert 传播、内部状态撤销与发送者实际消耗的费...
2026-10-05
区块链（19）：revert 以后为什么仍要核算 Gas 与 nonce
交易先经过签名、余额和 nonce 等可接收性检查，执行中还要为每一步消耗 gas。eth_estimateGas 是在给定当时的状态和参数下模拟，后续实际状态、排序和费用环境可能变化；“估算成功”不是“上链执行成功”，模拟时的读数据可能被其他交易改写。区块链（18）：EVM 执行后哪些状态进入状态根中的 revert 撤销执行帧的状态效果，不能据此推断发起者完全不付费用。 flowchart TD S[签名与 nonce 有效] --> I[被纳入区块] I --> E{EVM 执行} E -->|成功| C[状态变化 + 用气 + 回执成功] E -->|revert/耗尽 gas| F[业务状态未按预期改变，仍有费用] C --> B[再检查区块与最终性] F --> B EIP-1559 风格费用把协议动态调整的基础费与交易提出的费用上限、小费上限联系起来；基础费按规则处理，不应简单写成全部支付给验证者。应用实际支出要从回执用气量与生效单位价格复算，不能把 maxFeePerGas × gas...
