ILP(Interledger)预共享密钥V2（PSKv2）传输协议
备注：下文只做简单的翻译，没有做校验
目录
- 概观
- 与其他协议的关系
- 建立
- 加密
- 条件和履行
- 端到端的报价
- 操作模式
- 信息报价
- 单笔付款
- 规范
- 加密
- 数据包
- 条件和实现生成
概观
与PSKv1一样，PSKv2使用发件人和收件人之间共享的秘密来生成支付条件和履行情况，而无需重复的端到端通信。PSKv2可用于发送单个数据包或多个数据包，以及可用于报价的无法实现的测试支付。
与其他协议的关系
PSKv2旨在与ILPv4 Prepare，Fulfill和Reject数据包配合使用。
应用程序或更高级别的协议可能会使用PSKv2来发送个别请求和响应或信息引用。
PSKv2不包含分段和重新组合分组的功能，但它可以用于实现此类功能的更高级协议。这些更高级别的协议可能会在PSK数据包的数据字段中包含附加字段，以对各个请求和响应进行分组或排序。
建立
在使用PSKv2之前，发送者和接收者使用经过验证的加密通信通道（通常作为应用层协议的一部分提供）进行交换：
- PSK版本（比如
2.0这个版本） - 一个32字节的随机或伪随机共享密钥
- 接收者的ILP地址
接收者可以根据长期秘密和随机数生成共享密钥，如PSKv1的附录A：推荐的生成共享秘密算法中所述。在这种情况下，接收方会将随机数（不是秘密）附加到他们的ILP地址，以创建与发送方通信的目标地址。
加密
在PSKv2.0中，使用带有12字节初始化向量（IV）和16字节身份验证标签的AES-256-GCM对请求和响应数据进行加密。
如果后续版本支持额外的加密算法，那么在发送者和接收者建立预共享密钥时应该交换这些详细信息。如果接收方试图解密传入的数据包，但无法（可能是因为发送方使用不支持的密码），他们应该拒绝传入的传输并发生F06: Unexpected Payment错误。
条件和履行
发送方和接收方使用为该协议命名的预共享密钥生成条件和履行。该履行是从预共享密钥和加密的PSK数据中计算出来的。条件是实现的散列。
与在PSKv1中一样，这种生成条件和履行的方法可以为每个支付发送无需端到端通信的许多付款。但是，由于发件人也事先知道履行情况，因此两种PSK版本都不允许发件人将履行情况用作不可否认的付款证明。对于需要这种情况的用例，应该使用Interledger支付请求（IPR）等传输协议。
端到端的报价
与依赖于Interledger报价协议（ILQP）的 PSKv1 相比，PSKv2有两种内置的机制来发现给定路径的交换率：信息报价和动态价格发现。
对于纯信息报价，PSKv2使用无法实现的测试支付给接收方来确定给定路径的汇率。该条件设置为随机的32字节条件（没有已知的满足）。当收款人收到收款时，他们会拒绝收到的转账，并在收到的回复中包含多少收到的转账。发送者可以使用他们设置的源数量和接收者的响应来确定速率。
当发送者向接收者发送多笔付款时，他们需要动态查看汇率，因为汇率在交易过程中可能会发生变化。为了处理这些情况，每个PSKv2支付响应都包括最终传送给接收方的金额。与信息引用类似，发送者可以使用数据包的源数量和接收者的响应来确定和监控汇率。
按来源单位来判断价格：对于任何类型的Interledger报价，无论是端到端还是使用ILQP，发件人都应该在其来源单位中判断价格。接收者可以说谎在报价的测试支付中获得多少钱，或者他们可以运行自己的账本和连接器，这些支出和连接器碰巧汇率不佳。因此，发送者必须假设接收者说到达的数量代表了路径的“真实”速率。
线性汇率和固定目标金额报价：端对端报价对线性汇率最有效。如果路径速率是线性的，则可以通过发送任意数量的单个测试支付来确定。提供固定目标金额所需的来源金额可以通过将来源金额除以金额来轻松确定。如果汇率是非线性的，那么获得一个固定目标金额的信息报价将需要二分查找，这并不理想。但是，在主要或专门适用于小额付款的Interledger网络中，利率因支付规模而异的原因应该很少。
操作模式
信息报价
- 发件人创建一个类型为4的数据包，一个随机请求ID，并将请求数量设置为2 ^ 64 - 1（最大无符号64位整数或18446744073709551615）。发送方使用使用加密伪代码中描述的方法导出的加密密钥对分组进行加密。
- 发送方生成一个随机的32字节条件。
- 发送方发送一个ILP准备数据包，其中包含条件，加密数据和选定的源数量（在固定源支付的情况下）或任意数量（在目标数量固定的情况下）。
- Receiver将收到传入的Prepare数据包，按照Encryption Pseudocode中所述重新导入加密密钥，并解密PSK请求。
- Receiver将请求中的请求金额与它们收到的Prepare包中的金额进行比较。他们注意到传入的转账金额太低。
- Receiver使用发件人的请求中的相同请求ID创建PSK错误数据包，并将请求数量设置为到达Prepare数据包的数量。接收器使用与以前相同的加密密钥对数据包进行加密。
- 接收方使用拒绝数据字段中包含加密的PSK错误数据包的ILP拒绝回复ILP准备数据包。
- 发送方获取ILP拒绝数据包，解密PSK错误，并将接收方的请求金额除以发送方在原始ILP准备数据包中发送的金额，以确定近似路径交换率。
单笔付款
- 发件人确定数据包的源数量和最小目标数量，可能使用由信息报价或发送先前请求确定的汇率。
- 发件人使用随机请求ID创建PSK请求，并将请求金额设置为步骤1中确定的目标金额。发件人可以在PSK请求中包含附加数据。发送方根据加密伪代码中的描述导出加密密钥并加密请求。
- 发件人按照“可充值条件”中的说明生成条件。
- 发件人使用步骤1中确定的源数量，步骤3中的条件和步骤2中的加密请求作为数据发送ILP准备。
- Receiver将收到ILP Prepare数据包的通知，按照Encryption Pseudocode中所述重新导入加密密钥，然后解密数据。（如果接收方
F06: Unexpected Payment无法解密数据，应该返回带有代码的ILP拒绝） - 接收方检查以确保ILP准备数据包中的数据量大于或等于PSK请求中指定的请求数量。接收者应该返回一个带有代码
F99: Application Error和一个加密的PSK错误包的ILP拒绝包，其中包括作为数据到达准备的数量。 - Receiver使用相同的请求ID和请求金额设置为到达ILP准备数据包的数量创建一个PSK响应。接收器然后使用相同的加密密钥加密数据。
- Receiver按照下面的描述生成履行并通过履行和加密的应答数据完成传入转账。如果接收方
F05: Wrong Condition无法重新产生正确的条件，应该返回带有代码的ILP拒绝。 - 发送方获取ILP Fulfill数据包并从数据中解密PSK响应。如果请求ID与原始请求不匹配，或者PSK数据包不是响应类型，则它们应该忽略该响应。他们可能会使用响应中的请求金额来估计路径汇率。他们也可以使用来自接收器的PSK响应中的数据。
规范
加密
请求和响应数据使用带有随机12字节初始化向量（IV）和16字节认证标签的AES-256-GCM进行加密。
加密信封
另请参阅ASN.1定义。
(Numbers represent bytes)
4 8 12 16 20 24 28 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random IV | Authentication Tag | Ciph..|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ciphertext |
\ \
\ \
| Ciphertext |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 领域 | 类型 | 描述 |
|---|---|---|
| 随机四 | 12字节的UInt | Nonce用作AES-GCM算法的输入。也确保条件是随机的。发送者不能加密具有相同随机数的两个数据包 |
| 认证标签 | 16字节的UInt | 通过AES-GCM加密产生的认证标签可确保数据完整性 |
| 密文 | 0-32739字节 | 加密数据（请参阅下面的内容） |
加密伪代码
请注意，加密密钥是使用HMAC从共享密钥导出的。
iv = random_bytes(12)
encryption_key = hmac_sha256(shared_secret, "ilp_psk_encryption")
{ ciphertext, auth_tag } = aes_256_gcm(encryption_key, iv, data)
数据包
所有PSKv2.0请求和响应都以相同的字节格式对其数据进行编码，但字段的含义取决于它是请求还是响应。
如上定义，以下内容被加密，并且被设置为ILP Prepare，Fulfill或Reject数据包中的数据。
另请参阅ASN.1定义。
(Numbers represent bytes)
4 8 12 16 20 24 28 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| ReqID | Request Amount| Application Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Data |
\ \
\ \
| Application Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Junk Data |
\ \
\ \
| Junk Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
请求
PSK请求数据包只能在ILP准备数据包中发送。
| 领域 | 类型 | 描述 |
|---|---|---|
| 类型（T） | 总是4（UInt8） |
表示这是PSK2请求。如果请求数据包不在ILP准备数据包中，应该被拒绝或忽略。 |
| 请求ID（ReqID） | UInt32的 | ID用于关联请求和响应。发送者不能依靠接收者实施唯一性，但他们应该确保响应携带与发出请求相同的请求ID |
| 请求金额 | 答：64 | 应该到达ILP的最小数量为接收方准备数据包以实现它。当请求数量大于ILP准备金额时，接收方不应接受数据包 |
| 数据 | OER可变长度字节串 | 随付款一起携带的用户数据。请注意，这些数据是经过加密和认证的 |
| 垃圾数据 | 0-？字节 | （可选）包含的额外数据用于掩盖ILP付款的用途。接收器应该忽略这些数据。该协议的后续版本可能会定义额外的字段，在data字段和旧的实现将简单地忽略这些字段。 |
响应
PSK响应数据包只能在ILP Fulfill数据包中发送。
| 领域 | 类型 | 描述 |
|---|---|---|
| 类型（T） | 总是5（UInt8） |
表示这是PSK2响应。如果响应数据包不在ILP Fulfill数据包中，应该被拒绝或忽略。 |
| 请求ID（ReqID） | UInt32的 | ID用于关联请求和响应。接收者必须在其响应中使用与请求中相同的请求ID。发件人应该忽略其请求标识与原始请求不匹配的响应。 |
| 请求金额 | 答：64 | 到达ILP准备数据包的金额。这用于帮助发件人确定路径交换率以及接收者的收益。请注意，发件人必须信任接收者诚实地报告。 |
| 数据 | OER可变长度字节串 | 随付款一起携带的用户数据。请注意，这些数据是经过加密和认证的 |
| 垃圾数据 | 0-？字节 | （可选）包含的额外数据用于掩盖ILP付款的用途。接收器应该忽略这些数据。该协议的后续版本可能会定义额外的字段，在data字段和旧的实现将简单地忽略这些字段。 |
错误
PSK响应数据包只能在ILP拒绝数据包中发送。
| 领域 | 类型 | 描述 |
|---|---|---|
| 类型（T） | 总是6（UInt8） |
表示这是一个PSK2错误。如果响应数据包不在ILP拒绝数据包中，应该被拒绝或忽略。 |
| 请求ID（ReqID） | UInt32的 | ID用于关联请求和响应。接收者必须在错误中使用来自请求的相同请求ID。发件人应该忽略其请求标识与原始请求不匹配的响应。 |
| 请求金额 | 答：64 | 到达ILP准备数据包的金额。这用于帮助发件人确定路径交换率以及接收者的收益。请注意，发件人必须信任接收者诚实地报告。 |
| 数据 | OER可变长度字节串 | 随付款一起携带的用户数据。请注意，这些数据是经过加密和认证的 |
| 垃圾数据 | 0-？字节 | （可选）包含的额外数据用于掩盖ILP付款的用途。接收器应该忽略这些数据。该协议的后续版本可能会定义额外的字段，在data字段和旧的实现将简单地忽略这些字段。 |
条件和实现生成
发件人可以使用两种方法来生成条件，具体取决于他们是否希望付款能够完成。
无法实现的条件
如果发件人不希望收件人能够履行付款（如信息报价），他们可以产生一个无法实现的随机条件。
condition = random_bytes(32)
充满条件
如果发送方确实希望接收方能够满足条件，则必须按照以下方式生成条件。
这shared_secret是预先共享的密钥，它给这个协议起了名字。这data是加密的PSK请求。
hmac_key = hmac_sha256(shared_secret, "ilp_psk2_fulfillment")
fulfillment = hmac_sha256(hmac_key, data)
condition = sha256(fulfillment)
履行世代
以下伪代码详细说明接收器如何从数据重新生成履行。
注意：发件人可以使用无法实现的条件来获取信息报价。接收者必须返回一个错误响应数据包，其中包含到达传入传输时的数量，即使它们无法从请求重新生成履行。
这shared_secret是预先共享的密钥，它给这个协议起了名字。这data是加密的PSK请求。
hmac_key = hmac_sha256(shared_secret, "ilp_psk2_fulfillment")
fulfillment = hmac_sha256(hmac_key, data)