Qubic のスマートコントラクトに変更がありました。

　2025年1月14日より、コントラクトは実際に消費した計算リソースに対して支払いを行うようになります。

　このアップデートは、まずライブテストネット環境で検証された後、メインネットに展開されました。これにより、コントラクトが実行する「仕事」に直接比例した、有機的な バーンが導入されます。

　Qubic 上のすべてのスマートコントラクトは、「実行手数料リザーブ（残高）」を維持します。これは基本的に、計算コストをカバーするためのプリペイド残高です。

　そのリザーブが枯渇しても、コントラクトが消滅することはありませんが、「休止状態（dormant）」になります。資金を受け取ったり、基本的なシステムイベントに応答したりすることは可能ですが、リザーブが補充されるまで、そのコア機能（プロシージャ）を再び呼び出すことはできません。

　以前は、コントラクトがアクティブであり続けるためには、プラスの残高があることだけが必要でした。システムはリザーブが存在することを確認していましたが、実際の計算に基づいた実行コストの差し引きは行われていませんでした。それが今回変更されました。

　コントラクトは、そのプロシージャの実行にかかる時間に比例して課金されるようになり、手数料が実際の計算作業と直接結びつくようになります。

　手数料メカニズムは、それぞれ 676 ティック（Tick）続く「フェーズ」単位で動作します。プロセスは以下の通りです：

• 実行と測定:
  • Computor があなたのコントラクトのプロシージャを実行する際、各実行にかかる時間を測定します。

• 蓄積:
  • これらの測定値は、676 ティックの完全なフェーズにわたって蓄積されます。

• コンセンサス:
  • Computor は、特別なトランザクションを通じて測定値を共有します。
  • ネットワークはこれらの報告を集計し、「3分の2パーセンタイル（two-thirds percentile）」を使用して、公正で合意された実行手数料を決定します。

• 差し引き:
  • 合意された手数料は、次のフェーズでコントラクトのリザーブから差し引かれます。
  • このフェーズベースのアプローチにより、ネットワーク全体の正確性を確保しつつ、コンセンサスの効率を維持します。

　このシステムは、「アクションを開始した者が支払う」というシンプルな原則に従っています。

　ユーザーがコントラクトのプロシージャを呼び出すと、そのコントラクトのリザーブがコストをカバーします。コントラクト[A] がコントラクト[B]を呼び出す場合、実行が進む前にコントラクト[B]のリザーブがチェックされます。

　いくつかの操作は、実行手数料のチェックが無料のまま維持されます：

　データを読み取るだけのファンクションは、決してコストがかかりません。これらは、コントラクトの状態を変更することなくアクセスを提供するため、リザーブの状態に関係なく実行されます。プロシージャとファンクションの違いについての詳細は、QPI ドキュメントを参照してください。

　Qubic 上でスマートコントラクトを維持している場合は、以下の手順を検討してください：

• リザーブ状態の確認:
  • `contracts.qubic.tools` をチェックして、実行パターンに基づく現在のコントラクトの手数料消費を確認してください。
  • また、Qubic Explorer を通じてコントラクトのアクティビティを監視することもできます。

• プロシージャの精査:
  • 早期に終了（return）するコードは、使用するリソースが少なくなります。過度にループしたり、冗長な操作を繰り返したりするプロシージャは、コストが高くなります。

• 持続可能性の計画:
  • コントラクトは、`qpi.burn()` 関数または QUtil の `BurnQubicForContract` プロシージャを通じてリザーブを補充できます。
  • これらの操作は、Qubic CLI を使用して実行できます。
  • コントラクトのライフサイクル全体を通じて適切なリザーブを維持するための信頼できるメカニズムを、コントラクトに含めることが推奨されます。

• エラー処理の強化:
  • 他のコントラクトを呼び出す際は、それらの呼び出しが成功したかどうかを確認してください。
  • ターゲットとなるコントラクトの手数料が不足している場合、呼び出しは失敗しエラーコードを返します。
  • 必要に応じてフォールバックロジックを構築してください。

　Qubic での構築が初めての開発者にとって、スマートコントラクト開発ガイドは確実なスタート地点となります。

　Computor には、新しい設定オプション「実行手数料倍率（execution fee multiplier）」が追加されました。この設定は、生の実行時間を手数料の額に変換します。ネットワークは、全 Computor が提出した値の 3分の2パーセンタイルを使用してコンセンサスに達し、単一のオペレーターがコストを劇的に変化させることを防ぎます。

　Computor の運用に関する詳細情報は、コンピューター・ドキュメントを参照してください。

　コントラクトの実行手数料リザーブを追加するには、3つの方法があります：

• 内部的なバーン（Internal burning）:
  • コントラクトは `qpi.burn(amount)` を呼び出して、収集した手数料をリザーブ残高に変換できます。
  • また、`qpi.burn(amount, targetContractIndex)` を使用して他のコントラクトに資金を供給することも可能です。

• 外部からの拠出（External contributions）:
  • 誰でも QUtil コントラクトの `BurnQubicForContract` プロシージャに資金を送信し、どのコントラクトがリザーブのブーストを受けるべきかを指定できます。

• レガシーな手法:
  • QUtil の `BurnQubic` プロシージャは、特に QUtil 自身の予備に追加されます。

　これらのメカニズムは、Qubic のトークノミクスに直接結びついています。ここでは、従来の取引手数料ではなく、バーンが中心的なデフレメカニズムとして機能します。

　システムにはセーフガードが組み込まれています。

　リザーブが枯渇したコントラクトにトランザクションを送信した場合、添付された資金は自動的に返却されます。コントラクトが残高を維持できなかったからといって、ユーザーが資金を失うことはありません。

　休止状態のコントラクトであっても、読み取り専用のクエリは引き続き利用可能です。その状態はいつでも確認できますが、リザーブが補充されるまで、状態を変更するプロシージャは実行されません。

　このアップデートは、Qubic がスマートコントラクトの経済性をどのように扱うかにおける、有意義な転換点となります。

　より多くの仕事をするコントラクトが、より多く支払う。効率的なコードが真に価値を持つようになります。そしてネットワークは、恣意的な固定額ではなく、実際の有用性に結びついたトークンの持続的な バーン メカニズムを獲得しました。

　Qubic で構築を行っており、まだこの新しいモデルの下でコントラクトを確認していない場合は、今がその時です。

　技術的な詳細については、GitHub の完全なリファレンスドキュメントを参照してください。

　Qubic の Discord や Telegram コミュニティに参加して、他のビルダーと質問をしたり、アイデアを共有したり、実装戦略について話し合ってください。