Kasplex L2：Kaspa utxoブロックチェーン用のロールアップベースのスマートコントラクトソリューション

ブロックチェーンテクノロジーが発展するにつれて、特にUTXOモデルを採用するブロックチェーンにとって、スケーラビリティとプログラマ性は依然として重要な課題です。

As blockchain technology continues to develop, scalability and programmability remain crucial challenges, especially for blockchains that adopt the UTXO model. Among the emerging layer-one public blockchains, Kaspa stands out with its high throughput achieved by the BlockDAG structure and the GHOSTDAG protocol. However, Kaspa, like Bitcoin, faces limitations in terms of native smart contract functionality, a strength of account-based chains like Ethereum.

ブロックチェーンテクノロジーが発展し続けるにつれて、特にUTXOモデルを採用するブロックチェーンにとって、スケーラビリティとプログラマ性は重要な課題のままです。新たな層1のパブリックブロックチェーンの中で、Kaspaはブロックダグ構造とGhostDagプロトコルによって達成される高スループットで際立っています。ただし、カスパは、ビットコインと同様に、イーサリアムのようなアカウントベースのチェーンの強度であるネイティブスマートコントラクト機能の点で制限に直面しています。

To address this problem, the Kaspa ecosystem has been exploring several Layer 2 (L2) solutions, including Sparkle, Igra L2, and Kasplex L2. While Sparkle is still in the theoretical stage and Igra L2 is under development, our analysis will focus on Kasplex L2 as the closest to mature implementation.

この問題に対処するために、KaspAエコシステムは、Sparkle、Igra L2、Kasplex L2を含むいくつかのレイヤー2（L2）ソリューションを調査しています。 Sparkleはまだ理論的段階にあり、Igra L2は開発中ですが、分析は成熟した実装に最も近いKasplex L2に焦点を当てます。

Kasplex L2 is a second-layer scaling solution that keeps the first-level chain responsible for transaction ordering and data availability, shifting the computational load to the second layer. In this design, Kaspa's first-level chain, which uses the UTXO model and has a throughput of 10 BPS, determines the standard order of transactions and ensures that its data is accessible to everyone, while Kasplex L2 executes the Ethereum Virtual Machine (EVM) bytecode to perform smart contract functions.

Kasplex L2は、第1レベルのチェーンをトランザクションの順序とデータの可用性に責任を負わせ、計算負荷を2番目のレイヤーにシフトする2層スケーリングソリューションです。この設計では、UTXOモデルを使用し、10 bpsのスループットを備えたKaspaの最初のレベルチェーンは、トランザクションの標準順序を決定し、そのデータがすべての人がアクセスできるようにしますが、Kasplex L2はスマート契約機能を実行するためにイーサリアム仮想マシン（EVM）バイテコードを実行します。

The core mechanism of Kasplex L2 is to embed EVM bytecode in the payload of Kaspa primary chain transactions. This process can be divided into the following steps:

Kasplex L2のコアメカニズムは、KaspaプライマリチェーントランザクションのペイロードにEVMバイトコードを埋め込むことです。このプロセスは、次の手順に分けることができます。

* Transaction submission: A user submits a transaction to the Kaspa primary chain, where the payload contains EVM bytecode. For example, the payload may encode a call to the HelloWorld() smart contract function.

*トランザクションの提出：ユーザーは、ペイロードにEVMバイテコードが含まれるKaspAプライマリチェーンにトランザクションを提出します。たとえば、ペイロードは、helloworld（）スマートコントラクト関数への呼び出しをエンコードする場合があります。

* First-level chain ordering: Kaspa's BlockDAG orders transactions within its DAG structure, providing a deterministic transaction sequence.

*第1レベルのチェーン注文：KaspaのBlockDagは、DAG構造内のトランザクションを注文し、決定論的トランザクションシーケンスを提供します。

* Layer 2 execution: Kasplex L2 runs as an indexer, scanning the payload transactions on the primary chain, extracting the EVM bytecode, executing it in the specified order, and updating its state. Invalid or conflicting transactions (such as transactions attempting to double-spend) will be discarded.

*レイヤー2の実行：Kasplex L2はインデクサーとして実行され、プライマリチェーンのペイロードトランザクションをスキャンし、EVMバイトコードを抽出し、指定された順序で実行し、状態を更新します。無効または競合するトランザクション（2倍の支出を試みるトランザクションなど）は破棄されます。

Transaction submission mechanism

トランザクション提出メカニズム

Kasplex L2 supports two transaction submission methods, each having different effects:

Kasplex L2は2つのトランザクション送信方法をサポートしています。それぞれが異なる効果を持っています。

* Canonical Submission: Transactions are submitted directly to L1 through Kaspa-compatible wallets. This method does not require relay nodes and complies with the decentralization principle of the blockchain system.

*標準的な提出：トランザクションは、KaspA互換のウォレットを介してL1に直接送信されます。この方法では、リレーノードを必要とせず、ブロックチェーンシステムの分散化原理に準拠しています。

* Proxied Submission: Transactions are submitted through a relayer to be compatible with EVM tools like MetaMask. The relayer forwards the transaction to Kaspa L1 to ensure that it is recorded before being processed by L2. This approach prioritizes user convenience but introduces a reliance on relayers.

*提出された提出：トランザクションは、メタマスクなどのEVMツールと互換性があるため、中継者を介して送信されます。リレーヤーは、トランザクションをKaspa L1に転送して、L2によって処理される前に記録されることを確認します。このアプローチは、ユーザーの利便性を優先しますが、中継者への依存を紹介します。

The proxy submission mechanism ensures atomicity by requiring all second-layer transactions to be anchored on the L1 chain. If a transaction is generated on L2 but has not yet been recorded on the primary chain, the relayer will submit it to the L1 chain for confirmation. This design prevents "native" L2 transactions that bypass the L1 chain consensus and avoids potential security risks.

プロキシ提出メカニズムは、すべての第2層トランザクションをL1チェーンに固定することを要求することにより、原子性を保証します。トランザクションがL2で生成されているが、プライマリチェーンにまだ記録されていない場合、リレーヤーは確認のためにL1チェーンに提出します。この設計は、L1チェーンのコンセンサスをバイパスし、潜在的なセキュリティリスクを回避する「ネイティブ」L2トランザクションを防ぎます。

The following figure illustrates the two submission paths:

次の図は、2つの提出パスを示しています。

Canonical path: Wallet → Kaspa L1 → Kasplex L2

標準パス：ウォレット→カスパL1→カスプレックスL2

Proxy path: MetaMask → Relay → Kaspa L1 → Kasplex L2

プロキシパット：メタマスク→レイ→カスパL1→カスプレックスL2

As you may notice, the transaction is actually finalized on L1 before being interpreted by the L2 indexer. This is exactly how Kasplex L2 works: L1 finalizes the data first, and then L2 reads the transaction and updates the state.

ご存知かもしれませんが、L2インデクサーによって解釈される前に、トランザクションは実際にL1で確定されます。これはまさにKasplex L2の仕組みです。L1は最初にデータを完成させ、次にL2はトランザクションを読み取り、状態を更新します。

To better understand Kasplex L2, we can compare it with Bitcoin Inscriptions (specifically BRC-20), another approach to expanding the programmability of UTXO model blockchains. Both aim to integrate the strengths of the first-level chain—transaction ordering and data availability—while shifting computational complexity to the second layer, but they differ in their implementation and goals.

Kasplex L2をよりよく理解するために、UTXOモデルブロックチェーンのプログラマ性を拡大するもう1つのアプローチであるビットコインの碑文（特にBRC-20）と比較できます。どちらも、計算の複雑さを2番目のレイヤーにシフトする一方で、第1レベルのチェーンの強度（トランザクションの順序付けとデータの可用性）を統合することを目指していますが、実装と目標が異なります。

Similarities

類似点

Both Kasplex L2 and BRC-20 embed useful data in primary chain transactions. BRC-20 leverages Bitcoin's Tapscript (enabled by the SegWit upgrade) to store token metadata, typically in a three-step process: "commit (data hash) → reveal (reveal, data itself) → spend (spend, token transfer)."

Kasplex L2とBRC-20の両方が、プライマリチェーントランザクションに有用なデータを埋め込みました。 BRC-20は、ビットコインのTapscript（SEGWITアップグレードによって有効になっている）を活用してトークンメタデータを保存します。通常、3段階のプロセスで：「コミット（データハッシュ）→公開（公開、データ自体）→支出（支出、トークン転送）」

In contrast, Kasplex L2 embeds EVM bytecode into the payload of Kaspa L1 transactions. For example, if we want to execute a HelloWorld() function in a smart contract, the compiled bytecode will be put into the transaction payload. This structure enables L2 to perform the same functions as a standard EVM chain.

対照的に、Kasplex L2はEVM bytecodeをKaspa L1トランザクションのペイロードに埋め込みます。たとえば、スマートコントラクトでhelloworld（）関数を実行する場合、コンパイルされたbytecodeがトランザクションペイロードに入れられます。この構造により、L2は標準のEVMチェーンと同じ機能を実行できます。

Moreover, both rely on the first-level chain for ordering operations. For BRC-20, the Bitcoin blockchain is used to order token transfers, while Kasplex L2 leverages Kas

さらに、どちらも秩序操作のために第1レベルのチェーンに依存しています。 BRC-20の場合、ビットコインブロックチェーンはトークン転送を注文するために使用され、Kasplex L2はKASをレバレッジします