🍺 🛵 🤚🏼 ICOに飛び込む 💪🏼 🚔 🔓

この記事では、ICOの準備と実施の技術的側面を検討します。これは、同僚の記事「 ICOの技術的特徴」の続きです。開始」をご覧ください。ここでは、イーサリアムのスマートコントラクトに関連する技術的な問題について詳しく説明します。

技術プロジェクトの開発

スマートコントラクトを開発する前に、技術プロジェクトを作成しておくといいでしょう。これは、主要な技術的質問に答える契約システムの概略図であり、プロジェクト経済とICOシナリオの実現可能性を示しています。

通常、技術プロジェクトには何が含まれますか？これは、厚手の正式な文書である必要はありません。4〜5ページのキーポイントと2、3の図で十分です。そして、これらのページで、所有権の仕組みを最初に見てください。最も簡単なオプション：1つのトークンホルダーが販売され、ICO-すべてが連続しています。通常はそうします。より複雑なオプションは、マルチ署名を使用する場合です。信頼できるウォレットコントラクトを基本として、そこからマルチシグネチャを抽出し、ウォレットに適用してエーテルを保存するだけでなく、ICO自体とトークンを管理することもできます。ここでは想像力に制限はなく、さまざまなシナリオを数学的に簡単に実装できます。

ICOが分解されると、つまり、レートをカウントしてトークンを発行し、エーテルを受け取るのは1つのコントラクトではなく、各コントラクトが仕事をするときのスマートコントラクトのシステムになります。つまり、ICOステージでエーテルを受け入れ、そのロジックに応じて、発行する必要があるトークンの数を理解します。トークンの所有者であるトークンコントラクトに適切なコマンドを与えると同時に、イーサーを自分自身に保持せずに、特別なストレージ（これもコントラクト）に転送します。

放送を契約に保存することで犯罪を見ることはありません。それどころか、契約が何をするのかが明らかなので、それはさらに透明です。 ICOが終了するまで空気がそこに保管されていることが簡単にわかります。お金を集めなければ、投資家にすべてを返すことが保証され、所有者でさえそれを止めることはできません。

一方、この合併症は無料ではありません。これは、展開段階で追加の問題を引き起こすと言えます。そして、はい、これらの接続と課題は、脆弱性を導入する別の方法です。あなたの権利を注意深く見てください。

トークンの標準があり、 ERC20と呼ばれ、契約で実装する必要があるいくつかのメソッドを定義します。トークンがこの標準を実装している場合、多くの取引所で表示できます。さらに、Ethereum Wallet以外の他のウォレットはERC20をサポートしています。したがって、必要な機能を実装するだけで、トークンを操作するための既製のインフラストラクチャを取得できます。さらに、トークンの基盤を築き、すぐにERC20を実装するライブラリがあります。何らかの内部リソーストークンがあり、ユーザーが相互に交換することを想定していない場合は、標準を実装する必要はありません。彼らがこのトークンでこの遊園地に来て、アトラクションのチケットを購入した場合、おそらく、彼は取引所にリストを必要としません。

さらに、問題や奇妙なアクティビティが発生した場合に、一時停止状態を契約に含めることができます。たとえば、エーテルが注がれ、トークンが発行されない場合。次に、ICOを一時停止し、それを把握して決定を下す必要があります。この状態を技術設計に組み込むことは価値があります。技術プロジェクトでトークンの発行を提供することもできます。 ICOの前にこれについて考えることが重要です。なぜなら、それがトークンとどのように互換性を持つかを理解する必要があるからです。

必ずこのようなスキームを検討してください-これはICOの状態グラフです。これは有限状態マシン、つまりICOが可能な状態です。これはグラフであり、状態を説明し、ある状態から別の状態への遷移が発生することを示します。 ICOは、州を単に資金調達から「調達成功」に変更するべきではありません。それらをすぐに出しましょう。」 ICOの状態間の遷移を理解する必要があります。投資家は、すべてが公正であると考えているため、これを理解する必要があります。そして、これは開発者が理解し、明確にプログラムする必要があります。 Solidityにはこのためのすべての手段があります。いわゆる転送があり、その助けを借りて状態が記述されます。さらに、無効な遷移が発生しないように、コードによって制御される状態間で遷移することをお勧めします。

コントラクトの外部で使用可能な関数は、いわゆるSolidityモディファイアを使用して状態を設定できます。そのため、ICOの状態にのみ投資でき、一時停止することはできません。逆に、所有者は、正常に完了したICOでのみお金を引き出すことができます。

スマートコントラクト開発

技術プロジェクトの準備が整い、顧客が満足し、開発者が何をする必要があるかを理解したら、開発に進みます。 Ethereumには仮想マシン（Ethereum Virtual Machine、EVM）があり、これらと同じコントラクトプログラムを実行します。コントラクトは、仮想マシンによって実行されるいわゆるバイトコードです。この点で、いくつかの言語で契約を作成することが可能になります。 Solidity言語は、スマートコントラクトをゼロから開発するために特別に作成されたもので、Cに似た構文を持っています。彼以外にも、他の言語があります。JavaScriptに似た言語、Pythonに似た言語があります。

私の直感的な意見は、神経生理学的性質の理由でさえも、Solidityを選択する方が良いというものです。開発者がPythonに似た言語を使用する場合、それでもイーサリアムスマートコントラクトを作成します。しかし同時に、Pythonに典型的なセマンティクスとパターンが頭に浮かび始め、Blockchain向けに開発するときには明らかに機能しません。

Solidityについて長い間話すことができるので、ガイダンスが必要です。まず、 Truffleフレームワークの開発を大幅に促進します。コントラクトをテストし、メインのテストローカルチェーンにデプロイするのに役立ちます。また、これを段階的に行うこともできます。つまり、契約システムを新しい契約で補完することもできます。同時に、フレームワークは古いものをすべて記憶し、それらを再配布しません。

ライブラリを再利用するために呼び出すのはなぜですか？コミュニティは非常に若く、コードはほとんどありませんが、過去30〜40年にわたってソフトウェアの開発で得られたすべての原則は、ブロックチェーンの場合でも有効です。そして、十分にテストされたコードがあり、それ自体が幅広いプロジェクトで再利用を伴う場合、それを採用し、車輪を再発明しないでください。

まず、 OpenZeppelin / zeppelin-solidity libraryに注目します。スマートコントラクトを開発するとき、それは事実上の標準の危機にonしています。多くの契約やライブラリはありませんが、比較的小さいものです。しかし、それらは頻繁なケースをカバーし、契約書、いくつかのトークン、作成、書き込み可能なトークン、いくつかの典型的なICO、セキュリティに関連する何か、例えば再入攻撃に対する保護を保持するなど、すぐに使えるものを提供します。

別のライブラリはSafeMathです。 Zeppelin-solidityに接続したくない場合でも使用することをお勧めします。それは小さく、文字通りいくつかのワンライナーで、契約に直接コピーできます。彼女はあなたをあふれから守ります。これは非常に緊急で深刻な問題です。たとえば、Solidityで符号なしの数値を処理し、過失により3つから5つを差し引くと、契約は引き続き機能しますが、その結果、膨大な数が表示されます。これはオーバーフローが原因で発生しました。 SafeMathライブラリを使用すると、エラーが発生します。つまり、トランザクションはエラーで完了し、状態は変更されません。

多くの推奨事項があります。ステートマシンについて説明しましたが、それを実装することが望ましいです。ステートと修飾子を登録します。さらに、ある状態から別の状態への遷移を時間内に実装できます。同時に、各関数に修飾子が追加されます。「時間を見て、もし今ICOの始まりであれば、状態をICOに変更します。」

Solidityの世界、スマートコントラクトの世界では、典型的なパターンが形になり始めているパターンがあります。たとえば、ソフトウェア、特に一部の企業システムの開発には多くのパターンがあると聞きました。ここでは、たとえば、ユーザーが彼に送金しようとするときではなく、彼自身のために資金を受け取るときに、よく知られた引き出しパターンを含めることができます。たとえば、ICOが失敗した場合、投資家にお金を返す必要があるとき、自分でやろうとすると、多くの理由で成功しない可能性があります。また、セキュリティの問題もあります。適切な小切手を持つユーザーによる資金の引き出しとして払い戻しを設計すると、はるかに簡単になります。

一時停止モードについて説明しました。最近見たICOではあまり使用されませんが、これは非常に便利なメカニズムです。もちろん、彼は問題の状況の100％に対しては保証していません（一時停止していてもエーテルを盗むことができます）が、攻撃の可能性を大幅に減らします。

コントラクトの置換については、最後まで行って完全に動的なコントラクトを作成する必要はないと言わなければなりません。そのコードは、たとえば、elegatecallなどを呼び出すことで任意に置き換えることができます。問題が検出された場合、ロジックを置き換えることができます。これは、トークンとお金を別々に持っているという事実のために可能であり、お金は変わらないままです。原則として、このパーティクルを置き換えて、2つの既存のパーツに完全に透過的に関連付けることができます。いくつかの機能があります。 ICOがトークンなどを初期化する場合は、置換中に2回目の初期化が開始されないようにしてください。その結果、ICOには新しい住所があります。これは新しい契約です。置換の可能性は契約のコードで見ることができ、これは一種の妥協であるということを理解する必要があります。一方で、私はすべてが絶対に変わらないことを望みます（これはあなたに対する信頼を高めます）、他方では、それを安全にプレイすることは素晴らしいことです。妥協案として、完全に変更できない条件をコードに指定できます。たとえば、資金調達の最小しきい値が原則として変更されていないことをエーテルリポジトリに登録します。それから、投資家は、彼らが10万を集めたことが起こらないことを知っているでしょう、しかし、1億を集めたいと思ったが、それでも何をしたか。

可能であれば、契約のメソッドが入力時に受け取るパラメーターの妥当性を確認する必要があります。トークンが放出をサポートし、生成されるトークンの数がパラメーターで指定されている場合、たとえば、トークンの数よりもトークンの数が多いかどうかを調べることで、この数を確認できます。これにより、手動で入力したパラメータにタイプミスがある場合に確実になります。または、たとえば、外部インフラストラクチャで障害が発生したときに外部インフラストラクチャによって発行が開始された場合、数十億から数十億のトークンが発行されます。

GitHubへのさらに3つのリンク：

以下に、いくつかのソリューションを含むリポジトリのセットを示します。これらは実験的なものですので、慎重に試してください。通常、「これはアルファ版です。20ドルを超えて保存しないでください」と書かれていますが、すべての良いことは実験から得られることは明らかです。自分ですべてを一から書くよりも、何かを基礎として準備する方がいいかもしれません。

堅牢性の開発に必要なIDE 私はコマンドラインで積極的に作業することに慣れていて、コマンドラインからTruffleを実行しますが、実際には、 test

、 compile

、 migrate

3つのコマンドのみが必要です。開発環境については、PyCharmを選択しました。Solidity用の無料のプラグインがあり、これは良いことです。開発環境は大いに役立ち、PyCharm / Ideaは優れたIDEです。競合他社よりも2倍優れているとさえ言えます。開発環境の助けを使用して、馴染みのないコードを文字通り数時間理解している場合、契約内の変数とそのすべての使用を強調表示でき、監査を行うときに非常に役立ちます。

スマート契約を履行するためのコストについて少し。ブロックチェーンを変更する、つまりトランザクションに参加する計算のみにコストがかかります。 view

またはpure

修飾子を持つ関数があり、それらは状態を変更せず、ブロックチェーンにデータを送信せずに使用できます。ローカルで呼び出される関数を開発した場合、費用は一切かかりません。

ブロックチェーンで実際に実行され、状態を変更し、データを保存または送信するコードはすべて、価値があります。このテーマについて思考実験を行うのは簡単です。たとえば、非常に長い間機能し、多くのことを節約するコードを記述できますか。イーサリアムネットワークの参加者が同時にそれを繰り返す必要がある場合、コードは世界中の何百万台ものコンピューターで動作します。したがって、イーサリアムの開発者は、あなたがそれを支払うためにどんな方法でも気にし、現在の価格では非常に高価です。もう1つのことは、計算と行ごとにコストが異なることです。単純な算術演算の価格は3〜5単位のガスであり、州の変更には2万単位のガスがかかります。なんで？ブロックチェーンが変更されたため、あなたのために32バイト増加しました。これらのバイトは世界中の何百万ものコンピューターに到達しました。

スマートコントラクトテスト

テストは必要なステップです、ソフトウェアの50年の歴史はこれを教えてくれます。そして、ICOに付属するプロジェクトリポジトリにテストが表示されないのは奇妙です。たぶん、それらは完成し、書かれているが、単にレイアウトされていない。しかし、いずれにせよ、テストを行う場合、それらをレイアウトしてみませんか？したがって、投資家に対して、ここですべてが十分にテストされていることを示します。これはエラーがないことを保証するものではありませんが、多くの問題を回避するのに役立ちます。

テストはSolidityまたはJavaScriptで直接記述されます。いずれの場合でも、Truffleを使用すると、すべてのテストを一度に実行して、要約レポートを取得できます。一番下で言う必要があります：すべてのテストに合格し、失敗はありません。 ICOの最も重要な側面（トークン、クラウドセール自体、貯金、ボーナスなど）をテストしたことを、ICOのお客様、ユーザー、投資家の両方に示します。ボーナスは重要なものです。投資家がボーナスを受け取ることを知ることは非常に重要です。

単体テストがあります-それらは小さな孤立したコードフラグメントをテストし、そのようなテストはSolidityで書くのに便利です。

 function testValidationOfDecrease() { Bonuses b = new Bonuses(); b.add(1000000000, 50); b.add(1000000010, 60); b.validate(false); assertInvalid(b, true); b = new Bonuses(); b.add(1000, 60); b.add(1000000000, 50); b.add(1000000010, 60); b.add(1000000020, 0); b.validate(false); assertInvalid(b, true); }

コードはSolidityであり、単純に契約を作成してデータを送信し、契約が期待どおりに機能していることを確認します。 JavaScriptで記述されたテストがあります。通常、複数の契約が相互作用に関係している場合、より複雑なシナリオがここでチェックされます。前述の一連の契約を作成するとします。その後、複数の契約が関係し、複数のユーザーが存在する場合もあります。私たちはそれらを「投資家のようなもの」、「投資家のようなもの」とも呼びます。まだ所有者がいます、全く権利のないユーザーがいます。そして、ここで複雑な相互作用をプログラムし、相互作用中にトークンが正しく発行されることを確認できます。または、ハードキャップに達すると、投資家が変更を受け取ることを確認します。これらのテストは統合テストと呼ばれます。

JavaScriptからブロックチェーンへの呼び出しは非同期です-これにより、余分なコード、あらゆる種類の約束などが追加されるため、 await

、 async

構成要素の背後にあるすべての非同期性を隠す一種のJavaScriptコンパイラであるBabelを使用することをお勧めします。

 it("test max cap", async function() { const role = getRoles(); const [crowdsale, token, funds] = await instantiate(); // +5% await crowdsale.setTime(1511913601, {from: role.owner1}); await crowdsale.sendTransaction({from: role.investor1, value: web3.toWei(20, 'finney')}); await assertBalances(crowdsale, token, funds, web3.toWei(20, 'finney')); const investor3initial = await web3.eth.getBalance(role.investor3); await crowdsale.sendTransaction({from: role.investor3, value: web3.toWei(1000, 'finney'), gasPrice: 0}); const investor3spent = investor3initial.sub(await web3.eth.getBalance(role.investor3)); assertBigNumberEqual(investor3spent, web3.toWei(378, 'finney'), 'change has to be sent'); assert.equal(await crowdsale.m_state(), 4); await assertBalances(crowdsale, token, funds, web3.toWei(398, 'finney')); assertBigNumberEqual(await token.balanceOf(role.investor1), STQ(2100)); assertBigNumberEqual(await token.balanceOf(role.investor3), STQ(39690)); await checkNoTransfers(crowdsale, token, funds); await checkNotInvesting(crowdsale, token, funds); await checkNotWithdrawing(crowdsale, token, funds); await checkNotSendingEther(crowdsale, token, funds); await crowdsale.distributeBonuses(10, {from: role.nobody}); assertBigNumberEqual(await token.balanceOf(role.investor1), STQ(2600)); assertBigNumberEqual(await token.balanceOf(role.investor3), STQ(49140)); await checkNotInvesting(crowdsale, token, funds); await checkNotWithdrawing(crowdsale, token, funds); });

例外的な状況をテストすることを忘れないでください。たとえば、所有者がICOの成功後にお金を引き出すことを確認しました。また、これらの仲間-投資家2、投資家3、通りから匿名-がお金を引き出すことができないことをテストする必要があります。つまり、お金の引き出しのリクエストを送信すると、例外的な状況が判明し、契約はリクエストを受け入れません。

要約すると、テストする価値があります。すべての手段があります。ところで、プログラマーはテスターであってはなりません。なんで？クリエイターは自分の間違いをよく見ないからです。彼はすでに頭の中にある種のモデルを持っていて、それをコードに移しました。プログラマーが自分のコードをチェックしようとすると、モデルは必然的に頭に浮かび上がり、脳はこう言います。このメソッドを作成したので...そして、そこを見るのを止めます。より良いスムージーを持って行きましょう。」

テストに加えて、監査も必要です。監査は特別に訓練された人々によって実施されます。監査中に追加のテストが開発される場合がありますが、監査はまったく異なる状況であり、スキルもまったく異なります。

監査について話している場合、まず、脆弱性とは何か、そしてそれらに対して監査人に支払う金額を理解する必要があります。評価する方法はいくつかあります。たとえば、優れたOWASP方法論では、重要性と確率という2つの脆弱性の側面が導入されます。プロジェクトに対する脆弱性の影響は、これら2つの量の積です。これは、リスク評価マトリックスを思い出させるかもしれません。

実際には、スマートコントラクトの監査レポートでは、多くの場合、脆弱性の影響の程度とその重要性が耳に惹かれることを確認する必要があります。なぜこれが起こっているのか分かりません。それにもかかわらず、クリティカルはクリティカルな脆弱性ではありません。したがって、脆弱性が実際の生活に与える影響をプロジェクトと関連付ける別の方法論を提案します。スマートコントラクトの場合、この脆弱性を悪用した結果として非常に理解しやすいものがあります。エーテルまたはトークンを出力できますが、これは非常に悪いことです。条件によっては、契約がフリーズするか、条件が大幅に悪化するため、契約を交換する必要があります。ここで、監査人と監査クライアントには、最小限の紛争がある場合があります。監査レポートへのリンク：

レポートは、発見された脆弱性と（理想的には）次に何をすべきかについて説明する文書です。西洋のサークルの誰かが大きなレポートを書いています。彼らは、この関数を別の方法で呼び出す必要があると言っていますが、このコードをどこか別の場所に転送する方が良いと言っています。しかし、顧客がスマートコントラクトの連続開発に従事していない場合、ICOを1回実施して、エーテルを収集しているキャリアで砂を抽出し続ける必要がある場合、これを行う理由はありません。

スマートコントラクトのセキュリティ問題

対処する必要がある問題に移りましょう。これは、スマートコントラクトのセキュリティに関する別の記事のトピックです。いくつか注意点があります。開始するには、機能を慎重に確認し、最も厳しい制限で、必要に応じて権限で保護されていることを確認してください。たとえば、ブロックチェーン内で何も変更しない関数は、 view

として宣言できview

。ブロックチェーンをまったく読み込まない関数はpure

ようpure

です。これらの制限を課す価値があります。さらに、管理機能は所有者が確認する必要があります。当たり前のように思えますが、パリティを思い出してください。

もう一度繰り返します。ブロックチェーン内のすべてのデータは、状態に対する修飾子とアクセス権にもかかわらず、すべての人に公開されています。それはpublic

ているかもしれませんが、実際にはそうではないかもしれませんが、実際には、すべてが契約から読み取ることができます。承認にtx.origin

などのトランザクションパラメータを使用しないでください。これにより、脆弱性が開きます。 msg.sender

選択しmsg.sender

。

非自明から。おそらく、DAOがハッキングされたいわゆるリエントラント攻撃について多くの人が聞いたことがあるでしょう。問題は、コントラクトメソッドがまだ機能しているときに、外部呼び出しを行うことができることです。これは外部呼び出しにのみ適用されます。外部呼び出しは、同じメソッドまたは別のコントラクトメソッドにチェーンバックして戻ることができます。そして、これは脆弱性を開きます：契約状態がまだ一貫していない可能性があり、メソッド中の一部の不変条件が一時的に違反され、まだ復元されていない可能性があります。

これに対処する方法はいくつかあります。最もハードコアな方法nonReentrant

ライブラリコントラクトのnonReentrant

修飾子-コントラクトのリエントラントを禁止します。使ってみませんか？一定量のガスがかかり、条件を記述しますが、場合によっては、過剰なガス消費よりも安全性が重要です。

たとえば、フロントランニング攻撃を思い出してください。何かを暗号化してブロックチェーンに入れるとどうなりますか？誰も非対称暗号化をキャンセルしていないため、解読することは不可能です。しかし、パスワード付きのトランザクションを送信して合法的にこれを復号化しようとすると、これが起こります。まず、パスワードはブロックチェーンに流れ込んだため、誰もが見ることができるため、一度限りです。第二に、トランザクションがあなたを離れたが、まだメインブランチの一部になっておらず、トークンを記録していない場合、その時点で誰かがあなたのパスワードを見てトランザクション内でスリップすることができます。。

少し前に、別の攻撃-ショートアドレス攻撃に関する情報が登場しました。彼女はいくつかの交換を受けました。そして、トランザクションをイーサリアムに送信するライブラリ。コアEthereum web3 APIライブラリは影響を受けませんが、ソフトウェア交換の影響を受けます。攻撃は、ユーザーが1バイト短縮したアドレスを使用することでした。パラメーターがトランザクションにブラインドされた場合、このアドレスに続くパラメーターは1バイトシフトされました。また、Ethereum仮想マシンからこれらのパラメーターへのアピールがあった場合、calldataの最後にEVMが暗黙的にゼロを追加しました。番号は1バイトシフトされ、そのようなシフトは256の乗算です。つまり、交換側のすべてのセキュリティチェックが既に合格したときにユーザーは1ユニットの空気を除去しましたが、実際には256ユニットが彼に転送されました。

誰かが言います：「交換は間違ってプログラムされました。」私の意見では、既存のトランザクションパラメータ以外のバイトにアクセスする場合、実際にはゼロの暗黙的な置換ではなく、エラー、例外的な状況があるはずなので、イーサリアム仮想マシンに問題があります。そのため、コンピューター上の通常のアプリケーションのアドレス空間の管理で発生します。

オーバーフローについてはすでに言及しました。もう一度言いますが、たとえば、1バイトを占める数値などの短いデータ型があります。符号なしの場合、0から255までです。それらがあふれないようにすることが重要です。暗黙的に発生することもありますが、気付かないこともあります。たとえば、ループキーワードの場合、 var

キーワードを使用して型を置き換えます。つまり、パラメータをゼロに初期化すると、そこにある型は暗黙的にシングルバイトとして選択されます。 256に達することはありません。つまり、無限ループとフリーズされた契約がある可能性があります。凍結することはなく、落下しますが、サイクルが重要な場所のどこかにある場合、契約は下落を超えることはありません。

さまざまな算術では、暗黙的なタイプの式が存在する場合があります。たとえば、何かを累乗して2バイト数にし、結果を大きな数に割り当てた場合、型キャストを行わないと結果バイトが返され、再びオーバーフローが発生します。

バグ報奨金

バグ報奨金-文字通り翻訳された場合、これはバグに対する報酬です。ここでは、監査評価、つまり脆弱性評価と同じ評価方法が適用されます。 2種類の根本的に異なるバグバウンティプログラムを選びます。 1つ目は、いわゆる手動のバグ報奨金です。このビジネスがどのように形作られるかについての良いリンク： Aventus Token Sale Bug Bounty 。実際、これは「そのようなコードの脆弱性を探しましょう」というオファーの一種です。たとえば、最初のコードが彼にとって良いと思った人は誰でも条件が定められています。そして、一般的に、すべてがそこに有名に記述されており、どのくらいのお金がどの脆弱性に依存しているのかを見てください。仕組みはここで明らかです。セキュリティの専門家、ハッカーは、あれこれあれを見つけたとあなたに書きます。あなたがチェックし、もしそうなら、彼らは報酬を支払われます。

2番目のビューがあります：自動バグ報奨金。ハッカーと顧客の両方にとって魅力的です。ここでは、交渉、それがどのような脆弱性であるか、どのくらいのお金が支払われるかについての議論がないことが便利です。マニュアル版では、この形式で悪用されることは決してないと彼らは言う。これはここではありません。 2つのシナリオがあります。 1つ目は、ウォレット、イーサストレージ、リポジトリが単純に展開され、イーサがその上に注がれる場合に便利です。その後、「ブレイクイット、みんな」。ここで追加できる唯一のことは、「これはバグの恩恵であり、すべてを壊して取り去ることができるし、しなければならない」というコメントです。よくわかりませんが、これを行うことで、情報への不正アクセスに関する潜在的な質問や、あなたの利益のためにハッキングに対処するハッカーからの犯罪記事を削除しているように見えます。自動バグ報奨金の2番目のシナリオは、不変条件の違反です。通常、契約には明示的または暗黙的な不変式があります。たとえば、トークンには合計トークン数を示す数字があります。そして、この数は、トークン保有者の残高の合計に等しくなければなりません。または、たとえば、ICO中に動作するエーテル貯蔵施設は、収集されるエーテルの量を保持でき、貯蔵契約の残高はこの量以上でなければなりません。そうでない場合、不変式に違反します。

このバグ報奨金はどのように編成されていますか？利害関係者に不変式との契約の新しいコピーを提供する契約があり、彼らは何らかの形でそのコピーで遊んで不変式に違反しようとすることができます。それが壊れると、お金は自動的に彼らに到着し、彼らは親契約によって支払われます。ストーリー全体が自動であり、ハッカーは数時間で仕事の報酬を受け取ることができるため、これは便利です。バグが多い顧客は、100のエーテルがあり、それが0になったため、彼の契約がどのようにハッキングされたかを確認できます。ブロックチェーンではすべてが公開されているため、これが表示されます。そして、双方が議論する時間を無駄にする必要はありません。

契約の展開

開発、テスト、監査、およびバグ報奨金-これで、展開、つまりブロックチェーンに契約を締結する時が来ました。 Truffle , — migrate

. , .

— , , - , . , , , 20 20 . . , . . , .

, , , -, . , , , , 1 . , 300 . , , — . , , , , . , Testnet — Ethereum, , . , , , .

, , . , - , . . .

. , : «, , . ». , . : , , . , , , , Truffle . , , . , . . Truffle , geth, , . , . — . , , , .

, , . , . , . . , . . . .

, , , , ICO , .

— . , ABI , , Etherscan. . , , .

- . , , . , , , , .

, . , , , . , , , , , .

, . すべてが非常に簡単です。 , . , . , .

ICO-, , , , , , , , , . , , .

: , . , . - . , Ethereum, Ethereum, , , , , , Intel AMD. AMD64 , , . RISC-, reduced instruction set. - , . , , , — . , - backdoor, . , , .

. , . : . Etherscan. , , , . , , . . , . , , . user friendly . .

, Etherscan, . : « , , Etherscan — ?» , . , , , , . , . , , white paper.

おわりに

, . . , . , . 3 . ICO!

ICOに飛び込む