CX-Atomic — Cryptix Networkの新しいスマートコントラクト解説

Section 01

スマートコントラクトの様々なアプローチ方法

スマートコントラクトはブロックチェーン上で自動的に実行されるプログラムです。既存の各ブロックチェーンは、それぞれの設計思想に基づいて実装方法を選択しています。

各ブロックチェーンのスマートコントラクトには、大きく分けていくつかのアプローチが存在します。仮想マシン（VM）を使うアプローチと、VMを使わないアプローチです。さらに、どのレイヤーにコントラクトロジックを置くかによって、設計の特性が大きく変わってきます。

🖥️

VMベース方式

コントラクトコードを仮想マシンが解釈・実行する方式。EVM（Ethereum）・BPF（Solana）などが代表例。柔軟性が高く、任意のロジックを記述できます。

📜

スクリプト直接コンパイル方式

高水準言語をブロックチェーンのネイティブスクリプトに直接コンパイルする方式。KaspaのSilverScriptが代表例。VMを介さずL1が直接実行します。

⚡

プリコンパイル済み方式

コントラクトテンプレートを事前にRustでコンパイルし、コンセンサスルールとして組み込む方式。CryptixのCX-Atomicが採用する全く新しいアプローチです。

🔷 CX-Atomicの設計哲学

CX-Atomicはこれまでのどのスマートコントラクトシステムとも直接比較できない、全く新しいカテゴリーです。UTXOモデル・決定論的実行・プリコンパイル済みRust関数を組み合わせることで、おおよそのユースケース——DeFiの基本プリミティブ・トークン・DEX・DAO・NFT・PoWマイニングトークン——に対応します。

「シンプルで安全を保つ」というBitcoinの原則を、スマートコントラクトの領域に持ち込んだ設計です。

📌 CX-Atomicの現状：現在開発中です。先に、別の「RIFT」という直列ブロックチェーンに実装され、実証後にCryptix（BlockDAG）へ実装される予定です。

Section 02

各プラットフォームのスマートコントラクト解説

Ethereum・Solana・Kaspa・Cryptixのアプローチをそれぞれ解説します。それぞれに異なる設計の優先順位があります。

💎

Ethereum / EVM系

Solidity / Vyper → EVM（Ethereum Virtual Machine）

最大のエコシステム・最高の柔軟性

✅ 特徴

✅任意のロジックが記述可能（最高の柔軟性）
✅世界最大の開発者エコシステム
✅ERC-20・ERC-721等の確立された標準規格
✅最も多くのDeFiプロトコルが稼働
✅Solidityライブラリが豊富
✅L2（Rollup）によるスケーリング

📋 設計上の特性

📋グローバルVMが全コントラクトの状態を共有する設計
📋失敗したトランザクションでもガス代が発生する
📋コントラクトのセキュリティ監査が推奨される
📋全履歴の再現にアーカイブノードが必要
📋コントラクトデプロイ後の変更が制限される

EVM（Ethereum Virtual Machine）はグローバルな状態を持つ汎用マシンです。「最大限の柔軟性」を提供することを優先した設計で、任意のロジックを記述できます。世界最大のDeFiエコシステムを支えており、最も実績のあるスマートコントラクトプラットフォームです。

🌊

Solana

Rust / C → BPF（Berkeley Packet Filter）VM

高速・低コスト・Rustベース

✅ 特徴

✅高速処理（数万TPS）・低手数料
✅Rustによる型安全なプログラミング
✅Sealevelによる並列処理
✅活発な開発者コミュニティ
✅NFT・DeFiエコシステムが充実

📋 設計上の特性

📋BPF VMを使用する設計
📋コンピュートユニット（CU）の管理が必要
📋アカウントモデルは独自の学習コストがある
📋バリデータ参加にはハードウェア要件がある
📋PoSによる設計

SolanaはBPF仮想マシンを使用し、Rustで書かれたプログラムを実行します。高速性・低コスト・Rustの型安全性を特徴としており、NFTやDeFiのエコシステムが充実しています。アカウントモデルはEthereumと異なる独自の設計で、高スループットを実現しています。

⬡

Kaspa — SilverScript（Toccata後）

SilverScript → Kaspa Script（直接コンパイル・VMなし）

VMなし・UTXOモデル・2026年6月予定

✅ 特徴

✅グローバルVMなし（Kaspa Scriptに直接コンパイル）
✅UTXOモデルによる再入攻撃への構造的対応
✅ZK証明（Groth16・RISC Zero）をL1に統合
✅SilverScriptによる高い表現力
✅高速PoW BlockDAG（10BPS）との組み合わせ

📋 設計上の特性

📋2026年6月のToccataハードフォーク後に実装予定
📋UTXOローカル計算モデル（グローバル共有状態なし）
📋開発者エコシステムはこれから形成される段階
📋PoWマイニングトークンは設計上対応できない

SilverScriptはEVMのような別個のVMを使わず、Kaspa Scriptに直接コンパイルされる革新的な設計です。UTXOモデルを維持したままスマートコントラクトを実現するアプローチは技術的に非常に独自性が高く、ZK証明との組み合わせで将来的な可能性が大きい設計です。2026年6月のToccataハードフォーク後に実装される予定です。

⚡

Cryptix — CX-Atomic

プリコンパイル済みRust + UTXOベース + 決定論的コンセンサス検証

🌟 全く新しいカテゴリー・開発中

✅ 強み

✅グローバルVMなし（プリコンパイル済みRust関数）
✅完全決定論的（浮動小数点・乱数・外部入力なし）
✅再入攻撃・ガス操作・無限ループが設計上不可能
✅世界初：PoWマイニングトークン（CX-MIN）対応
✅ジェネシスから全状態を再計算可能
✅500〜2,000コントラクトアクション/秒（未最適化）
✅コントラクト監査不要（プリコンパイル済みで事前検証済み）
✅システム手数料ゼロ

📋 設計上の特性

📋現在開発中（RIFTで先行実装予定）
📋EVMのような任意ロジックは設計の対象外
📋8KBの状態制限（拡張パスあり）
📋新しい概念のため学習コストがある
📋開発者エコシステムはこれから

CX-Atomicは既存のどのスマートコントラクトシステムとも直接比較できません。「前例のない独自の融合であり、比較対象が存在しない新しいカテゴリー」です。ネイティブコントラクトテンプレートはプリコンパイル済みのRust関数であり、動的なバイトコードアップロードも外部ライブラリも存在しません。CX-VMはオプションとして存在しますが、コントラクトインスタンス内のサンドボックスに完全に閉じ込められ、グローバルコンセンサスに影響を与えません。おおよそのユースケース——DeFi基本プリミティブ・トークン・DEX・DAO・NFT・マイニングトークン——に対して十分に対応できる設計です。

Section 03

スマートコントラクト詳細比較表

4つのブロックチェーンの設計上の特性比較一覧表。

比較項目	Ethereum / EVM	Solana	Kaspa（Toccata後）	CX-Atomic
実行方式	グローバルEVM	BPF VM	Scriptに直接コンパイル	プリコンパイル済みRust
グローバルVM	あり（EVM）	あり（BPF）	なし	なし※
決定論性	条件次第	条件次第	高い	完全（数学的保証）
再入攻撃耐性	対策が必要	アカウントモデルで緩和	UTXOで構造的対応	設計上不可能
失敗時のガス代	発生する	発生する	ゼロ	ゼロ
コントラクト監査	推奨・必要	推奨・必要	推奨	不要（事前検証済み）
状態管理方式	グローバルDB（無制限）	アカウントベース	UTXOローカル	UTXO（8KB/インスタンス）
状態の再現性	アーカイブノード推奨	スナップショット方式	ブロック履歴から可能	ジェネシスから完全再計算
プルーニング安全性	アーカイブノード前提	スナップショット依存	ブロック保持で安全	設計上完全安全
PoWトークン対応	対応していない	対応していない	対応していない	世界初（CX-MIN）
柔軟性・表現力	最高（任意ロジック）	非常に高い	高い	おおよそのユースケースに対応可
処理速度	数百〜数千TPS	数万TPS	10BPS（高速）	500〜2,000アクション/秒（未最適化）
コンセンサス方式	PoS	PoS + PoH	PoW + BlockDAG	PoW + BlockDAG
システム手数料	あり	あり	あり	ゼロ
開発者エコシステム	最大（Solidity）	大きい（Rust）	形成途上	これから
現在の実装状況	稼働中	稼働中	2026年6月予定	開発中（RIFT先行）

※ CX-VMについて：CX-Atomicには「CX-VM」という特殊VMが存在しますが、これはグローバルVMではありません。コントラクトインスタンスのState UTXO内に完全にサンドボックス化されており、グローバルコンセンサスには影響を与えません。EVMやBPFのように全コントラクトが共有するグローバルマシンとは根本的に異なります。

Section 04

CX-Atomic — 技術詳細解説

UTXOベーススマートコントラクトとして全く新しいアーキテクチャを採用しています。

🏗️ コントラクトインスタンスとUTXOモデル

CX-Atomicは「コントラクト（contract_id）」と「コントラクトインスタンス（instance_id）」を明確に分離します。同じコントラクトコードで複数のトークン・市場・DAOを独立して動かすことができます。

// 各インスタンスはちょうど1つのState UTXOを持つ
UTXO:
value = 0
script = OP_CONTRACT <contract_id> <instance_id>
payload = <state_bytes> // 最大 8 KB

// 実行のたびに厳格な置き換えチェーン
state_utxo(contract_id, instance_id, N)
→ state_utxo(contract_id, instance_id, N+1)

// コンセンサスが強制する4つの条件
1. 入力State UTXO：ちょうど1つ
2. 出力State UTXO：ちょうど1つ
3. 決定論的実行（同じ入力 → 必ず同じ結果）
4. new_state ≤ 8 KB　（違反 → トランザクション・ブロック無効）

📄

CX-Atomic: Contract State, UTXO Model, and Pruning Compatibility（公式技術文書）

全 6 ページ — サムネイルをクリックで拡大表示

1

p.2 — State Stored as a UTXO / State Transition Mechanics

2

$p.3 — Why This Works With Pruning / How a New Node Syncs / Why Old State UTXOs Are Not Needed$

3

p.4 — What Exactly Gets Pruned / Comparison With Account-Based Systems / 8KB State Limit

4

p.5 — 8KB Capacity / Why 8KB Works So Well / How the Limit Can Be Expanded

5

p.6 — Multi-Contract Designs / Summary (Technical TL;DR)

6

💾 8KB状態制限 — 見た目より遥かに大きい

「8KBは少なすぎる」と思われるかもしれません。しかしCryptixのUTXOモデルではVMオーバーヘッドなし・Merkle Patricia Trieなし・パディングなし・型メタデータなしの純粋なバイナリ格納のため、EVMより遥かに効率的です。

💰

1インスタンスあたりの収容量

300〜600のトークン残高
数百のNFT所有者
数百のレジストリエントリ
50〜200のDAO投票・提案
数十のマルチシグ提案

📐

8KBを超えた場合の拡張パス

グローバル上限の引き上げ：コンセンサスパラメータ更新のみ（16KB・32KB等）
マルチUTXOシャーディング：同一インスタンスを複数UTXOに分散
マルチコントラクト設計：複数の連携ミニコントラクト
全パスがプルーニング安全

⚙️ コントラクトテンプレートとCX-VM

🔧

ネイティブコントラクトテンプレート

全てのネイティブコントラクトはプリコンパイル済みのRust関数です。動的なバイトコードアップロードなし・外部ライブラリなし・I/Oなし・乱数なし。確定的な整数計算のみ。コントラクト監査が不要なのはこのためです。

📦

CX-VM（サンドボックス内専用VM）

より高度なプログラマビリティのためのオプション。コントラクトインスタンスのState UTXO内に完全にサンドボックス化されており、グローバルコンセンサスに影響しません。EVMのようなグローバルVMとは根本的に異なります。

CX-Atomic 技術仕様

グローバルVMなし（プリコンパイル済みRust関数）

CX-VM（オプション）インスタンス内サンドボックス・グローバルに影響しない

状態の最大サイズ8 KB / コントラクトインスタンス

ペイロード上限35 KB

決定論性完全（浮動小数点なし・乱数なし・外部入力なし）

処理速度500〜2,000コントラクトアクション/秒（未最適化）

1ブロックあたりの制限同一インスタンスにつき最大1アクション

異なるインスタンス間同一ブロック内で並列処理可能

実装言語Rust

ペイロード形式Magic Prefix「CX」+ 正規CBOR

状態再現性ジェネシスから完全再計算可能

システム手数料ゼロ（フリーテクノロジー）

Section 05

CX-Atomicのセキュリティアーキテクチャ

CX-Atomicは「設計段階でセキュリティを組み込む」という哲学のもと、さまざまな保護機能を備えています。

🛡️ 設計段階で対応している保護機能

再入攻撃への構造的対応

単一状態不変条件により、コントラクトの再帰的な呼び出しが設計上発生しない。UTXOモデルの特性として自然に実現されています。

ガス操作・無限ループへの対応

グローバルVMを持たない設計。CX-VMはサンドボックス内のみで動作し、ステップ制限・メタリングルールが厳格に適用されます。

リソース管理

8KB状態制限・35KBペイロード制限のハードキャップ。全リソースに上限が設定されており、設計上一定の範囲内に収まります。

コンカレント実行の制御

1インスタンス＝1State UTXO。同一ブロック内での同一インスタンスへの競合実行を防止。複数インスタンスは並列処理可能です。

ペイロード整合性

正規CBORのみを受け入れる厳格な構造。パース失敗で即座にブロック無効化。曖昧なエンコードを許容しない設計です。

状態の境界管理

8KB状態制限と、メモリプールの保護（ウォレットあたり最大25保留ペイロード）により状態サイズが一定範囲内に収まります。

アクセス制御

OP_CONTRACTによりState UTXOは通常の署名では操作不可。正規のコントラクト実行のみが状態を変更できます。

Reorg安全性

完全決定論的設計により、チェーン再編成（Reorg）が発生しても全ノードが同じ状態に収束することが数学的に保証されます。

📐 5つの数学的設計不変条件

単一状態不変条件 — 各(contract_id, instance_id)ペアに対して、常にちょうど1つのState UTXOのみが存在する
決定論的遷移不変条件 — 同じ入力に対して全ノードが必ず同じ結果を計算する。非決定論的な動作は設計上存在しない
リソース制限不変条件 — 状態≤8KB・ペイロード≤35KB。コンセンサスレベルで強制されるハードキャップで回避不可能
純粋性不変条件 — コントラクト実行は純粋・決定論的・副作用フリー。I/O・ネットワーク・スレッド・OS呼び出しは存在しない
リプレイ不変条件 — 全ての状態をジェネシスブロックから決定論的に再計算可能。過去の任意の時点の状態を完全に再現できる

📄

CX-Atomic: Security Architecture（公式技術文書）

全 8 ページ — サムネイルをクリックで拡大表示

1

p.2 — Section 1: Introduction / 1.1 Contract Templates / Section 2: Security Goals / Section 3: Core Security Components

2

p.3 — Section 3.1: Pre-Compiled Contract Templates / 3.1.1 CX-VM / 3.2 State UTXO Model / 3.3 Single Execution per Block

3

p.4 — Section 3.4: Secure Payload Structure / 3.5 Consensus-Driven Execution / 3.6 Payload & Mempool DoS Protection

4

p.5 — Section 3.7: Reorg & Pruning Safety / 3.8 Error Model / 3.9 Script-Level Isolation / Section 4: Threat Model

5

p.6 — Section 4: Threat Mitigations (4.3–4.11) / Section 5: Formal Security Invariants

6

p.7 — Section 6: Resistance to Historical Exploits / Section 7: Network Level Security / Section 8: Security-by-Design

7

8

Section 06

CX-MIN — 世界初のPoWマイニングトークン標準

CX-Atomicが実現する最も革新的なユースケースの一つが、CX-MINです。

⛏️ なぜこれまでのブロックチェーンで実現できなかったのか

Bitcoin — PoWはプロトコルレベルで動作するが、ユーザー定義のPoWトークンは設計上存在しない
Ethereum — VMの非決定論性・ガスモデル・乱数モデルの特性上、オンチェーンでのPoWハッシュ検証が困難
Solana — コンピュートユニットの設計上、対応していない
Kaspa SilverScript — UTXOローカル計算のアーキテクチャ上、設計の対象外
CX-MIN — 完全決定論的実行・UTXOモデル・コンセンサス検証により世界初で実現

🔬 CX-MINが同時に実現する組み合わせ

🌟 どのブロックチェーンも実現していなかった7つの要素の同時実装

ファンジブルトークンとして完全に機能（転送・バーン可能）
永続的なオンチェーン状態（外部インデクサー不要）
決定論的な難易度調整（コントラクト内で自動実行）
決定論的な時間ベース発行制限（30秒間隔制約）
整数のみのデフレーション（丸め誤差ゼロ）
コントラクト内でのPoW検証（完全オンチェーン）
コンセンサスによる強制・全ノードが検証

// SHA3バージョン（Contract ID 250）のPoWハッシュ構造
H = SHA3-256(
"CXMIN_SHA3" || // プレフィックス
contract_id_be || // コントラクトID（ビッグエンディアン）
block_height_be || // ブロック高
block_time_be || // ブロック時刻
miner_address_hash || // マイナーアドレスハッシュ
nonce_be // ノンス
)

// 有効条件
leading_zero_bits(H) ≥ difficulty_bits

// 難易度調整：60秒/報酬をターゲット（1〜250ビット）
// 制約：前回報酬から30秒以上の間隔が必要
// デフレーション：30日ごとに reward_new = reward_old × (1-deflation_ppm/1,000,000)

⛏️

CX-MIN-SHA3（Contract ID 250）

SHA3-256によるPoWマイニング
ASIC + CPU両対応
ターゲット：60秒に1報酬
難易度自動調整（1〜250ビット）
月次デフレーション設計
管理者ミントなし・プレマインなし

💎

CX-MIN-BLAKE3（Contract ID 251）

BLAKE3-256によるPoWマイニング
CPU専用（より公平な参加）
全発行がPoW作業のみで生成
完全公平ローンチ
コンセンサスレベルで全ノードが検証
完全オンチェーン・外部依存なし

📄

CX-Atomic: CX-MIN Mineable Token Standard（公式技術文書）

全 8 ページ — サムネイルをクリックで拡大表示

$p.1 — カバーページ$

1

p.2 — CX-MIN概要図 / Section 1: Introduction

2

p.3 — Section 2: Design Goals / Section 3: System Overview

3

p.4 — Section 3: Token Model & Mining Model / Section 4: Proof-of-Work Mechanism

4

p.5 — Section 4: Difficulty Check・Adjustment・Restrictions / Section 5: Tokenomics

5

p.6 — Section 5: Emission End / Section 6: Contract Architecture / Section 7: Security Features

6

p.7 — Section 8: Implementation in Cryptix / Section 9: Use Cases

7

8

🔗 RIFTとの連携 — 段階的な実装戦略

なぜRIFTが先行するのか

CX-Atomicは、RIFTというブロックチェーンがCryptixよりも先にメインネットでテスト採用予定です。RIFTは直列ブロックチェーンのため実装が相対的にシンプルで、本番環境でのテストベッドとして機能します。RIFTでの実証後、並列処理（BlockDAG）を持つCryptixへ実装が続きます。この段階的アプローチにより、実装リスクを最小化しながら確実なローンチを目指します。

Section 07

Cryptixが実装済みの主要機能

CX-Atomicはまだ開発中ですが、Cryptix NetworkはすでにメインネットでL1ネイティブの機能を複数稼働させています。

🔄

Atomic Token & Swap（L1ネイティブ）

スマートコントラクト不要でトークンを発行し、作成と同時にL1内蔵DEXで即売買できる仕組みです。流動性カーブはL1のコンセンサスルールとして直接組み込まれており、管理者も運営者も存在しません。詐欺防止のLock Gate機能も内蔵しています。

💬

Cryptix Messenger（L1ネイティブ）

ウォレットに統合されたE2E暗号化メッセンジャーです。サーバー不要・検閲不可能な設計で、PoWブロックチェーンへのL1統合は世界初。送金と同時にメッセージを送ることができます。

⚡

FastChain / HF-A

Cryptixブロックチェーン自体のスケーラビリティを向上させるアップグレードです。L1ネイティブ機能（Atomic Token・Swap・Messenger）とは別カテゴリーで、BlockDAGアーキテクチャをさらに活かし、より高いスループットと効率的なデータ伝播を実現します。

各機能の詳細解説記事

🔄

Cryptix Atomic Token & Swap 紹介記事

L1ネイティブDEX・流動性カーブ・Lock Gate・ICOスタイルローンチの詳細解説

💬

Cryptix Messenger 紹介記事

L1ネイティブE2E暗号化メッセンジャーの仕組みと機能の詳細解説

⚡

Cryptix FastChain / HF-A 紹介記事

スケーラビリティ向上アップグレードの設計と技術詳細の解説

CX-Atomic Cryptix Network の新しいスマートコントラクト

スマートコントラクトの様々なアプローチ方法

VMベース方式

スクリプト直接コンパイル方式

プリコンパイル済み方式

🔷 CX-Atomicの設計哲学

各プラットフォームのスマートコントラクト解説

✅ 特徴

📋 設計上の特性

✅ 特徴

📋 設計上の特性

✅ 特徴

📋 設計上の特性

✅ 強み

📋 設計上の特性

スマートコントラクト詳細比較表

CX-Atomic — 技術詳細解説

CX-Atomic: Contract State, UTXO Model, and Pruning Compatibility（公式技術文書）

1インスタンスあたりの収容量

8KBを超えた場合の拡張パス

ネイティブコントラクトテンプレート

CX-VM（サンドボックス内専用VM）

CX-Atomicのセキュリティアーキテクチャ

再入攻撃への構造的対応

ガス操作・無限ループへの対応

リソース管理

コンカレント実行の制御

ペイロード整合性

状態の境界管理

アクセス制御

Reorg安全性

CX-Atomic: Security Architecture（公式技術文書）

CX-MIN — 世界初のPoWマイニングトークン標準

⛏️ なぜこれまでのブロックチェーンで実現できなかったのか

🌟 どのブロックチェーンも実現していなかった7つの要素の同時実装

CX-MIN-SHA3（Contract ID 250）

CX-MIN-BLAKE3（Contract ID 251）

CX-Atomic: CX-MIN Mineable Token Standard（公式技術文書）

なぜRIFTが先行するのか

Cryptixが実装済みの主要機能

Atomic Token & Swap（L1ネイティブ）

Cryptix Messenger（L1ネイティブ）

FastChain / HF-A

Cryptix Atomic Token & Swap 紹介記事

Cryptix Messenger 紹介記事

Cryptix FastChain / HF-A 紹介記事

Cryptixに参加する・もっと知る