SEIは、最新のGigaアップグレードを説明する新しいホワイトペーパーをリリースします

SEIは、最新のGigaアップグレードを説明する新しいホワイトペーパーをリリースしました。ほとんどの読者は、17ページの詳細な技術コンテンツの読みが難しいと感じています。

The latest Giga upgrade from Sei is a significant step in advancing the capabilities of blockchain technology. This article, compiled by Felix, from PANews, provides a clear and concise summary of the main points discussed in Pavel Paramonov's, Founder of Hazeflow, article on the topic.

SEIからの最新のギガアップグレードは、ブロックチェーンテクノロジーの機能を進めるための重要なステップです。 PanewsのFelixがコンパイルしたこの記事では、Topisの記事であるHazeflowの創設者であるPavel Paramonov'sで説明されている主要なポイントの明確で簡潔な要約を提供します。

The article highlights how Giga introduces asynchronous block generation, a multi-proposer model with Autobahn, and parallel execution to enhance performance at different levels.

この記事では、Gigaが非同期ブロック生成、Autobahnを使用したマルチプロポーザーモデル、および異なるレベルでのパフォーマンスを向上させる並列実行を導入する方法を強調しています。

At the heart of Giga lies an interesting take on an idea. Usually, people think about a list of transactions. If we know the initial state of the chain and the transactions are applied in the same order by all honest nodes, they will come to the same final state.

Gigaの中心には、アイデアの興味深い見方があります。通常、人々はトランザクションのリストについて考えます。チェーンの初期状態を知っていて、トランザクションがすべての正直なノードによって同じ順序で適用されると、それらは同じ最終状態になります。

In this case, the result depends only on the initial state and the order of transactions. This means that we only need to agree on the order of transactions in a block. Each node can independently compute the final state.

この場合、結果は初期状態とトランザクションの順序にのみ依存します。これは、ブロック内のトランザクションの順序についてのみ同意する必要があることを意味します。各ノードは、最終状態を個別に計算できます。

Now, an important detail is that execution and consensus (generation) are done in parallel. While a node is performing computations on one block, it is also receiving other blocks.

現在、重要な詳細は、実行とコンセンサス（生成）が並行して行われることです。ノードは1つのブロックで計算を実行していますが、他のブロックも受信しています。

Thus, we can say that blocks are actually executed in total order (not in parallel) and the block generation process itself does happen in "parallel" with consensus. But for any given block, these processes are completely asynchronous.

したがって、ブロックは実際には総順序で実行され（並行していない）、ブロック生成プロセス自体がコンセンサスと「並行」で発生すると言えます。しかし、特定のブロックでは、これらのプロセスは完全に非同期です。

Obviously, it seems impossible to perform consensus and execute the same block at the same time. Therefore, when executing block n, the node will receive block n+1 to proceed to the next step.

明らかに、コンセンサスを実行して同じブロックを同時に実行することは不可能と思われます。したがって、ブロックnを実行すると、ノードはブロックn+1を受信して​​次のステップに進みます。

If the consensus becomes skewed (e.g. 1/3 of the nodes in the network act maliciously), the chain will halt, similar to a standard BFT protocol.

コンセンサスが歪んだ場合（ネットワークのノードの1/3が悪意のある）、標準のBFTプロトコルと同様に、チェーンが停止します。

Transactions that fail to execute within a block do not invalidate the block, but simply remain in a failed state, because generation and execution are separate, and the final state of the current block is committed in subsequent blocks.

ブロック内で実行できないトランザクションは、ブロックを無効にすることはありませんが、生成と実行が別々であり、現在のブロックの最終的な状態が後続のブロックでコミットされるため、単に失敗した状態にとどまります。

How Is The Multi-Proposer Model Implemented and What Is Autobahn ?

マルチプロポーザーモデルはどのように実装されており、Autobahnとは何ですか？

The consensus protocol itself is called "Autobahn" (like the German Autobahn with no speed limit). Autobahn decouples data availability from transaction ordering, and it has an interesting model behind it.

コンセンサスプロトコル自体は「Autobahn」と呼ばれます（速度制限のないドイツのオートバーンのように）。 Autobahnは、トランザクション注文からのデータの可用性を切り離し、その背後に興味深いモデルがあります。

Just like any lane on a highway, there are multiple lanes and each node has its own lane. Nodes use these lanes to make proposals about the ordering of transactions. A proposal is just an ordered collection of transactions.

高速道路の他の車線と同様に、複数の車線があり、各ノードには独自の車線があります。ノードはこれらのレーンを使用して、トランザクションの順序付けについて提案します。提案は、取引の順序付けられたコレクションにすぎません。

Autobahn sometimes performs a "tipcut" operation, which aggregates multiple proposals to finalize the order of transactions.

Autobahnは「Tipcut」操作を実行することがあります。これにより、複数の提案が集約されてトランザクションの順序が最終的になります。

Proposers have an incentive to wait to publish blocks and publish a single block when possible, but the execution time limit for each block (similar to the gas limit) changes this dynamic slightly.

提案者には、可能な場合はブロックを公開して単一のブロックを公開するのを待つインセンティブがありますが、各ブロックの実行時間制限（ガス制限と同様）がこの動的にわずかに変更されます。

A proposal on a channel is usually equivalent to one block, which means that when a tipcut occurs, multiple blocks will be cut off at the same time.

チャネル上の提案は通常、1つのブロックに相当します。つまり、チップが発生すると、複数のブロックが同時に遮断されます。

After that, the leader of the slot sends the Tipcut to other nodes to complete the sorting. In fact, when a node votes on a single Tipcut, it is already preparing for the next Tipcut.

その後、スロットのリーダーが他のノードにチップカットを送信してソートを完了します。実際、ノードが単一のチップカットに投票するとき、それはすでに次のチップカットの準備をしています。

Nodes that missed batches can obtain them asynchronously from the validators listed in the PoA: this is the essence of why data availability is needed.

バッチを逃したノードは、POAにリストされているバリッタから非同期にそれらを取得できます。これが、データの可用性が必要な理由の本質です。

Under synchronous conditions, if the leader is correct, Autobahn completes the proposal confirmation in two rounds of communication. If the leader fails, the mechanism elects a new leader to maintain the progress.

同期条件下では、リーダーが正しい場合、Autobahnは2ラウンドのコミュニケーションで提案の確認を完了します。リーダーが失敗した場合、メカニズムは進捗を維持するために新しいリーダーを選出します。

The next tip-cut proposal can actually start during the commit phase of the current tip-cut, thus reducing latency since execution happens in parallel with generation.

次のチップカット提案は、実際に現在のチップカットのコミットフェーズ中に開始でき、したがって、実行と並行して実行されるため、遅延が減少します。

In fact, the entire model is a multi-proposer model, where many nodes can make proposals for their block ordering at the same time. Each validator proposes its own blocks and receives proof (PoA) that the network owns these blocks, which helps improve the throughput and overall efficiency of the network.

実際、モデル全体はマルチプロポーザーモデルであり、多くのノードがブロック順序の提案を同時に作成できます。各バリデーターは独自のブロックを提案し、ネットワークがこれらのブロックを所有していることを証明（POA）を受け取り、ネットワークのスループットと全体的な効率を改善するのに役立ちます。

Parallel Execution And Its Applicability

並列実行とその適用性

As mentioned, the block execution process and consensus happen in parallel, even though the blocks themselves are actually executed sequentially. You might be wondering if this constitutes true parallel execution.

前述のように、ブロック自体が実際に順次実行されている場合でも、ブロック実行プロセスとコンセンサスは並行して発生します。これが真の並列実行を構成するかどうか疑問に思うかもしれません。

The answer is both yes and no.

答えはイエスとノーの両方です。

Although blocks are executed one after the other, transactions within a block can be executed in parallel if the transactions do not modify (write to) the same state and the result of one transaction does not affect another transaction.

ブロックは次々と実行されますが、トランザクションが同じ状態を変更（書き込み）しない場合、ブロック内のトランザクションは並行して実行できます。

In short, their execution paths should not depend on each other. Giga has no memory pool and transactions are included by nodes immediately.

要するに、彼らの実行パスは互いに依存してはなりません。ギガにはメモリプールがなく、トランザクションはすぐにノードに含まれます。

There may also be situations where there are high-frequency conflicts, in which case the system switches to processing transactions one at a time to ensure that transactions can move forward.

また、高周波の競合がある状況もある場合があります。その場合、システムはトランザクションが前進できるようにトランザクションを1つずつ処理に切り替えます。

To put it simply, parallel execution distributes transactions across multiple cores, allowing transactions that do not interfere with each other to run simultaneously.

簡単に言えば、並列実行は複数のコア間でトランザクションを配布し、互いに干渉しないトランザクションが同時に実行されるようにします。

Storage Issues and Optimization

ストレージの問題と最適化

Due to the large volume of transactions, data needs to be both secure and easily accessible, so its storage method should be slightly different from traditional blockchain storage. Giga stores data in

トランザクションが大量にあるため、データは安全で簡単にアクセスできる必要があるため、そのストレージ方法は従来のブロックチェーンストレージとわずかに異なるはずです。ギガはデータを格納します