ビットコインレイヤー2：アーク

ARKは、元々トルコの若い開発者であるBurakが提案した新しいチェーンオフチェーントランザクションバッチングメカニズムです。現在、2つの実装が構築されています。1つはARKラボによって、もう1つは2番目には、どちらもBurakが関与していません。

ARKの当初の提案ははるかに複雑であり、現在構築されている実装よりもプライバシーに焦点を当てた設計目標を伴いました。また、もともと構築するためにCheckTemplateVerify（CTV）を要求することも想定されていました。

プロトコルは、適切に機能するために中央の調整サーバーに依存しますが、それにもかかわらず、同じ機能とセキュリティがLightningネットワークが行うことを保証することができます。必要な期間中にユーザーがオンラインにとどまる限り、常に（短期間オペレーターを信頼することを選択しない限り）すべてのユーザーは、いつでもARKシステムを一方的に出て、いつでもファンドの一方的な制御を取り戻すことができます。

稲妻とは異なり、ARKは、ユーザーが資金を受け取るために事前に割り当てられた流動性を彼らに割り当てていることを要求しません。 ARKユーザーは、単に財布に搭載し、すぐに資金を受け取ることができます。

さまざまな構成要素の箱を歩きましょう。

箱舟

ARKに保持されているコインは、仮想UTXOS（VUTXOS）と呼ばれます。これらは、オンチェーンを提出した後にユーザーの一方的な制御の下で実際のUTXOの作成を保証するが、それ以外の場合はオフチェーンに保持されている単に事前に署名したトランザクションです。

すべてのユーザーのvutxosは、事前に署名されたトランザクションの木、または「バッチ」の木にネストされています。 ARKは、コーディネーターサーバー、またはARKサービスプロバイダー（ASP）を持つことで機能し、バッチを作成するために必要なユーザー間の調整を促進します。ユーザーが資金を受け取っているときはいつでも、ARKへのオンボーディング、またはオフボーディングで、新しいバッチを作成するためにトランザクションと関連するトランザクションツリーを構築する必要があります。

ツリーは、ツリーとASPにvutxosを保持しているすべてのユーザーを含むN-of-nマルチシグでロックされた単一のルートUtxoを確認し、最終的には葉に到達するまでゆっくりとUtxosに分割されます。各vutxoは、2分の2マルチシグ、1つのキーがユーザーが保持しているキー、もう1つはASP、またはタイムロック後のユーザーによって署名する必要があるスクリプトを使用して保証されます。

ツリーが分割されるたびに、vutxosはオンチェーンを作成しますが、実際にVutxosに分割されていないより多くの内部utxosもそうです。これらの内部UTXOはそれぞれ、ASPで構成されるN-of-Nマルチシグでロックされており、ツリーのさらに下にVutxoを持っているすべてのユーザーがロックされています。バッチ作成プロセス中に、ユーザーはそれぞれのVutxosから始めて、ツリーのルートに戻って署名プロセスを経ています。これにより、各ユーザーがvutxoに対する主張の前にルートに署名されないことが保証され、最悪のシナリオで常に一方的なアクセスがあることを保証します。

各バッチには有効期限もあります（次のセクションでは意味があります）。この有効期限は、ルートUTXO ONCHAINおよびすべての内部UTXOの代替支出条件として存在するため、ASPはすべての資金を単独で単独で費やすことができます。

トランザクション、事前確認、およびコネクタ入力

箱舟での取引に関しては、セキュリティモデルの観点からの独自のコストと影響の両方を伴う2つの可能なメカニズムが可能です。ラウンド外の転送、または事前に取引されたトランザクションがあり、ラウンド転送、または実際に確認されたトランザクションがあります。

ラウンド外の転送を実施することは、非常に単純なプロセスです。あるユーザー（アリス）が別のユーザー（ボブ）を支払いたい場合、ASPに連絡して、Vutxoにボブに費やしてトランザクションを共同署名させます。ボブには、事前に署名されたトランザクションと、それを前にバッチルートオンチェーンに戻す他のすべてのトランザクションが与えられます。ボブは現在、この取引で一方的に箱舟を出ることができるようになっています。彼は、アリスと共謀して倍増しないことをASPを信頼しなければなりません。これらのラウンド外のトランザクションは、最終的に確認する前に複数回チェーンすることさえできます。

ARKトランザクションを最終化するには、ユーザーは「バッチスワップ」に従事する必要があります。ユーザーは実際に単一のバッチ内の転送を信頼できることを確認することはできません。新しいバッチで作成された新鮮なvutxoを既存のバッチでvutxoを原子的に交換する必要があります。これは、ASPをスワップのファシリテーターとして使用して、「コネクタ入力」と呼ばれるものの助けを借りて行われます。

ユーザーがバッチスワップでアークトランザクションを完成させると、VutxoのASPへの制御を放棄します。これには問題がありますが、ASPが単にそれを維持し、新しいバッチで確認されたvutxoを与えないのを止めるものは何ですか？コネクタ入力。

新しいバッチが作成されると、コネクタUTXOSで構成される新しいツリーをインスタンス化するチェーンで確認されるトランザクションで2番目の出力が作成されます。ボブがASPへの没収トランザクションを介してバッチスワップを実施するためにサインすると、トランザクションにはコネクタUTXOSの入力として含まれます。

これにより、原子保証が作成されます。ボブの確認されたVutxoは、同じトランザクションのバッチに含まれています。これは、彼の没収トランザクションが有効であるために必要なコネクタ入力が作成されます。そのバッチがオンチェーンで作成されない場合、つまりボブは実際に新しい確認されたvutxoを受け取ることはありません。彼がASPに署名した没収トランザクションは、有効で確認可能なオンチェーンではありません。

流動性ダイナミクスとブロックスペース

ユーザー間の転送を容易にするために新しいバッチを作成するために必要なすべての流動性は、ASPによって提供されます。彼らは、古いバッチが期限切れになるまでユーザー向けの新しいバッチを作成するのに十分な流動性を持つ必要があり、ASPはそれらを一方的にスイープして、以前にロックされてユーザー向けのvutxosを作成するために古い流動性を取り戻すことができます。

これは、ARKプロトコルの中心にある流動性ダイナミクスの中核です。ある意味では、これは大規模な効率的な勝利であり、流動性プロバイダーにユーザーを評価することを要求していません。また、ファンドを受け取る前にユーザーが実際に大量の支払いを受け取るかを基本的に推測します。

これは、ASPが保留中のトランザクションを最終決定するために新しいバッチを作成するためにASPがどれくらいの頻度で提供されるかによって、まともな程度に軽減できます。 ASPがトランザクションが登場するときにリアルタイムで新しいバッチを作成しようとする場合、流動性要件はexめの高いものになります。ただし、ASPは、新しいバッチを作成する頻度を低下させ、流動性要件を大幅に低下させる可能性があります。

このダイナミックは、ブロックスペースの使用にも影響を与えます。 ARKトランザクションが同等の信頼性のない最終性を持つために、強力な確認保証を完全にオフシェンすることができる稲妻とは異なり、オンチェーンを作成する新しいバッチが同等の信頼できない程度になります。これは、トランザクションのボリュームがオンチャイン自体を反映していない稲妻とは異なり、非常に圧縮された効率的な方法ではあるものの、ARKトランザクションの速度には本質的にブロックスペースの使用量が本質的に必要であることを意味します。これにより、任意の時間間隔で作成できるアークバッチの数の理論上の上限が作成されます（ただし、この動的に応じて、アークツリーは小さくても大きくなります）。

まとめます

アークは、多くの点で、ライトニングネットワークとほぼ逆のトレードオフセットを提示します。これは、オフチェーントランザクションの大規模なブロックスペース効率の改善であり、Lightningネットワークでの流動性配分の問題を解決しますが、ブロックチェーンのスループット制限と相関するスループット制限がはるかに密接になります。

ほぼ反対のトレードオフのこのダイナミクスは、Lightningネットワークにとって非常に補完的なシステムになります。また、それと相互操作することもできます。つまり、Vutxosは、Lightningネットワークに入るか終了するトランザクションで原子的に交換できます。

最終的には、より広いビットコインエコシステムにどのように適合するかはまだわかりませんが、当初の意図とは異なる場合でも、機能的なニッチを見つけることは間違いなく貴重なプロトコルスタックです。

この投稿ビットコインレイヤー2：アークは最初にビットコインマガジンに登場し、忍によって書かれています。