文書の過去の版を表示しています。

QUBIC 実行手数料 AMA (2026/01/20) 要録

原文 Jg ױ（@Jgvks666）さん / X] on Discord]（"Jg ọ" @jgvks） * https://discord.com/channels/768887649540243497/1369949639876542575/1463234008480747612 ---- スピーカー：Raika（技術エキスパート）、Fnordspace（アーキテクト）、Stephanie ===== 👥 スピーカー紹介 ===== * **Fnordspace (アーキテクト):** * システムの理論的・構造的基礎（ステート、ファンクション、バランス vs リザーブ）を構築。 * **Raika (技術エキスパート):** * 複雑な実装（ノード間通信）、直面した課題、および将来のソリューションの詳細を担当。 * **補足:** * 経済的ビジョンに関する最終決定権者として CFB（Come-from-Beyond）氏が引用されました。 ---- ===== 1. スマートコントラクトの解剖学 ===== 　課金体系を理解するために、コントラクトの3つのコンポーネントを区別する必要があります。 * **ステート (The State):** * 永続的なメモリ。これはコンセンサスによって検証される重要な要素です（676台の Computor 全てが全く同じステートを保持する必要があります）。 * **ファンクション (Functions):** * 読み取り専用（リードオンリー）のメソッド。ステートを変更せず、トランザクションを必要としないため、**無料**です。 * **プロシージャ (Procedures):** * 処理を実行し、ステートを変更する可能性のあるメソッド。トランザクションを必要とし、**実行手数料**の対象となります。 ---- ===== 2. 手数料メカニズムと「リザーブ（準備金）」 ===== 経済モデルにおける根本的な区別が強調されました。 * **コントラクト・バランス (Contract Balance):** * いわゆる「普通預金口座」であり、標準的な操作や送金に使用されます。 * **実行手数料リザーブ (Execution Fee Reserve):** * これは「ロックされた口座」です。このリザーブに送金された Qubic は、入金された瞬間に**バーン（焼却・流通から除外）されたとみなされます。** * **仕組み:** * コントラクトは実行にかかるコストをこのリザーブから引き出します。リザーブが空（またはマイナス）になると、コントラクトは実行を停止します。 * **補充方法:** * 初期状態では IPO によって補充され、その後は特定の機能を通じて自発的に Qubic をバーンすることでリロードされます。 ---- ===== 3. コスト計算：クォーラム（合意）の課題 ===== 最大の技術的課題は、「ネットワークをメッセージで飽和させることなく、いかにして676台の Computor に支払価格を合意させるか」でした。 * **素朴なアプローチ（不採用）:** * すべての Computor が毎ティック実行時間を送信すると、1ティックあたり676件のトランザクションが発生し、帯域幅が飽和してしまいます。 * **採用された解決策（蓄積ウィンドウ）:** * **フェーズ N-1 (蓄積):** 各 Computor が676ティックのウィンドウにわたって実行時間を測定します。 * **フェーズ N (通信):** 1ティックにつき1台の Computor のみが結果をネットワークに送信します。 * **フェーズ N+1 (差し引き):** ノードは受信したすべての値をソートし、中央値（451番目の値）を採用します。この合意された金額がリザーブから差し引かれます。 ---- ===== 4. 価格調整（マルチプライヤー） ===== Q&Aセッションからの重要な詳細：「ミリ秒単位の時間」を「Qubicのコスト」に変換する係数（マルチプライヤー）が存在します。この係数は固定ではありません。各 Computor は独自のマルチプライヤーを調整でき、十分な数の Computor がこの係数を変更すれば、ネットワーク全体の手数料コストが上下します。これは内部的な市場メカニズムとして機能します。 ---- ===== 5. 深刻な問題：「ダイジェスト計算（Digest Computation）」 ===== メインネットへのデプロイ中、一部のコントラクトが天文学的な手数料を支払う事態が発生しました。 * **原因:** * 安全策として、システムは「すべてのプロシージャがコントラクトのステートを変更した」と仮定していました。これにより、ネットワークは毎ティックごとにコントラクトメモリ全体の「ハッシュ（デジタル指紋）」を再計算せざるを得ず、これが非常に高コストな操作となりました。 * **一時的な修正:** * この特定の再計算に関連する手数料は現在無効化されています。 * **将来の解決策（スマート・ステート変更検知）:** * メモリが実際に変更されたかどうかをシステムが検知できるようにアップデートされます。これにより、再計算（およびその課金）は必要な場合にのみ行われるようになります。 ---- ===== 6. エポック管理（ハードリセット vs シームレス） ===== セッションの最後で提起された技術的ポイントとして、週の切り替わり（エポック移行）があります。 * **シームレス・トランジション:** * 蓄積・差し引きサイクルは通常通り継続されます。 * **ハードリセット (完全再起動):** * ノードのRAMがクリアされるため、最後の蓄積フェーズの情報が失われます。したがって、この最終フェーズの手数料は請求されません。 ---- ===== 7. Qubic と Ethereum の比較 ===== | 比較項目 | Ethereum (Gas) | Qubic (Execution Fees) | | **支払者** | ユーザー | **コントラクト（事前補充されたリザーブから）** | | **失敗時のコスト** | Gas代は失われる | (コントラクトの設計に依存) | | **コントラクト間呼び出し** | 呼び出し元ユーザーが負担 | **開始したコントラクト（A→BならA）が全額負担** | | **経済モデル** | ユーザー負担型 | **「フリーミアム」モデルが可能** | **※フリーミアム:** ユーザーは何も支払わず、コントラクト側が IPO 収益などでコストをカバーするモデル。 ---- ===== 8. 開発者への推奨事項 ===== Raika氏より、スマートコントラクト作成者向けの明確なロードマップが示されました。 * **リザーブの確認:** * コントラクトの停止を避けるため、ログやダッシュボードを活用してください。 * **呼び出し報酬 (Invocation Reward):** * 現在はコントラクト自体が「ユーザーが十分な資金を送ったか」をチェックしていますが、将来的にこのチェックは Core で行われ、リソースを節約できるようになります。 * **最適化:** * ステートサイズ（割り当てメモリ）を削減し、プロシージャを簡素化して請求額を下げてください。 * **エラー処理:** * リザーブ切れの外部コントラクトを呼び出すと、自身の実行も失敗します。このシナリオをコードに組み込んでください。 ---- **リプレイ（録音）はこちら:** [[https://x.com/_Qubic_/status/2013627630311096445?s=20|Qubic X Space - Execution Fees AMA

News, 実行手数料, AMA