Announcing lnd 0.14 beta: Scale and Security Go Up - Michael Levin

https://lightning.engineering/posts/2021-11-18-lnd-v0.14/

DeepL直訳

We're pleased to announce lnd 0.14 beta, our final release of 2021! Building on our commitment to make the Lightning Network more reliable, robust, and secure, our latest release includes:
2021年の最終リリースとなるlnd 0.14 betaを発表します。ライトニングネットワークの信頼性、堅牢性、安全性を高めるためのコミットメントに基づき、最新のリリースには以下が含まれています：

・Revamped replicated storage backends + optimized etcd database support for increased redundancy in the stack
・複製されたストレージのバックエンドを刷新し、最適化されたetcdデータベースをサポートすることで、スタックの冗長性を高めました。

・Initial support for a Postgres replicated backend initially running in a key-value mode allowing for more efficient storage of large datasets
・大規模なデータをより効率的に保存できるように、キーバリューモードで動作するPostgresレプリケートバックエンドを最初にサポートしました。

・Initial version of remote signing, an oft-requested feature, for enhanced security
・セキュリティ強化のため、要望の多かったリモートサインの初期バージョンを搭載

・In-memory pathfinding resulting in 10x faster pathfinding with increased response times
・メモリ内での経路探索により、経路探索を10倍高速化し、応答時間を短縮

・Added RPC middleware interceptor which allows developers to construct business logic for LND through the use of custom macaroons
・カスタムマカロンを利用してLNDのビジネスロジックを構築できるRPCミドルウェアインターセプターの追加

・Reusable Lightning invoices with AMP, allowing for users to continually receive payments without regenerating a new invoice each time
・再利用可能なLightning請求書（AMP付き）により、請求書を再生成することなく、継続的に支払いを受けることが可能になりました。

This release wouldn't have been possible without tremendous community support (over 40 contributors to this release alone). In this post, we've included a list of the highlights, and you can find more details in the full release notes.
今回のリリースは、コミュニティからの多大なサポート（今回のリリースだけで40名以上の貢献者）がなければ実現しませんでした。この記事では、そのハイライトを紹介していますが、詳細はリリースノートをご覧ください。

Building for Scale and Security
スケールとセキュリティのための構築

Given the rapid growth of the Lightning Network over the past few months, this release prioritizes adding features, enhancements and optimizations that increase scalability and security. LND's security and scalability are critical properties to an optimal infrastructure for our users. The primary new features in this release that demonstrate this priority are Postgres database support, full remote database support, in-memory pathfinding, and an initial version of remote signer capabilities.
過去数ヶ月の間にライトニングネットワークが急速に成長したことを踏まえ、今回のリリースでは、スケーラビリティとセキュリティを向上させる機能の追加、強化、最適化を優先しました。LNDのセキュリティとスケーラビリティは、ユーザーにとって最適なインフラを実現するための重要な特性です。この優先順位を示す本リリースの主な新機能は、Postgresデータベースのサポート、フルリモートデータベースのサポート、インメモリーパスファインディング、およびリモートサイナー機能の初期バージョンです。

Postgres Database Support
Postgres データベースのサポート

In this version of lnd, we've added initial Postgres database support, using it as a key-value store. Postgres has several advantages over the default bbolt backend. First, Postgres better handles larger datasets, which as the Lightning Network continues to grow, will be crucial to scaling smoothly. Additionally, Postgres has more widespread industry use and provides stronger security assurances from years of battle testing, plus on-the-fly database compaction to decrease maintenance requirements. LND's initial method for data storage will use Postgres as a key-value store but in the future, native Postgres tables will be phased in to handle heavily loaded data segments -- like invoices and payments.
このバージョンのlndでは、初期のPostgresデータベースサポートを追加し、キーバリューストアとして使用しています。Postgresは、デフォルトのbboltバックエンドに比べていくつかの利点があります。まず、Postgresはより大きなデータセットの処理に優れており、ライトニングネットワークが成長し続ける中で、スムーズにスケーリングすることが重要になります。さらに、Postgresは業界でより広く使用されており、長年の実戦テストから得られたより強固なセキュリティの保証と、メンテナンスの必要性を減らすためのオンザフライでのデータベース圧縮を提供します。LNDの初期のデータ保存方法は、Postgresをキーバリューストアとして使用しますが、将来的には、請求書や支払いなどの負荷の高いデータセグメントを処理するために、Postgresのネイティブテーブルを段階的に導入する予定です。

Full Remote Database Support
リモートデータベースの完全サポート

The latest version of LND now stores all of its data in the same remote database, such as etcd, instead of just the channel state and wallet data. Compared to prior versions that had stored certain state-like wallet information locally, this change makes lnd fully stateless allowing for users running lnd (at scale) with multiple nodes to switch over to a new leader node, the only node able to read and mutate the database, almost instantaneously. This change should make running multiple lnd nodes at scale a smoother experience with less downtime. This feature also enables high-availability designs to run LND at larger scale.
最新バージョンのLNDでは、チャネルの状態やウォレットのデータだけでなく、すべてのデータをetcdなどの同じリモートデータベースに保存するようになりました。ウォレット情報のような特定の状態をローカルに保存していた以前のバージョンと比較して、この変更によりLNDは完全にステートレスになり、複数のノードでLNDを（大規模に）運用しているユーザーは、データベースの読み取りと変更が可能な唯一のノードである新しいリーダーノードに、ほぼ瞬時に切り替えることができます。この変更により、複数のlndノードを大規模に運用する際に、ダウンタイムの少ないスムーズな運用が可能になります。また、この機能により、ハイアベイラビリティ設計でLNDを大規模に運用することが可能になります。

In-Memory Pathfinding
インメモリ・パスファインディング

Pathfinding has been a costly read-write operation to perform -- especially given all the new nodes to route with -- but no more! Keeping a copy of the channel graph in memory turbo charges pathfinding while reducing IOPS (input output operations per second) load for infrastructure-engineers' bottom line. In preliminary tests, we've seen as high as a 10x path finding attempt speed up, which should translate to lower perceived payment latencies across the network. This feature uses more RAM so low-memory systems are advised to run with the routing.strictgraphpruning=true configuration option. This flag more aggressively removes zombie channels from the graph, reducing the number of channels that need to be kept in memory. For mobile nodes, this can be disabled with the flag --db.no-graph-cache=true.
パスファインディングはこれまで、特に新しいノードを使ってルーティングを行う場合には、読み書きのコストがかかっていましたが、これからは違います。チャンネルグラフのコピーをメモリ上に保持することで、パスファインディングを高速化するとともに、IOPS（Input Output Operations per Second）の負荷を低減し、インフラエンジニアの収益に貢献します。予備的なテストでは、経路探索の試みが10倍も高速化されたことが確認されており、これによりネットワーク上での支払い遅延の認識が低くなるはずです。この機能はより多くのRAMを使用するため、メモリの少ないシステムでは routing.strictgraphpruning=true 設定オプションを使用することをお勧めします。このフラグは、ゾンビチャンネルをグラフから積極的に削除し、メモリに保持する必要のあるチャンネル数を減らします。モバイルノードでは、--db.no-graph-cache=trueを指定することで、この処理を無効にできます。

Remote Signing for a More Secure Lightning Node
Lightningノードの安全性を高めるリモートサイン

Fans of "defense in depth", an information security concept based on layers, now have another tool to harden their infrastructure with: remote signing functionality. Remote signing refers to a mode of lnd where the wallet is segregated into two parts. One instance is running in watch-only mode -- with its wallet holding only public keys. The second instance manages the corresponding private keys.
ディフェンス・イン・デプス（Defense in Depth）」と呼ばれる情報セキュリティの概念は、層を重ねることで成り立っていますが、この度、インフラを強固にするための新たなツールとして、リモート・サイニング機能が加わりました。リモートサインは、ウォレットを2つの部分に分離したLNDのモードを指します。1つのインスタンスはウォッチオンリーモードで動作しており、ウォレットには公開鍵のみが格納されています。2つ目のインスタンスは、対応する秘密鍵を管理します。

The advantage of such a setup is that the lnd instance containing the private keys (the "signer") can be completely offline except for a single inbound gRPC connection and the outbound connection to bitcoind, btcd, or neutrino. The signer instance can run on a different machine with more tightly locked down network security, optimally only allowing the single gRPC connection from the outside. With this setup, system administrators can lock down the node and isolate access to sensitive key material.
このような設定の利点は、秘密鍵を持つlndインスタンス（「署名者」）は、1つのインバウンドgRPC接続とbitcoind、btcd、またはneutrinoへのアウトバウンド接続を除いて、完全にオフラインにできることです。署名者のインスタンスは、ネットワークセキュリティがより厳しく制限された別のマシン上で実行することができ、外部からの単一のgRPC接続のみを許可するのが最適です。この設定により、システム管理者はノードをロックダウンし、機密性の高いキーマテリアルへのアクセスを分離することができます。

With this functionality, which has been requested by many users, this version of lnd can be more secure due to less hot wallet risk. Furthermore, this is just the initial initial version of remote signing in lnd. Future versions will have a slimmer binary and eventually implement more validation.
多くのユーザーから要望のあったこの機能により、本バージョンのlndは、ホットウォレットのリスクを低減し、より安全なものとなります。さらに、これはlndのリモート署名の初期の初期バージョンに過ぎません。今後のバージョンでは、よりスリムなバイナリを採用し、最終的にはより多くの検証を実装する予定です。

Improved Connectivity
接続性の向上

Bridging the Network with Hybrid Tor Connectivity
ハイブリッドTor接続によるネットワークのブリッジング

In this version of lnd, users can choose to enable a hybrid Tor connectivity mode, where Tor is only used for connections to Tor-only nodes, and clearnet for everything else. This will help improve network connectivity as a larger proportion of Lightning nodes are Tor. This new behavior can be added using the tor.skip-proxy-for-clearnet-targets flag.
ハイブリッドTor接続によるネットワークのブリッジングこのバージョンのlndでは、ユーザーはハイブリッドTor接続モードを有効にすることができます。このモードでは、TorはTorのみのノードへの接続にのみ使用され、それ以外の接続にはclearnetが使用されます。これにより、LightningノードのうちTorの割合が多くなるため、ネットワークの接続性が向上します。この新しい動作は tor.skip-proxy-for-clearnet-targets フラグで追加できます。

Automated Tor Health Checks
自動化されたTorのヘルスチェック

Further, a new health check, Tor connection, is added to lnd's liveness monitor upon startup. This check will ensure the liveness of the connection between the Tor daemon and lnd's Tor controller. This feature will help to fix issues where the tor daemon restarting lead to destabilized peering.
さらに、起動時の lnd の liveness モニターに、新しいヘルスチェック、Tor connection が追加されました。このチェックは、Tor デーモンと lnd の Tor コントローラ間の接続の有効性を確認します。この機能により、torデーモンの再起動によってピアリングが不安定になる問題を解決することができます。

Channel and Payment Improvements
チャネルと決済の改善

Batched Channel Funding
バッチ式チャネル資金調達

In this version of lnd, multiple channels can now be opened in a single transaction in a safer and more straightforward way. This option is accessible through the BatchOpenChannel RPC as well as lncli batchopenchannel. With this option, users can save on fees by amortizing the cost of opening multiple channels across a single batch.
本バージョンのlndでは、より安全でわかりやすい方法で、複数のチャネルを1つのトランザクションで開くことができるようになりました。このオプションは、BatchOpenChannel RPCおよびlncli batchopenchannelからアクセスできます。このオプションにより、ユーザーは複数のチャネルを開くためのコストを1つのバッチで償却することで、手数料を節約できます。

Explicit Channel Negotiation
明示的チャネルネゴシエーション

This new protocol extension, called explicit channel negotiation, allows a channel initiator to signal their desired channel type to use with a remote peer. If the remote peer supports the channel type and agrees, the previous implicit negotiation, based on the shared set of feature bits, is bypassed, and the proposed channel type is used. This change paves the way for more advanced channel types, particularly those that leverage advanced taproot features.
明示的チャネルネゴシエーション」と呼ばれるこの新しいプロトコル拡張により、チャネル・イニシエータは、リモート・ピアとの間で使用したいチャネル・タイプを通知することができます。リモート・ピアがそのチャネル・タイプをサポートし、同意した場合、共有された機能ビット・セットに基づいて行われていた暗黙のネゴシエーションはバイパスされ、提案されたチャネル・タイプが使用されます。この変更により、より高度なチャネルタイプ、特にタップルートの高度な機能を活用したチャネルタイプへの道が開かれました。

Reusable Static AMP Invoices
再利用可能なスタティックAMP請求書

AMP invoices are now fully re-usable, meaning it's possible for an lnd node to pay a static AMP invoice multiple times. AMP, Atomic Multi-path Payments, Invoices are the successor to the widely used "keysend" protocol as it enables payments to be sent in multiple shards similar to Multi-Path Payments (MPP). From a user perspective, this functionality gives the ability to create one invoice that can be used repeatedly so that developers can create subscription-like features.
AMP請求書が完全に再利用可能になりました。つまり、lndノードが静的なAMP請求書を複数回支払うことが可能になりました。AMP（Atomic Multi-path Payments）請求書は、広く使われている "keysend "プロトコルの後継で、マルチパス・ペイメント（MPP）と同様に複数のシャードで支払いを行うことができます。ユーザーの視点から見ると、この機能は、開発者がサブスクリプションのような機能を作ることができるように、繰り返し使用できる1つの請求書を作成する機能です。

An AMP invoice can be created by adding the --amp flag to lncli addinvoice. From there, repeated payments can be made to the invoice using lncli payinvoice. On the receiver side, notifications will still come in as normal, but notifying only the new "sub-invoice" paid each time.
AMP請求書を作成するには、lncli addinvoiceに--ampフラグを追加します。AMP請求書は、lncli addinvoiceに--ampフラグを追加することで作成でき、そこからlncli payinvoiceを使って請求書に繰り返し支払いを行うことができます。受信側では、通知は通常通りに届きますが、毎回支払われる新しい「サブインボイス」のみが通知されます。

Compared to approaches that require nodes to continually fetch new invoices from a server/node, reusable AMP invoices allow applications and wallets to fetch a single (somewhat long lived invoice) that can be used for repeated payments. In addition, the AMP invoice format (which specifies a new payment type) is compatible with the currently deployed invoice negotiation protocols (such as Offers, LNURL, LN Address, etc), as they can be used to fetch an AMP invoice for storage by the client. On the API level, in addition to the normal paymenthash value we all know and love, reusable AMP invoices introduce two new fields to eventually replace the payment hash from an accounting Pov: the paymentaddr and setid (both 32 byte values). Each AMP invoice is generated with a fresh paymentaddr that can be used to look up all the past payment repeated payments to the same invoice. Each time a user attempts a new payment, they generate a new setid to associate with the existing paymentaddr. In this new operating mode, the two tuples of (paymentaddr, setid) are enough to uniquely identify a given payment.
ノードがサーバー／ノードから新しい請求書を継続的に取得する必要があるアプローチと比較して、再利用可能なAMP請求書は、アプリケーションやウォレットが、繰り返し支払いに使用できる単一の（やや長持ちする）請求書を取得することを可能にします。さらに、AMPインボイスのフォーマット（新しい支払いタイプを指定する）は、現在導入されているインボイスネゴシエーションプロトコル（Offers、LNURL、LN Addressなど）と互換性があり、これらのプロトコルを使ってAMPインボイスを取得し、クライアントに保存することができます。APIレベルでは、通常のpaymenthash値に加えて、再利用可能なAMP請求書では、会計上の観点から最終的に支払いのハッシュを置き換えるために、paymentaddrとsetid（両方とも32バイトの値）という2つの新しいフィールドが導入されています。各AMP請求書は、新しいpaymentaddrで生成されます。このpaymentaddrは、同じ請求書に対して繰り返された過去の支払いをすべて検索するのに使用できます。ユーザーが新しい支払いを試みるたびに、既存のpaymentaddrに関連する新しいsetidが生成されます。この新しい動作モードでは、(paymentaddr, setid)の2つのタプルだけで、特定の支払いを一意に識別することができます。

The initial implementation from an API perspective has been made with the goal of minimizing the set of changes for applications and services that already accept payments on Lightning. Future iterations will evolve to create a more first-class API for subscription and recurring payments with input from the developer and wallet community. Similar to keysend (which AMP supersedes), users will need to opt into being able to receive these new payments with the --accept-amp flag. In addition, we plan to finalize our AMP specification, so the new payment type can be deeply integrated into other implementations and wallets.
APIの観点から見た初期の実装は、すでにライトニングでの支払いを受け付けているアプリケーションやサービスの変更を最小限に抑えることを目的としています。将来的には、開発者やウォレットコミュニティの意見を取り入れながら、サブスクリプションや定期的な支払いのためのよりファーストクラスのAPIを作成するために進化させていく予定です。AMPの後継であるkeysendと同様に、ユーザーは--accept-ampフラグを使ってこれらの新しい支払いを受けられるようにする必要があります。さらに、AMPの仕様を確定し、他の実装やウォレットにこの新しい決済タイプを深く統合できるようにすることを計画しています。

Unlocking Functionality with Macaroons
マカロンで機能を引き出す

Macaroon-Based Middleware Interceptor
マカロンを使ったミドルウェアのインターセプター

0.14 introduces a new middleware interceptor for macaroons. This mechanism is similar to existing channel or HTLC interceptors, but for the gRPC messages themselves. With this new system, developers can implement custom business logic outside of lnd itself. In order to ensure the security of this new layer, we bind everything to macaroons with custom caveat conditions. Only client requests with the attached custom caveat macaroon will even be given to the middleware for inspection.
0.14では、マカロン用の新しいミドルウェアインターセプターを導入しました。このメカニズムは、既存のチャネルやHTLCのインターセプターと似ていますが、gRPCメッセージそのものを対象としています。この新しいシステムにより、開発者はlnd自体の外側にカスタムビジネスロジックを実装することができます。この新しいレイヤーのセキュリティを確保するために、すべてをカスタムcaveat条件でマカロンにバインドしています。カスタム・ケイバット・マカロンが添付されたクライアント・リクエストだけが、ミドルウェアに渡されて検査されます。

The inclusion of the macaroon interceptor serves to fully unleash the potential of macaroons as an access control and Lightning application primitive. The interceptor allows the creation and validation of nearly arbitrary policies such as "Bob can make payments on Tuesdays, but only up to 100k satoshis". In addition to being able to accept/deny requests based on these custom macaroons, the middleware also allows modifying the responses as well. This feature can be used to implement scoped wallets, where a user only sees their available balance from the WalletBalance call, though the wallet as a whole may hold more funds. Such policies can be used to implement fire-walled multi-user community wallets, downtime detection services, and much more.
マカロンインターセプターを搭載することで、アクセスコントロールやLightningアプリケーションのプリミティブとしてのマカロンの可能性を最大限に引き出すことができます。このインターセプターは、「ボブは火曜日に支払いを行うことができるが、10万サトシまで」といった、ほぼ任意のポリシーの作成と検証を可能にする。ミドルウェアでは、これらのカスタムマカロンに基づいてリクエストの受け入れ/拒否ができるだけでなく、レスポンスも変更することができます。この機能を利用して、スコープ付きウォレットを実装することができます。ユーザーはWalletBalanceコールから得られる利用可能な残高しか見ることができませんが、ウォレット全体ではより多くの資金を保有している可能性があります。このようなポリシーは、ファイアーウォールされたマルチユーザーコミュニティウォレットやダウンタイム検知サービスなどの実装に使用できます。

Conclusion: Lightning Go Up!
結論: Lightning Go Up!

We've introduced a number of improvements in v0.14-beta to make developing on the Lightning Network safer, more secure, connected, and scalable than ever. Since 0.13, we've made immense progress on these key areas through the features outlined in depth above. We're excited to see this technology deployed in the wild by our users around the world.
v0.14-betaでは、ライトニングネットワーク上での開発をこれまで以上に安全、セキュア、コネクテッド、スケーラブルなものにするために、多くの改善点を導入しました。0.13以降、これらの重要な分野では、上記の機能を通じて非常に大きな進歩を遂げています。私たちは、この技術が世界中のユーザーによって実用化されるのを楽しみにしています。

With all the recent developments this year we're excited to be contributing to the continued growth of the Lightning Network with this release. If you haven't already, please join the lnd Slack, reach out to us on Twitter, contribute a PR, or subscribe to our newsletter!
このリリースにより、ライトニングネットワークの継続的な成長に貢献できることを嬉しく思います。まだの方は、ぜひlnd Slackに参加したり、Twitterで連絡を取ったり、PRを投稿したり、ニュースレターを購読したりしてください。