# Deferred Execution (遅延実行)
Monadブロックチェーンの新しい側面の1つは、実行がコンセンサスから切り離されていることです。
要約すると、コンセンサスはMonadノードがトランザクションの正式な順序について合意に達するプロセスであり、実行はそれらのトランザクションを実際に実行して状態を更新するプロセスです。
Monadのコンセンサスでは、ノードはトランザクションの正式な順序について合意に達しますが、リーダーや検証ノードがまだトランザクションを実行している必要はありません。
つまりリーダーは、結果の状態ルートをまだ知ることなく順序付けを提案し、検証ノードは(たとえば)ブロック内のすべてのトランザクションが元に戻さずに実行されるかどうかを知らずに、ブロックの妥当性について投票します。
どうすればいいの？そしてなぜMonadはこんなことをするのでしょうか？
その答えはMonadの設計の基礎であり、これによりMonadは大幅な高速化を実現し、単一シャードのブロックチェーンを数百万のユーザーに拡張できるようになります。
## 実行とコンセンサスのインターリーブは非効率的です
イーサリアムでは、実行は合意の前提条件であるため、ノードがブロックに関して合意に達すると、(1)ブロック内のトランザクションのリストと、(2)実行後のすべての状態を要約するマークル ルートの両方について合意することになります。そのトランザクションのリスト。その結果、リーダーは提案を共有する*前に、*提案されたブロック内のすべてのトランザクションを実行する必要があり、検証ノードは投票で応答する*前にそれらのトランザクションを実行する必要があります。*
このパラダイムでは、実行にかかる時間は非常に限られています。これは、実行を2回実行し*、*コンセンサスを得るための複数ラウンドのクロスグローブコミュニケーションに十分な時間を残しておく必要があるためです。さらに、実行するとコンセンサスがブロックされるため、ガス制限は非常に控えめに選択し、最悪のシナリオでも予算内ですべてのノードで計算が完了するようにする必要があります。
## 決定的な順序付けは状態の決定論を意味する
ここに明らかだが重要な洞察があります：トランザクションの公式な順序が与えられた場合、真の状態は完全に決定されます。真実を明らかにするには実行が必要ですが、真実はすでに決定されています。
Monadは、この洞察を利用して、コンセンサス前にノードが実行する必要があるという要件を取り除きます。ノードの合意は、公式な順序についてのみです；各ノードはブロックNのトランザクションを独立して実行しながら、ブロックN+1についてのコンセンサスを開始します。
これにより、実行がコンセンサスに追いつく必要があるだけなので、フルブロック時間に相当するガス予算が可能になります。さらに、このアプローチは、実行が平均でコンセンサスに追いつく必要があるだけなので、正確な計算時間の変動に対してより寛容です。
## 遅延メルクルルートは依然としてステートマシンのレプリケーションを保証する
上記に対する主な反論は以下の通りです。
* もしノードの1つが悪意を持っており、コンセンサスで指定された正確なトランザクションを実行しない場合はどうなるか？（例えば、特定のトランザクションを省略するか、または状態変数を任意の値に設定するかもしれません。）
* もしノードが実行中にミスを犯した場合はどうなるか？
これらの懸念に対処するため、Monadではブロック提案にDブロック遅延のメルクルルートを含めます。ここでDはシステム全体のパラメーターです（現在は10になることが予想されます）。この遅延メルクルルートの結果：
1. ネットワークがブロックNについてコンセンサス（2/3多数決）に達した後、ネットワークはブロックN-Dの公式な結果がメルクルルートMに根ざした状態であることに同意したことを意味します。軽量クライアントは、ブロックN-Dでの状態変数値のメルクル証明をフルノードに問い合わせることができます。
2. ブロックN-Dで実行エラーがあるノードは、ブロックNからコンセンサスから外れます。これはそのノードにブロックN-D-1の終了状態へのロールバックを引き起こし、その後ブロックN-Dのトランザクションの再実行（メルクルルートが一致することを期待して）、その後ブロックN-D+1、N-D+2などのトランザクションの再実行が続きます。
Ethereumのアプローチは、コンセンサスを利用してステートマシンのレプリケーションを非常に厳格に強制します：ノードがコンセンサスに達した後、大多数が公式の順序とその順序から生じる状態について同意していることを知ります。しかし、この厳格性は非常に限られたスループットという大きなコストを伴います。Monadはこの厳格性を少し緩和し、大きな効果を上げています。
## ファイナリティについて
MonadBFTでは、ファイナリティは単一スロット(1 秒)であり、フルノードを使用している場合、実行結果の遅れは通常1秒未満です。これを少し開梱してみましょう。
**Monad のファイナリティは単一スロット(1 秒)です**。トランザクションを送信すると、単一ブロック後に(他のすべてのトランザクションの中で)トランザクションの正式な注文が表示されます。ネットワークの大多数による悪意のあるアクションがない限り、順序が変更される可能性はありません。これにより、モナドのファイナリティは[イーサリアム](https://hackmd.io/@prysmaticlabs/finality)よりも大幅に速くなります(2 エポック、別名 12.8 分)。
**トランザクションの実行結果**(成功したか失敗したか? その後の残高はどうなったか?) は**通常、フル ノードではファイナリティよりも1秒未満遅れます。** トランザクションの結果をすぐに知る必要がある人(たとえば、注文のステータスを知りたい高頻度トレーダー)は、フル ノードを実行できます。 Monadは、フルノードのコストを最小限に抑えるように設計されています。詳細については、「ハードウェア要件」を参照してください。
フルノードを実行せずにトランザクションの結果を安全にクエリしたい人は誰でも、マークルプルーフを使用して残高をフルノードにクエリしながらライトクライアントを実行できます。この場合、クエリにはマークルルート遅延(`D=10`ブロック、つまり10秒)だけ遅れが生じます。現在、ほとんどのユーザーはソフトウェア(ブラウザ)ウォレットまたはブロックエクスプローラーを使用してブロックチェーンの状態を表示していることに注意してください。これらの使用パターンにはどちらもライトクライアントは含まれません。
一部の読者は、マークルルート遅延(`D=10`ブロック)とファイナリティを誤って混同し、ファイナリティが10ブロックであると誤って仮定する可能性があります。それは真実ではない。公式のトランザクション順序は1ブロック後に決定され、その後は超多数によるビザンチン的な振る舞いがなければ再組織化は行われません。
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://neafs-organization.gitbook.io/japanads-doc/na/konsensasu/deferred-execution-chi-yan-shi-xing.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.