Starknet 上没有"普通地址"：账户合约的四个必选函数

没有”外部账户”的链

在以太坊里，地址分两种：由私钥直接控制的外部账户（EOA），和由代码控制合约账户。Starknet 取消了第一种——在这条链上，你的账户本身就是合约。官方文档明确说 Starknet 原生支持账户抽象，思路与以太坊 EIP-4337 同源：用带任意验证逻辑的智能合约账户替代 EOA。区别只是执行层的位置：以太坊上的账户抽象要靠打包器、入口合约和支付方一整套外围设施拼出来，Starknet 则把它写进了协议的交易规则里。

固定签名方案的代价在文档里被列得很直白：一把私钥等于账户的全部控制权，助记词必须永远安全地拿着；钱包功能被签名方案锁死，加多签、轮换密钥、限制花费都要靠链下服务或合约封装来打补丁。

四个必选函数：账户合约的”岗位说明书”

Starknet 判断”一个合约有没有资格当账户”的办法非常朴素：看它有没有实现规定的函数。官方文档给出的清单是——

• __validate__：任何调用交易都必须执行，用来验证交易签名；
• __execute__：验证通过后真正执行交易内容，文档要求它与 __validate__ 的函数签名完全一致；
• __validate_declare__：账户要替新合约类做声明（Declare）交易时必需；
• __validate_deploy__：账户要部署自己的实例、即首次上链时必需，参数是账户合约的类哈希与计算账户地址用的盐值（salt）。

这套设计意味着”账户长什么样”完全由项目自己写代码决定：签名可以用 Stark 曲线，也可以用别的加密方案；可以一个签名都不验直接放行测试网；也可以实现多重签名、会话密钥、每日限额。验证逻辑任意，正是把 EOA 的僵化换来的一面。验证与执行拆成两个入口还有一层用意：钱包或路由可以先用验证函数判断一笔交易有没有资格进场，再让执行函数处理业务，两段的接口形状被协议强制对齐，第三方就能用统一姿势预判交易，而不用猜每个账户的内部实现。

地址从哪来、怎么”先有身份后部署”

Starknet 的账户地址不是随机串，而是由类哈希、部署者地址、构造参数和盐值共同派生出来的。这带来一个和以太坊部署类似的结构：你可以先按规则算出自己的账户地址，把资产转给这个还没部署的账户，再在真正发起第一笔交易时用 __validate_deploy__ 顺带完成账户部署。文档同时提醒账户有自己的交易序号（nonce），签名消息里带上序号就是防重放的标准手段。

硬币的另一面：自由带来的新责任

账户抽象不是免费的午餐，至少有三条边界值得写在使用者的检查清单上。

第一，验证逻辑是代码，代码可以有 bug。EOA 的风险在私钥，Starknet 账户的风险多了一份”验签函数本身写错或被改坏”的可能，尤其是老版本账户合约升级逻辑的权限归谁，要事前看清。第二，任意签名方案也意味着任意授权话术：一个用”会话密钥”的钱包可以让小额操作免签名，便利的边界完全由那部分合约代码说了算，用户需要理解自己签过的规则而不是只看界面。第三，账户模型不改变二层网络自身的信任结构——排序、数据发布与证明提交由谁执行、出问题时怎么退出，是另一层问题，不能因为”账户能自定义验证”就推论整条链免信任。

对普通用户，可以核对的点很具体：在区块浏览器里看一笔 Starknet 交易，调用方地址对应的是合约账户；查询该地址的类哈希能知道它用的是哪套账户实现；账户有没有做过升级、升级给谁触发，属于需要自己留意的链上痕迹。

最后提示：本文机制描述以 Starknet 官方文档为准，各版规范仍在演进；自定义签名逻辑不消除私钥丢失、合约缺陷与二层数据可用性的固有风险，文中内容不构成投资建议。