著者：Tolly、Solana Labsの共同創設者 出典：X、@aeyakovenko 翻訳：Good Oba、Golden Finance
Solanaでは、状態はフラットなキーバリューストアとして整理される。プログラムはこのステート上で実行され、コンセンサスのためのキー投票プログラムを含め、値を更新する。非同期実行の主な目的は、投票手続きを他のすべての手続きから独立して実行できるようにすることである。この目的を一貫して達成するためには、いくつかの重要な原則を保証する必要がある。
実行ドメイン
実行ドメインとは、実行時に互いに独立したプログラムとその操作のキーと値の集合のことです。実行ドメインは異なるスレッドやコアで実行でき、様々なマシン上で異なる時間に完了する。重要なのは、ある実行ドメイン（例えばドメインA）は、別のドメイン（例えばドメインB）の値を読み書きできないことである。しかし、ドメインは、どちらのドメインの実行中も一貫性を保つ状態を共有することができる。ドメイン間の状態を同期し、キーと値の移動を容易にするプロトコルが必要です。
トランザクション手数料の支払者は、トランザクションが実行されるドメインを決定する。
主要ドメイン：VEDとUED
Solanaでは、投票実行ドメイン（VED）とユーザー実行ドメイン（UED）という2つのドメインに焦点を当てる。目標は、すべてのユーザー手続きが実行される前に、バリデータが投票できるようにすることです。
VEDの構成要素
システム手続き: 送金に使われる
投票手続きシステム
投票手続きシステム変数：投票に使われる投票手続きシステム変数
投票手続き：核となる投票手続き。この手続きは静的で一貫性があり、UEDとVEDの両方に存在しなければならない。
投票権: 投票権を持つアカウント
投票経費支払者: 投票に関連する経費を支払うアカウント
投票経費支払者資金: 投票に関連する経費を支払うアカウント
投票経費支払者資金: 投票に関連する経費を支払うアカウント。/strong>：solをVEDに移動するために使用できる再生可能なアカウント
UEDに置かれた他のすべてのアカウント
VEDステータスの計算
エポックN-1とNの境界で、ランタイムはN+1ドメインのVEDステータスを計算します。この計算はエポックNの終了前に完了しなければなりません。UED計算はエポックN-1を開始する前に完了しなければなりません。
VEDステータスの基準
投票アカウント：5,000ソル以上が誓約され、アクティブなアカウント。
経費支払者・投票権、経費支払者基金：上記の投票アカウントに関連したもの。
新しく作成された投票アカウントは、最初は非アクティブに設定されています。ユーザーはこれらのアカウントをアクティブにする必要があり、アクティブにすると、次回のVEDステータス計算に含まれます。ユーザーはアカウントを非アクティブにすることができ、N+1エポックの間、VEDステータスから削除されます。
VEDでの資金移動
投票口座で宣言された費用支払者資金口座は、VEDでの資金移動に使用できます。Voting AccountのFee Payer Funding Accountを更新した後、現在のFee Payer Fundは次のEpochの終わりまで有効なままです。再計算されたVEDがアクティブになると、新しい費用支払者基金はVEDステータスになり、費用支払者に追加のソルを追加するために使用することができます。
これを経費支払人と統合することは可能ですが、投票ごとに使用される署名の数を最小限にするために、経費支払人は通常、投票権と同じ値に設定されます。
ユニバーサル実行ドメイン
上記の方法は、投票手続きに非常に適しています。さらに一歩進んで、任意の数の実行ドメインにアプローチを拡張することもできます。アカウントは、OS のハイパーバイザーが物理ページの VMID を追跡するのと同じように、マップされている実行ドメインを追跡します。
アカウントは複数のドメインで同時に読み書きできないので、他のマッピングは無効です。
システムスナップショットは、投票プログラムとシステムプログラムをRX-UED-VEDとして構成します。インターフェースを提供する。実際の更新は、まだ活性化するために完全なエポックを必要とします。
アカウントは、オーナープログラムがターゲットドメインにある場合にのみ、ドメイン間で再マップすることができます。したがって、VEDとUEDの間で移動できるのは、投票プログラムとシステムプログラムのアカウントのみです。
ユニバーサルアプローチでは、明示的な経費支払者ファンドアカウントはもはや必要ありません。開発者は、ドメイン間で資金を移動するために、VEDとUEDの間で任意のシステムアカウントを再マッピングすることができます。
VEDハッシュの計算
ブロックを受け取った後、ノードはすべてのトランザクションを実行します。
生成されたVEDステータス更新は、銀行ハッシュ、VEDハッシュの計算に使用されます。バリデータは古いバンクハッシュの代わりにVEDハッシュを使って投票できるようになりました。フォークに関する最後の投票以降にUEDハッシュの更新があった場合、そのハッシュとスロットが投票に含まれます。
UEDハッシュの計算
ブロックを受け取った後、ノードはすべてのトランザクションを処理します:
VED にないアカウントは UED の一部とみなされます。
UEDアカウントのみを含むトランザクションを実行します。
UED手数料支払者を含むが、混合口座を含む取引は失敗します。
他のすべてのトランザクションをスキップします。
生成されたUEDステータス更新は、銀行ハッシュ、UEDハッシュの計算に使用されます。
ファイナリティ
ファイナリティは変更されません。
トランザクション実行ステータスコード
非同期実行の副作用として、投票フォーク時に非決定性が同期的かつ即座に検出されない可能性があります。1/3以上のバリデータが異なるUEDハッシュを提出した場合、すべてのノードは確認と投票を停止し、オペレータに警告しなければなりません。
ステータスコードを得るために、RPC APIリクエストは、同じUEDハッシュを計算する観測されたプレッジを指定できるようにしなければならない。実行ステータスは、ExecutionStatus (signature, pledge = X)として表すことができます。複数のノードとクライアントがあるセットアップでは、Xに0を指定することが許容されます。
非確定性は、確認されたトランザクションに対してステータスコードがユーザーに返される前に検出される必要がある唯一の障害であるため、Xのデフォルト値は通常、楽観的な確認しきい値または約5％と同じくらい低くすることができます。
リーダーとブロック生成
リーダーは、VEDが完了するとすぐにブロック生成を開始できなければなりません。これは、リーダーがUED料金支払者のステータスについて、部分的で不完全な情報を持つことを意味します。
投票手続きの機能起動
投票手続きは、以下のようになります。VEDの投票は、機能的に活性化されたときにエポック境界を越える可能性があり、投票手続きに触れるUEDの他のトランザクションのタイミングとは異なる動作をすることを前提に設計されなければならない。
報酬
VEDステータスの投票アカウントのみが報酬を受け取るべきである。
ペナルティ
すべての投票アカウントは、「アクティブ」または「VED」のステータスにかかわらず、ペナルティのリスクがあります。
グローバルクロックの更新
クロックシステム変数は投票によって更新されます。別の方法を用いるべきである。その代わりに、各ブロックリーダーはクロックを最大1秒進めることができます。時計が実際の時間よりも速く成長するためには、ネットワークの少なくとも40%が悪意を持っている必要がある。時計をデフォルトで400ミリ秒進めることもできる。50ミリ秒のドリフトを仮定すると、12.5％のリーダーだけが同期を保つために時計の時間を調整する必要がある。
JinseFinance
Beincrypto
cryptopotato
Tristan
Bitcoinist
Cointelegraph