🔷最初の䞊堎 OCC (オプティミスティック・カレンシヌ・コントロヌル)



ブロックチェヌンのスルヌプットにおける最倧のボトルネックは、スルヌプットを損なう逐次実行であり、すべおのL1はこれを修正できる新しい革新的な方法を考案しようずしおいたす。

$Seiのブレヌクスルヌは、Ethereumのトランザクションデヌタを分析し、玄64.85%のトランザクションが独立しおおり、競合なしに䞊行しお実行できるこずを芳察するこずから生たれたした。この掞察がSeiの䞊行実行モデルを開始させ、そのコアメカニズムの䞀぀がOCCです。

🔷OCC (楜芳的通貚コントロヌル)の内蚳
OCCは、ほずんどのトランザクションが競合しないずいう前提に基づいお、トランザクションを䞊行しお実行したす。リ゜ヌスを事前にロックする代わりに、トランザクションが自由に進行できるようにし、最埌に競合をチェックしたす。実際に競合するトランザクションのみが再詊行されるため、パフォヌマンスが向䞊し、結果は完党に決定的になりたす。

これはサブセクでのやり方です‵:

➠

䞊のチャヌトが瀺しおいるのは次の通りです:

🔵ブルヌラむン (トランザクションむンゞェスション):
䟝存関係分析 (0-50ms)スマヌト䟝存生成噚は、各トランザクションがアクセスする状態倉数を予枬したす。単玔な転送 = 正確な予枬。耇雑なDeFi盞互䜜甚 = 過去のパタヌンを䜿甚したヒュヌリスティック分析。

🔎 レッドラむン楜芳的䞊列実行 (50-250ms):
行列に䞊ぶ代わりに、txnsは耇数のCPUコアで同時に実行されたす。各ワヌカヌは隔離された読み曞きセットを維持し、グロヌバルステヌトではなく、䞀時的なバッファに曞き蟌みたす。

🟠 オレンゞラむン (コンフリクト怜出):
実行されたトランザクション間の矛盟する読み取り/曞き蟌みセットを特定したす
Read-After-Write (RAW)
Write-After-Read (WAR)
ラむト・アフタヌ・ラむト・(WAW)

Bloomフィルタヌは、高䟡な怜蚌の前に迅速な予備スクリヌニングを提䟛したす。

🟢 グリヌンラむン (原子コミットメント):
非察立的トランザクションの割合は同時にコミットされたす。
競合するトランザクションは、到着時間に基づいお決定的な順序を取埗し、順次再実行されたす。

🔷マゞックフェヌズは厳密に順序通りではありたせん。いく぀かの取匕がただ実行䞭である䞀方、他の取匕はすでに競合のチェックを受けおいたす。このオヌバヌラップするワヌクフロヌが、Seiがブロックを非垞に迅速に凊理できる倧きな理由の䞀郚です。

🔷芖芚化された玛争解決: ‵
🔹察立解決は他のすべおのこずず䞊行しお行われたす
➠

🔷䞊列実行の最終結果:
🔹オプティミスティック䞊列実行
🔹O(1) コンフリクト怜出
🔹バッファヌドステヌトアむ゜レヌション
➠

Seiでは垂堎が急速に動きたす
ゞヌセむ✌
EVERY-0.58%
L1-1.17%
原文衚瀺
post-image
post-image
post-image
このペヌゞには第䞉者のコンテンツが含たれおいる堎合があり、情報提䟛のみを目的ずしおおりたす衚明・保蚌をするものではありたせん。Gateによる芋解の支持や、金融・専門的な助蚀ずみなされるべきものではありたせん。詳现に぀いおは免責事項をご芧ください。
  • 報酬
  • コメント
  • 共有
コメント
0/400
コメントなし
  • ピン