备注：下文只做简单的翻译，没有做校验

哈希时间锁定协议（HTLAs）

泛化散列-Timelock合同（HTLCs）用于保护Interledger付款。

本文档假定您熟悉HTLC和Interledger。它简要地总结了两者，但在IL-RFC 1：Interledger架构之后它可能是最好的阅读。

Interledger使用条件转移提供安全的多跳付款。一些分类帐原生地使用散列时间锁合同（HTLC）提供有条件的转帐。但是，并非所有分类帐都支持HTLC。

哈希时间锁定协议（HTLAs）是可以通过任何类型的分类账实现的HTLC的泛化，无论分类账是否支持HTLC。HTLAs与公共和私人区块链，集中账本，支付渠道以及没有账本的现金或案例一起工作。有一系列HTLA类型需要不同级别的分类帐功能和双边信任。本文档介绍了HTLAs如何工作并概述了不同选项的功能和权衡。

注意：Interledger付款可以同时安全地跨越多种类型的HTLAs。HTLA类型的选择完全是双边决定。所使用的HTLA类型不影响路径中其他人的安全。有关详情，请参阅Interledger跨多种HTLAs。

目录

1. 哈希时间间隔合同背景（HTLC）
2. 哈希时间锁定协议（HTLAs）
3. HTLAs没有帐簿支持
4. Interledger跨越多种HTLAs
5. HTLA类型的频谱
   1. 条件支付渠道（使用HTLC）
   2. 总账持有/托管（使用HTLC）
   3. 简单的付款渠道
   4. Trustlines
6. 附录：其他HTLA类型

哈希时间间隔合同背景（HTLC）

甲散列-Timelock合同（HTLC）是一个条件转移，其中条件是由分类帐执行。这是比特币社区在雷电网络中使用的一个概念。

当转账“准备好”时，发送者的资金将被分类账暂停，等待满足预定条件。条件是散列表，或者加密散列函数的摘要，例如Lightning和Interledger中的SHA-256。“合同”规定，收件人可以通过在给定超时之前提供散列摘要的有效原像来索取资金。超时后，资金将自动返回给发件人。这是哈希时间锁定合约。

HTLC由分类账强制执行，因此交易双方只需要相信分类账正确执行合同。但是，此机制需要来自分类帐的支持，并且只能与实施散列码和超时的分类帐一起使用。

Interledger旨在与所有分类账一起工作，所以它必须支持带和不带对散列码和超时支持的分类账。

哈希时间锁定协议（HTLAs）

合同是由第三方执行的某种类型的协议。哈希时间锁定协议（HTLAs）将HTLC的概念概括为包含由分类账实施的协议。自该项目开始以来，Interledger一直在使用该原则，但最近在Interledger邮件列表的这个主题中提出了HTLA术语。

HTLAs支持通过所有类型的分类账进行安全的Interledger支付，包括那些不支持条件转账的分类账。

HTLAs没有帐簿支持

使用HTLA而不支持散列码和超时的分类账的两方可以按照以下方式进行。发件人会向收件人发送一条消息，告诉他们他们希望用给定的散列锁和超时“准备”传输。双方同意，如果收件人在超时之前显示哈希的原始图像，则执行转移并且发件人向收件人欠款。债务通过账簿上的简单转账结算。

如果是邮政资助协议，发件人可以向收件人清偿债务，如果分类账速度快且收费低，或者欠款总额达到各方的信任/信用限额，则可以每次付款。在这种情况下，收件人必须相信发件人支付他们欠款。风险可以通过限制发件人在结算之前发送多少来限制。

对于预先资助的协议，发件人将个人付款金额或批量金额转移给收件人。然后收款人从预付款额中扣除每笔“有条件转账”的金额。在这种情况下，发件人必须信任收件人不要窃取预先资助的金额，但这种风险显然可能受限于预先资助的金额。

HTLAs因此可以与支持散列码和超时的分类帐（如HTLC）以及不支持的分类帐一起使用。

有关HTLAs更多细节，而不会台账支持见下面的章节上简单的支付渠道和Trustlines。

Interledger跨越多种HTLAs

一次Interledger付款可以跨多种不同类型的HTLAs。Interledger协议确保每个HTLA的安全性独立于路径中使用的其他HTLA类型。

这是理解HTLAs和Interledger的关键，因此我们将使用示例流程来说明它。

付款流程示例

在经典的Alice到Bob支付的这种演绎中，Alice在实现HTLC的区块链上有一个帐户，Bob有一个帐户与没有实现HTLC的银行：

        On-Ledger HTLC                 Payment Channel                  Trustline
Alice --(Blockchain A)--> Connector 1 --(Blockchain B)--> Connector 2 --(Bank C)--> Bob

每个--(...)-->代表不同类型的HTLA，但它们都使用相同的散列锁。

Interledger协议流程（详述如下）确保每个参与者只需关心他们直接参与的HTLAs。在路径的不同部分失败 - 或选择看似不明智的HTLA类型 - 不会影响任何其他协议。

Interledger协议支付流程：

1. Alice并Bob同意这个散列表H。P只有知道前像Bob（并且Alice在PSK的情况下）。
2. AliceConnector 1通过Blockchain A使用散列锁创建和资助HTLC 来准备转移H（请参阅On-Ledger Holds / Escrow）。
3. Connector 1Connector 2通过他们的共享付款渠道准备转账，也使用散列码H（参见简单付款渠道）。
4. Connector 2Bob使用Hashlock 准备转移到其共享的信任线上H（请参阅Trustlines）。
5. 如果在传输超时之前Bob产生原像P，Connector 2将Bob通过增加其信任线上的余额来“付费” 。
6. 如果Connector 2发送P到Connector 1他们的转移超时之前，Connector 1将发送一个签名的索赔支付Connector 2。（请注意，Connector 1实际上是否与路径中的其他方无关，Connector 2已经支付Bob并且不能撤销，Connector 1可以提交原始图像Blockchain A并且仍然拒绝提出要求，Connector 2这是已知和可管理的风险Connector 2和其他方面都没有受到影响。）
7. 如果Connector 1的提交P到Blockchain A超时之前，转移被执行，Alice将接收证明P该Bob支付。（请再次注意，HTLC Blockchain A是否正确执行只与Alice和有关Connector 1。分类帐的属性仅对持有该分类帐上的帐户的当事人很重要。）

想到这一点的一种方式是HTLAs抽象出“获得报酬”的含义。这只是双方之间的协议，没有人关心这是如何构建的。重要的是每个人都对他们直接参与的协议感到满意。由于所有的哈希锁都是相同的，要么所有的传输都会发生，要么都不会（禁止连接器实现失败）。

有关Interledger协议套件和安全性的更多详细信息，请参阅IL-RFC 1：Interledger体系结构。

互联网“帽子提示”：能够集成任何类型网络的重要性已由RFC 1149：“在Avian运营商上传输IP数据报的标准”证明。

HTLA类型的频谱

各种类型的HTLAs在复杂性和风险之间进行权衡。分类账提供的功能越多，该分类帐的用户就越需要互相信任。

条件支付渠道（使用HTLC）

• 需要分类帐功能：使用HTLC更新的付款渠道
• 非功能分类帐要求：快速*
• 风险货币：无
• 示例： 闪电式频道 *

通过有条件的支付渠道，参与者通过在分类账上的共享临时账户中存入资金来设置渠道。准备好条件传输时，发件人会将收件人签名的更新发送到包含散列码和超时的频道。收件人可以赎回转移金额，当且仅当他们可以在超时之前呈现散列原像。如果发件人和收件人同意在超时之前传送原像，他们可以用新约定的频道余额交换签名的声明。如果有争议，收件人可以将最后的声明和散列预映像显示在分类帐上，并且分类帐将决定预映像是否有效并在超时之前提交。

使用有条件的付款渠道，发件人和收件人可以在没有任何资金风险的情况下进行交易，因为所有的争议都将由账本进行调解。这可以被用作一种机制，以便通过分类帐支持比分类账本来可以支持更多的支付量。

* 关于账本速度的说明：有条件的付款渠道可能最适合快速分类账，因为每次转账的超时都必须考虑分类账的处理时间。收款人依赖这样的事实：即使与发件人之间存在争议，他们也可以通过将其索赔和散列码preimages提交给分类账，从而赎回他们的资金。但是，发件人和连接器需要或要求Interledger付款快速执行或失败（例如重试和降低汇率风险）的原因很多。因此，如果分类账可以在几秒钟或更短的时间内处理索赔，则条件付款渠道只能与Interledger一起使用。

总账持有/托管（使用HTLC）

• 总帐功能要求：使用HTLC进行转账
• 非功能分类帐要求：快速，低费用，高吞吐量
• 风险货币：无
• 示例： 以太坊托管合同，XRP托管

如果分类账提供对HTLC的支持并且速度快而且价格便宜，参与者可以直接通过分类账发送所有Interledger支付。发件人通过将资金投入到分类帐提供的保留帐户中，以等待给定的散列锁和超时来准备条件转移。如果收件人在超时之前显示散列原始图像，则分类账将执行转账并自动将资金存入收款人的账户。如果达到超时，分类账将资金返还给发件人。

使用分类账提供的条件转账可以使各方无风险地进行交易，但分类账必须能够快速处理大量付款并且收费较低。

简单的付款渠道

• 总帐功能要求：无条件，单向付款渠道
• 非功能分类帐要求： N / A
• 风险资金：无索赔合计/无履行
• 示例： 比特币CLTV频道，XRP PayChan

简单的支付渠道允许各方发送比分类账可以自行处理更多的付款。为了建立一个简单的单向付款渠道，发件人将资金存入与收款人分享的分类账中的临时账户。资金只能通过提交双方签署的索赔从分类账中提取，该索赔指定将转移给收款人的资金部分和将返还给发件人的金额。发件人通过向收件人发送签名声明（而非账本），有效支付收件人，使收件人有权收回频道资金的大部分。

要在HTLA中使用简单的付款渠道，发件人仅通过向收件人发送邮件（包括散列码和超时）来“准备”条件传输。如果收件人在超时之前显示散列原像，发件人会向收件人发送一份新的签名声明以涵盖迄今为止发送的总传送量。

发件人和收件人之间的协议规定如何处理纠纷，包括收件人认为他们及时提交了原像并且发件人认为不是这样的情况。双方应该强制自己对暂停的看法，而不是推迟到对方。

在这种后投资模式中，收款人必须相信发件人已经完成支付渠道索赔尚未涵盖的准备或执行的转账总额。收件人通过限制他们愿意接受发件人的转账金额来限制他们的风险，而没有相应的索赔。发件人可以通过发件人预先为每次转账预付款项，并将信息与信息一起准备转账，从而将收款人风险转移给发件人。使用简单的付款渠道进行预先筹资会稍微复杂一些，因为如果转账回滚，收件人需要将其他付款渠道更新发送回发件人。

简单支付渠道所需的功能目前几乎包括比特币（甚至没有SegWit），以太坊，XRP，Zcash和连锁店。

Trustlines

• 账簿的特点：账户之间的转账
• 非功能分类帐要求： N / A
• 风险资金：信托基金余额总额
• 例子： ilp-plugin-virtual

当分类帐不支持Interledger时，各方仍可使用信任线连接到Interledger。发件人通过向收件人发送包含散列码和超时的消息来准备传输。如果收件人在超时之前生成散列图像，发件人的债务将增加转帐金额。与简单的付款渠道一样，参与者必须就如何解决争议达成一致，其中包括关于是否及时提交散列原始图像的意见分歧。发件人可以继续发送付款，直至达到收件人允许的最大余额。此时，寄件人通过在账本上转账来结清余额。

在这种模式中，其中一方必须信任另一方以获得信任线的全部未清余额。这可能适用于发件人和收件人是朋友或有长期业务关系的情况。

值得注意的是，信任线可以处理任何类型的“分类账” - 包括现金！只要在发送方和接收方之间有转移资金的方式，他们就可以发送Interledger付款并仅在达到信任限额时结算。如果双向支付流量是平衡的，那么甚至可能永远不需要解决。

附录：其他HTLA类型

本附录包含其他可能的HTLA类型，但以上没有提及，因为它们不太理想或尚未实施。

第三方托管

如果分类账支持快速，廉价的转账，但不支持扣款并且发件人和收件人不相互信任，则可以使用第三方托管提供商。在这种情况下，发件人通过将资金与散列码和超时值一起发送给托管提供商来准备转移。如果收件人在超时之前提交了散列预映像，托管提供商会将资金转移给收件人。如果不是，托管提供商将资金转回。

优选的是，分类账实现保持本身，但这种类型HTLA可以的情况下这是不可能的或不发生使用。无论是由于信誉还是法律安排，发件人和收件人都必须信任托管提供商以获取每次转让的全部价值。如果发件人和收件人做到互相信任了一些限制，他们可以通过使用Trustlines避免第三方的需要。

公证的付款渠道

由于超时时间不一致，可能会在基于付款渠道的HTLA中发生争议。既然有真相至于hashlock原像是否及时提交任何单一来源，时钟偏差或网络延迟可能导致收件人认为，而发送者认为它过期的转移应该被执行。

为了减轻超时纠纷的风险，发件人和收件人可以同意使用第三方公证人担任计时员。发件人通过向公证人和收件人提交详细信息来准备转移（除非公证人也充当信息经纪人）。收件人将preimage提交给执行超时的公证人。公证人签署一份声明，证明原像是否及时收到，并将签署的信息发给发件人和收件人。

第三方公证员可以使用简单或更复杂的付款渠道。在简单的，无条件的类型中，公证人的决定不用于实际的支付渠道更新，而仅仅是公证人作为发件人和收件人之间协议的决策者。在更复杂的品种中，可以构建支付渠道，使得频道更新取决于公证人的签名声明。当使用第三方公证人时，发件人和收件人必须相信公证人不与当事人之一勾结，并且不签署两个相互冲突的陈述。

第三方支付渠道

在第三方托管和公证支付渠道的担保之间，“第三方支付渠道”涉及在支付渠道中托管货币，并赋予第三方权力来提出索赔。要设置付款渠道，发件人会在简易付款渠道中为分类帐中的临时帐户提供资金。但是，第三方的密钥有权在频道余额上创建声明，而不是使用发件人的公钥。

当发送者准备转移时，他们会向接收者发送消息，包括散列锁和超时。为了执行转移，收件人将原始图像提交给第三方。如果第三方在超时前获得了原像，他们通过签署新的索赔从发件人的资金中支付收件人。

在这种模式下，收件人根本不需要信任发件人。相反，接受者相信第三方会诚实地执行超时，并在及时提交preimages时签署索赔。这意味着收件人只需要信任第三方就已经执行但尚未被索赔覆盖的转账。

发件人必须相信第三方不会创造比他们欠的更多的索赔，这意味着他们相信第三方的付款渠道的整体平衡。但是，除非第三方与接收方勾结，否则他们没有支付超过发送方欠款的动机。

最后

以上就是阳光毛衣为你收集整理的哈希时间锁定协议（HTLAs）哈希时间锁定协议（HTLAs）的全部内容，希望文章能够帮你解决哈希时间锁定协议（HTLAs）哈希时间锁定协议（HTLAs）所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。