LOREWORD

从0到深入理解以太坊
第五章 · 第二课

Ethereum learning path · 05.02

一笔授权，
为什么全网都相信？数字签名 · 从控制权直觉到 ECDSA 验证

网络从未见过你的私钥，却能独立确认一条交易确实获得了授权。 这不是信任钱包品牌，而是一套任何节点都能重复计算的密码学证明。

  • 05 · 02 密码学基础
  • 68 MIN 阅读与实验
  • 0 → 深入 公式可选阅读

The thesis

以太坊不认识现实中的“你”。它证明的是： 一段精确字节，获得了某个地址对应私钥控制者的授权。

01 · Orientation

“只有你能动用”，究竟指谁？

先把人、钱包、地址、私钥和链上余额分开。

第五章第二课 · 主线讨论普通 EOA 的 secp256k1 / ECDSA 签名

你的 ETH 不在手机钱包里，也不在一串助记词“里面”。余额记录在以太坊的共享状态中， 由地址索引。钱包主要做四件事：保管密钥、组织待签内容、向你展示请求、 再把签名后的结果交给网络。

一句精确定义

对经典外部账户 EOA，所谓“控制账户”，是指能够为协议要求的精确数据产生有效签名， 使节点恢复出的发送者地址等于该账户地址。私钥不会被发送给节点，也不会保存在链上。[1]

STATE

ETH 在链上状态里

地址索引余额与 nonce。钱包读取这份公共状态，而不是从本地文件“取出币”。

SECRET

私钥是授权能力

谁能使用这把私钥，谁就能生成同等有效的 EOA 授权；协议无法识别现实身份。

PROOF

签名是公开证明

任何人都能验证，只有掌握私钥的人才能为那段精确数据生成它。

INTERFACE

钱包是决策界面

密码学只判断“签名有效”；你是否看懂金额、合约与权限，要靠钱包显示和判断。

数字签名能证明什么，不能证明什么？

签名能力边界
问题 结论 原因
证明某把私钥参与了授权？ 可以 验证者用摘要、签名和公钥关系重复计算。
证明签名后数据没有被替换？ 可以 哪怕改一个字段，摘要也变，原签名不再对应。
证明签名者是现实中的 Alice？ 不可以 协议只认识密钥和地址，不认识护照、人脸或法律身份。
把交易内容加密、隐藏起来？ 不可以 签名解决真实性与完整性，不等于加密；交易数据通常公开。
证明用户理解并愿意承担后果？ 不可以 恶意页面也能诱导有效签名；“有效”不等于“安全”。
标题里的重要限定

“只有你能动用”更准确地说是“只有控制该私钥的人能为经典 EOA 授权”。 私钥一旦泄露、被共享，或恶意软件能调用签名器，攻击者产生的签名在协议眼中同样有效。

02 · Authorization pipeline

从一次点击，到全网接受

节点不相信钱包的“from”标签；它自己恢复发送者。

假设 Alice 要向 Bob 发送 0.25 ETH。钱包界面只是一层翻译； 真正被签名的是一组严格编码的字段。网络收到后，会独立重建摘要、恢复公钥与地址， 再检查 nonce、费用上限和余额。[2]

Interactive · 01

授权流水线

逐步查看钱包与节点各自知道什么。所有地址和哈希均为教学缩写。

01 / HUMAN INTENT

先确认你想做什么

钱包把协议字段翻译成“向谁、多少、在哪条链、调用什么”。这一层决定你是否真正知情。

wallet preview
action
发送 ETH
to
0xB0B0…2048
value
0.25 ETH
network
Ethereum · chainId 1
02 / CANONICAL ENCODING

把意图变成唯一字节序列

字段顺序、类型、空值和交易类型都有协议定义。相同语义若编码不同，也会得到不同摘要。

type 0x02 signing payload
chain_id
0x01
nonce
0x2a
destination
0xb0b0…2048
amount
0x03782dace9d90000
03 / KECCAK-256

压缩成 32 字节摘要

签名算法处理摘要，而不是逐字阅读自然语言。改动任何被签字段，摘要几乎会完全不同。

signing digest · shortened
input
0x02 || rlp([...])
keccak256
0x8f52b4e1…91c73a06
size
32 bytes
privacy
摘要不隐藏原始交易
04 / ECDSA SIGN

私钥在本地生成签名

钱包或硬件设备用私钥与一次签名用临时值计算结果。私钥不随交易离开签名环境。

recoverable signature · shortened
r
0x6d8a…2f41
s
0x2c19…90de
yParity
0
private key
never transmitted
05 / PUBLIC-KEY RECOVERY

节点自己找出发送者

节点用摘要与可恢复签名重建公钥，再按以太坊规则派生地址。raw transaction 没有可信的 from 输入。

derived identity
digest + sig
→ public key Q
keccak256(Q)
0xd135…a11ce
last 20 bytes
0xA11c…7E57
sender
Alice EOA
06 / PROTOCOL CHECKS

有效签名只是第一道门

节点还会检查交易格式、nonce、费用条件、余额与执行规则。签名正确不保证交易一定成功执行。

node checks
signature
valid
nonce
42 = expected
funds
sufficient
execution
进入 EVM / 状态转换

第 1 步：人先确认操作语义；密码学只能保护你最终签下的精确数据。

两个经常混在一起的哈希

SIGNING DIGEST

签名前摘要

由未签名交易的规定字段计算，ECDSA 对它签名。不同交易类型的编码规则不同。

TRANSACTION HASH

交易哈希

对完整已签名交易计算，包含签名字段；区块浏览器常用它作为交易标识。

不要写进脑中的错误字段

区块浏览器和 JSON-RPC 常显示 from，但它是客户端从签名恢复出的派生结果。 如果网络直接相信请求里自报的 from: Alice，任何人都能伪造转账。

03 · Keys and curve

私钥不出门，证明如何出门？

单向关系让公开验证成为可能。

第五章第一课负责完整讲解私钥、公钥与地址。本课只抓住签名需要的骨架： 私钥是一个秘密整数 d，公钥是曲线点 Q = dG， 地址再由公钥哈希导出。正向计算可行，反向从公钥求私钥在现实计算规模下不可行。

secp256k1 是怎样的空间？

以太坊 EOA 使用的 ECDSA 建立在 secp256k1 曲线上。 它不是纸面上一条连续光滑的线，而是在巨大有限域中的离散点集合； 曲线方程可写成 y² ≡ x³ + 7 (mod p)。所谓 dG 不是普通乘法，而是把基点 G 按曲线加法规则重复组合。[3]

为什么公开签名不会公开私钥？

验证只需要公钥关系，不需要重演“私钥做过什么”。可以把它类比成一个只在内侧盖章的模具： 外界看到印记，能用公开规则检查印记与某把公开锁匹配，却不能从印记倒推出模具。 这个类比只帮助直觉；真正保证来自椭圆曲线离散对数问题与 ECDSA 的代数结构。

哈希与签名不是一回事

哈希把任意长度数据压成固定长度摘要，不使用私钥；签名使用私钥对摘要产生证明。 任何人都能算同一份数据的哈希，只有密钥控制者能产生对应有效签名。

04 · ECDSA microscope

ECDSA 到底算了什么？

先读直觉；公式用于精确校准，不要求手算。

签名要把三样东西不可分割地绑在一起：消息摘要 z、私钥 d，以及本次签名专用的秘密临时值 k。 输出是两个整数 r、s；以太坊再携带恢复所需的 yParity。

01 · KEY RELATION Q = dG

私钥 d 与基点 G 生成公钥 Q。Q 可以公开，d 必须保密。

02 · MESSAGE z = keccak256(encoded data)

先按交易或消息标准编码，再得到要签的 32 字节摘要。

03 · EPHEMERAL POINT R = kG · r = xR mod n

每次签名使用秘密临时值 k。r 来自临时点 R 的 x 坐标。

04 · SIGNATURE RESPONSE s = k−1(z + rd) mod n

s 把摘要、私钥与临时值绑定；最终数学签名为 (r, s)。

验证者如何在不知道 d 的情况下检查？

w = s−1 mod n
u₁ = z · w mod n
u₂ = r · w mod n
X = u₁G + u₂Q
valid ⇔ xX mod n = r 代入签名公式后，X 会落回签名时的临时点 R。验证者只用公开的 z、r、s、Q 和曲线参数，就能确认“这个摘要与这把公钥匹配”，不需要知道 d 或 k。
展开一个可以手算的玩具曲线示例
  1. 玩具曲线：y² = x³ + 2x + 2 mod 17，基点 G=(5,1)，阶 n=19。
  2. 取私钥 d=7，得到公钥 Q=7G=(0,6)。
  3. 消息摘要整数 z=11，仅本次使用 k=3。
  4. R=3G=(10,6)，所以 r=10。
  5. s=3⁻¹(11+10×7) mod 19 = 8。
signature = (r=10, s=8)
yParity = 0
verification X = (10,6)
xX mod 19 = 10 = r
VALID

把 z 改成 12：X=(3,16)
3 ≠ 10 → INVALID
仅教学，绝不可用于真实资产

上面的模 17 曲线小到可以手算，也小到任何人都能暴力破解。生产签名必须使用经过审计的密码学库、 安全随机源或可靠的确定性 nonce 方案；不要自行实现 ECDSA。

最危险的同名词：k 不是 transaction nonce

SECRET · ECDSA

临时值 k

签名器内部每次签名使用，必须保密且不可重复。它不进入交易，也不是公开序号。

PUBLIC · PROTOCOL

transaction nonce

EOA 的公开交易计数，用于排序并防止同一条已签交易在同链重复执行。

PUBLIC · APPLICATION

授权 nonce

permit、订单或登录协议自行设计的防重放编号，必须由应用检查并消费。

MEMORY RULE

三个 nonce，三层职责

临时 k 保护私钥；交易 nonce 保护链上交易顺序；应用 nonce 保护链外授权。

为什么重复使用 k 会泄露私钥？

如果两条不同摘要 z₁、z₂ 使用同一个 k， 它们会拥有相同的 r。攻击者拿到两组公开签名，就能消去私钥项， 先求出 k，再反推出 d。这不是“签名次数太多”的问题， 而是签名器随机数或确定性 nonce 实现失败。

k = (z₁ − z₂) · (s₁ − s₂)−1 mod n
d = (s₁k − z₁) · r−1 mod n RFC 6979 描述了从私钥与消息摘要确定性地产生 k 的方法，可避免依赖外部随机数质量； 但 Ethereum 共识并不规定钱包必须采用哪种实现策略。[4]

Interactive · 02

只改一个字段，原签名会怎样？

教学指纹用于可视化差异，不是真实 Keccak-256；验证结论遵循真实签名逻辑。

待验证字段

to
0xB0B0…2048
value
0.25 ETH
nonce
42
chainId
1
data
0x
signature
固定 Alice 原签名

验证观察窗

教学指纹 · 非真实哈希 0x8f52 b4e1 19d0 7ac3 · 91c7 3a06
恢复地址
0xA11c…7E57
✓ ALICE

原始字段：重建的摘要与 Alice 签名时相同，恢复出的地址仍是 Alice。

05 · Signature anatomy

r、s、v、yParity 各是什么？

数学 ECDSA 只有 (r,s)；以太坊还要支持公钥恢复。

常见以太坊可恢复签名占 65 字节：32 字节 r、32 字节 s，再加 1 字节恢复信息。现代协议更精确地称最后一项为 yParity；历史接口常把它规范化成 v = 27/28。

为什么还需要 yParity？

r 主要给出临时点 R 的 x 信息；曲线上通常存在两个 y 坐标候选。yParity 告诉恢复算法选择奇数还是偶数 y 的候选。 它描述的是临时点 R，不是公钥 Q 的奇偶位。获得 R 后， 可用 Q = r⁻¹(sR − zG) 恢复公钥。

v 为什么有时是 27/28，有时是 37/38？

恢复字段的不同语境
语境 常见表示 chainId 在哪里
底层恢复位 yParity = 0 / 1 不在恢复位中
历史消息签名 / 旧接口 v = 27 / 28 消息格式自行决定是否绑定链
EIP-155 legacy 交易 v = 35 + 2×chainId + yParity 既进入签名前数据，也反映在 v 中；主网常见 37/38
EIP-2718 typed 交易 signature_y_parity = 0 / 1 作为独立的已签名 chain_id 字段
EIP-2098 紧凑签名 (r, yParityAndS) · 64 bytes 不由紧凑表示自动提供

low-s：同一授权为什么不该有两个外观？

标准 ECDSA 中，(r,s) 与 (r,n−s) 都可能验证通过。 这叫签名可塑性：攻击者不需要私钥，也能把一个有效签名改成另一个有效外观， 进而改变完整交易哈希。对以太坊可恢复交易签名，等价变换还要同时翻转恢复位： (r,s,yParity) → (r,n−s,1−yParity)；legacy 表示中相当于 v: 27 ↔ 28。EIP-2 因此要求交易签名的 s ≤ n/2，选定这一对平凡等价表示中的低半区版本。[5]

协议层与合约层不要混写

EIP-2 让交易层拒绝 high-s 签名，但 EVM 的 ecrecover 预编译仍可接受它。 智能合约验证任意消息签名时，仍应使用成熟库主动检查 low-s、合法 v 与非零恢复地址。

06 · Transaction signatures

一笔交易，究竟封住了哪些字段？

签名保护精确编码，不保护钱包 UI 的概括句。

现代 EIP-1559 type-2 交易把交易类型字节与 RLP 编码字段一起哈希。 下面这组字段只要有一个变化，签名前摘要就变化，原签名恢复出的发送者也不再匹配。 不同 typed transaction 会有不同字段，但“先固定类型与内容，再签名”的原则相同。

signingDigest = keccak256(
  0x02 || rlp([
    chain_id, nonce,
    max_priority_fee_per_gas, max_fee_per_gas,
    gas_limit, destination, amount, data, access_list
  ])
) 签名后再附加 signature_y_parity、signature_r、 signature_s，形成可广播的完整 type-2 交易。[6]
type 0x02 chain_id nonce priority fee max fee gas limit destination amount data access list

签名有效，为什么交易仍可能失败？

数字签名只回答“谁授权了这组字段”。节点仍要判断：nonce 是否正好轮到， 余额是否足够覆盖 value 与费用上限，交易格式是否合法，Gas 是否满足内在成本。 进入 EVM 后，合约还可能因为权限、价格、余额、截止时间或显式 revert 而失败。授权真实性与执行成功是两道不同检查。

重放不是一个问题，而是三层问题

LAYER 01 · SAME CHAIN

交易 nonce

一笔成功进入链上后，EOA nonce 前进；再次广播旧签名通常因 nonce 过期而被拒绝。

LAYER 02 · OTHER CHAIN

chainId

EIP-155 把链标识绑定进 legacy 交易；typed 交易则明确签入独立 chain_id。

LAYER 03 · APPLICATION

授权 nonce / deadline

链外 permit、订单和登录消息必须由应用限制次数、有效期与验证域。

EIP-155 解决了什么？

早期 legacy 交易若不绑定链，同一份已签交易可能被复制到另一条兼容链执行。 EIP-155 把 chainId 加入签名前数据，并把 legacy v 设为 35 + 2×chainId + yParity。 当两条链使用不同 chainId 时，同样的金额与接收方也会得到不同摘要与签名。 它不区分共享同一 chainId 的链或分叉，也保留了旧式未保护 legacy 签名的兼容性。[7]

精度提醒

不要把“EIP-155 的 v 编码 chainId”泛化到所有签名。它是 legacy 交易语境； type-2 等 typed transaction 把 chain_id 与 signature_y_parity 分开编码。

07 · Message signatures

“签名消息”为什么也可能动资产？

不立刻上链、不花 Gas，不代表没有授权后果。

交易签名是协议交易的一部分；消息签名则常在链外完成，用于登录、挂单、 投票、permit、领取或元交易。它本身不一定立即改变链上状态， 但第三方之后可以把签名提交给合约，兑换成真实权限。

TRANSACTION

协议交易签名

签名一组交易字段，提交后由节点恢复 sender 并尝试执行状态转换。

  • 直接进入交易池与区块流程
  • 绑定交易 nonce 与 chainId
  • 执行需要 Gas
EIP-191 · PERSONAL_SIGN

带前缀的字节消息

先加以太坊消息前缀和字节长度，再哈希签名，避免被当成原始交易。

  • 本身不发交易
  • 不天然绑定 DApp、链或合约
  • 消息长度按字节，不按字符
EIP-712 · TYPED DATA

结构化类型消息

把类型、验证域与字段结构纳入摘要，让钱包有机会清楚展示授权语义。

  • 可绑定 chainId 与 verifyingContract
  • 适合 permit、订单与元交易
  • 仍需应用自行设计防重放规则
RAW SIGNING

不透明原始摘要

用户往往无法判断十六进制究竟代表什么；除非明确理解协议，不应盲签。

  • 语义可读性最差
  • 域隔离取决于应用设计
  • 高风险操作应拒绝盲签

EIP-191：给普通消息加一个“这不是交易”的边界

digest = keccak256(
  "\x19Ethereum Signed Message:\n" ||
  ASCII_decimal(byteLength(message)) ||
  messageBytes
) 开头的 0x19 与版本设计让这类 signed data 不能被当成一个有效 RLP Ethereum 交易。注意 UTF-8 的“你好”是 6 字节，不是 2 字节。[8]

更完整地说，ERC-191 是 signed data 的总框架：版本 0x45 对应常见 personal_sign 前缀，0x01 交给 EIP-712， 0x00 则可以绑定 intended validator。这里先聚焦用户最常见的 0x45 路径。

EIP-712：把“签什么”变成结构化数据

digest = keccak256(
  "\x19\x01" ||
  domainSeparator ||
  hashStruct(message)
) domain 可包含 name、version、chainId、verifyingContract、salt； message 则包含 spender、amount、nonce、deadline 等业务字段。类型信息也参与哈希。[9]

域分离只能绑定应用实际纳入、且验证者按同一方式重算的字段： 例如 name、version、chainId 或 verifyingContract； 消息结构回答“授权了什么动作与参数”。但 EIP-712 规范明确不自动提供完整重放保护。 应用必须设计状态化防重放机制：消费 nonce、记录订单填充状态、使用 bitmap 或撤销记录等； deadline 常用于限制有效窗口，但不是每个协议都必须与 nonce 同时采用。

Interactive · 03

钱包签名请求检查器

全部是虚构示例，不连接钱包、不读取账户，也不会产生真实签名。

LORE WALLETSignature request
EIP-4361 style login

登录示例站点

证明你控制当前地址，不授予资产转移权限；仍需核对域名、URI、nonce 与有效期。

domainlearn.example
urihttps://learn.example
chainId1
nonce8f2Qx7
expiration2026-07-25 22:00 UTC

你必须看见的边界

  • 来源：域名与当前页面一致。
  • 动作：只证明地址控制权，没有 spender 或 token amount。
  • 防重放：服务端 nonce 应一次性消费。
  • 时效：有清晰到期时间。
  • 风险：低于资产授权，但钓鱼站可借签名冒充你登录。

登录挑战：重点核对域名、URI、一次性 nonce 和到期时间；不要把任意十六进制当登录消息。

签名不花 Gas，也可能价值巨大

一个 permit 可以允许 spender 转走代币；一个链外订单可以被撮合合约执行； 一个领取授权可以把权益给指定接收者。断开钱包连接不会撤销已经产生的签名， 因为签名是独立的可复制数据。

08 · Human security

密码学正确，仍可能签错

签名安全最薄弱的一层，常常是你看到的那块屏幕。

攻击者通常不需要破解 secp256k1。他只要让用户为攻击者准备好的数据产生一个完全有效的签名。 所以真正的安全问题从“这个签名是否有效”变成“钱包是否准确表达了将被授权的后果”。

HIGH RISK

盲签十六进制

看不见目标合约、资产、金额与调用语义。硬件钱包若要求开启 blind signing，应停下来核实。

HIGH RISK

无限额度 Permit

签名本身不上链，但任何获得它的人都可能在有效期内提交，授予 spender 极大额度。

CONTEXT RISK

无 nonce / 无期限

同一授权可能被重复使用或长期保存；应用级消息需要明确的一次性编号与 deadline。

LOWER RISK

清晰登录挑战

不含资产权限、绑定正确域名且 nonce 一次性消费，风险较低，但仍可能被用于会话劫持。

签名前，按顺序问七个问题

  1. 请求来自哪里？浏览器域名、钱包显示的 origin、连接的应用是否一致？
  2. 我授权什么动作？是登录、转账、approve、permit、挂单、投票，还是无法解释的原始字节？
  3. 谁获得权限？核对 to、spender、operator、recipient 与 verifyingContract。
  4. 涉及哪些资产与额度？金额、token、NFT id、最小收到量，是否出现无限额度或全部资产？
  5. 在哪条链与哪个域？chainId、合约地址、应用 name/version 是否与预期一致？
  6. 能用几次、多久？检查 transaction nonce、授权 nonce、deadline、salt 与取消机制。
  7. 界面能解释全部字段吗？无法清晰解码、仿冒域名、异常催促或要求盲签时，直接拒绝。

清晰签名，比“请确认”更重要

好的钱包会把 calldata 或 typed data 翻译成可核对的资产、方向、金额、授权对象和有效期； 更进一步的清晰签名标准让硬件设备也能按协议描述显示含义。无论界面多漂亮， 最终都要以真实待签字段为准，而不是网页上的营销句子。[10]

一个实用的拒签规则

如果你无法用一句具体的话复述“哪个地址，在什么链上，允许哪个合约， 对什么资产，在多长时间内，执行什么动作”，就还没有足够信息签名。

09 · Boundaries

把十个常见误区彻底拆开

准确的边界，比记住更多名词更重要。

MYTH · 01

“签名证明现实身份”

错误。它证明密钥控制；现实身份需要额外的可信绑定。

MYTH · 02

“签名会加密消息”

错误。它提供真实性与完整性；消息和签名通常可公开读取。

MYTH · 03

“签名会暴露私钥”

正常实现不会。泄露或重复临时 k 才可能破坏私钥。

MYTH · 04

“from 是交易输入”

错误。sender 由摘要和签名恢复；展示的 from 是派生字段。

MYTH · 05

“v 永远等于 27/28”

错误。legacy、typed transaction 与库接口的表示不同。

MYTH · 06

“yParity 属于公钥”

错误。它选择签名临时点 R 的 y 坐标候选。

MYTH · 07

“EIP-155 保护所有签名”

错误。它主要隔离不同 chainId 的 legacy 交易重放。

MYTH · 08

“EIP-712 自动防重放”

错误。应用仍须处理 nonce、deadline 与状态消费。

MYTH · 09

“Keccak-256 就是 SHA3-256”

不精确。以太坊使用标准最终定稿前的 Keccak 变体。

MYTH · 10

“有效签名就是安全授权”

错误。密码学验证一致性，不能证明用户理解 UI。

合约账户没有单一私钥，怎么“签名”？

本课主线讨论经典 EOA。智能合约钱包、DAO 或多签地址没有一把天然对应合约地址的私钥。 ERC-1271 提供 isValidSignature(hash, signature) 标准接口， 让合约按自己的代码规则声明某份证明是否有效；规则可以是多签、角色、时间条件， 甚至其他签名方案。通过时标准返回 0x1626ba7e，验证调用本身不应修改状态； 但结果可以随角色、时间或链上状态变化。应用若只会 ecrecover， 就不能完整支持合约账户。[11]

不要混用的三类密钥 / 验证模型
场景 典型验证方式 本课位置
经典 EOA 交易与消息 secp256k1 / ECDSA，可恢复地址 本课主线
合约账户 / 智能钱包 ERC-1271，由代码定义有效性 本节边界提示
PoS 验证者共识消息 BLS 密钥与可聚合签名 第十章共识课程展开
助记词与多地址派生 BIP39 / HD wallet 密钥树 第五章第三课展开
现代账户仍不改变本课核心

多签、MPC、threshold signature、EIP-7702 与账户抽象改变“谁能满足授权规则”， 却没有改变基本问题：验证者必须把一段精确数据、一个验证域和一套可检查的控制规则绑定起来。

10 · Recap

把整课压缩成一条责任链

每一步只回答一个问题，合起来才是安全授权。

六句话记住数字签名

  1. ETH 在链上状态里，钱包保管的是授权能力。
  2. 签名证明某把私钥授权了精确数据，不证明现实身份，也不加密内容。
  3. 节点用摘要与可恢复签名重建公钥和地址，raw transaction 不靠自报 from。
  4. ECDSA 的秘密临时值 k 绝不能泄露或重复；它和公开 transaction nonce 完全不同。
  5. 交易 nonce 处理同链重复执行；不同 chainId 提供跨链域隔离；应用规则处理业务层重放。
  6. 消息签名可能兑换成资产权限；无 Gas、未上链、已断开钱包都不等于无风险。

现在检查你的理解

1. 一个 EOA 签名最准确地证明了什么？

2. 节点如何确定交易发送者？

3. 哪种错误最可能直接泄露 ECDSA 私钥？

4. 对 EIP-1559 type-2 交易，chainId 在哪里？

5. EIP-712 是否自动保证一份授权只能使用一次？

6. 为什么“不花 Gas 的签名”仍可能转移资产权限？

尚未作答。完成 6 题后，用自己的话复述“签名证明什么、不能证明什么”。

11 · Glossary and sources

术语与一手资料

页面以官方协议、标准与文档为事实基线。

核心术语

digest / 摘要
对规范编码数据计算的固定长度哈希；签名算法处理它。
secp256k1
Ethereum EOA 使用的椭圆曲线参数集合。
ECDSA
椭圆曲线数字签名算法，数学签名结果为 (r,s)。
yParity
帮助从签名恢复临时点 R 与公钥的 y 奇偶位。
low-s
把 s 限制在曲线阶的低半区，消除一类签名可塑性。
domain separation
把应用、版本、链与验证合约等上下文绑定进摘要。
replay / 重放
复制一份仍被接受的旧授权，在相同或不同上下文再次执行。
ERC-1271
让合约账户用代码回答某份签名或证明是否有效的标准接口。

官方与规范资料

  1. 01
    ethereum.org — Ethereum accounts EOA、私钥、公钥、地址、钱包与账户状态的官方基础说明。 页面更新：2026-04-13 · 核对：2026-07-25
  2. 02
    ethereum.org — Transactions 签名交易、字段、发送者证明与网络执行流程。 页面更新：2026-03-12 · 核对：2026-07-25
  3. 03
    SECG — SEC 2: Recommended Elliptic Curve Domain Parameters secp256k1 的有限域、曲线参数、基点与阶等标准定义。 SEC 2 v2.0 · Section 2.4.1
  4. 04
    RFC 6979 — Deterministic Usage of DSA and ECDSA 从私钥与消息摘要确定性产生每次签名 nonce 的标准方法。 RFC 6979 · 2013-08
  5. 05
    EIP-2 — Homestead Hard-fork Changes 交易签名 low-s 规则与签名可塑性的协议理由。 Final · Homestead
  6. 06
    EIP-1559 — Fee market change for ETH 1.0 chain type-2 交易的签名前字段、chain_id 与 signature_y_parity 编码。 Final · London
  7. 07
    EIP-155 — Simple replay attack protection legacy 交易把 chainId 纳入签名摘要与 v 的跨链重放保护。 Final · Spurious Dragon
  8. 08
    ERC-191 — Signed Data Standard personal_sign 前缀、版本字节与“不可被当成交易”的消息边界。 Final · Signed data standard
  9. 09
    EIP-712 — Typed structured data hashing and signing 类型化结构、domainSeparator、hashStruct 与安全考虑。 Final · Typed data standard
  10. 10
    ethereum.org — Add clear signing to your protocol 钱包和硬件设备如何把原始调用转换为人类可核对的操作语义。 教程发布：2026-05-11
  11. 11
    ERC-1271 — Standard Signature Validation Method for Contracts 合约账户通过 isValidSignature 由代码定义签名有效性的标准。 Final · Contract signatures
  12. 12
    ERC-2098 — Compact Signature Representation 把 yParity 收入低 s 最高位的 64 字节紧凑签名表示。 Final · Compact signatures
  13. 13
    Ethereum Yellow Paper — Appendix F 交易签名、发送者恢复、secp256k1 参数与有效性约束的形式化定义。 Protocol specification · 核对：2026-07-25
下一步

你现在知道网络为何相信“这份授权来自某个地址”。第五章第三课将把视角从一次签名 转向长期密钥管理：助记词、BIP39、HD 钱包、派生路径、备份与恢复为什么决定资产能否安全保存。