首页 - 文章 - 新闻 - 正文

T-FI, 新一代经济模型、交易替换及监视工具的改进

浪花财经新闻 2021年3月13日

1.76W 0 8

2月虽然短暂，但这并不意味着毫无收获。过去一个月对BOSAGORA来说恰恰相反。于上个月，最值得我们骄傲的进展是已经完成了消除协议(Slashing protocol) 。可以以适当的惩罚给予在BOSAGORA平台进行所有不当行为的用户。

以下为上个月开发活动的摘要和目前仍在开发的项目：

2月的核心开发:
每月活动

上個月, 我們共有71个与BOSAGORA相关的Pull-request和71條问题。其中:

60 个Pull-request请求
11 个Pull-request请求的合併
35 个新事项
36 个已决議的事項

已開發的功能:

#1419 通過HTC實現間接支付渠道(支付渠道，功能)

这由Drey进行。为了使 Flash 层易于使用和更具可扩展性，我们需要通过间接渠道启用支付路由。

例如，请參考以下例子：
愛麗絲 <=> 波 <=> 查理 <=> 迪倫

在此渠道布局中，爱丽丝只能向波发送闪电合約，而她卻不能将合約发送给查理或迪伦。爱丽丝需要为查理和迪伦开辟新的渠道。
不過, 这方法非常繁琐:

只会增加上锁交易的負荷
只会加重爱丽丝需要的簿记量
直到渠道开放交易被外部化为止，所有小额交易会被延迟
为所有相关方带来额外费用

通过使用哈希时间锁定合約来支持间接支付渠道。详情可参考支付渠道中 HTC 的简要说明: https://hackernoon.com/what-are-hashed-timelock-contracts-htlcs-application-in-lightning-network-payment-channels-14437eeb9345。我程序执行的引擎正如这所帮助，能够支持HTLC 和定时装置。我们可以在Flash层中透过其来实现间接支付渠道。

完成的定义：

爱丽丝可以通过中间渠道向迪伦发送小额交易
直至所有HTC 都得到解决为止, 闪存通道不会关闭
以限制性去取代HTLC延迟。例如, 若波是中间人, 可能会决定拒绝HTLC。
HTC应该要自动化

有关更多信息，请参阅下面的 Github 链接：
https://github.com/bpfkorea/agora/issues/1419

#1267 实施埃尔图(Eltoo)概念证明 (支付渠道，功能)

这由Drey进行。如#1266所述，目前有两个主要的竞争性LN更新机制。分別為LN-Penalty及Eltoo。LN-Penalty拥有三个兼容的实现方式，而Eltoo，因新的签名哈希类型(BIP 118)的要求, 仍然被禁止开发或部署在比特币上。LN-Penalty開發人員似乎也同意Eltoo進化較大, 不但会超越LN-Penalty, 甚或乎可能取代处罚更新协议。这两个协议都可以同时在比特币上使用。

就我们而言，我们比比特币有着很大的优势。因為我们可以隨時开发协议，不受软分叉(soft-fork)的要求而受阻碍。除此之外，我们的Pos系统可能使其易于创建多方渠道, 甚至可以使这种多方渠道创建成为协议规则的一部分（例如，考虑法定人数洗牌）。

作为第一步，我们可以尝试实现埃尔图的概念证明。其有许多活动部件，我们应该把目标放在最简单的概念证明上。

这可能需要以下几点：

執行证人（脚本）字段
实现非常简单的基于栈的执行引擎，及仅提供所需的操作代码（例如时间锁定、序列匹配）
实现脚本匹配的序列号(这甚至可能在以後用schnorr tricks來優化，需进行实验）
添加对sighash_noinput的支持
为多跳支付(multi-hop payment)添加HTLC 支持
分配超过4万资金用于创建频道

有关更多信息，请参阅下面的 Github 链接：

https://github.com/bpfkorea/agora/issues/1267

#1529 I 闪光层：实现洋葱加密路由(支付渠道，功能)

这由Drey进行。我们在 Flash 协议中实施了类似以下内容。

用于路由的支付包称为"洋葱"。

以洋葱类较路由付款。在从付款人（付款人）到付款目的地（收款人）的路线上，洋葱会沿着路径从节点传递到另一个节点。发件人从中心到外部, 构建整个洋葱。首先，发件人为付款人（最终）创建付款信息，并使用只有收件人才能解密的加密层对其进行加密。然后，发件人用最终收件人使用最终节点之前紧接的路径中节点的指令包装该层，并使用只有该节点才能解密的层进行加密。

这些图层由逆時方向工作的指令构建，直至整个路径被分层编码。然后，发件人将完整的洋葱交给只能读取最外层的路径中的第一个节点。每个节点都剥去一层，然后在其内部找到说明以揭示路径中的下一个节点，使洋葱得以继续传递。由于每个节点只剥去一层，所以它不能读取洋葱的其余部分。它只知道洋葱从何而来及下一个目的地，但並没有任何迹象表明谁是原始寄件人或最终收件人。

整过程只会持续到洋葱到达付款目的地（收款人）为止。然后，目的地节点打开洋葱，发现没有其他要解密的层和可以读取其中的付款信息。

有关更多信息，请参阅下面的 Github 链接：

https://github.com/bpfkorea/agora/issues/1529

#1583 闪存层：网络拓扑内存表示（路径查找，功能）

这由Omer进行。這是#158的分支问题。通过闪电网络路由付款的问题本质上是一个图形问题。我们应该通過闪电节点了解网络的有效内存表示。以便我们能够有效地沿着网络穿越和构建路径。

有关更多信息，请参阅下面的 Github 链接：

https://github.com/bpfkorea/agora/issues/1583

#1533 在系统集成测试中更改客户端代码以使用Faucet（路径查找，功能）

这由Chris进行。现在，我们已经有了一个专门用于创建事务的应用程序，我们可以将其用作馈入集成测试网络的一种方式，该网络将提供比测试/系统中当前客户端代码更好的覆盖率。

有关更多信息，请参阅下面的 Github 链接：

https://github.com/bpfkorea/agora/issues/1553

#1444 Slashing(削减)信息验证（路径查找，功能）

这由Jay进行。此问题与＃1076有关，该问题与实现削减协议有关。我们需要从#1076问题中分离一些与阻止标题验证相关的任务，因为其任务有许多事情要处理以及可能较耗时。

我们一直在将有关削减验证器的信息添加到一个块中。新添加的信息如下。

/// Hash of random seed of the preimages for this this height
Hash random_seed;

/// List of indices to the validator UTXO set which have not
revealed the preimage

uint[] missing_validators;

在任何情况下，random_seed不得无效, 它是由当前验证器的原像生成的，并且必须与节点本身的原地random_seed相同。这是验证例程需要检查的内容。在当前的 Agora 代码中，除了行为不端的验证器操纵信息的情况外，还有 2 种情况下信息无效。

在追赶过程中，没有用于生成比较所需的原地随机数种子的原像。因此，我们需要一个过程来从其他节点获取原映像, 并将信息添加到ValidatorSet中。
在许多单元测试或网络测试中，有些情况下不考虑维护验证检查和生成random_seed所需的原像。

为此，我们必须添加有关减少块头信息的验证例程，并使代码通过上述情况和测试。

有关更多信息，请参阅下面的 Github 链接：

https://github.com/bpfkorea/agora/issues/1444

#1614 Flash：固定洋葱包大小 (支付渠道，功能)

这由Drey进行。在＃1529中，实施了洋葱加密数据包。不過它们的大小根据跳数而变化。

在 LN 中，洋葱包經常固定了大小。这样可以确保没有节点能够知道数据包经过了多少跳或仍需要经过多少跳。跃点只知道前一跳和下一跳。而这是一项重要的隐私功能。

为此，我们查阅了以下页面：
https://github.com/lnbook/lnbook/blob/develop/03_how_ln_works.asciidoc

https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md

有关更多信息，请参阅下面的 Github 链接：
https://github.com/bpfkorea/agora/issues/1614

#1419 通過HTC實現間接支付渠道(支付渠道，功能)

这由Drey进行。为了使 Flash 层易于使用和更具可扩展性，我们需要通过间接渠道启用支付路由。

例如，请參考以下例子：
爱丽丝 <=> 波 <=> 查理 <=> 迪倫

在此渠道布局中，愛麗絲只能向波发送闪电合約，而她卻不能将合約发送给查理或迪伦。爱丽丝需要为查理和迪伦开辟新的渠道。
不过，这方法非常繁琐：

只会增加上锁交易的負荷
只会加重爱丽丝需要的簿记量
直到渠道开放交易被外部化为止,所有小額交易會被延迟
为所有相关方带来额外费用

通过使用哈希时间锁定合約来支持间接支付渠道。详情可参考支付渠道中 HTC 的简要说明: https://hackernoon.com/what-are-hashed-timelock-contracts-htlcs-application-in-lightning-network-payment-channels-14437eeb9345。我们执行的引擎正如这所帮助，能够支持HTLC 和定时设备。我们可以在Flash层中通过其来实现间接支付渠道。

完成的定义：