用 SSP 发送和接收 Ethereum
在为 Ethereum 设置好 SSP 之后,把 ETH 转入和转出自托管钱包是你最先会做的事情之一。一旦你理解了账户模型,以及 SSP 的 2-of-2 multisig 如何融入一笔普通的 Ethereum 交易,这件事其实很简单。本指南将带你走一遍接收 ETH、发送 ETH,以及当你用两台设备签名时幕后到底发生了什么。
如果你对 SSP 中的 ETH 完全陌生,请先阅读 SSP 中的 Ethereum 了解全局,然后再回到这里学习实操的收发流程。
账户模型速览
在底层,Ethereum 的工作方式与 Bitcoin 不同。在 Bitcoin 上,你的钱包要处理许多未花费输出,并在每次花费时生成新的找零地址。在 Ethereum 上,你的账户就是一个仅持有余额的单一地址。你接收 ETH 时,余额上升;你发送时,余额下降。没有找零地址,也没有需要考虑的输出选择。
这对自托管有两点实际影响。第一,你可以无限期地重复使用同一个地址,因此只有一个地址需要备份、核对和分享。第二,每笔交易都必须排序,Ethereum 用一个名为 nonce 的计数器来处理这件事——下文还会详述。
在 SSP 中,这个单一地址就是你的 2-of-2 multisig 账户。在 EVM 链上,它是一个 ERC-4337 智能合约账户,因此即使在链上看起来像一个普通地址,两把密钥仍然把守着每一次花费。
接收 ETH
接收是更安全的一半,因为没有任何东西离开你的钱包。你把地址给发送方,然后等待网络确认。
你的 0x 地址
你的 Ethereum 接收地址以 0x 开头,后面跟着 40 个十六进制字符。SSP 会以文本和可扫描的码两种形式显示它,方便发送方原样复制。由于 Ethereum 重复使用一个地址,你不需要为每笔付款准备新地址。
在两台设备上核对地址
自托管把地址核对的责任交到你手里。把已复制的地址替换成攻击者地址的恶意软件是整个行业的真实风险,所以要确认你即将分享的地址确实是你自己的。SSP 在扩展程序和 SSP Key 上都会显示账户,因此请在每台设备上看一眼开头和结尾的字符,确保它们一致。同样的习惯也适用于把 Bitcoin 接收进 SSP——请在你掌控的硬件上核对,而不是仅凭别人发给你的网页。
一个地址同时接收 ETH 和 ERC-20 代币
同一个 0x 地址既接收 ETH,也接收 ERC-20 代币,因为代币存在于会向你的地址记账的合约中。你不需要为每种代币准备单独的地址。你需要做的,是确保发送方使用了正确的网络。
选择正确的网络
这是人们在 EVM 链上丢失资金最常见的方式。一个在 Ethereum 主网上存在的地址,在 Polygon、Base 以及其他 EVM 链上同样存在,但一条链上的余额并不是另一条链上的余额。如果有人通过错误的网络给你发 ETH,它不会到达你正在关注的那条链。在分享地址之前,先与发送方就确切的网络达成一致,并确认 SSP 已设置为同一条链。第 3 篇文章详细讲解了如何在 Polygon、Base 及其他 EVM 链上使用 SSP。
发送 ETH:2-of-2 联合签名流程
SSP 的 multisig 设计会在发送时显现出来。单密钥钱包签名一次便广播。SSP 需要你的两把密钥,因此流程多了一个批准步骤——而这一步正是整个安全模型的关键所在。
下面是一次发送的大致形态,因具体标签可能变化,这里说得比较概括:
- 在 SSP Wallet 扩展程序中选择发送,输入收款地址和金额,然后查看手续费。
- 扩展程序构建交易,并用密钥 1 完成第一次签名。
- 你手机上的 SSP Key 收到推送通知。你在那里核对相同的细节,并用密钥 2 联合签名。
- 两个签名合并后,交易被广播到网络。
由于任何一台设备都无法单独转移资金,只攻破你浏览器的攻击者仍然无法发送。他还需要你的手机来批准。在 EVM 链上,SSP 使用 Schnorr 聚合把两个签名合并为一个,因此落到链上的是一笔账户抽象操作,而不是两个分开的签名。更深入的机制在以账户抽象方式实现的 EVM multisig 中讲解。
这种联合签名的习惯,在精神上与用 SSP 发送 Bitcoin 完全一致;只是底层的交易格式不同。
交易的生命周期
把一次发送想象成一条短短的流水线会有帮助:
- 构建——扩展程序组装交易:收款方、金额、gas 设置和下一个 nonce。
- 签名——密钥 1 在扩展程序中签名。
- 联合签名——在你批准推送之后,密钥 2 在 SSP Key 上签名。
- 已提交 / 待确认——合并后的交易被广播,停留在 mempool 中等待被打包进区块。
- 已确认——验证者把它打包进区块。其后每一个区块都会增加确认数,并使其更难被回滚。
一笔交易只有在链上确认后才算最终完成。在此之前它处于待确认状态,在某些情况下可以被替换。你可以在像 Etherscan 这样的公开区块浏览器中粘贴交易哈希,来查看任何交易的进展。
理解 nonce
nonce 是一个按账户计数、用来给你的交易排序的计数器。你的第一笔交易使用 nonce 0,下一笔使用 1,以此类推。网络严格按顺序处理它们。
这种排序有一个实际后果。如果一笔交易卡在待确认状态——通常是因为它的 gas 价格对当前网络状况而言太低——其后的每一笔交易都会被堵在它后面,因为网络不会跳到更高的 nonce。解决办法是替换这笔卡住的交易:你用相同的 nonce 但更高的手续费重新提交一笔交易,让验证者得以选用新版本。钱包通常把这呈现为"加速"或"替换"操作。SSP 对替换交易仍然要求 2-of-2 联合签名,因为它是一笔新交易。
你很少需要手动处理 nonce——SSP 会为你填好——但知道它的存在,就能解释为什么一笔待确认的交易会拖住它后面的交易。
gas,从高层来看
每一笔 Ethereum 交易都要花费 gas,以 ETH 支付。即使你在转移 ERC-20 代币也是如此:代币搭载在一笔 Ethereum 交易之上,而这笔交易需要 ETH 来支付计算。实用的原则是,始终在账户里留一点 ETH 余额以便支付 gas,否则即使你的代币余额没问题,一次发送也可能因 gas 不足而失败。
EIP-1559 下的 gas 定价分为由网络设定的基础费,以及你为了更快被打包而添加的优先小费。这里我们说得简略;关于完整的图景——基础费、小费、费用为何会飙升,以及在自托管中如何选择——请阅读为自托管用户讲解的 Ethereum gas 费用。
ETH 与 ERC-20 代币
ETH 是 Ethereum 的原生资产,也是用来支付 gas 的东西。ERC-20 代币是由智能合约定义的独立资产,合约按你的地址记录余额。发送代币在技术上更像是一次合约交互,而不是单纯的价值转移,但在 SSP 中它遵循同样的构建、签名、联合签名、广播流程。
某些代币操作需要一次性的授权(approval),之后另一个合约才能代表你转移代币——这在兑换和 DeFi 中很常见。授权是一个独立话题,不在本文范围内;你只需知道,要求你批准花费的提示是代币交互的正常一环,而同样的 2-of-2 联合签名会保护它。
发送前的实用注意事项
- 正确的网络。 确认链与收款方期望的一致。Base 上的 ETH 不是 Ethereum 主网上的 ETH。
- 地址格式。 Ethereum 地址是
0x加 40 个十六进制字符。请粘贴,切勿手动重打,并在两台设备上核对开头和结尾。 - ENS 名称。 有些钱包允许你发送到像
name.eth这样可读的名称,而不是原始地址。把它当作任何地址对待:在批准前确认它解析到的是你预期的收款方。 - 留 ETH 付 gas。 只有代币的余额无法支付自己的 gas。请留一点 ETH。
关于 Ethereum 交易如何构成的协议层细节,官方 Ethereum 交易文档 是一份可靠的参考。
小结
在 SSP 中接收 ETH,就是在正确的网络上分享你已核对过的 0x 地址。发送则多了一个刻意为之的步骤——SSP Key 的联合签名——它把单一故障点变成了两个。为 gas 留一点 ETH 在手边,当一笔交易停滞时留意 nonce,并且每次都确认网络,这样 SSP 中日常的 ETH 转移就会变得习以为常。从这里出发,gas 费用那篇文章是自然而然的下一篇。
