跳到主要内容

003 · 内容获取请求需求

要解决什么​

买方已经选中报价并拥有可用费用池后，需要向卖方提出“请交付这个确定内容”的请求。请求必须让卖方能够验证：买方选择了自己的哪份报价、使用哪个池的当前支付能力、选了哪个仲裁者、要种子还是某个文件块，以及最晚何时交付。

它不是 005 交易签名，但它已经签入验货后应执行的最终累计金额和目标序号；买方尚未验货，费用池金额仍未推进。

内容怎样定位​

请求内容只有两类：

  • Seed：请求报价对应的 seed；内容哈希必须等于报价中的 SeedHash。
  • Block：请求一个文件块；内容哈希必须存在于已获得 seed 给出的文件块哈希列表中。

种子包含文件块哈希列表，因此块索引、块实际大小和尾块身份都能从 seed 推导。请求中不重复发送块索引或大小。文件块可以按任意顺序请求；“通常先获得 seed”是内容发现流程，不是支付序号的含义。

费用池怎样定位​

买方选择一个可用池及其当前最新累计支付状态：

SpendTxID + BasePaymentSequence

BasePaymentSequence 是费用池状态版本，不是块序号、不是请求序号，也不表达种子与块的顺序。买方可选择任意一个自己的可用池，但只能使用该池当前最新状态。

同一个池不能同时被卖方接受为多张未完成请求，否则同一笔余额会被重复承诺，买方可能在卖方交付多个内容后只支付其中一笔。这是卖方的本地运行约束；它不把数据库变成真值，卖方保存的已签名支付状态才是依据。具体的原子门闩、持久化及释放时机见 005。

买方在 003 中签入该序号、绝对累计金额和固定费率，并不要求卖方对这些字段反签确认。卖方可以交付 004，也可以拒绝或不作为；若卖方无法正常提交且买方拒签 005，卖方可按 007 使用这张最终授权请求仲裁。

为什么只带引用​

请求携带 QuoteTermsHash，而不重复报价原文。该哈希让卖方在多份报价中精确找到被选中的条款；卖方验证原始报价和签名后，才能验买方的请求签名。

请求本身再产生 PaymentAuthorizationHash。004 用它引用授权，005 用它把付款和具体取件关联；007 只提交完整 003 授权和费用池执行材料，不要求仲裁者读取 001、004、payload 或历史付款链。

具体字段和校验规则见内容获取请求规范。