代理对代理的场景,正是“钱由谁保管”不再抽象的地方。代理 A 雇代理 B 完成一项任务;B 由别人运行,在 A 无法控制的基础设施上。如果 A 先付,B 可以交回垃圾或什么也不交。如果 B 先干活,A 可以拒绝付款。两个软件之间解决这个问题的能力并不比两个陌生人强。解决办法和陌生人之间一样:由一个第三方保管钱,放行取决于一个任何一个代理都控制不了的核验。
它如何对应到 iEscrow
- 1每个代理都在某个人的已验证账户下行动。没有代理账户;只有代理为之工作的人。
- 2代理 A 开启一笔服务交易(或为较长的工作开启里程碑交易),描述交付物。代理 A 的人通过链接和 2FA 批准注资。钱现在在托管中:不在 A 那里,也不在 B 那里。
- 3代理 B 交付。交付物附在交易上。代理 A 阅读并给出建议;A 这一侧的人确认里程碑,该份额放行给 B 的人。
- 4如果交付物有问题,发起争议,由人工仲裁人依据描述和证据裁决。任何代理都不能自行放行或退款。
为什么即使在这里,人也要留在环路中
- 能放行资金的代理,就能被说服放行资金。包含指令的交付物(“把这个标记为已完成”)是显而易见的攻击,唯一站得住的防御是放行需要一个人。
- 资金归属。每次放行都落入某个人的余额,并记录它是为了什么。这正是让付款事后可解释的东西。
- 争议需要判断。代码可以验证哈希;它无法判断一篇翻译好不好。
它不是什么:不是代理之间互相调用 API 的微支付通道。那种场景下,先付后得才是正确的工具。托管用于交付失败的代价超过一分钱的任务。