Skip to content

Commit 8fcdb5f

Browse files
bittomhanbittomhan
authored
Newsletter-49: translate into Chinese (#1812)
1 parent 6a4daaf commit 8fcdb5f

4 files changed

Lines changed: 107 additions & 2 deletions

File tree

‎_includes/specials/2019-exec-briefing/zh/lightning.md‎

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,16 @@
1+
{% include references.md %}
2+
{% capture operating-on-lightning-zh %}Kotliar 开始解释说，前几年较高的交易费用对 Bitrefill 的业务产生了重大影响，因此他们特别努力在降低费用相关的支出方面表现出色。接收 LN 支付的能力支持了这一目标，他相信他们是第一个在主网上出售真实商品以接收 LN 支付的服务。如今，LN 支付约占他们销售额的 5%，这与他们使用以太坊的业务量相似。
3+
4+
他认为企业现在开始研究 LN 是很重要的。“在比特币中，我们已经习惯于等待 [...] 但让客户等待不确定的时间，会产生客户离开的风险。”例如，当存款在交易所结算时，客户可能不再有兴趣进行本可以为交易所赚取佣金的交易。此外，Bitrefill 使用 LN 的经验表明，LN 改进的发票消除了链上比特币支付中出现的多种支付错误，包括超额支付、少付、卡住的交易、复制粘贴错误以及其他问题。通过 LN 接收支付还消除了合并 UTXO 的需要，并减少了在热钱包和冷钱包之间轮换资金的需求。消除所有这些问题有可能显著减少客户支持和后端支出。
5+
6+
在他演讲的一个特别有趣的部分，Kotliar 显示了当前链上支付中或许有高达 70% 是用户将资金从一个交易所转移到另一个交易所（甚至在同一交易所的不同用户之间）。如果所有这些活动都可以通过 LN 支付从链上转移，交易所及其用户可以节省大量资金，并且比特币中的每个人都将受益于可用区块空间的增加。
7+
8+
Kotliar 用几个简短的片段结束了他的演讲。他描述了 Bitrefill 看到 LN 用户今天使用的软件和服务，以及他预计他们在不久的将来会使用的。他接着解释了 Bitrefill 为 LN 用户（包括企业）提供的两个服务，[Thor][] 和 [Thor Turbo][]。最后，他简要描述了对 LN 的几项计划改进：可重复使用地址（参见 [Newsletter #30][newsletter #30 spon]）、拼接进出（参见 [#22][Newsletter #22 splice]）和更大的通道（也参见 [#22][Newsletter #22 wumbo]）。
9+
10+
总的来说，Kotliar 提出了一个令人信服的观点，即 LN 的更快速度、更低费用和改进的发票意味着希望在不久的将来保持竞争力以服务比特币客户的企业，应该立即开始研究实现 LN 支持。{% endcapture %}
11+
12+
[thor]: https://www.bitrefill.com/thor-lightning-network-channels/?hl=en
13+
[thor turbo]: https://www.bitrefill.com/thor-turbo-channels/?hl=en
14+
[newsletter #30 spon]: /zh/newsletters/2019/01/22/#pr-opened-for-spontaneous-ln-payments
15+
[newsletter #22 splice]: /zh/newsletters/2018/11/20/#splicing
16+
[newsletter #22 wumbo]: /zh/newsletters/2018/11/20/#wumbo

‎_includes/specials/bech32/zh/12-midway.md‎

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
{% auto_anchor %}
2+
这个部分标志着 Bech32 系列已过半，因此我们决定在本周介绍一些与 Bech32 相关的趣闻，这些趣闻有趣但不足以独立成段。
3+
4+
- **<!--how-is-bech32-pronounced-->****Bech32 的发音是什么？** 提案的共同作者 Pieter Wuille 使用轻声的“ch”，因此这个词听起来像 [“besh thirty two”][wuille bech32]。这个名字是一个混合词，将地址的纠错编码（BCH）的字母与其数值基（base32）的名称结合起来。将其与轻声“ch”发音，使得 *bech32* 的第一个音节与比特币的传统地址格式 *base58* 相似。我们承认，这种详细解释破坏了这个笑话，但这是一个巧妙而有趣的文字游戏。
5+
6+
- **<!--bch-has-nothing-to-do-with-bitcoin-cash-s-ticker-code-->****BCH 与 Bitcoin Cash 的代码无关：** Bech32 所基于的 BCH 代码名称是 [Bose-Chaudhuri-Hocquenghem][wikipedia bch] 的缩写，Hocquenghem 于 1959 年发明了这种类型的循环码，随后 Bose 和 Ray-Chaudhuri 在 1960 年独立重新发现了它们。此外，Bech32 地址格式在 2017 年 3 月宣布，比后来被称为 Bitcoin Cash 的计划（最初计划使用代码 *BCC*）的[首次计划][first plans]早了三个月。
7+
8+
- **<!--over-ten-cpu-years-consumed-->****消耗超过十年的 CPU 计算时间：** 使用现有的关于 BCH 代码的信息，Bech32 的作者能够找到为比特币地址提供他们所需的最低错误检测能力的代码集。然而，这个集合中有近 16 万个符合条件的代码，作者预计其中有些代码会比其他的更好。为了在其中找到最优的代码，使用了超过 200 个 CPU 核心和[超过 10 年的计算时间][cpu time]。
9+
10+
[wuille bech32]: https://youtu.be/NqiN9VFE4CU?t=1827
11+
[cpu time]: https://youtu.be/NqiN9VFE4CU?t=1329
12+
[wikipedia bch]: https://en.wikipedia.org/wiki/BCH_code
13+
[first plans]:https://blog.bitmain.com/en/uahf-contingency-plan-uasf-bip148/
14+
{% endauto_anchor %}

‎_posts/zh/2019-03-19-bech32-sending-support.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -94,7 +94,7 @@ h2:not(:first-of-type) { margin-top: 3em; }
9494

9595
*最初发布于 [Newsletter #49][].*
9696

97-
{% include specials/bech32/12-midway.md %}
97+
{% include specials/bech32/zh/12-midway.md %}
9898

9999
## 采用速度
100100

@@ -182,7 +182,7 @@ h2:not(:first-of-type) { margin-top: 3em; }
182182
[newsletter #46]: /zh/newsletters/2019/05/14/#bech32-发送支持
183183
[newsletter #47]: /zh/newsletters/2019/05/21/#bech32-发送支持
184184
[newsletter #48]: /zh/newsletters/2019/05/29/#bech32-发送支持
185-
[newsletter #49]: /en/newsletters/2019/06/05/#bech32-sending-support
185+
[newsletter #49]: /zh/newsletters/2019/06/05/#bech32-发送支持
186186
[newsletter #50]: /en/newsletters/2019/06/12/#bech32-sending-support
187187
[newsletter #51]: /en/newsletters/2019/06/26/#bech32-sending-support
188188
[newsletter #52]: /en/newsletters/2019/06/26/#bech32-sending-support

‎_posts/zh/newsletters/2019-06-05-newsletter.md‎

Lines changed: 75 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,75 @@
1+
---
2+
title: 'Bitcoin Optech Newsletter #49'
3+
permalink: /zh/newsletters/2019/06/05/
4+
name: 2019-06-05-newsletter-zh
5+
slug: 2019-06-05-newsletter-zh
6+
type: newsletter
7+
layout: newsletter
8+
lang: zh
9+
---
10+
本周的 Newsletter 描述了提议的 Erlay 协议，该协议可以显著减少节点之间中继未确认交易的开销，总结了 Bitrefill CEO Sergej Kotliar 关于闪电网络的执行简报，并列出了一些最近对上周描述的 COSHV 提案的更改内容。还包括我们关于 Bech32 发送支持和流行比特币基础设施项目中值得注意的代码更改的常规部分。
11+
12+
{% comment %}<!-- include references.md below the fold but above any Jekyll/Liquid variables-->{% endcomment %}
13+
{% include references.md %}
14+
{% include specials/2019-exec-briefing/zh/lightning.md %}
15+
16+
## 行动项
17+
18+
*本周无。*
19+
20+
## 新闻
21+
22+
- **<!--erlay-proposed-->****Erlay 提议：**Gleb Naumenko、Pieter Wuille、Gregory Maxwell、Sasha Fedorova 和 Ivan Beschastnikh 的一篇新论文描述了一种替代交易中继协议，[Erlay][]。当前，当一个节点了解到一个新的交易并且该交易通过了其中继策略时，它会将该交易的 txid 通知其所有的节点（除了之前已经通知过的节点）。这是一种非常简单有效的策略，但效率不高——节点接收到的大多数通知是它几分钟前从其他节点已经得知的交易通知。根据论文，这种冗余浪费了大约 44% 的所有节点带宽。
23+
24+
论文尝试使用作者的 Erlay 协议来减少这种冗余，该协议将中继分为两个阶段：扇出阶段和对账阶段。在扇出阶段，节点仅将其了解到的新交易直接宣布给从节点的出站节点中选出的最多八个节点。
25+
26+
在对账阶段，节点将定期从其每个出站节点请求一个短交易标识符（短 txids）的*草图*，该草图用于所有该节点通常会宣布给该节点的新交易。草图是使用 [libminisketch][] 库创建的，该库在[Newsletter #26][] 中描述，它基于纠错码实现了一种高效带宽的集合对账技术。收到请求的草图后，节点自身也会生成一个草图，其中包含它通常会宣布给其对等节点的所有新交易。节点将其草图与对等节点的草图结合，以生成任何差异的列表。该差异包含集合中新交易中某一个集合中但不在另一个集合中的交易的短 txids。节点随后可以从该对等节点请求任何缺失的交易，并继续查询其下一个对等节点的草图。每秒钟重复一次，以便节点能够快速接收未通过扇出通知接收到的任何交易。这种简单的两步协议（扇出和对账）描述了 Erlay 的主要操作；论文中描述和分析的协议的其余部分涵盖了用于草图的最佳参数和一系列如果集合对账失败的后备步骤。
27+
28+
在描述 Erlay 协议之后，论文使用一个模拟的由 60,000 个节点（数量和使用情况与当前比特币网络相似）组成的网络和一组分布在多个数据中心的 100 个国际节点的实时集分析其性能。最值得注意的结果是，Erlay 减少了用于宣布新交易存在的带宽量 84%。然而，交易在网络中传播到所有节点的时间大约增加了 80%（2.6 秒）。比特币交易平均每十分钟只能确认一次，因此三秒的延迟似乎是为了大幅减少带宽而支付的合理代价。
29+
30+
在确定该协议是一个值得的效率改进之后，论文考虑了其最重要的次要方面：其对隐私的影响。目前，每个 Bitcoin Core 节点都稍微延迟向其对等节点中继交易；这使得间谍节点更难以使用时间关联来猜测他们从中接收到交易的第一个对等节点是创建交易的节点。针对网络对等节点中不同数量的间谍节点（从 5% 到 60% 的间谍节点），进行了多次模拟测试当前中继协议与 Erlay 的有效性。在间谍节点是接受入站连接的公共节点的情况下，Erlay 的表现总是等于或优于当前协议。在间谍节点是向诚实节点发起连接的私有节点的情况下，Erlay 有时表现得更好，有时表现得更差——但从未比当前协议差 10% 以上（这种最坏的情况是不太可能出现的情况）。论文还指出，Erlay 与提议的 [BIP156][] 蒲公英协议兼容，以进一步提高网络对间谍节点的抵抗力。
31+
32+
考虑到比特币中继策略的未来可能变化，论文指出，如果出站节点数量从 8 增加到 32，Erlay 节点用于宣布新交易存在的带宽仅会增加 32%，而使用当前协议则会增加 300%。正如上述关于 Erlay 两个阶段的段落所描述的，新交易仍然仅通过直接公告扇出给 8 个对等节点，但节点将对所有 32 个对等节点执行集合对账。四倍的中继连接改进增加了时间敏感交易（如闪电网络合约协议）快速到达矿工的机会。
33+
34+
除了 libminisketch，实现 Erlay 在 Bitcoin Core 中所需的代码更改仅为 584 行代码，并且在比实际预期条件更差的情况下，集合对账的 CPU 密集型部分的基准测试耗时不到一毫秒。如果对该论文没有异议，Naumenko 已宣布计划撰写一份 BIP 并努力将 Erlay 包含在 Bitcoin Core 的后续版本中。用于交易中继的方法是 P2P 网络协议的一部分（不是共识规则），因此该更改可以在多个用户升级后立即开始运行，尽管我们预计节点还将包括一个向后兼容模式以支持尚未升级的对等节点。
35+
36+
- **<!--presentation-operating-on-lightning-->****演讲：闪电网络操作：**Bitrefill CEO Sergej Kotliar 为上个月的 Optech 执行简报做了关于闪电网络的演讲。[视频][kotliar ln]现已发布。 {{operating-on-lightning-zh}}
37+
38+
- **<!--coshv-proposal-replaced-->****COSHV 提案被替换：**我们在[上周][news48 coshv]描述的 COSHV 提案的作者用一个不同名称的[类似提案][alt-coshv]替换了该提案。新提案不仅检查交易输出的哈希——现在哈希还包括交易的版本号、输入数量、序列号和锁定时间。此更改消除了与交易易变性相关的问题，这些问题会影响使用带有某些类型合约协议（如闪电网络）的操作码。此外，通过对交易中允许的输入数量进行哈希处理，原始提案对单个输入的限制被解除——然而，该提案警告称，仍然建议只允许一个输入以避免不必要的交互。（注意：除了新名称外，更改不会影响我们上周撰写的 COSHV 摘要。）
39+
40+
## Optech 推荐
41+
42+
在撰写本文时，Bitcoin Core 项目目前有[超过 300 个开放的拉取请求 (PR)][core prs]。其中一些正在进行中，但其余大部分正在等待开发人员审核，并确定需要修复的任何问题或确认它们可以合并。
43+
44+
如果您想通过审核 PR 来帮助改进 Bitcoin Core，但不确定如何入门，我们建议您查看 [Bitcoin Core PR Review Club][]. 在每周的 IRC 会议中，经验丰富的 Bitcoin Core 贡献者提供有关选定 PR 的背景信息，然后回答新贡献者的现场问题。通常，他们会得到其他知名 Bitcoin Core 贡献者的协助，有时包括正在讨论的 PR 的作者。
45+
46+
Optech 建议任何希望更多参与 Bitcoin Core 过程的工程师参加。IRC 会议在每周三 17:00 UTC 举行。
47+
48+
## Bech32 发送支持
49+
50+
*在 [Bech32 系列][bech32 series] 中为期 24 周的第 12 周，旨在让您支付的对象获得隔离见证的所有好处。*
51+
52+
{% comment %}<!-- weekly reminder for harding: check Bech32 Adoption
53+
wiki page for changes -->{% endcomment %}
54+
55+
{% include specials/bech32/zh/12-midway.md %}
56+
57+
## 值得注意的代码和文档更改
58+
59+
*[Bitcoin Core][bitcoin core repo]、[LND][lnd repo]、[C-Lightning][c-lightning repo]、[Eclair][eclair repo]、[libsecp256k1][libsecp256k1 repo] 和 [比特币改进提案（BIPs）][bips repo] 本周的值得注意的更改。*
60+
61+
- [Bitcoin Core #15741][] 通过批处理数据库更新而不是顺序更新，加快了使用 `importmulti` RPC 导入密钥、地址和其他信息到钱包中的速度。在 PR 作者执行的测试中，这将导入 10,000 个地址的时间从 465 秒减少到 4 秒。
62+
63+
- [LND #2985][] 等待中继 gossip 公告，直到有至少十个要发送的公告，并且距离上一个批次已经过去五秒，从而减少带宽开销。这延续了 LND 和其他实现为减少 gossip 协议开销而进行的工作，因为闪电网络在过去一年中显著增长。
64+
65+
- [LND #2761][] 切换为使用持久状态机进行路由支付，并为机器存储一些额外的状态数据，提高了程序正确处理守护进程重启时未解决的 HTLC 的能力。
66+
67+
{% include linkers/issues.md issues="15741,2985,2761" %}
68+
[bech32 series]: /zh/bech32-sending-support/
69+
[news48 coshv]: /zh/newsletters/2019/05/29/#提议的交易输出承诺
70+
[alt-coshv]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016997.html
71+
[kotliar ln]: https://www.youtube.com/watch?v=1UDD9PMFTds
72+
[Bitcoin Core PR Review Club]:https://bitcoin-core-review-club.github.io/
73+
[core prs]: https://github.com/bitcoin/bitcoin/pulls
74+
[newsletter #26]: /zh/newsletters/2018/12/18/#minisketch-library-released
75+
[Erlay]: https://arxiv.org/pdf/1905.10518.pdf

0 commit comments

Comments
 (0)