スピーカー：Raika（技術エキスパート）、Fnordspace（アーキテクト）、Stephanie

• Fnordspace (アーキテクト):
  • システムの理論的・構造的基礎（ステート、ファンクション、バランス vs リザーブ）を構築。

• Raika (技術エキスパート):
  • 複雑な実装（ノード間通信）、直面した課題、および将来のソリューションの詳細を担当。

• 補足:
  • 経済的ビジョンに関する最終決定権者として CFB（Come-from-Beyond）氏が引用されました。

　課金体系を理解するために、コントラクトの3つのコンポーネントを区別する必要があります。

• ステート (The State):
  • 永続的なメモリ。これはコンセンサスによって検証される重要な要素です（676台の Computor 全てが全く同じステートを保持する必要があります）。

• ファンクション (Functions):
  • 読み取り専用（リードオンリー）のメソッド。ステートを変更せず、トランザクションを必要としないため、無料です。

• プロシージャ (Procedures):
  • 処理を実行し、ステートを変更する可能性のあるメソッド。トランザクションを必要とし、実行手数料の対象となります。

経済モデルにおける根本的な区別が強調されました。

• コントラクト・バランス (Contract Balance): いわゆる「普通預金口座」であり、標準的な操作や送金に使用されます。
• 実行手数料リザーブ (Execution Fee Reserve): これは「ロックされた口座」です。このリザーブに送金された Qubic は、入金された瞬間にバーン（焼却・流通から除外）されたとみなされます。
• 仕組み: コントラクトは実行にかかるコストをこのリザーブから引き出します。リザーブが空（またはマイナス）になると、コントラクトは実行を停止します。
• 補充方法: 初期状態では IPO によって補充され、その後は特定の機能を通じて自発的に Qubic をバーンすることでリロードされます。

最大の技術的課題は、「ネットワークをメッセージで飽和させることなく、いかにして676台の Computor に支払価格を合意させるか」でした。

• 素朴なアプローチ（不採用）: すべての Computor が毎ティック実行時間を送信すると、1ティックあたり676件のトランザクションが発生し、帯域幅が飽和してしまいます。
• 採用された解決策（蓄積ウィンドウ）: * フェーズ N-1 (蓄積): 各 Computor が676ティックのウィンドウにわたって実行時間を測定します。
  • フェーズ N (通信): 1ティックにつき1台の Computor のみが結果をネットワークに送信します。
  • フェーズ N+1 (差し引き): ノードは受信したすべての値をソートし、中央値（451番目の値）を採用します。この合意された金額がリザーブから差し引かれます。

Q&Aセッションからの重要な詳細： 「ミリ秒単位の時間」を「Qubicのコスト」に変換する係数（マルチプライヤー）が存在します。この係数は固定ではありません。各 Computor は独自のマルチプライヤーを調整でき、十分な数の Computor がこの係数を変更すれば、ネットワーク全体の手数料コストが上下します。これは内部的な市場メカニズムとして機能します。

メインネットへのデプロイ中、一部のコントラクトが天文学的な手数料を支払う事態が発生しました。

• 原因: 安全策として、システムは「すべてのプロシージャがコントラクトのステートを変更した」と仮定していました。これにより、ネットワークは毎ティックごとにコントラクトメモリ全体の「ハッシュ（デジタル指紋）」を再計算せざるを得ず、これが非常に高コストな操作となりました。
• 一時的な修正: この特定の再計算に関連する手数料は現在無効化されています。
• 将来の解決策（スマート・ステート変更検知）: メモリが実際に変更されたかどうかをシステムが検知できるようにアップデートされます。これにより、再計算（およびその課金）は必要な場合にのみ行われるようになります。

セッションの最後で提起された技術的ポイントとして、週の切り替わり（エポック移行）があります。

• シームレス・トランジション: 蓄積・差し引きサイクルは通常通り継続されます。
• ハードリセット (完全再起動): ノードのRAMがクリアされるため、最後の蓄積フェーズの情報が失われます。したがって、この最終フェーズの手数料は請求されません。

※フリーミアム: ユーザーは何も支払わず、コントラクト側が IPO 収益などでコストをカバーするモデル。

Raika氏より、スマートコントラクト作成者向けの明確なロードマップが示されました。

1. **リザーブの確認:** コントラクトの停止を避けるため、ログやダッシュボードを活用してください。
2. **呼び出し報酬 (Invocation Reward):** 現在はコントラクト自体が「ユーザーが十分な資金を送ったか」をチェックしていますが、将来的にこのチェックは Core で行われ、リソースを節約できるようになります。
3. **最適化:** ステートサイズ（割り当てメモリ）を削減し、プロシージャを簡素化して請求額を下げてください。
4. **エラー処理:** リザーブ切れの外部コントラクトを呼び出すと、自身の実行も失敗します。このシナリオをコードに組み込んでください。

リプレイ（録音）はこちら: Qubic X Space - Execution Fees AMA