jakiro
著者：Toly、Solana Labs共同出典：X、@aeyakovenko翻訳：Shan Ouba、ビットチェーンビジョンレルム
Solanaでは、州の組織はフラットなキー値ストレージであり、プログラムはコンセンサスのための主要な投票手順を含め、この州の更新値を実行します。非同期実行の主な目的は、投票手順が他のすべてのプログラムとは独立して動作することを許可することです。常にこの目標を達成するには、いくつかの重要な原則を確保する必要があります。
実行ドメイン
実行ドメインは、一連の手順とその動作キーと値であり、実行中に互いに独立しています。実行ドメインは、異なるスレッドとコアで実行でき、さまざまなマシンで異なる時間に完了します。重要なことは、1つの実行ドメイン（ドメインAなど）が別のドメイン（ドメインBなど）で値を読み書きできないことです。ただし、ドメインは、任意のドメインの実行中に一貫した状態で共有できます。フィールド間の状態を同期させ、キーと値の動きを促進するには、プロトコルが必要です。
取引料金の支払い担当者は、取引実行のドメインを決定します。
キードメイン：VEDとUED
Solanaでは、主に投票実行ドメイン（VED）とユーザー実行ドメイン（UED）の2つのドメインに焦点を当てています。目標は、すべてのユーザープログラムが実行される前に、検証を投票できるようにすることです。
VEDコンポーネント
-
システムプログラム：転送用
-
投票プログラムシステム変数：投票のための投票プログラムシステム変数
-
投票：コア投票手順。このプログラムは静的で一貫性があり、UEDおよびVEDで利用できる必要があります。
-
投票権：投票権を持つ口座
-
投票料金の支払い：投票に関連する料金を支払うアカウント
-
費用支払資金：SOLをVEDの更新アカウントに移動するために使用できます
-
他のすべてのアカウントはUEDに配置されます
VED状態を計算します
n-1とnの間のさようなら境界で、ランタイム時にn+1ドメインのVEDステータスを計算します。この計算は、エポックnの前に完了する必要があります。UED計算は、ERA N-1が完了した後に開始する必要があります。
VEDステータスの標準
-
投票口座：5000を超えるSOLおよびアクティブ状態のパッケージ。
-
費用支払者と投票許可、費用支払資金：上記の投票口座に関連付けられています。
-
新しく作成された投票口座は、最初はアクティブとして設定されました。ユーザーは、これらのアカウントをアクティブにする必要があります。次のVEDステータス計算に含まれます。ユーザーはアカウントを停止でき、アカウントはN+1時代にVED状態から削除されます。
VEDで資金を移動します
投票口座で宣言された資金口座は、VEDの資金を移動するために使用できます。投票口座の支払い費用を更新した後、現在の費用支払人基金は次の時代の終わりまでに活動し続けます。再計算されたVEDアクティベーションが一度、新しいコスト支払い基金はVED州に入り、コスト支払いに追加のSOLを追加するために使用できます。古い費用支払い基金はUED州に入るため、資金はUEDの口座に送り返すことができます。
それは、各投票に使用される署名の数を最小限に抑えるために、費用支払者と統合することができますが、通常、投票許可と同じ値に設定されます。そしてued。
ユニバーサル実行ドメイン
上記の方法は、投票手続きを非常にターゲットにしています。この方法は、任意の数の実行ドメインにさらに宣伝できます。オペレーティングシステム管理プログラムが物理ページのVMIDを追跡するのと同じように、マッピングされている実行ドメインを追跡するアカウント。この特定のプロジェクトでは、マッピングのごく一部が便利です。
-
rx-ued：uedで読んで実行します
-
rx-ed-ved：uedとvedで読み、実行します
-
RW-VED：Vedで読み取りと書き込み
-
rw-ed：uedで読んで書きます
アカウントは複数のドメインで同時に読み書きできないため、他のマッピングは無効です。
-
プログラム：RX-edまたはrx-ed-vedとしてのみマッピングできます。つまり、ユーザーまたは2つのドメインで読み取り可能で実行可能ですが、記述することはできません。プログラムを含むトランザクションは失敗する必要があります。
-
アカウント：マップまたはRWのみがマッピングできます。
System Snapshot投票プログラムとシステムプログラムをRx-ed-vedに構成します。システムプログラムは、VEDからVEDおよびモバイルインターフェイスにシステムアカウントと投票プログラムアカウントを提供します。実際の更新には、アクティブになるために完全なERAが依然として必要です。
所有者のプログラムがターゲットドメインにある場合にのみ、アカウントをドメイン間で再マッピングできます。したがって、投票プログラムとシステムプログラムのアカウントのみがVEDとUEDの間を移動できます。
一般的な方法を使用した後、明示的なコスト支払いファンドアカウントは必要ありません。開発者は、VEDとUEDの間のシステムアカウントを再マップして、ドメイン間で資金を移動できます。
Ved Hashを計算します
ブロックを受信した後、ノードはすべてのトランザクションを実行します。プロセスは次のとおりです。
-
実行には、VEDアカウントを含むトランザクションのみが含まれます。
-
VEDコストの支払いの取引は、口座混合が失敗しました。
-
他のすべてのトランザクションをスキップします。
生成されたVEDステータスの更新は、銀行のハッシュ、つまりVEDハッシュの計算に使用されます。検証は、古い銀行ハッシュの代わりにVed Hashで投票できるようになりました。フォークの前回の投票以来、UEDハッシュアップデートがある場合、ハッシュとスロットは投票に含まれます。
uedハッシュを計算します
ブロックを受信した後、ノードはすべてのトランザクションを処理します。
-
VEDにないアカウントは、UEDの一部と見なされます。
-
実行には、UEDアカウントを含むトランザクションのみが含まれます。
-
ued経費の支払いを含む取引は、混合口座が失敗しました。
-
他のすべてのトランザクションをスキップします。
生成されたUEDステータスアップデートは、銀行ハッシュ、UEDハッシュを計算するために使用されます。
究極の
最終的なセックスは変わらないままです。
トランザクション実行ステータスコード
非同期実行の副作用は、投票時にすぐに検出されない場合があります。1/3以上の検証装置が異なるUEDハッシュを提出する場合、すべてのノードは確認と投票を停止し、オペレーターを警告する必要があります。
ステータスコードを取得するには、RPC API要求を使用すると、ユーザーが同じUEDハッシュ観測で観察された誓約を指定できるようにする必要があります。実行状態は、executionStatus（署名、誓約= x）として表現できます。ここで、xは0または特定のデフォルト値になります。複数のノードとクライアントの設定では、x値は0に受け入れられます。これにより、ユーザーは確認されていない自信が生じます。
非決定的は、確認されたトランザクションのステータスコードをユーザーに返す前に検出する必要がある唯一の障害です。したがって、Xのデフォルト値は通常、楽観的なしきい値から約5％です。
リーダーとブロック生成
リーダーは、VEDが完了した直後にブロックの作成を開始できる必要があります。これは、リーダーが州の一部とUEDコストの支払いの不完全な情報を持っていることを意味します。
-
リーダーが作成したブロックに対してのみVEDドメインを実行する
-
UEDの荷重は、無効なコスト支払いをスキップする必要があります
投票手順の機能的な活性化
投票プログラムは、VED投票が機能がアクティブ化されたときにエポック境界を越え、UEDの投票プログラムと接触している他のトランザクションの時間を操作する場合に設計する必要があります。
賞
VEDの投票口座でのみ報酬を受ける必要があります。
罰する
すべての投票口座は、アクティブ状態であろうとVED州であろうと、罰せられるリスクです。
グローバルクロックアップデート
クロックシステム変数は、投票により更新されます。代替方法を使用する必要があります。それどころか、各ブロックリーダーはクロックを最大1秒前方に移動できます。ネットワークの少なくとも40％は悪意を必要とし、クロックは実際の時間よりも速く成長する可能性があります。クロックは、400ミリ秒のデフォルトで前進することもできます。50ミリ秒のドリフトを想定すると、同期を維持するためにクロックを調整する必要があるリーダーの12.5％のみがリーダーです。
