在一台钱包里同时使用多个应用时，你是否用同一个地址签名，不只是习惯问题，也是隐私问题：你在链上做过什么，会全部挂在同一个地址上。2019 年提出的 ERC-1775 给出过一种叫 App Keys 的方案——为每个应用从你已有的账户里自动派生一把专用密钥，应用之间彼此隔离。这份提案在官方仓库中标注为 Stagnant（停滞），但它提出的派生思路仍然值得普通用户看懂。下面按”它解决什么、怎么派生、能隔离到什么程度、今天能不能用”四层展开。
它想同时解决的两个矛盾
一边是安全：主账户装着大部分资产，每一次签名最好都经过你本人确认，不能被任何应用代劳。另一边是体验：不少加密应用需要用户高频签名，甚至要盯着链上状态自动签数据（例如对提款发起争议），每次都弹窗确认根本行不通。同时，如果你在好几个应用里复用同一个账户，链上活动就是完全可关联的——每个应用都能看到你在别处的资金规模与行为轨迹。主账户不能放松，通用账户又不能随便放权，ERC-1775 的解法是引入第二种账户：只在特定应用里活动、随时可以丢弃、也几乎不放钱的应用密钥账户。
派生算法只有一行
规范的核心是 appKeyPrivKey = keccak256(privKey + originString)：把当前选中主账户的私钥与应用来源字符串（即发起请求的网站 origin）拼接后做哈希，得到的私钥就是这个应用专属的。它的巧妙之处在于可再生：同一句助记词、同一个主账户、同一个域名，算出来的密钥永远相同，所以你换手机、重装钱包之后重新连上那个应用，账户自动就回来了，不需要任何额外备份。规范还把它暴露为 wallet_getAppKeyForAccount 这个 RPC 方法，让应用向钱包请求与当前账户绑定的应用密钥。要注意，这样派生出的密钥不是 BIP32 合规的扩展密钥——一个域名对一个账户只有一把——应用若需要更多派生层级，只能拿这把密钥当作初始熵，在它上面另开一棵 HD 树，而树的结构就不在标准约定之内了。同一句助记词如何对应一串账户，HD 钱包助记词、派生路径与地址的关系：换钱包地址变了怎么回事里已经讲过，App Keys 相当于在这套体系旁边又开了一条按域名寻址的支路。
Persona：同一句助记词下的多套身份
规范允许你用不同账户索引去派生不同的应用密钥组：生活侧用索引 0 的账户做基准，工作侧换另一个账户做基准，于是你在同一个域名下会得到两组完全不同的地址，应用端无法知道两者背后是同一句助记词。这比分开保管两套助记词省事——备份仍然只有一份——隔离却接近两套钱包。规范把这种用法称为 persona，同一套机制也可以用来给一个应用配多个辅助账户，由一个主账户做身份锚点。
权限侧与签名委托
App Keys 的另一半价值在权限模型：它设想与 EIP-2255 的权限请求机制配合，应用申请到的只是一项”可以请这个应用密钥签名”的能力，钱包因此可以对这类签名放松确认强度——反正里面没钱，风险可控。规范还专门描述了一种”签名但先不广播”的操作：钱包替应用把交易签好存着，需要时再由别人替它上链。这类委托签名能力，后来在意图撮合与授权委托一系列提案里被反复沿用。
状态与使用边界
必须把现状讲清楚：ERC-1775 的官方状态是 Stagnant，也就是说它不是哪家主流钱包都实现的功能，主流钱包的”每个网站记住不同账户”更多是钱包内部的账户索引加权限系统，而不是严格按域名派生密钥。给用户三条纪律：第一，按应用隔离账户的思想值得借——用主地址直接连高关联度的应用，等于把自己的全部历史一次性展示给对方，地址画像与聚类风险在NFT 持仓会被链上画像吗？地址聚类风险与隔离方案里讲过；第二，派生必须发生在你控制的钱包或设备里，任何网页或工具让你贴主私钥来”帮你算应用密钥”，一律按盗钥处理；第三，应用密钥若接收过入金，资金链路会把它和主账户重新关联，隔离只覆盖签名行为本身。派生路径的阅读方法见BIP-44 派生路径怎么读：为什么同一句助记词，导入后地址却不一样。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。