FC2ブログ

ブラックリスト機能付き仮想通貨コントラクトをデプロイしてみる

どうも、ぺろりんです。

今回も 「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門」で勉強していきます。

前回は最低限みたいな機能が付いた仮想通貨コントラクトをデプロイして遊んでみましたが、次の話題は「ブラックリスト」です。

登録されると取引禁止になる「ブラックリスト」機能付きの仮想通貨コントラクトをデプロイして、実際にユーザーをブラックリストに追加したり、リストからはずしたりしてみて、挙動を確認してみます。

引き続きJavaScript VMを使って、ブラウザ上で完結した環境で動作確認していきます。


ブラックリストの仕組み

コード自体は 「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門」を参照していただきたいのですが、基本的な仕組みは簡単なものです。

「blackList」という名前の変数をフラグとして使ってif文でフラグをチェックし、そのユーザーに「ブラックリスト」フラグが立っていたら取引がなかったことになる、という内容です。

今回のコードは、前回のコードにこの変数「blackList」を使ったフラグチェック機能が付いたものです。


「ブラックリスト」機能付きの仮想通貨コントラクトをコンパイルしてみる

さて、教科書通りのコードを入れてコンパイルしてみると、案の定めっちゃ怒られますw


数は結構ありますが、内容を分類すると前回対処した4通りの警告と同じものでした。
というわけで、前回の知識をそのまま使えばコードを修正できます。

やることをザクっと書くと以下の4つですが、詳しくは前回の記事をご覧ください。
・「public」をつける
・「emit」をつける
・「throw」を「revert()」に置き換える
・コントラクタを「constructor」にする

上記の4種類をやってみると、「Static Analysis raised 2 warning(s) that requires your attention. Click here to show the warning(s).」というのは残るものの、いっぱい出ていた警告は綺麗になりました\(^o^)/
このメッセージは害はなさそうなので先に進みます。



「ブラックリスト」機能付きの仮想通貨コントラクトをデプロイしてみる

EnvironmentでJavaScript VMを選び、Deployのプルダウン的なところを開いて仮想通貨の総量、名前、単位、小数点以下の桁数をそれぞれ入力してtransactします。


これでデプロイできました。



デプロイした「ブラックリスト」機能付きの仮想通貨コントラクトで遊んでみる

ここでは、以下のアドレスをユーザーA、ユーザーBと呼ぶことにします。
ユーザーA:0xca35b7d915458ef540ade6068dfe2f44e8fa733c
ユーザーB:0x14723a09acff6d2a60dcdf7aa4aff308fddc160c

ユーザーAは、この仮想通貨コントラクトをデプロイしたときのユーザーです。
なのでこのコード上、ユーザーAが「owner」となり、ブラックリストにユーザーアカウントを追加/削除できる権限を持ちます。


残高確認

まずは、ユーザーA、Bそれぞれの残高確認をしてみます。
これはbalanceOfというので確認できます。

まだ送金していないので、ユーザーAの残高は、全OreOreCoinである10000[oc]です。



そして、送金していない状態なので、当然ユーザーBは残高0[oc]です。




送金

このままだとあまり面白くないので、この世界にOreOreCoinをすこし流通させてみましょう。

というわけで、すべてのOreOreCoinを持っているユーザーAから、ユーザーBへ2000[oc]を送金してみます。

まずはAccount欄をユーザーAにして、送金先アドレスと送金する量を入力しつつtransferを実行します。




これでユーザーAからユーザーBへ2000[oc]送金できました。
残高を確認してみましょう。

まずはユーザーAを見るとbalanceOfのところに8000とあります。


次にユーザーBは、balanceOfのところに2000とあります。



ユーザーBをブラックリストに登録してみる

入力欄にユーザーBのアドレスを入れて(言い忘れましたが、アドレスは「"(ダブルクォーテーション)」で囲む必要があります)、blacklistingを実行してみました。
これでユーザーBのアドレスがブラックリストに登録され、ユーザーBとOreOreCoinのやり取りができなくなっているはずです。



ユーザーBをブラックリストに登録した状態でユーザーAからユーザーBへ送金してみる

ユーザーBをブラックリストに登録した状態で、ユーザーAからユーザーBへ2000[oc]送金してみます。



「logs」欄を見ると、RejectedPaymentToBlacklistedAddrという、ブラックリストに登録されたユーザーに送金した際に呼び出されるイベントが呼び出されていました。

実際、残高確認をしてみると、以下の通り2000[oc]の移動がなかったことがわかります。

ユーザーA。


ユーザーB。


逆に、ユーザーBからユーザーAへ1000[oc]送金してみる、というのも同様にできません。






ユーザーBをブラックリストからはずしてみる

ブラックリストからはずすには、ユーザーBのアドレスを入力してdeletefromblacklistを実行します。




ユーザーBをブラックリストからはずしてから送金してみる

ユーザーAからユーザーBへ1000[oc]送ってみました。
うまくいくと、eventとしてTransferが呼び出されます(、というコードになっています)。


ちゃんと送金できたようです。



逆に、ユーザーBからユーザーAへ2000[oc]送ってみます。


残高も想定通りの挙動になっていることがわかります。




その他の挙動確認

個人的に挙動が気になったところも確認してみます。


変数blackListにユーザーBのアカウントを入れるとどうなるか?

blackListは、これの値によってユーザーがブラックリストに入っているかどうかを管理する変数です。
ブラックリストに登録するときは、引数にされたアドレスのblackList値を1に、ブラックリストからはずすときには-1にするような動作をします。

で、恐らくアドレスを入れてblackListボタンを押すと、引数にしたアドレスのblackList値を返すと思われます。
実際、ユーザーBのアドレスを入れてblackListボタンを押すと、先ほどブラックリストからはずしたときに設定された-1が返ってきました。




特にブラックリストの追加削除していないユーザーAについては、blackList値は0でした。


何もしていないユーザーのblackList値が0なら、個人的にはブラックリストからはずすときにはblackList値は0で良いような気もするのですが、ブラックリストに登録されたという履歴を残すためなんでしょうか?


ユーザーAをブラックリストに登録してみる

これは普通にできました。




そして、ちゃんとブラックリスト登録されたユーザーAからユーザーBへ送金しようとしても、送金されませんでした。




オーナーがブラックリストに登録されてはダメかと思いましたが、考えてみれば、オーナーはブラックリストの追加/削除をするだけで、ブラックリストに登録されていようがブラックリストの追加/削除はできるので、別に変なことにはならないんですねw


まとめ

今回は、「ブラックリスト」機能付き仮想通貨コントラクトをデプロイして、その動きを確認してみました。

コンパイル時の警告に関しては前回の知識だけで乗り切れたので、スムーズにデプロイできました。
デプロイ後の動きとしても、教科書の想定通りに動いていることが確認できました!

というわけで、今回はこのへんで。

テーマ : プログラミング
ジャンル : コンピュータ

Keyword : ブロックチェーン Browser-Solidity Solidity Ethereum イーサリアム 仮想通貨

仮想通貨コントラクトを作成してみる

どうも、ぺろりんです。

「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門」のつづきです。
このシリーズでは、前回はSolidityの仕様についてまとめました。

この本もようやく実践編にきました!

今回は、教科書の実践編で基本的な仮想通貨コントラクトを作成するところをBrowser-Solidity上でやっていきます。
ここではこれまで通り、JavaScript VMで実行するのでオンライン上で完結した環境です。


仮想通貨コントラクトのデプロイ

教科書通りのコードで「OreOreCoin」なるものをデプロイしていきます。

が、そのままのコードだとこんな感じでコンパイル時にエラーが出ます。


すべて警告で、内容的には以下の4種類です。(キャプチャの順番とは前後していますが、あとの説明用にこの順で載せています)
Warning: No visibility specified. Defaulting to "public".

Warning: Defining constructors as functions with the same name as the contract is deprecated. Use "constructor(...) { ... }" instead.

Warning: "throw" is deprecated in favour of "revert()", "require()" and "assert()".

Warning: Invoking events without "emit" prefix is deprecated.


これら4種類の警告について、それぞれ対処してみましょう。


Warning: No visibility specified. Defaulting to "public".

「public」のところは以前調べたのと同じで、以下のように「public」を入れると消えました。
function OreOreCoin(uint256 _supply, string _name, string _symbol, uint8 _decimals) public {

function transfer(address _to, uint256 _value) public {



Warning: Defining constructors as functions with the same name as the contract is deprecated. Use "constructor(...) { ... }" instead.

これも以前調べたのと同じです。
以下のように、コンストラクタのところで「function OreOreCoin(…」としていたのを「constructor(…」に直すと上手くいきました。
constructor(uint256 _supply, string _name, string _symbol, uint8 _decimals) public {



Warning: "throw" is deprecated in favour of "revert()", "require()" and "assert()".

「throw」ではなく、「revert()」、「require()」、「assert()」の使用が推奨されているみたいです。

たとえば「require()」なら、どうやら
 if(<条件>) throw

 require(<throwのときに各条件の反対>)
が同等の意味になるようです。(「反対」の意味は、おそらく補集合と考えると良さそう)

「throw」を一番簡単に書き換えるとすると、「throw」を「revert()」に置き換えれば上手くいきそうです。
実際、
if (balanceOf[msg.sender] < _value) throw;
if (balanceOf[_to] + _value < balanceOf[_to]) throw;


if (balanceOf[msg.sender] < _value) revert();
if (balanceOf[_to] + _value < balanceOf[_to]) revert();

に書き換えて再度コンパイルしてみると、この部分のWarningが消えました。

これに関しては、参考に挙げたSolidityのassertとrequireとrevertの違い(アルゴリズムとかオーダーとか)にとても分かりやすくまとめられていました。
最近のバージョンのSolidityでは「throw」が「revert()」に自動で変換されるようです。

参考サイトにあった内容をさらに短くまとめておくと、以下の内容のようです。
・revert(<メッセージ>) → ここでコントラクトは停止して実行前に戻す。残りのガスは返却。条件は指定できない。
・require(<条件>) → ここでコントラクトは停止して実行前に戻す。残りのガスは返却。条件を指定する。
・assert(<条件>) → ここでコントラクトは停止して実行前に戻す。残りのガスも消費。条件を指定する。

(参考)
ERC20 Token Standard Interface を使った Smart Contractの実装について(Qitta)
Error creating contracts on Ethereum wallet(StackeEchange)
Solidityのassertとrequireとrevertの違い(アルゴリズムとかオーダーとか)
Error handling: Assert, Require, Revert and Exceptions(Solidity)


Warning: Invoking events without "emit" prefix is deprecated.

さしあたり、解決策としては
Transfer(msg.sender, _to, _value);

の冒頭に「emit」を付けて
emit Transfer(msg.sender, _to, _value);

とすれば、この部分のWarningが消えました。

これでようやく怒られないコードになりました\(^o^)/

(追記:2018/9/3)--
参考に挙げた「‘emit’ keyword in Solidity(Medium)」によると、これはv0.4.21以降で推奨される書式で、イベントの呼び出しを明示するためのようです。

明示する理由の1つがDAO事件とありますが、いまいちピンとこない。。
ちょっと調べた感じではこの辺の関連を見つけられなかったので、分かる方ぜひ教えてください。
--(追記ここまで)

(参考)
‘emit’ keyword in Solidity(Medium)
Invoking events without “emit” prefix is deprecated in Transfer(msg.sender, _to, _value);(StackExchenge)
【備忘録】【Solidity】【Truffle】エラー:Warning: Invoking events without "emit" prefix is deprecated.(katonobo’s blog)
Warning: Invoking events without "emit" prefix is deprecated #8(GitHub)


OreOreCoinをデプロイしてみる

ようやくコンパイルが(ほぼ)綺麗に通ったので、この状態でデプロイしてみます。
(実はまだメッセージは残るんですが、無害そうなのでとりあえず先に進みます。)

Deployのところを開いて、テキスト通り値を入力しつつtransactします。



うまいことデプロイできました。


ボタンを押してコンストラクタの値を取得してみると、デプロイ時に入力した内容が反映されていることが確認できます。


balanceOfでユーザーアカウントごとのOreOreCoin残高も確認してみましょう。
まずはデプロイしたユーザーアカウントです。


この「…a733c」(以下、「ユーザーA」と呼ぶことにします)というアカウントアドレスを、「"」(ダブルクォーテーション)で囲んでbalanceOfのところに入力してbalanceOfボタンを押します。ちゃんとユーザーAが 10000 [oc]持っていることがわかります。



次に、別の「…c160c」(以下、「ユーザーB」と呼ぶことにします)というユーザーアカウントについて、残高確認をしてみましょう。


OreOreCoinの送金はまだしていないので、ユーザーA以外のアカウントは残高 0 [oc]のはずです。
先ほどと同様の手順で、今度はユーザーBのアカウントアドレスでbalanceOfしてみると、たしかに残高が 0 [oc]であることが確認できます。




OreOreCoinを送金してみる

デプロイがうまくいって、現状の値確認もできたので、今度は送金してみましょう。
ユーザーAからユーザーBへの送金を試みてみます。

失敗例

transferのところに、送り先であるユーザーBアドレスと、送りたい値( 2000 [oc])を入力してtransactします。
ここで、送り主のアドレスはグローバル変数msg.senderにより、現在の送信主アドレスを自動取得するため、特に入力はしません。


で、やってみましたが、うまくいかない……


画像にあるエラーメッセージを見てみると、「from」のところがなぜかユーザーBになっている。。

どうやら原因は、先ほどbalanceOfしたときの流れでやっていたので、このときに取得したユーザーBのmsg.senderの値が残っていたか、もしくはBrowser-SolidityのAccount欄アカウントを間違ってユーザーBにしたままtransferやってたせいでtransferのときに取得するmsg.senderの値がユーザーBになってしまったかで、残高 0 [c]のユーザーBから送金しようとしていました。

たぶん後者の、Account欄の問題かな……?


いずれにしろ、msg.senderでユーザーBのアドレスを取得してtransferしようとしたことが原因でした。
そして、まだOreOreCoinを持っていないユーザーBからの送金はできないと、エラーになりました。


成功例

原因がわかったので、Browser-SolidityのAccount欄をユーザーAにしつつ、念のためもう一度ユーザーAについてbalanceOfを実行してから、あらためてユーザーBへ 2000 [oc]送金してみたら、今度はうまく送金できました。




ユーザーA、ユーザーBそれぞれについて、送金後の残高をbalanceOfで確認してみます。

まずはユーザーA。


つづいてユーザーB。


ユーザーAからユーザーBへ、2000 [oc]がちゃんと送金できたことが確認できました。


まとめ

今回は、「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門」の実践編にあるOreOreCoinという、簡単な仮想通貨のサンプルコードをデプロイして、状態確認と送金をやってみました。

テキストのサンプルコードをそのままコンパイルすると4種類の警告が出たので、それらの対処もしてみました。
送金はいい感じに教育的な内容で(笑)失敗しましたが、エラー内容をもとに対応してうまく解決できました。

警告とかエラーの対処が、やっぱり勉強になるなぁとあらためて実感しました。
ではでは今回はこのへんで。

テーマ : プログラミング
ジャンル : コンピュータ

Keyword : ブロックチェーン Browser-Solidity Solidity Ethereum イーサリアム 仮想通貨

Solidityの仕様のまとめ(データ型、単位換算、グローバル変数)

どうも、ぺろりんです。


今日も今日とて、ちょっとずつですが「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門」を読み進めていきます。

今回はCHAPTER3-4で、Solidityのざっくりとした仕様説明みたいな章なので、ここでの知識をメモとしてまとめておきます。


Solidityで使えるデータ型

Solidityでは以下のデータ型が使えます。
小数点を扱えるデータ型、日付型もないというのは注意しないといけないですね。

カッコの中には「値型」か「参照型」[注1]の分類を記載しています。


ブーリアン(bool:値型)

・true(真)かfalse(偽)の値をとる。
・使える演算子は「!(not)」、「&&(and)」、「||(or)」、「==(equal)」、「!=(not equal)」。
・andとorは短絡評価[注2]


整数(int、uint:値型)

・符号付の「int」、符号なしの「uint」がある。
・8~256の、ビット数が8の倍数長の型がある(例:int8、uint256)。数字を省略すると256になる。
・使える演算子は比較演算子(<=、<、==、!=、>=、>)、ビット演算子(&:and、|:or、^:xor、~:not)、算術演算子(+、-、*、/、剰余:%、累乗:**、左シフト:<<、右シフト:>>)。


アドレス(address:値型)

・20倍とのアドレスを格納する。
・初期値は0x000…00(16進数で20倍となので、0が40個)。
・使える演算子は比較演算子(<=、<、==、!=、>=、>)。
・使えるメソッドは所有ETHの確認:<アドレス値>.balance、ETHの送金(失敗時はなかったことになる):<address>.transfer(uint256 <送金量>)、ETHの送金(失敗時はfalseを返す):<address>.send(uint256 <送金量>)returns(bool)、gas指定で送金(失敗時はfalseを返す):<address>.call.value(uint256 <送金量>).gas(uint256 <ガスの値>)returns(bool)。


配列(Arrays:参照型)

・固定長:<配列名>[<長さ>]、可変長:<配列名>[] がある。
・配列の要素は0番目からスタート。
・使えるメソッドは配列の長さ確認:<配列名>.length、配列の最後に要素を追加:<配列名>.push(<追加する要素の値>)。


文字列(string:参照型)

・文字列の比較はできない。keccak256()という関数でハッシュ値に変換することで比較できる。
・最大長は256bit?

(参考)
Solidity言語メモ(Qitta)
【Solidity基礎】型の種類(ブロックチェーンエンジニアとして生きる)
Ethereum Solidityの型(block-chain.jp)


構造体(Structs:参照型)

・構造体[注3]は以下の書式で宣言。

struct <構造体名>{
<データ型> <変数名>;
<データ型> <変数名>;

}

・直接構造体自体の値は返せないので、<対象構造体の配列名>[<要素番号>].<構造体中の変数名>の形で値を取得する。


マッピング(mapping:参照型)

・連想配列。値を呼び出すキーとなる名前を付ける。
・mapping(<キーのデータ型>=><呼び出したい値のデータ型>)の形式で宣言する。


単位換算

仮想通貨Etherの単位

Ethereumの単位はwei、szabo、finny、etherとある。
・以下の書式で単位換算できる。

<換算後の量> = <換算したい元の量> / 1 <単位>



時間の単位

・使える単位は、seconds(秒)、minutes(分)、hours(時)、days(日)、weeks(週)、years(年:= 365days)
・以下の書式で単位換算できる。

<換算後の量> = <換算したい元の量> / 1 <単位>



グローバル変数

ここはまだイマイチ使い方がわからないので写経します。

・block.blockhash(unit blockNumber):指定ブロックのハッシュを返す。
・block.coinbase:カレントブロックのマイナーのアドレスを返す。
・block.number:カレントブロックの番号を返す。
・block.timestamp:カレントブロックのタイムスタンプを返す。
・msg.sender:送信者のアドレスを返す。
・msg.value:送金額を返す。
・now:block.timestampのエイリアス。


まとめ

今回はSolidityの仕様に関しての知識が書いているパートだったので、動きを見るよりも、勉強ノート的な感じでメモとしてまとめておきました。
こうやってデータで残しておくと、あとで検索できて便利かなと。。


[注1] 値型、参照型…値型は値そのものが入るが、参照型は値のアドレスが入る。
[注2] 短絡評価…「A || B」の真理値がAのみで決まるときにBは考慮されない、というような評価。たとえば、A=trueの場合、Bがtrueでもfalseでも(A || B)はtrueなので、Bは評価されない。
[注3] 構造体…複数の型のデータから構成されるデータ構造。

テーマ : プログラミング
ジャンル : コンピュータ

Keyword : ブロックチェーン Browser-Solidity Solidity Ethereum イーサリアム

Browser-Solidity(Remix)でEthereumを送金してみる

どうも、ぺろりんです。

今回は、オンライン上で使用するBrowser-Solidity(Remix)でEthereumを送金してみます。

やり方は、いつも通り「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門」を参照しながらやってみます。

ただしすこし教科書と環境が違うので、そのへんは探り探りです。
環境に関してはこちらこちらの記事をご覧ください。


Browser-Solidity(Remix)でのEthereum送金

送金確認コントラクトのデプロイ

まずは教科書にあるコードをそのまま使わせてもらい、コンパイルしてみます。


「function ()」の後ろに「public」がないと警告が出るので、ここで使っている教科書をお使いの方はご注意ください。
これは「Solidity環境の準備で手こずっている話」の内容を参照のこと。

ただ、実はこれでも以下の警告が出ます。。
Static Analysis raised 1 warning(s) that requires your attention. Click here to show the warning(s).


この警告のリンクを見に行くと以下の内容が表示されるのですが、このままやっても動きそうなので、ひとまずここでは無視して進むことにします。
Fallback function of contract RecvEther requires too much gas (40541). If the fallback function requires more than 2300 gas, the contract cannot receive Ether.


コンパイルしたのでデプロイしたいのですが、その前にアカウントのアドレスを確認してみましょう。
Run>Accountの横にあるアイコンをクリックしてアドレスをコピーします。
内容をメモ帳に出したのが次の画像です。


さて、デプロイしてみます。



先ほどコピーしたアカウントのアドレスとデプロイ後の情報を比べてみると、fromのところに先ほどのアドレスがあります。


Account部分に戻ってみると、先ほどは「100 ether」だった部分の値が「100」から減っていることがわかります。


まだ送金するETHの指定はしていなかったので、デプロイ時にgasを支払っている分が引かれてるってことかな……?


ためしに 1[wei] を送金してみる

次はRun>Valueに「1 wei」を指定して、右下の「RecvEther」を開いて「(fallback)」を押してみます。




この時点で「recvEther」と「sender」を押すとこんな内容になります。
「recvEther」の値の1ってのを見ると、「recvEther」にETHが送られた感があります。




また、Run>Accountのところの値もさっきより減っています。



別アカウントから 1[wei] を送金してみる

今度はRun>Accountでアカウントを変更して、別のアカウントから 1[wei] 送金してみましょう。




ちゃんとアカウントからもETHが減っています。


……ただし計算が合ってるのかがわからないw
たぶん送金で指定した 1[wei] と、「transaction cost」とか「execution cost」あたりが消費されてそうな気がするんですが、gas priceがわからなくて計算できない。。(「gas price」についてはこちらを参照)

右下の「recvEther」も見てみましょう。今度は「2」になっています。
教科書にも書いている通り、ここは[wei]単位で出るようです。




「recvEther」のところの「0:」は、下の「sender」にある「address」と紐づいているのかな……??

一応確認してみると、初めに選んでいたアカウントのETHは特に減っていませんでした。


こんな感じで、とりあえず送金はうまくできました。


まとめ

今回は、送金確認用のコントラクトをデプロイして、(たぶんそのコントラクトに向けて?)ETHを送金してみました。
アカウントを変更して送金することもやってみて、ちゃんと選んだアカウントから送金着にETHが減っているところも確認できました。

徐々にではありますが、一応なりともBrowser-Solidity(Remix)の基本的な動きが見れてきた気がします。

ではまた次回へ。

テーマ : プログラミング
ジャンル : コンピュータ

Keyword : ブロックチェーン Ethereum イーサリアム Solidity Browser-Solidity

Browser-Solidity(Remi)で既存コントラクトにアクセスしてみる

どうも、ぺろりんです。

前回は、かなり手こずりながらもオンライン版のBrowser-Solidity(Remix)をなんとか動かすことができました。

この環境の使い方を知るために、もう少しいじってみようかと思います。

ひとまず、教科書として使っている「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門」でやっている「既存コントラクトへのアクセス」をやるのが今回の目標です。

つまづきながらも一応は目標を達成したので、その紆余曲折をおたのしみくださいw


既存コントラクトへのアクセス

既存コントラクトの作成と警告の対処

既存コントラクトにアクセスするための事前準備として、まずは前回と同じ要領で、アクセス先のコントラクトとして1つコントラクトを作ってみましょう。

……というわけでブラウザのキャッシュを消して前回と同じことをやってみたら、また別の警告が!


警告内容は以下のようなものです。
browser/sample.sol:6:2: Warning: Defining constructors as functions with the same name as the contract is deprecated. Use "constructor(...) { ... }" instead.
function HelloWorld(string _greeting) public {
^ (Relevant source part starts here and spans across multiple lines).


ググってみると、どうも上の画像にある記法は非推奨だとか。
参考サイトによれば、コントラクトと同じ名前の関数名でコントラクタを定義するのはだめで、constructorと書きなさいってことみたいです。

まだコンストラクタなどがよくわかってないですが、やってみるとうまくいきました。


ためしにデプロイしてsetGreetingに文字を入れ、greetingとかsayとかをポチポチ押してみます。


とりあえずうまくいったっぽい……。

これでアクセス先のコントラクトは用意できました。

(参考)
Ethereum: Solidity v0.4.23〜 の新しいコンストラクタの書き方(Qiitta)


既存コントラクトにアクセスしてみる

さて、教科書と微妙に違う環境で教科書通りに進もうとしてるので探り探りですが、次は既存コントラクトにアクセスしてみます。

既存コントラクトにアクセスするためには、アクセス先の既存コントラクトのアドレスを知る必要があります。

まずコントラクトアドレスってどれだってことで、半分勘に頼りながら探ってみます。。
同じHelloWorldさんをもう一つデプロイして、別の文字「へろー」をsetGreetingに入れたものを作ってみました。


先ほどの図の右下の赤枠で、いかにもこの2つ目(setGreetingに「へろー」と入れた方)のアドレスをコピーできそうなところがあります。
で、プロンプト的な画面のなかで、こいつをデプロイした行がどれかと探るわけですが、「creation of HelloWorld pending...」というデプロイ中っぽい行の後に、「HelloWorld」の文字が。
三角マークを押して開いてみて、「contractAddress」にある値と、先ほど右下の赤枠でコピーした内容(上の画像のメモ帳参照)を比べてみると一致します。

なのでまぁ、、さっきの右下の赤枠でコピーできるのが、その時デプロイしたコントラクトのアドレスっぽいかな、という予想のもとすすんでみます。

先ほどは2つ目のコントラクトアドレスを見ていましたが、今度は3つ目のHelloWorldをデプロイして1つ目のコントラクト(HelloWorld)にアクセスすることを目指してみます。

例によって、1つ目のHelloWorld(setGreetingに「Helloはろー」と入れた方)で、コントラクトアドレスをコピーします。


ここでコピーした内容を、Deployボタンの下にあるボックスにペーストして、「At Address」ボタンを押してみます。


「At Address」を押して出てきた(デプロイされた)3つ目のHelloWorldで、setGreetingに“何も入力せず”にgreetingとsayを押してみます。
すると、1つ目のHelloWorldでsetGreetingにあった「Helloはろー」というのが出てきました。


これで、既存コントラクトへのアクセスができた……気がしますw


まとめ

今回は、Browser-Solidity(Remix)をオンライン上で使い、あらかじめデプロイしたコントラクトに(紆余曲折のすえ)アクセスする(既存コントラクトへのアクセス)ということをやってみました。

既存コントラクトの準備中「Defining constructors as functions with the same name as the contract is deprecated.」という警告に出くわしたので、その対処もしました。

一応なりとも目標だった「既存コントラクトへのアクセス」はできましたが、だいぶのんびり進んでいますねw
まぁまったりとやっていきます。では今回はこのへんで。
また次回~。

テーマ : プログラミング
ジャンル : コンピュータ

Keyword : ブロックチェーン Browser-Solidity Solidity Ethereum イーサリアム

プロフィール

ぺろりん

Author:ぺろりん
最近仮想通貨が楽しくなってきました。
基本的な技術をちゃんと知りたいなぁと思いつつ、まったりお勉強していこうかと思います。

twitter:ぺろりん@ぶろっくちぇーん

カテゴリ
最新記事
最新コメント
月別アーカイブ
カレンダー
10 | 2018/11 | 12
- - - - 1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 -
検索フォーム
RSSリンクの表示
リンク
ブロとも申請フォーム

この人とブロともになる

QRコード
QR
メールフォーム

名前:
メール:
件名:
本文: