一句话定位
脚本less 脚本是一族用密码学协议代替脚本语言实现合约逻辑的思路：付款条件不出现在锁定脚本里，而是编码进签名协议本身——要么凑齐协作方才产生有效签名，要么签名本身携带解锁另一笔支付所需的秘密。链上验证者只核对一个普通签名，复杂度被藏进了签名生成过程。它与脚本语言不是取代关系，而是”哪些条件用协议表达更便宜”的分工问题。
适配器签名：让付款交出秘密
代表性构造是适配器签名：把”付款”设计成必须同时交出某个秘密的签名。构造者在真实密钥上叠一层加密，签名者只能生成一个适配器签名；它无效——直到被加密的那部分秘密被解出，签名才转正；而解密的动作本身就把秘密暴露给对手方。把秘密定义成”一条通道的惩罚交易密钥”，就得到闪电网络里让违约自动被惩罚的机制雏形；把秘密定义成哈希原像，就得到链上看不到哈希锁、只看到普通支付的原子交换。这类构造的验证端零脚本负担，链上痕迹只有一笔标准交易。
门限与聚合：把多人凑成一把钥匙
脚本less 脚本的第二根支柱是签名聚合：MuSig 类协议把 n 个公钥折成一个，签名过程需要 n 方协作，验证走普通路径；FROST 类协议做 t-of-n 门限，同样链上隐形。在 Taproot 里，这类方案占据密钥路径：参与者列表与门限规则只存在于链下的密钥聚合约定里，链上只看到一个经过调整的公钥。脚本路径则留给时效、分支这类确实需要公开承诺的条件——两者正交，组合使用。
分工：什么该进协议，什么该进脚本
判据有三条。可验证性：条件的不满足必须能被密码学机制证明，靠人裁决的不算；协调成本：多轮交互的协议对掉线敏感，时效性强的条件放脚本更稳；隐私与体积：参与方名单不想公开的，适合聚合路线。原子交换里双方可以离线协商适配器交换，而”到期可退”这种全局时间条件不适合密码学表达，用 CSV 时间锁反而简单——现代方案普遍是混合体：聚合公钥加脚本树。
快速问答
问：脚本less 脚本比智能合约弱吗？ 答：表达能力不同，不是强弱。它擅长”协作即条件”的结构，无法直接表达需要链上状态判断的逻辑。
问：它依赖 Schnorr 吗？ 答：聚合路线依赖可线性组合的签名方程，Schnorr 是现成载体；适配器类构造本身不必然依赖，但工程上常基于同一曲线体系。
问：用这类技术的安全注意点是？ 答：协议交互轮次里的状态机与重放防护——私钥安全之外，掉线重试、并发会话隔离是事故高发区。
一个容易卡住的点
初学者常问：适配器签名在秘密被解出之前对所有人无效，那被中间人截获怎么办？答案是无效签名花不掉也偷不走，这正是无效的含义。攻击面因此从签名被盗移到了协议交互被搅局：重放、并发会话、顺序错乱才是这类方案真正要防的事故。选型时考察实现方的状态机测试覆盖，比考察密码学论文更能预测线上表现。
部署视角的检查表
上线一套基于适配器或聚合的方案前过一遍：密钥仪式由谁主持、参数是否可审计；会话标识能否防并发；协议在对手方拒不收尾时是否有退款路径；参与方列表变更时旧承诺如何失效；升级时旧地址的支出路径是否保留。每一条在历史上都有对应的事故案例，答不出的项目等于把工程债押在了用户身上。
风险提示：本文仅作技术科普，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。