01 背景
Qtumはブロックチェーンの基盤となるインフラストラクチャの研究に焦点を当てており、ビットコインとEVMに基づいて継続的に繰り返します。Qtumメインネットは2年近く安定して動作しており、システムのいくつかの欠陥とコンセンサスルールもその過程で明らかにされています。これらの欠点により、ブロックチェーン技術の開発と適用がある程度妨げられてきました。
ブロックチェーン技術の絶え間なく変化するアプリケーションシナリオに適応するために、Qtumは基礎となるプロトコルを徐々にアップグレードし、Qtum 2.0を起動します。この記事で説明するハードフォークは、Qtum 2.0に関連する最初のアップグレードになります。
QIP（Qtum Improvement Proposal）について
Qtum Improvement Proposals（QIP）は、Qtum開発者とコミュニティによって提案されたQtumの基盤となるテクノロジーのアップグレードに関する一連の具体的な提案です。すべての提案はgithubで公開されており、誰でも提案を公開で議論できます。広く認識されている提案は、Qtum開発チームによって実装されます。
Qtum QIP： https : //github.com/qtumproject/qips/issues
02 目的と動機
このハードフォークは、Qtumのメインネットの立ち上げ以来最大のバージョンの反復であり、将来のブロックチェーンアプリケーションインフラストラクチャとしてのQtumの技術的基盤であり、4つのコンセンサス関連のQIPアップグレードが含まれています。彼らです：
-
QIP-5：契約トランザクションの出力スクリプトに署名検証を追加します
https://github.com/qtumproject/qips/issues/6
-
QIP-6： btc_ecrecoverプリコンパイルされたコントラクトをQtumのEVM仮想マシンに追加する
https://github.com/qtumproject/qips/issues/7
-
QIP-7： Qtum EVM仮想マシンを最新のEthereum Constantinople（Constantinople）バージョンにアップグレードする
https://github.com/qtumproject/qips/issues/8
-
QIP-9：難易度調整アルゴリズムを変更して、ブロック時間をより安定させます
https://github.com/qtumproject/qips/issues/9
その中でも、QIP-5とQIP-7は、Qtumにいくつかの新機能を追加して、より複雑なスマートコントラクトアプリケーションシナリオに実際に適応し、その後のアップグレード（プライバシー資産など）の技術的基盤にもなります。QIP-6はスマートコントラクト開発を改善します利便性、使用コストの削減、QIP-9はQtumネットワークの安定性をさらに向上させます。
「ハードフォーク」アップグレードが必要なのはなぜですか？
Qtumは完全に分散化されたネットワークです。各ノードは独立したノード/ウォレットプログラムを実行します。各ノードが実行するプログラムのバージョンを制御することはできませんが、すべてのノードはQtumネットワーク上のすべてのトランザクションに対して統一された合意ルールを使用できます。同意します。一部のノードが他のノードとは異なるコンセンサスルールを採用している場合、それらは2つのチェーンに「分岐」します。
通常のアップグレードではコンセンサスルールは変更されず、一部のノードがアップグレードを完了していなくても、ネットワークは分岐しません。ただし、このアップグレードに関連するすべての変更はコンセンサスルールに関連しています。つまり、アップグレードされたノードとアップグレードされていないノードは異なるコンセンサスルールを採用し、ハードフォークが発生します。新しいバージョンに切り替えないことによる不要な損失を避けるために、すべてのユーザーができるだけ早くアップグレードを完了することを強くお勧めします。
03 ハードフォーク関連のQIPの概要
QIP-5
解説
署名トランザクションを契約トランザクションの出力スクリプトに追加して、所有権を証明し、QTUMを所有するアドレスなしで契約を呼び出すことができるようにします。
動機
Qtumでスマートコントラクトを呼び出すには、対応するガス料金の支払いが必要です。契約が呼び出されるたびに、呼び出し契約の住所に残高が必要です（残高が非常に少ない場合でも）。たとえば、QRC20トークンの転送は、最も一般的な契約呼び出しの1つです。アドレスAに1000 QC（Qtumで公開されているQRC20安定したコイン）があるとすると、この1000 QCを送信するには、アドレスAに一定の金額が必要です。 QTUMは、アドレスを所有していることを契約に証明します。アドレスAに残高がない場合、契約を呼び出すことはできません。つまり、1000 QCは使用できません。現在、唯一の解決策は、一部のQTUMをアドレスAに転送してから、契約を呼び出してトークンを送信することです。ただし、これはチェーン上のUTXOデータセットの貴重なリソースを浪費するだけでなく、ユーザーエクスペリエンスにも大きな影響を与えます。同時に、より複雑なスマートコントラクトアプリケーションシナリオ（予測市場アプリケーション、分散型取引所など）では、この制限により、ユーザーがブロックチェーンアプリケーションを使用するためのしきい値が大幅に増加しています。
恩恵
OP_SENDERオペコードを追加することにより、QIP-5は、契約呼び出し元アドレスの所有権を証明するメカニズムを提供し、アドレスのQTUMなしで証明を提供して、スマート契約を呼び出すことができます。元のシステムはそれほど変わっていませんが、既存のスマートコントラクトエコシステムに大きな変更が加えられています。
-
アドレスは、QTUMトークンを所有せずにスマートコントラクト（QRC20トークンの送受信など）を呼び出して、通常のユーザーのトークンの送受信エクスペリエンスを向上させることができます。注：契約を呼び出すことは無料ではありませんが、他の住所で支払うことができます
-
より多様なサービスが生成され、サービスプロバイダーはサービス料金を支払い、ユーザーはサービスを使用するだけで済みます。これは実際のアプリケーションシナリオにより近いものです
-
複数のアドレスが1つのトランザクションで複数の契約を呼び出すことができるため、契約呼び出しの柔軟性が向上します。
-
チェーン上のUTXOデータセットのスペースを節約する
考えられるリスク
QIP-5は追加のコンセンサスルールを追加しますが、それでも元のルールと互換性があるため、理論的にはセキュリティリスクをもたらすことはありません。ただし、既存のインフラストラクチャにある程度の影響があります。
-
この機能を正しく使用するには、追加のRPCコマンドを開発する必要があります。サービスプロバイダーはインフラストラクチャを同期してアップグレードする必要があります
-
追加のスクリプトの追加により、サービスプロバイダーはスクリプトに対して追加の検証を実行する必要があります。そうしないと、そのようなトランザクションは認識されません。
QIP-6
解説
通常の契約による直接呼び出しのために、btc_ecrecoverプリコンパイルされた契約をQtumのEVM仮想マシンに追加します。
動機
Solidiyでは、ecrecover関数は楕円曲線の署名を対応する公開鍵アドレスに復元できます。Qtumのスマートコントラクトのmsg.senderは、ビットコインと同様のP2PKHアドレスを使用し、ecrecover関数によって返されるアドレス形式はEthereumと同じであり、2つを直接比較することはできません。開発者にとって、これは契約でいくつかの論理的な判断を煩雑にするでしょう。この問題を解決するための現在の一般的な方法は、追加のライブラリコントラクトを呼び出すことですが、より多くのガスを消費し、スマートコントラクトを使用するコストが増加します。
恩恵
QIP-6は、プリコンパイルされたコントラクトを通じてbtc_ecrecoverという名前の関数を実装します。新しい関数は元の関数のすべてのインターフェースと互換性がありますが、次の利点があります。
-
btc_ecrecoverによって返されるアドレスタイプは、直接比較できるmsg.senderアドレス形式と完全に一致しており、契約開発プロセスにおける論理的判断を簡素化します
-
事前にコンパイルされた契約はガス消費を大幅に節約し、スマート契約を使用するコストを削減できます
考えられるリスク
QIP-6は元のシステムに変更を加えず、新しい機能は元の機能インターフェイスと完全に互換性があるため、理論的にはリスクはありません。
QIP-7
解説
Qtum EVM仮想マシンを最新のEthereum Constantinople（Constantinople）バージョンにアップグレードします。
動機
現在、Qtumは以前のバージョンのEVM仮想マシンを使用しています。Qtumメインネットがリリースされた後、EVMはビザンチンとコンスタンチノープルにアップグレードされました。新しいバージョンの仮想マシンには、可変長データの返却や静的なコントラクト呼び出しなど、多くの新しい開発者向けの機能が追加されています。ますます多くの開発者が、契約およびアプリケーション開発のためにこれらの新機能に依存する必要があります。
恩恵
QIP-7には、EVMビザンチンバージョンとコンスタンチノープルバージョンのすべての新機能が含まれており、より複雑なスマートコントラクトとアプリケーションを実現できます。たとえば、QtumがQIP-19でサポートする予定のプライバシー資産の場合、関連するスマートコントラクトは、EVMの新しいバージョンで提供される新機能に依存する必要があります。さらに、アップグレードが完了した後、理論的には、Ethereum上のすべてのスマートコントラクトとアプリケーションをQtumに移植でき、同時に、基になるUTXOモデルの独自のセキュリティと安定性を取得できます。
考えられるリスク
EVMビザンチンとコンスタンチノープルの両方のバージョンがイーサリアムメインネットでアクティブ化され、それらの安定性が検証されており、低リスクで完全な前方互換性があります。ただし、Qtumの最下層はUTXOモデルを使用しており、これはEVMアカウントモデルと整合性がないため、既存の契約を移行する場合、開発者はQtumバージョンのEVMの特性に注意する必要があります。
QIP-9
解説
QIP-9には、実際には2つのアップグレードが含まれています。
1. Qtumメインネットのマイニング（ステーキング）難易度調整アルゴリズムを変更して、ブロック生成時間をより安定させ、予想時間に近づけます（コンセンサス関連）。
2.ネットワーク全体の重み推定アルゴリズムを変更して、真の値に近づけます。（コンセンサスとは関係ありません）
動機
Qtumによって設計されたブロック間隔は128秒です。理論的には、ブロック間隔が変動すると、コンセンサスメカニズムによって難易度の値が調整されてブロック間隔が延長または短縮され、平均ブロック生成時間が128秒のままになります。ただし、現在Qtumで使用されている難易度調整アルゴリズムは大きく変動するため、メインネットワークの平均ブロック生成時間は約144秒で、TPSが約12％削減される可能性があります。
一方、Qtumネットワークの重量（ステーキングされているコインの合計として理解できます）は、ネットワーク全体のセキュリティを反映し、ステーキング（マイニング）の予想される利益も決定します。Qtumは完全に分散化されたネットワークであるため、ネットワーク全体の重みは、マイニングの難しさによってのみ推定できます。ただし、既存の重み推定アルゴリズムは大きく変動し、シミュレーション結果によると、実際の重みとの分散が大きいため、現在のネットワーク状態を正確に反映できません。
恩恵
-
QIP-9は改善された難易度調整アルゴリズムを提供し、ブロック間隔の指数移動平均に従って難易度を調整します。これにより、平均ブロック生成時間を128秒に近づけることができます。トランザクションの平均確認時間もそれに応じて短縮されます
-
QIP-9は、ネットワークの重みの推定アルゴリズムを改善し、移動平均を使用して推定します。元のアルゴリズムと比較して、新しいアルゴリズムと実際の重みの間の分散は小さく、変動は小さいため、現在のネットワークのステーキングステータスをより正確に反映できます。
考えられるリスク
-
QIP-9に含まれる難易度調整アルゴリズムには、セキュリティ上のリスクはありません。
-
ネットワークの重み推定アルゴリズムは、推定値を平滑化しますが、実際の重みが急激に変動する場合のネットワーク状態の変化を反映することはできないため、今後改善の余地があります。ただし、このアップグレードにはコンセンサスメカニズムが含まれていないため、その後の定期的なアップグレードで再度変更できます
04 ハードフォークリリース計画
このハードフォークに関連するすべてのコードは、ほぼ半年間開発およびテストされています。ハードフォークアップグレードは、最初にテストネットワークでアクティブ化され、テストネットワークが安定して実行された後、Qtumメインネットワークでアクティブ化されます。
高さのアップグレードはプリセットブロックで自動的にアクティブ化され、テストネットワークフォークの高さは 446,320（2019年9月20日と推定 ）、Qtum メインネットワークフォークの高さは 466,600（2019年10月の推定時間 16） 10月17日）。アップグレードが自動的に完了するように、ユーザーは常に公式にリリースされた最新バージョンであるウォレットを実行し続けることをお勧めします。
考えられる影響
-
アップグレードをアクティブ化しても、まだアップグレードを完了していないノードが多数ある場合、ほとんどのノードがアップグレードされるまで、アップグレードがアクティブ化されると、短時間で2つのチェーンに分割される可能性があります。アップグレードが完了していない場合、ネットワーク全体の重みが不安定になり、ブロック生成時間が大きく変動したり、すべてのトランザクションの確認時間が長くなる場合があります（為替の預金や引き出しなど）。
-
アップグレードがアクティブ化された後、コンセンサス関連の主要な脆弱性が見つかった場合、開発チームはそれをすばやく修正してユーザーにアップグレードを促す必要がある場合があります。そうでない場合、フォークが再度発生する可能性があります
対策
ノードが完全にアップグレードされていない問題の場合、Qtumはすべての取引所、サービスプロバイダー（ウォレット、ブラウザー）、Staker（マイナー）、および一般ユーザーに事前にアップグレードを完了してメインネットがアクティブ化される前にほとんどのノードがアップグレードされ、アップグレードが保証されることを通知しますスムーズに行く
アップグレード自体の脆弱性に関して、Qtum開発チームはリリース前の半年間内部テストを実施しており、すべてのテストに合格しています。同時に、このアップグレードは3か月前にテストネットワークでアクティブ化され、メインネットワークがアクティブ化およびアップグレードされる前にすべての脆弱性が検出および修正されることを確認します。
すべてのユーザーがノードを最新バージョンに更新し、ハードフォークのアクティブ化期間中にすべてのトランザクションを複数回確認するか、ネットワークが安定してから転送してください。
将来的にハードフォークはありますか？
コンセンサス関連のアップグレードにハードフォークが必要な場合は、今回と同様のプロセスを採用して、ユーザーにアップグレードを通知します。その後のQtumは、x86仮想マシン、プライベートアセット、スマートコントラクトマイニング機能をリリースする予定で、ハードフォークが必要になる場合があります。Qtum開発チームは、フォークを必要とするアップグレードをマージして、ハードフォークアップグレードの数を最小限に抑えます。
ユーザーは何をする必要がありますか？
セキュリティの観点から、Qtumノード/ウォレットを実行しているすべてのユーザーは、メインネットがアクティブ化される前にウォレットの最新バージョンにアップグレードする必要があります。
ウォレットの最新バージョンのリリース情報に注意してください：
-
https://github.com/qtumproject/qtum/releases/
-
https://qtumeco.io/wallet
そして、新しいバージョンがリリースされたらすぐに更新します。
ネットワークのさまざまな参加者に対して、アップグレードの完全な準備をすることをお勧めします。
交換、財布
-
ハードフォークがアクティブ化される前後に、QTUMおよびQRC20トークンの預金と引き出しの記録に注意を払い、トランザクションがメインチェーンによって十分に確認された後で、預金と引き出しを確認する必要があります。
-
QRC20トークンの引き出しには、サポート手順（QIP-5関連）を事前にアップグレードできるため、新機能を使用してガス料金をできるだけ早く支払うことができます。
サービスプロバイダー（例：ブラウザー）
-
アップグレードがアクティブ化されたときにOP_SENDERでトランザクション出力を認識できないことを回避するために、事前にQIP-5関連のサポートプログラムを開発することをお勧めします。
鉱山労働者（鉱業用プール、個人用ステーカー）
-
アップグレードがアクティブ化される前後に、常にネットワークの重みに注意を払い、予想される収入に応じてユーザーの収入と手数料を調整する必要があります。
開発者
-
最初にテストネットワークを使用して、メインネットワークがアクティブ化されたときに展開できる新機能のコントラクトとアプリケーションを開発できます。（QIP-7）
-
QIP-5と組み合わせて、より多くのアプリケーションシナリオを検討してください。
一般ユーザー
-
常に財布をバックアップしてください。
05参考 リンク
-
QIP-5の具体的な実装については、以下を参照してください。
https://github.com/qtumproject/qips/issues/6
-
QIP-6の具体的な実装については、以下を参照してください。
https://github.com/qtumproject/qips/issues/7
-
QIP-7の具体的な実装については、以下を参照してください。
https://github.com/qtumproject/qips/issues/8
-
QIP-9の具体的な実装については、以下を参照してください。
https://github.com/qtumproject/qips/issues/9
-
ビザンチン：https：//blog.ethereum.org/2017/10/12/byzantium-hf-announcement/
-
コンスタンチノープル：https：//blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/
-
QIP-19：https：//github.com/qtumproject/qips/issues/19