スマートコントラクトの概要

この記事では、スマート コントラクトとは何か、その概要を説明し、さまざまなスマート コントラクト プラットフォームとその機能について説明し、それらがどのように機能し、どのような利点がもたらされるかについても説明します。 この資料は、スマート コントラクトのトピックに詳しくないが、さらに理解したいと考えている読者にとって非常に役立ちます。

通常契約との比較スマートコントラクト

詳細を掘り下げる前に、紙で指定される通常の契約とデジタルで表現されるスマート コントラクトの違いの例を見てみましょう。

スマートコントラクトが登場する前は、これはどのように機能していたのでしょうか? 価値の分配のための特定のルールと条件、および与えられたルールと条件に従ってこの分配の実装を保証する特定のメカニズムを確立したいと考えている人々のグループを想像してください。 それから彼らは集まり、身分証明書の詳細、条件、関係する価値観を書き留めた紙を作成し、日付を記入し、署名します。 この契約は、公証人などの信頼できる当事者によって認証されたものでもあります。 さらに、これらの人々は、そのような契約書の紙のコピーを持って別の方向に進み、契約自体に対応しない可能性のあるいくつかの行動を実行し始めました。つまり、彼らはあることをしましたが、紙の上では何かを行うべきであることが証明されていました。全然違う。 そして、この状況からどうやって抜け出すのでしょうか？ 実際、グループのメンバーの XNUMX 人がこの書類を受け取り、いくつかの証拠を取り、法廷に持ち込んで、契約と実際の行為との遵守を達成する必要があります。 多くの場合、この契約を公正に履行することは困難であり、それが不快な結果をもたらします。

スマートコントラクトについて何が言えるでしょうか? これらは、契約条件を記述する可能性と、契約を厳密に実行するためのメカニズムの両方を組み合わせています。 条件が設定され、対応するトランザクションまたはリクエストが署名されている場合、そのリクエストまたはトランザクションが受け入れられると、条件を変更したり、その実装に影響を与えたりすることはできなくなります。

XNUMX つのバリデーターまたはネットワーク全体と、実行のために送信されたすべてのスマート コントラクトを厳密な時系列順に保存するデータベースがあります。 このデータベースには、スマート コントラクトを実行するためのすべてのトリガー条件が含まれている必要があることも重要です。 さらに、契約に記載されている配分額そのものを考慮する必要があります。 これが何らかのデジタル通貨に当てはまる場合、このデータベースはそれを考慮する必要があります。

言い換えれば、スマート コントラクトのバリデーターは、スマート コントラクトが操作するすべてのデータにアクセスできる必要があります。 たとえば、単一のデータベースを使用して、デジタル通貨、ユーザー残高、ユーザー トランザクション、タイムスタンプを同時に管理する必要があります。 そして、スマート コントラクトでは、条件は、特定の通貨でのユーザーの残高、特定の時間の到来、または特定の取引が実行されたという事実だけで、それ以上ではありません。

スマートコントラクトの定義

一般に、この用語自体は研究者の Nick Szabo によって造られ、1994 年に初めて使用され、1997 年にスマート コントラクトの概念そのものを説明する記事で文書化されました。

スマート コントラクトは、事前に定義された条件にのみ依存する価値分配の自動化が実行されることを意味します。 最も単純な形式では、厳密に定義された条件があり、特定の当事者によって署名された契約のように見えます。

スマート コントラクトは、サードパーティへの信頼を最小限に抑えるように設計されています。 場合によっては、すべてが依存する意思決定の中心が完全に排除されることがあります。 さらに、そのような契約は監査が容易です。 これは、そのようなシステムのいくつかの設計機能の結果ですが、ほとんどの場合、スマートコントラクトによって、分散環境と、誰でもデータベースを分析して契約の実行の完全な監査を実行できる機能の存在が理解されます。 これにより、契約自体の履行の変更を伴う遡及的なデータ変更に対する保護が保証されます。 スマート コントラクトを作成して開始する際のほとんどのプロセスをデジタル化すると、実装のテクノロジーとコストが簡素化されることがよくあります。

簡単な例 - エスクロー サービス

非常に簡単な例を見てみましょう。 これは、スマート コントラクトの機能の理解に近づくだけでなく、どのような場合にスマート コントラクトを使用する必要があるかをよりよく理解するのに役立ちます。

ビットコインを使用して実装することもできますが、現時点ではビットコインはまだ本格的なスマートコントラクトのプラットフォームとは言えません。 それで、バイヤーがいて、オンラインストアを持っています。 顧客はこのストアからモニターを購入したいと考えています。 最も単純なケースでは、購入者が支払いを完了して送信し、オンライン ストアがそれを受け入れて確認し、商品を発送します。 ただし、この状況では大きな信頼が必要です。購入者はモニターの費用全体についてオンライン ストアを信頼する必要があります。 オンライン ストアは購入者の目には評判が低い可能性があるため、支払いを受け入れた後、何らかの理由でストアがサービスを拒否し、購入者に商品を発送しないリスクがあります。 したがって、購入者は、そのようなリスクを最小限に抑え、そのような取引をより信頼できるものにするために、この場合に何が適用できるかを質問します（したがって、オンラインストアもこの質問をします）。

ビットコインの場合、買い手と売り手が独立して仲介者を選択できるようにすることが可能です。 物議を醸している問題の解決に携わっている人はたくさんいます。 また、参加者は一般的な仲介者のリストから信頼できる仲介者を選択できます。 これらは一緒に 2 of 3 マルチシグネチャ アドレスを作成します。このアドレスには XNUMX つのキーがあり、そのアドレスからコインを使用するには任意の XNUMX つのキーによる XNUMX つの署名が必要です。 XNUMX つのキーは購入者に属し、XNUMX つ目はオンライン ストアに、XNUMX つ目は仲介者に属します。 そして、そのようなマルチシグネチャアドレスに、購入者はモニターの支払いに必要な金額を送金します。 これで、売り手は、自分に依存するマルチ署名アドレスでしばらくの間資金がブロックされていることを確認した場合、安全にモニターに郵便で送ることができます。

次に、買い手は小包を受け取り、商品を検査し、最終的な購入を決定します。 彼は提供されるサービスに完全に同意し、自分のキーでトランザクションに署名し、マルチ署名アドレスから売り手にコインを転送する場合もあれば、何か不満がある場合もあります。 XNUMX 番目のケースでは、彼は仲介者に連絡して、コインを別の方法で配布する代替取引をまとめます。

届いたモニターに少し傷があり、オンライン ストアの Web サイトにはケーブルがキットに含まれている必要があると記載されていたにもかかわらず、キットにはコンピューターに接続するためのケーブルが含まれていなかったとします。 次に、買い手は、この状況で騙されたことを仲介者に証明するために必要な証拠を収集します。サイトのスクリーンショットを撮り、郵便受領書の写真を撮り、モニターの傷の写真を撮り、シールが貼られていたことを示します。壊れてケーブルが抜けてしまった。 次に、オンライン ストアは証拠を収集し、仲介者に転送します。

仲介者は、購入者の憤りとオンラインストアの利益の両方を同時に満たすことに関心があります（理由は後で明らかになります）。 これは、マルチシグネチャアドレスからのコインが購入者、オンラインストア、仲介者の間で一定の割合で使用される取引を構成します。仲介者は自分の仕事の報酬として一部を受け取るためです。 総額の 90% が売主に、5% が仲介者に、5% が買主に報酬として支払われるとします。 調停者は自分のキーを使用してこのトランザクションに署名しますが、まだ適用できません。XNUMX つの署名が必要ですが、価値があるのは XNUMX つだけであるためです。 このようなトランザクションは買い手と売り手の両方に送信されます。 少なくとも XNUMX 人がコインを再配布するためのこのオプションに満足した場合、トランザクションは事前署名されてネットワークに配布されます。 それを検証するには、取引当事者の XNUMX 人が仲介者のオプションに同意するだけで十分です。

最初に、双方の参加者が信頼できる調停者を選ぶことが重要です。 この場合、彼はどちらかの利益とは独立して行動し、状況を客観的に評価します。 仲介者が少なくとも XNUMX 人の参加者を満足させるコイン配布のオプションを提供しない場合、購入者とオンライン ストアの両方が合意した上で、XNUMX つの署名を入れることで新しいマルチ署名アドレスにコインを送信できます。 新しいマルチ署名アドレスは、この問題に関してより有能で、より良い選択肢を提供する可能性のある別の調停者によって編集されます。

ドミトリーと冷蔵庫の例

スマート コントラクトの機能をより明示的に表示する、より複雑な例を見てみましょう。

最近、寮の同じ部屋に引っ越してきた XNUMX 人の男性がいるとします。 XNUMX人は自分の部屋に一緒に使える冷蔵庫を購入することに興味を持っています。 そのうちのXNUMX人は、冷蔵庫を購入するために必要な金額を集めて売り手と交渉することを志願しました。 しかし、彼らは知り合ったばかりで、信頼関係はまだ十分ではありません。 明らかに、そのうちの XNUMX 人は XNUMX 人目にお金を与えることでリスクを負っています。 さらに、売主を選択する際にも合意に達する必要があります。

彼らはエスクローサービスを利用することができます。つまり、取引の実行を監視し、物議を醸す問題が発生した場合に解決する仲介者を選択することができます。 次に、同意した後、スマートコントラクトを作成し、その中で特定の条件を規定します。

最初の条件は、特定の時間前 (たとえば XNUMX 週間以内) に、対応するスマート コントラクト アカウントが特定のアドレスから特定の金額の支払いを XNUMX 回受け取る必要があるということです。 これが起こらない場合、スマート コントラクトは実行を停止し、コインをすべての参加者に返します。 条件が満たされる場合、販売者と仲介者の識別子の値が設定され、すべての参加者が販売者と仲介者の選択に同意するという条件がチェックされます。 すべての条件が満たされると、資金は指定されたアドレスに送金されます。 このアプローチにより、あらゆる側からの詐欺から参加者を保護することができ、通常は信頼する必要がなくなります。

この例では、各条件を満たすためのパラメーターを段階的に設定できるこの機能により、任意の複雑さとネストされたレベルの深さのシステムを作成できるというまさに原理がわかります。 さらに、最初にスマート コントラクトの最初の条件を定義し、その条件が満たされた後にのみ、次の条件のパラメーターを設定できます。 言い換えれば、条件は正式に記述されており、その条件のパラメータはその動作中にすでに設定できます。

スマートコントラクトの分類

分類のために、さまざまな基準グループを設定できます。 ただし、技術開発の時点では、そのうちの XNUMX つが関連しています。

スマート コントラクトは、集中型または分散型の実行環境によって区別できます。 分散化の場合、スマートコントラクトを実行する際の独立性とフォールトトレランスが大幅に向上します。

また、条件を設定して満たすプロセスによって区別することもできます。条件は、自由にプログラム可能、制限付きまたは事前定義済み、つまり厳密に型指定できます。 スマート コントラクト プラットフォーム上に特定のスマート コントラクトが 4 つだけある場合、それらのパラメーターは任意の方法で設定できます。 したがって、それらの設定ははるかに簡単です。リストからコントラクトを選択し、パラメーターを渡します。

開始方法によれば、自動化されたスマートコントラクト、つまり特定の条件が発生したときに自動実行されるコントラクトと、条件が指定されているがプラットフォームがその履行を自動的にチェックしないコントラクトがあります。別途開始する必要があります。

さらに、スマート コントラクトのプライバシー レベルは異なります。 完全にオープンにすることも、部分的または完全に機密にすることもできます。 後者は、サードパーティのオブザーバーがスマートコントラクトの条件を確認しないことを意味します。 ただし、プライバシーのトピックは非常に幅広いため、現在の記事とは分けて検討することをお勧めします。

以下では、現在のトピックをより明確に理解するために、最初の XNUMX つの基準を詳しく見ていきます。

ランタイムごとのスマートコントラクト

実行環境に基づいて、集中型スマート コントラクト プラットフォームと分散型スマート コントラクト プラットフォームが区別されます。 集中型デジタル契約の場合、単一のサービスが使用されます。バリデータは XNUMX つだけあり、バックアップおよび回復サービスもあり、これも集中管理されます。 スマート コントラクトの条件を設定し、まさにこのサービス データベースで考慮される値を配布するために必要なすべての情報を保存するデータベースが XNUMX つあります。 このような集中型サービスでは、クライアントが特定のリクエストに条件を設定し、そのような契約を使用します。 プラットフォームの集中型の性質により、認証メカニズムは暗号通貨よりも安全性が低い可能性があります。

例として、移動通信プロバイダー (さまざまな携帯電話会社) を取り上げます。 ある通信事業者が、さまざまな形式 (音声通話、SMS 送信、モバイル インターネット トラフィックなど) で送信されるトラフィックの集中記録をサーバー上に保管し、さまざまな標準に従って記録を保持しているとします。ユーザー残高上の資金の。 したがって、移動通信プロバイダーは、提供されるサービスの会計処理とその支払いをさまざまな条件で行うための契約を作成できます。 この場合、「○○の番号に○○のコードを記載したSMSを送信すると、○○の条件でトラフィックを分散します」といった条件を設定するのが簡単です。

もう XNUMX つの例として、インターネット バンキングの拡張機能と、定期支払い、入金の自動換算、指定口座への利息の自動引き落としなどの非常にシンプルな契約を備えた従来の銀行を挙げることができます。

分散型実行環境を備えたスマート コントラクトについて話している場合、バリデーターのグループが存在します。 理想的には、誰でもバリデーターになれるのです。 データベース同期プロトコルと合意に達したことにより、形式が頻繁に変更され、オープンな仕様がない一部の条件付きクエリではなく、厳密に記述されたコントラクトを持つすべてのトランザクションを保存する共通データベースができました。 ここで、トランザクションには、厳密な仕様に従って契約を実行するための指示が含まれます。 この仕様はオープンであるため、プラットフォーム ユーザー自身がスマート コントラクトを監査および検証できます。 ここで、分散型プラットフォームは独立性と耐障害性の点で集中型プラットフォームより優れていることがわかりますが、その設計とメンテナンスははるかに複雑です。

条件の設定と履行方法によるスマートコントラクト

ここで、スマート コントラクトが条件を設定および満たす方法においてどのように異なるかを詳しく見てみましょう。 ここで、ランダムにプログラム可能でチューリング完全なスマート コントラクトに注目します。 チューリング完全スマート コントラクトでは、書き込みサイクル、確率を計算するための関数など、独自の電子署名アルゴリズムに至るまで、ほとんどすべてのアルゴリズムをコントラクト実行の条件として設定できます。 この場合、本当に恣意的なロジックの記述を意味します。

任意のスマート コントラクトもありますが、チューリング完全なものはありません。 これには、独自のスクリプトを備えたビットコインとライトコインが含まれます。 これは、特定の操作のみを任意の順序で使用できることを意味しますが、ループや独自のアルゴリズムを作成することはできなくなります。

さらに、事前定義されたスマート コントラクトを実装するスマート コントラクト プラットフォームもあります。 これらには、Bitshares や Steemit が含まれます。 Bitshares には、取引、アカウント管理、プラットフォーム自体とそのパラメーターの管理のためのさまざまなスマート コントラクトがあります。 Steemit も同様のプラットフォームですが、Bitshares のようなトークンの発行や取引ではなく、ブログに焦点を当てています。つまり、コンテンツを分散型で保存および処理します。

任意のチューリング完全コントラクトには、イーサリアム プラットフォームとまだ開発中の RootStock が含まれます。 したがって、以下ではイーサリアム スマート コントラクト プラットフォームについてもう少し詳しく説明します。

開始方法別のスマートコントラクト

開始方法に基づいて、スマート コントラクトは、自動化と手動 (自動化されていない) の少なくとも XNUMX つのグループに分けることもできます。 自動化されたものは、既知のパラメーターと条件がすべて与えられた場合、スマート コントラクトが完全に自動的に実行されるという事実によって特徴付けられます。つまり、追加のトランザクションを送信したり、後続の実行ごとに追加の手数料を費やす必要がありません。 プラットフォーム自体には、スマート コントラクトがどのように完了するかを計算するためのすべてのデータが含まれています。 そこでのロジックは恣意的なものではなく、あらかじめ決められており、これらはすべて予測可能です。 つまり、スマートコントラクトの実行の複雑さを事前に推定し、それに一定の手数料を使用することができ、その実装のためのすべてのプロセスがより効率的になります。

自由にプログラムされたスマート コントラクトの場合、実行は自動化されません。 このようなスマート コントラクトを開始するには、事実上すべてのステップで、次の実行ステージまたは次のスマート コントラクト メソッドを呼び出す新しいトランザクションを作成し、適切な手数料を支払い、トランザクションが確認されるのを待つ必要があります。 スマート コントラクト コードは任意であり、永遠ループ、一部のパラメーターと引数の欠如、ハンドルされない例外など、いくつかの予測不可能な瞬間が発生する可能性があるため、実行は正常に完了するかどうかが決まります。

イーサリアムアカウント

イーサリアムアカウントの種類

イーサリアムプラットフォームにはどのような種類のアカウントがあるかを見てみましょう。 ここにはアカウントの種類が XNUMX つだけあり、他のオプションはありません。 XNUMX つ目のタイプはユーザー アカウントと呼ばれ、XNUMX つ目は契約アカウントと呼ばれます。 それらがどのように異なるのか見てみましょう。

ユーザーアカウントは電子署名の個人キーによってのみ管理されます。 アカウント所有者は、ECDSA (楕円曲線デジタル署名アルゴリズム) アルゴリズムを使用して、電子署名用の独自のキー ペアを生成します。 このキーで署名されたトランザクションのみが、このアカウントの状態を変更できます。

スマート コントラクト アカウントには別のロジックが提供されます。 これは、スマート コントラクトの動作を完全に決定する事前定義されたソフトウェア コードによってのみ制御できます。つまり、特定の状況下でコインをどのように管理するか、どのユーザーの主導で、どのような追加条件の下でこれらのコインが配布されるかなどです。 開発者がプロ​​グラムコード内でいくつかの点を規定していない場合、問題が発生する可能性があります。 たとえば、スマート コントラクトは、どのユーザーからもさらなる実行の開始を受け付けない特定の状態を受け取る場合があります。 この場合、スマート コントラクトにはこの状態を終了するための規定がないため、コインは実際には凍結されます。

イーサリアムでのアカウントの作成方法

ユーザー アカウントの場合、所有者は ECDSA を使用して独自にキー ペアを生成します。 イーサリアムは電子署名にビットコインとまったく同じアルゴリズムとまったく同じ楕円曲線を使用しますが、アドレスの計算方法が若干異なることに注意することが重要です。 ここでは、ビットコインのように二重ハッシュの結果は使用されなくなりましたが、256 ビットの長さの Keccak 関数を使用して単一ハッシュが提供されます。 最下位ビットは結果の値から切り取られます。つまり、出力ハッシュ値の最下位 160 ビットです。 その結果、イーサリアムのアドレスを取得します。 実際には 20 バイト必要です。

イーサリアムのアカウント識別子は、アドレスがチェックサムを追加して 58 進数でエンコードされるビットコインや他の多くのシステムとは異なり、チェックサムを適用せずに XNUMX 進数でエンコードされることに注意してください。 これは、イーサリアムでアカウント識別子を扱うときは注意する必要があることを意味します。識別子に XNUMX つでも間違いがあると、コインの損失につながることが保証されます。

重要な特徴があり、それは、最初の入金を受け取った時点で、一般データベース レベルのユーザー アカウントが作成されることです。

スマート コントラクト アカウントの作成には、まったく異なるアプローチが必要です。 最初に、ユーザーの XNUMX 人がスマート コントラクトのソース コードを作成し、その後コードがイーサリアム プラットフォーム用に特別なコンパイラーに渡されて、独自のイーサリアム仮想マシンのバイトコードが取得されます。 結果のバイトコードは、トランザクションの特別なフィールドに配置されます。 開始者のアカウントに代わって認証されます。 次に、このトランザクションはネットワーク全体に伝播され、スマート コントラクト コードが配置されます。 取引に対する手数料、およびそれに応じて契約の実行に対する手数料は、開始者のアカウントの残高から引き落とされます。

各スマート コントラクトには、必ず (このコントラクトの) 独自のコンストラクターが含まれます。 空の場合もあれば、コンテンツが含まれている場合もあります。 コンストラクターが実行されると、スマート コントラクト アカウント識別子が作成され、これを使用してコインを送信したり、特定のスマート コントラクト メソッドを呼び出したりすることができます。

イーサリアムのトランザクション構造

より明確にするために、イーサリアム トランザクションの構造とスマート コントラクト コードの例を見ていきます。

Ethereum トランザクションは複数のフィールドで構成されます。 これらの最初の nonce は、トランザクションを配布し、その作成者であるアカウント自体に関連する、トランザクションの特定のシリアル番号です。 これは二重取引を区別する、つまり同じ取引が二度受け付けられた場合を排除するために必要である。 識別子を使用することにより、各トランザクションは一意のハッシュ値を持ちます。

次に次のようなフィールドが来ます ガス代。 これは、イーサリアム基本通貨がガスに変換される価格を示し、スマートコントラクトの実行と仮想マシンリソースの割り当ての支払いに使用されます。 それはどういう意味ですか？

ビットコインでは、手数料は基本通貨、つまりビットコイン自体によって直接支払われます。 これは、単純な計算メカニズムのおかげで可能になります。つまり、トランザクションに含まれるデータの量に対して厳密に料金を支払います。 イーサリアムでは、トランザクション データの量に依存することが非常に難しいため、状況はさらに複雑です。 ここで、トランザクションには仮想マシン上で実行されるプログラム コードも含まれる場合があり、仮想マシンの各操作の複雑さは異なる場合があります。 変数にメモリを割り当てる操作もあります。 これらには独自の複雑さがあり、各操作の支払いはそれに依存します。

ガス換算での各操作のコストは一定です。 これは、特に各操作の一定コストを決定するために導入されています。 ネットワークの負荷に応じて、ガス価格、つまり手数料を支払うために基本通貨がこの補助単位に変換される係数が変化します。

イーサリアムのトランザクションにはもう XNUMX つの特徴があります。仮想マシンで実行するために含まれるバイトコードは、何らかの結果 (成功または失敗) で完了するまで、または手数料を支払うために割り当てられた一定量のコインがなくなるまで実行されます。 。 何らかのエラーが発生した場合に、送信者のアカウントのコインがすべてコミッションに費やされてしまう状況 (たとえば、仮想マシンで開始されたある種の永遠のサイクル) を避けるために、次のフィールドが存在します。 ガスを始動する (ガス制限とも呼ばれます) - 送信者が特定のトランザクションを完了するために使用できるコインの最大量を決定します。

次のフィールドは 宛先アドレス。 これには、コインの受信者のアドレス、またはそのメソッドが呼び出される特定のスマート コントラクトのアドレスが含まれます。 後は畑です 値、宛先アドレスに送信されるコインの量が入力されます。

次は、と呼ばれる興味深いフィールドです。 データ、構造全体が収まる場所。 これは個別のフィールドではなく、仮想マシンのコードが定義される構造全体です。 ここに任意のデータを配置できます。これには別のルールがあります。

そして最後のフィールドは 署名。 これには、このトランザクションの作成者の電子署名と、この署名の検証に使用される公開キーの両方が同時に含まれています。 公開キーから、このトランザクションの送信者のアカウント識別子を取得できます。つまり、システム自体で送信者のアカウントを一意に識別できます。 トランザクションの構造に関する重要なことがわかりました。

Solidity のスマート コントラクト コードの例

次に、例を使用して最も単純なスマート コントラクトを詳しく見てみましょう。

contract Bank {
    address owner;
    mapping(address => uint) balances;
    
    function Bank() {
        owner = msg.sender;
    }

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint amount) public {
        if (balances[msg.sender] >= amount) {
            balances[msg.sender] -= amount;
            msg.sender.transfer(amount);
        }
    }

    function getMyBalance() public view returns(uint) {
        return balances[msg.sender];
    }

    function kill() public {
        if (msg.sender == owner)
            selfdestruct(owner);
    }
}

上記は、ユーザーのコインを保持し、オンデマンドで返すことができる簡略化されたソース コードです。

したがって、次の機能を実行する銀行スマート コントラクトがあります。残高にコインを蓄積します。つまり、トランザクションが確認され、そのようなスマート コントラクトが発行されると、残高にコインを含めることができる新しいアカウントが作成されます。 ユーザーとユーザー間のコインの分配を記憶します。 残高管理にはいくつかの方法があり、ユーザーの残高を補充、引き出し、確認することができます。

ソースコードの各行を見てみましょう。 このコントラクトには定数フィールドがあります。 そのうちの XNUMX つは、アドレス型で、所有者と呼ばれます。 ここで、コントラクトは、このスマート コントラクトを作成したユーザーのアドレスを記憶します。 さらに、ユーザーのアドレスと残高の間の対応を維持する動的な構造があります。

これに Bank メソッドが続きます。これは契約と同じ名前です。 したがって、これはそのコンストラクターです。 ここで、owner 変数には、このスマート コントラクトをネットワーク上に配置した人のアドレスが割り当てられます。 これがこのコンストラクターで発生する唯一のことです。 つまり、この場合の msg は、このコントラクトのコード全体を含むトランザクションとともに仮想マシンに転送されたデータそのものです。 したがって、msg.sender は、このコードをホストするこのトランザクションの作成者です。 彼はスマートコントラクトの所有者になります。

入金方法では、取引ごとに一定数のコインを契約アカウントに送金できます。 この場合、これらのコインを受け取ったスマート コントラクトは、それらを貸借対照表に残しますが、これらのコインが誰に属しているかを知るために、これらのコインの送信者が誰であるかを正確に残高構造に記録します。

次のメソッドはwithdrawと呼ばれ、パラメータをXNUMXつ取ります。これは、誰かがこの銀行から引き出したいコインの量です。 これにより、このメソッドを呼び出して送信するユーザーの残高に十分なコインがあるかどうかがチェックされます。 十分な数のコインがある場合、スマート コントラクト自体がその数のコインを呼び出し元に返します。

次に、ユーザーの現在の残高を確認する方法です。 このメソッドを呼び出した人は、スマート コントラクト内のこの残高を取得するために使用されます。 このメソッドの修飾子が view であることに注意してください。 これは、メソッド自体はクラスの変数を一切変更せず、実際には読み取りメソッドであることを意味します。 このメソッドを呼び出すために別のトランザクションが作成されることはなく、手数料も支払われず、すべての計算がローカルで実行され、その後ユーザーは結果を受け取ります。

kill メソッドは、スマート コントラクトの状態を破棄するために必要です。 ここでは、このメソッドの呼び出し元がこのコントラクトの所有者であるかどうかを追加チェックします。 そうであれば、コントラクトは自己破棄され、破棄関数は XNUMX つのパラメーター、つまりコントラクトが残高に残っているすべてのコインを送信する先のアカウント ID を受け取ります。 この場合、残りのコインは自動的に契約所有者のアドレスに送られます。

イーサリアムネットワーク上のフルノードはどのように機能しますか?

このようなスマート コントラクトがイーサリアム プラットフォーム上でどのように実行され、完全なネットワーク ノードがどのように機能するかを概略的に見てみましょう。

Ethereum ネットワーク上のフル ノードには少なくとも XNUMX つのモジュールが必要です。
2 つ目は、他の分散プロトコルと同様に、PXNUMXP ネットワーキング モジュールです。これは、ネットワーク接続および他のノードとの連携のためのモジュールであり、ブロック、トランザクション、および他のノードに関する情報が交換されます。 これは、すべての分散型暗号通貨の伝統的なコンポーネントです。

次に、ブロックチェーン データの保存、処理、優先ブランチの選択、ブロックの追加、ブロックのリンク解除、これらのブロックの検証などを行うモジュールがあります。

XNUMX 番目のモジュールは EVM (イーサリアム仮想マシン) と呼ばれます。これは、イーサリアム トランザクションからバイトコードを受け取る仮想マシンです。 このモジュールは、特定のアカウントの現在の状態を取得し、受信したバイトコードに基づいてその状態を変更します。 各ネットワーク ノード上の仮想マシンのバージョンは同じである必要があります。 各イーサリアム ノードで行われる計算はまったく同じですが、非同期で行われます。誰かがこのトランザクションを先にチェックして受け入れ、つまりトランザクションに含まれるすべてのコードを実行し、その後誰かがこのトランザクションを確認して受け入れます。 したがって、トランザクションが生成されるとネットワークに配信され、ノードがそれを受け付け、検証時にはビットコインでビットコインスクリプトが実行されるのと同じように、ここでも仮想マシンのバイトコードが実行されます。

トランザクションに含まれるすべてのコードが実行され、特定のアカウントの新しい状態が生成され、このトランザクションが適用されたかどうかが明確になるまで保存された場合、トランザクションは検証されたとみなされます。 トランザクションが適用されると、この状態は完了しただけでなく、現在の状態ともみなされます。 各ネットワーク ノードの各アカウントの状態を保存するデータベースがあります。 すべての計算が同じ方法で行われ、ブロックチェーンの状態が同じであるため、すべてのアカウントの状態を含むデータベースも各ノードで同じになります。

スマートコントラクトの誤解と限界

イーサリアムと同様のスマートコントラクトプラットフォームに存在する制限としては、以下のものが挙げられます。

• コードの実行。
• メモリを割り当てる。
• ブロックチェーンデータ。
• 支払いを送る。
• 新しい契約を作成します。
• 他の契約を呼び出します。

仮想マシンに課せられる制限を見て、それに応じてスマート コントラクトに関するいくつかの誤解を払拭してみましょう。 仮想マシンでは、イーサリアムだけでなく同様のプラットフォームでも使用でき、真に任意の論理操作を実行できます。つまり、コードを作成するとそこで実行され、追加でメモリを割り当てることができます。 ただし、料金は操作ごと、および割り当てられた追加メモリ単位ごとに個別に支払われます。

次に、仮想マシンはブロックチェーン データベースからデータを読み取り、このデータを XNUMX つまたは別のスマート コントラクト ロジックを実行するトリガーとして使用できます。 仮想マシンはトランザクションを作成して送信したり、新しいコントラクトを作成したり、ネットワーク上にすでに公開されている他のスマート コントラクト (既存、利用可能なものなど) のメソッドを呼び出すことができます。

最も一般的な誤解は、イーサリアム スマート コントラクトは、その条件に従って任意のインターネット リソースからの情報を使用できるというものです。 実際のところ、仮想マシンはインターネット上の外部情報リソースにネットワーク リクエストを送信することはできません。つまり、たとえば屋外の天気に応じてユーザー間で価値を分配するスマート コントラクトを作成することは不可能です。または、誰が何らかのチャンピオンシップで優勝したか、または外の世界で起こった他の事件に基づいています。これらの事件に関する情報は、単にプラットフォーム自体のデータベースにないためです。 つまり、これに関してブロックチェーン上には何もありません。 そこに表示されない場合、仮想マシンはこのデータをトリガーとして使用できません。

イーサリアムのデメリット

主なものを列挙してみましょう。 最初の欠点は、イーサリアムでのスマート コントラクトの設計、開発、テストにいくつかの困難があることです (イーサリアムはスマート コントラクトの作成に Solidity 言語を使用します)。 実際、実践してみると、すべてのエラーのうち非常に大きな割合が人的要因に属していることがわかります。 これは実際、平均以上の複雑さを持つ既に作成された Ethereum スマート コントラクトに当てはまります。 単純なスマート コントラクトではエラーの可能性が低い場合、複雑なスマート コントラクトでは、資金の盗難、凍結、予期せぬ方法でのスマート コントラクトの破棄などにつながるエラーが非常に頻繁に発生します。そのようなケースの多くはすでに発生しています。知られています。

XNUMX 番目の欠点は、仮想マシン自体も人間によって作成されるため、完璧ではないことです。 任意のコマンドを実行することができ、そこに脆弱性が存在します。多くのコマンドが特定の方法で設定され、事前に予期せぬ結果を引き起こす可能性があります。 これは非常に複雑な領域ですが、これらの脆弱性が現在のバージョンのイーサリアム ネットワークに存在し、多くのスマート コントラクトの失敗につながる可能性があることを示す研究がすでにいくつかあります。

もう一つの大きな難点、デメリットとも言えます。 それは、仮想マシン上で実行されるコントラクトのバイトコードをコンパイルすれば、特定の操作順序を決定できるという結論に実際的または技術的に到達できるという事実にあります。 これらの操作を一緒に実行すると、仮想マシンに大きな負荷がかかり、これらの操作の実行に支払った料金に比べて速度が不釣り合いに低下します。

過去には、仮想マシンの動作を詳細に理解している多くの人がそのような脆弱性を発見したイーサリアムの開発期間がすでにありました。 実際、トランザクションは非常に少額の手数料を支払っていましたが、実質的にネットワーク全体の速度が低下しました。 これらの問題は、第一に問題を決定し、第二にこれらの操作を実行するための価格を調整し、第三にハード フォーク (すべてのネットワーク ノードを新しいバージョンに更新することを意味します) を実行する必要があるため、解決するのが非常に困難です。ソフトウェアの変更を行ってから、これらの変更を同時にアクティブ化します。

イーサリアムに関しては、多くの研究が行われ、肯定的なことも否定的なことも含めて多くの実践的な経験が得られていますが、それでもなお、何らかの形で対処しなければならない困難や脆弱性が残っています。

これで記事のテーマ部分は完了しました。よくある質問に移りましょう。

よくある質問

— 既存のスマート コントラクトの当事者全員が条件を変更したい場合、マルチシグを使用してこのスマート コントラクトをキャンセルし、その実行条件を更新した新しいスマート コントラクトを作成できますか?

ここでの答えは XNUMX つあります。 なぜ？ なぜなら、スマート コントラクトは、一度定義されると、それ以上の変更を意味しない一方で、一部の条件の完全または部分的な変更を提供する事前に作成されたロジックを持つことができるからです。 つまり、スマート コントラクトの何かを変更したい場合は、これらの条件を更新できる条件を規定する必要があります。 したがって、そのような慎重な方法でのみ、契約の更新を組織することができます。 しかし、ここでも問題が発生する可能性があります。何らかの間違いを犯し、対応する脆弱性が発生してしまいます。 したがって、そのようなものは非常に詳細に、慎重に設計およびテストする必要があります。

— 調停者が参加当事者の XNUMX つ（エスクローまたはスマート コントラクト）と契約を結んだ場合はどうなりますか? スマートコントラクトにはメディエーターが必要ですか?

スマートコントラクトでは仲介者は必要ありません。 存在しないかもしれません。 エスクローの場合、調停者が当事者の一人と陰謀を結んだ場合、そのとおり、このスキームはその価値をすべて急激に失います。 したがって、調停者は、このプロセスに関与するすべての当事者から同時に信頼されるような方法で選択されます。 したがって、信頼できない仲介者を使用してマルチシグネチャアドレスにコインを転送することはできません。

— XNUMX つのイーサリアム トランザクションで、多くの異なるトークンを自分のアドレスから異なるターゲット アドレスに転送することは可能ですか。たとえば、これらのトークンが取引される交換アドレスなどは可能ですか?

これは良い質問であり、イーサリアムのトランザクション モデルと、それがビットコイン モデルとどのように異なるかに関するものです。 そしてその違いは根本的です。 イーサリアムのトランザクション モデルで単にコインを転送する場合、コインはあるアドレスから別のアドレスに転送されるだけで、変更はなく、指定した特定の金額だけが転送されます。 言い換えれば、これは未使用出力 (UTXO) のモデルではなく、アカウントと対応する残高のモデルです。 理論的には、巧妙なスマート コントラクトを作成すれば、一度に複数の異なるトークンを XNUMX つのトランザクションで送信することが可能ですが、それでも多くのトランザクションを実行し、コントラクトを作成し、それにトークンとコインを転送して、適切なメソッドを呼び出す必要があります。 。 これには労力と時間がかかるため、実際にはそのようには機能せず、イーサリアムでのすべての支払いは個別のトランザクションで行われます。

— イーサリアム プラットフォームに関する誤解の XNUMX つは、外部のインターネット リソースのデータに依存する条件を記述することは不可能であるということです。では、どうすればよいでしょうか?

解決策は、スマート コントラクト自体が XNUMX つ以上のいわゆる信頼できるオラクルを提供できることです。このオラクルは、外界の物事の状態に関するデータを収集し、それを特別な方法でスマート コントラクトに送信します。 契約自体は、信頼できる当事者から受け取ったデータを真実であるとみなします。 信頼性を高めるには、大規模なオラクルのグループを選択し、その共謀のリスクを最小限に抑えます。 契約自体は、多数派と矛盾するオラクルからのデータを考慮していない可能性があります。

ブロックチェーンに関するオンラインコースの講義の XNUMX つは、このトピックに当てられています。スマートコントラクトの概要"。

出所： habr.com