テクニカル分析: イーサリアム、ビットコイン、ビットコイン キャッシュのスマート コントラクトの違いは何ですか?

編集者注: この記事は以下から引用しました第一種倉庫（ID：first_vip1）、許可を得てOdailyによって転載されました。

編集者注: この記事は以下から引用しました

第一種倉庫（ID：first_vip1）

、許可を得てOdailyによって転載されました。

この記事では、これら 3 つのプラットフォームにおけるスマート コントラクトの顕著な違いに焦点を当てます。焦点はスマート コントラクトとスクリプト機能にあるため、ここではプラットフォームやブロックチェーンの基本については説明しません。この記事では、オンチェーン スマート コントラクトと、RSK などのいくつかの第 2 層スマート コントラクト ソリューションの存在についても紹介します。これらのソリューションについては議論する価値があることは間違いありませんが、紙面の都合上、あまり詳細な検討は行いません。

副題

イーサリアム: 独自の状態を持ち、チューリング完全である

画像の説明

図：EVMの料金体系

使用されるオペコードに応じて、各トランザクションにはかなりの量の Gas がかかります。ガス料金はイーサリアムのネイティブ暗号通貨である ETH で支払われます。これらのノードがブロックごとに実行しなければならない計算量を制限するために、単一ブロックで使用できるガスの量には「ブロック ガス制限」と呼ばれる制限があります。

スマート コントラクト機能の実行中に、コントラクトは必要なデータを保存し、アクセスできます。用途に応じて、これらのデータは異なる場所、つまり異なるデータの場所に保存できます。 1 つ目は「スタック」で、計算に使用される値が含まれます。スタック内の最初の 16 項目のみに簡単にアクセスできるため、長期保管には適していません。スタックを使用した計算を以下に示します。

画像の説明

図: スタックベースのコンピューティング

第 2 に、スタックを補足するために、現在のコントラクトの実行中にデータを保存、取得、および渡すために「コントラクト メモリ」を使用できます。これらの値はメモリから取得してスタック上の計算に使用し、結果をメモリに戻すことができます。これらの値は、現在の実行中にのみ保持されます。コントラクトの実行が終了すると、コントラクトのメモリとスタックは消去されます。

最終的に、データが存在する場所は「契約ストレージ」であり、契約の実行中にデータを永続化するために使用されます。トークン残高などの永続変数はコントラクト ストレージに保存されます。データの永続性のために、コントラクト メモリが各イーサリアム ノードに保存されます。したがって、メモリは RAM に似ており、ストレージはハード ドライブまたは永続データベースに似ています。

Ethereum 仮想マシンの仕組みの詳細については、MyCrypto の記事を参照してください。

スマート コントラクトの作成 すべてのスマート コントラクトは EVM を使用しますが、ほとんどの JVM バイトコードが手書きではないのと同様、ほとんどのスマート コントラクトは EVM バイトコードを使用して手書きではありません。代わりに、イーサリアムでスマート コントラクトを作成するために使用できる高級言語がいくつかあります。最も人気のある言語は Solidity ですが、EVM 指向のプログラミング言語である Vyper も使用できます。下の画像には、非常に単純な Solidity スマート コントラクトの例が含まれています。

これらのデプロイされたコントラクトは、EVM バイトコードの「フラグメント」としてネットワーク内にのみ存在し、単独ではほとんど使用できません。これらと「インターフェイス」するには、すべてのパブリック関数とそのパラメーターのリストを含むアプリケーション バイナリ インターフェイス (ABI) を提供する必要があります。これらのコントラクトについてユーザーにさらに認識してもらうために、Etherscan などのサービスはコントラクトのソース コードの検証を支援し、ユーザーがコントラクトを使用する前にコードを検査できるようにします。

すべてのスマート コントラクトには、Ethereum ノードに接続し、その JSON-RPC インターフェイスを使用して直接アクセスできます。ただし、多くのスマート コントラクトは、ノードに接続して ABI を管理するフロントエンド アプリケーションを通じてアクセスされます。これは、内部で JSON-RPC を呼び出すことができる、さまざまな Ethereum SDK (web3.js や ethers.js など) の 1 つを使用して実行できます。これにより、最も困難な部分が視覚化されるため、契約ユーザーにとってより良いエクスペリエンスが提供されます。

スマート コントラクトは、呼び出しとトランザクションという 2 つの異なる方法で操作できます。呼び出しはコントラクト関数へのネイティブ呼び出しであり、ブロックチェーンには何もブロードキャストされません。したがって、呼び出しプロセスは「読み取り専用」であり、契約状態を変更することはできず、料金は発生しません。このトランザクションは実際の「書き込み操作」であり、実際にネットワークにブロードキャストされてブロックチェーンに組み込まれ、マイナー手数料が発生します。 ERC20 トークンを例にとると、トークン残高は呼び出しによって取得され、トークンはトランザクションの開始によって転送されます。

イーサリアムのこれらの特性 (チューリング完全 EVM と永続ストレージを備えた) により、オンチェーンで実行されるあらゆるタイプの分散アプリケーションの作成が可能になります。良い例は、Maker、Uniswap、Compound などのアプリケーションと、ERC20 および ERC721 トークン標準を含む DeFi エコシステムです。これらのアプリケーションでは、無制限の数の動的アクターによる複雑な機能が可能になります。

図: rDai における DeFi の相互運用性

最も重要なことは、スマート コントラクト自体が他のスマート コントラクトの「参加者」になることができ、これらのコントラクト間の強力な統合と構成が可能になることです。たとえば、トークン残高を保持してコンパウンドに貸したり、Uniswap と交換したり、rDai を使用して自動的に DAI に投資し、生じた利息を慈善団体に寄付したりするスマート コントラクトです。

スマート コントラクトは相互に対話できますが、オンチェーン上のすべてのトランザクションは外部アカウントから取得される必要があります。したがって、イーサリアム スマート コントラクト間の対話は、やはり最初のトランザクションを通じてユーザーによってトリガーされる必要があります。この最初のトリガーの後、コントラクト間の対話は直接アクセスと同様になります。

言い換えれば、スマート コントラクトは、他のスマート コントラクトの「読み取り専用関数」を呼び出したり、「書き込み操作」(トランザクション) をトリガーしたりできます。外部アカウントのみがトランザクションをトリガーできるため、スマート コントラクト間のトランザクションは、ユーザーが開始したトランザクションと区別するために内部トランザクションまたはメッセージ コールと呼ばれます。

副題

ビットコイン: ステートレスでシンプル

すべてのビットコイントランザクション（通常の送金を含む）は、「ビットコインスクリプト」（スクリプト）と呼ばれるスタックベースのプログラミング言語によってサポートされています。前述したように、イーサリアムの EVM はチューリング完全かつ相互運用可能なスマート コントラクト向けに設計されていますが、ビットコイン スクリプトは意図的にさまざまな制限を追加し、根本的に異なる方法で動作します。ビットコイン スクリプトの解釈は EVM と似ており、ビットコイン スクリプトはスタック (Stack) を使用して値 (Value) を保持し、これらの値に対して計算を実行します。ただし、EVM とは異なり、スタックはビットコイン スクリプトで利用できる唯一のデータの場所です。これは、後で契約を実行する際に使用するために複数の値を保存することが困難であることを意味します。さらに重要なのは、これは、コントラクトの実行中に保持される値を保存または変更することは不可能であることを意味します (ただし、EVM は可能です)。

これがイーサリアムのスマートコントラクトとビットコインの最大の違いです。イーサリアムのモデルはステートフルですが、ビットコインはステートレスです。一般的な理解では、イーサリアムは一般的な命令型可変データ プログラミング パラダイムに似ているのに対し、ビットコインは関数不変データ パラダイムに似ていると考えられます。

ビットコインのモデルでは、トランザクションを独立してより効率的に検証できるため、トランザクションの並列化やシャーディングが容易になります。ただし、変更可能なデータ ストレージがなければ、ビットコイン上のイーサリアムのような複雑なスマート コントラクトを作成することはより困難になります。たとえば、ERC20 コントラクトはトークンの残高を追跡し、変更を加える必要があります。

これらの状態の違いに加えて、ビットコイン スマート コントラクトの複雑さを制限する要因が他にもあります。特に、ビットコイン スクリプトでは、特定の算術関数や、あらゆる形式のループや再帰がサポートされていません。また、そのコントラクトには 520 バイトの有効サイズ制限があり、最大 201 個のオペコードしか含めることができません。

ビットコインのほとんどのスマート コントラクトは、単純なコントラクトのいくつかのカテゴリに分類されます。たとえば、複数の参加者が使用できるマルチシグネチャ コントラクトや、ハッシュされたタイムロック コントラクト (HTLC) などです。

そして、ビットコインのこれらのコントラクトは非常にシンプルであるため、価値のほとんどは、さまざまなコントラクトと他のオフチェーン アプリケーション ロジックを組み合わせることによって取得されます。このようにして、単純な契約を組み合わせて、ライトニング ネットワークやクロスチェーン オークションなどの複雑なソリューションを作成できます。

ビットコインのトランザクションの説明 ビットコインのすべてのトランザクションは、いわゆる「トランザクション出力」を通じて実現されます。これらのトランザクション出力がアカウントで利用可能な場合、それらは未使用トランザクション出力 (UTXO) と呼ばれます。これらの UTXO は、ロック スクリプト (または scriptPubKey) と指定された使用条件によってロックされます。 UTXO を使用しようとすると、ロック解除スクリプト (または ScriptSig) が提供され、これらのスクリプトが一緒に計算を実行します。トランザクションは、スクリプトがエラーなしで実行され、結果の値が TRUE である場合にのみ有効になります。

EVM と同様に、すべてのビットコイン ノードはこれらのスクリプトを実行してトランザクションを検証しますが、ビットコイン ブロックチェーンにはガスコストの概念がないため、マイナーはトランザクション データのバイトごとに支払いを受けます。ノードが実行しなければならない作業量を制限するために、より負荷の高いスクリプト操作の一部にも制限が設けられています。

スマート コントラクトとの対話 ビットコインのスマート コントラクトは、P2SH モデル (ファーストクラス ウェアハウスの注: 「スクリプト ハッシュへの支払い」と訳されています) を使用して作成されます。 P2SH モードのロック スクリプトにはスクリプト ハッシュが含まれており、完全なスクリプト (引き換えスクリプトと呼ばれる) のロック解除スクリプトと、その引き換えスクリプトのロック解除スクリプトを提供する必要があります。以下の図はこのパターンを示しています。

画像の説明

図: P2SH モード

一流のウェアハウスの知識: P2SH モードは、複雑なスクリプトの使用を簡素化するために導入されました (従来のメカニズムは P2PKH)。複雑なロック スクリプトは、ビットコイン アドレスが A 20 であるのと同じように、20 バイトのハッシュを持つ単純なスクリプトにコンパイルされます。 -Base58 エンコーディングに基づくバイト公開キー。 P2SHと従来のP2PKH方式の最大の違いは、転送条件の設定者が送信者から受信者に変わることです。償還スクリプトにさまざまな送金条件を追加することで、マルチシグネチャトランザクションなどのさまざまな形式のトランザクションを実現できます。

ビットコイン ノードは、これらのスマート コントラクト トランザクションを 2 段階で検証します。まず、引き換えスクリプトがハッシュ化され、ロック スクリプトのハッシュと照合されます。それらが一致する場合、「引き換えスクリプト」が元のロック スクリプトであるかのように、「ロック スクリプト」を使用して「引き換えスクリプト」のロックが解除されます。

これらの展開の違いにより、両方のタイプのスマート コントラクトを組み合わせて使用​​することが奨励されます。良い例は、イーサリアムとビットコインの非保管ローカル トランザクションをサポートする LocalCryptos です。イーサリアムの場合、1 つの大きなスマート コントラクトを使用してすべてのトランザクションを追跡しますが、ビットコインの場合、トランザクションごとに個別のコントラクトを作成します。

スマート コントラクトの作成 イーサリアムには EVM バイトコードにコンパイルする高級言語が複数ありますが、ビットコインはこれにあまり注意を払ってきませんでした。 Bitcoin Script を使用して構築できるシステムは複雑ですが、契約自体は多くの場合単純です。したがって、基礎となるシステムを抽象化する必要はほとんどありません。また、ビットコイン コントラクトにはサイズ制限があり、追加バイトごとにコストがかかるため、コントラクトを「可能な限り小さく」保つことが重要です。

これらの高級言語はビットコインではそれほど重要ではありませんが、存在します。 Ivy は、2017 年に Dan Robinson によって作成された、ビットコインで「最も洗練された」高水準言語です。以下の図は、Ivy で書かれたスマート コントラクトの例を示しています。この契約は、受取人が期限内に使い切らなかった場合に送金者が回収できる送金に使用できます。

最近、Blockstream の数人の研究者が、基盤となるシステムを抽象化するのではなく、スマート コントラクトの分析と構成可能性に焦点を当てた言語である Miniscript をリリースしました。ビットコイン契約には抽象的な複雑さが欠けていることが多いことを考えると、これは取るべき正しい道のように思えます。

副題

上記は、一方では、完全にイーサリアムチェーン上に存在する多くの強力で便利なスマートコントラクトを作成できるイーサリアムですが、同時にそのステートフルな性質（ステートフル）により、スケーラビリティの問題も引き起こします。一方、ビットコインのスマート コントラクト ステートレス (ステートレス) モデルでは、スマート コントラクト トランザクションの独立した簡単な検証が可能ですが、そのスクリプト システムによりコントラクトの実用性が制限されます。

フォーク以前は、ビットコイン キャッシュとビットコインは同じ歴史を共有していたので、それらの基礎となるスクリプト システムは機能的に同一であり、ビットコイン キャッシュはこれらの同じ側面から恩恵を受けています。それ以来、ビットコイン キャッシュ コミュニティの大部分が「より便利なスマート コントラクト」の必要性を認識するようになりました。 Bitcoin Cash は、ビットコインのステートレス検証を可能にする基本的な特性を維持しながら、スマート コントラクトをより便利にする新機能を有効にします。

BCH の機能アップグレード Bitcoin Cash スマート コントラクトの可能性を理解するには、半年ごとに行われるネットワーク アップグレードに注目する必要があります。これらのネットワーク アップグレードは、2017 年の最初のハード フォーク以来、毎年 5 月と 11 月に実行されています。 Schnorr 署名など、その他のいくつかの改良が加えられていますが、特にビットコイン スクリプト エンジンへの変更について説明します。

ビットコインの初期の頃、安全でない使用のため、一部のオペコードが無効になりました。 Bitcoin Cash のフォーク後 1 年以内に、Bitcoin-ABC ノードの開発者はこれらの問題に対処し、次の図に示すように、機能をわずかに変更してオペコードを再導入しました。最も重要なのは、このアップグレードにより、ビットコイン スクリプトで構造化データをエンコードおよびデコードできるようになりました。

画像の説明

図: BCH は 2018 年 5 月に新しいオペコードを有効にしました

半年後、2018 年 11 月の Bitcoin Cash ネットワークのアップグレードで別の新しいオペコードがリリースされました。その中には、ユーザーがビットコイン スクリプトでメッセージの署名を検証できるようにするアップデート OP_CHECKDATASIG があります。 2018 年に導入されたスクリプト更新を組み合わせると、これらの更新を使用して、新しくて便利なスマート コントラクト機能を Bitcoin Cash に導入できます。

スマート コントラクトの作成 Bitcoin Cash の新機能により、元の Bitcoin Script に比べてスマート コントラクトがさらに複雑になります。このため、高レベル言語、SDK、ツールを通じて高レベルの抽象化レイヤーを提供するエコシステムを持つことがさらに重要になります。

現在この問題に取り組んでいる 2 つの大きなプロジェクトは、Spedn (仮名 Tendo Pein によって作成) と CashScript (この記事の著者 Rosco Kalis によってイーサリアムの Solidity 言語に触発されて作成) です。これらのツールはまだ活発に開発中ですが、これらのツールを使用すると、Bitcoin Cash でのスマート コントラクトの操作が容易になります。機能の一部を、CashScript コード スニペットを使用して以下に示します。

この例は、以下の HODLVault 契約例で見ることができます。この契約は、特定の BCH/USD 価格に達するまで HODL を強制します。必要な BCH/USD 価格フィードはオラクルプロバイダーによって公開され、ユーザーによってコントラクトに渡されます。分散化を強化するために、単一の集中サービスを信頼するのではなく、複数のデータ ソースを使用するようにスマート コントラクトを設定できます。

コベナント 2 番目の大きな使用例は、コベナントと呼ばれるテクニックです。その名前は、オブジェクトの使用を制限するために財産法で使用される用語に由来しています。ビットコイン キャッシュの場合、スマート コントラクトでの通貨の使用が制限されます。したがって、ビットコインのスマート コントラクトは一般に金銭的支出のみを承認できますが、ビットコイン キャッシュ コントラクトは支出できる金額や受取人の身元に制限を課すことができます。

ビットコインを転送する場合、送信者はトランザクションを承認するための署名を提供する必要があります。この署名を生成するために、送信者はトランザクションのハッシュ表現に署名します。このハッシュは Sighash と呼ばれ、実際のトランザクション データは Sighash プリイメージに含まれています。

同じ署名を持つ _OP_CHECKSIG_ と _OP_CHECKDATASIG_ を使用することで、Sighash データにアクセスできます。データ形式は仕様で確認でき、以下の画像に含まれています。重要なフィールドは scriptCode で、これにはスマート コントラクト自体のバイトコードが含まれます。もう 1 つは、ユーザーがトランザクション出力を強制できるようにする hashOutputs です。

画像の説明

図: Bitcoin Cash Sighash データ形式

保証契約が技術レベルでどのように機能するかを知るのは素晴らしいことですが、CashScript は契約に関連する複雑さのほとんどをすでに抽象化しています。 CashScript を使用してスマート コントラクトを作成する場合、これらのフィールドは、Sighash のオリジナルを検証してデコードするという手動の手順を行わなくても、すぐに使用できます。

保証付き契約テクノロジーを使用した最初のスマート コントラクトは、ユーザーが亡くなった人の財産を自分のものに移転できるスマート コントラクトである Licho's Last Will です。この契約では 3 つの異なる機能が定義されています。 1 つ目は、後継者が 180 日後に資金を請求できるようにするものです。 2 つ目では、所有者のコールド キー (ColdKey) を任意の方法で使用できるようにします。 3 番目の方法では、所有者のホット キーを使用して、契約残高全体を強制的に契約に送り返すことで 180 日の期間を更新できます。

Last Will の CashScript バージョンは以下に含まれていますが、オリジナルのバージョンは Spedn によって書かれており、ここで参照できます。

これは便利な保証契約の単純な例の 1 つですが、保証契約ではさらに複雑な機能が可能になります。 Last Will契約が署名された後、その作成者であるKarol Trzeszczkowski氏は、Patreonなどに定期的な支払いを強制する会社であるMecenasの設立を続けた。

保証型契約はもともと「ビットコイン規約」というタイトルの論文で提案され、新しいオペコード _OP_CHECKOUTPUTVERIFY_ が必要でした。 _OP_CHECKTEMPLATEVERIFY_ や _OP_CHECKSIGFROMSTACK_ など、他の提案も続きました。後者は、ビットコイン キャッシュのコベナントの実装に非常に似ています。保証契約の詳細については、Tendo Pein の記事をご覧ください。

シミュレートされた状態では「遺言」契約が検討されており、契約が締結されているときに相続人を変更することが有益である可能性があります。現在のコントラクトのバイトコードを調べることで現在のコントラクトへの送信を強制できるため、このバイトコードをわずかに変更することでわずかに異なるコントラクトへの送信を強制できます。コントラクトの残高全体を、バイトコードは同じだが継承者が異なるコントラクトに送信する関数を作成できます。

この手法を使用すると、契約の同じルールを維持しながら、契約内の特定の変数を変更することができます。イーサリアムのようなステートフル システムのスケーラビリティの問題なしにコントラクト状態の利点の一部を提供するため、これを「シミュレートされた状態」と呼びます。このアプローチには、どこかでトレードオフを行う必要があるため、他の欠点もあります。

結論は

バイトコード内でこれらの変数を置き換えるのは、特にバイトコードのさらに奥深くにある変数を置き換えようとする場合、面倒に感じることがあります。この機能は、新しいパラメータを指定することによって新しいバイトコードが自動的に生成されるように、高級言語で抽象化する必要があります。この抽象化は次のようになります。

未来を見据えて

多くの抽象化には大規模な契約が必要となり、その結果、料金が高くなります。しかし、ビットコイン キャッシュの取引手数料は一般に低いため、両方の長所を生かしています。ただし、ビットコイン キャッシュにはビットコインと同じサイズ制限があるため、これらの抽象化により制限内に収まることが難しくなります。その結果、多くの開発者はコンパイルされたバイトコードを手動で最適化する必要がありました。

結論は

すべての暗号通貨は、スマート コントラクト システムで重視されます。イーサリアムは、最も幅広い機能を備えた最も一般的に使用されているスマート コントラクト プラットフォームです。ビットコインは、ステートレス スクリプト システムを通じてスマート コントラクトのより基本的なバージョンを提供します。これは検証がより効率的ですが、機能が低下します。 Bitcoin Cash は Bitcoin と同じ基盤を持っていますが、効率的な検証と有用なスマート コントラクトの間で妥協を試みる新機能が追加されています。最終的には、全員が同じような目標に向かって進みます。