fc2ブログ

日本の仮想通貨ビジネスがヤバイ

どうも、ぺろりんです。

イケハヤさんのVoicyに触発されてここでも最近の仮想通貨業界について触れてみます。

イケハヤさんによると、最近の日本政府による仮想通貨業界(特に仮想通貨取引所)に対する規制がナンセンスかつ厳しく、これのせいでビジネスが成り立たなくなるのが見えていて、日本の仮想通貨ブロックチェーンはお先まっくらだという感じの主張でした。

お恥ずかしながらこれを聴くまで認知していなかったのですが、特にSBIの仮想通貨取引所では日本円しか入出金できないという話が衝撃的でした。

このへんを含めての感想と、個人的な展望としてポジティブなアイディアを書いてみようかと思います。


感想的な

マジかよと思ってSBIバーチャル・カレンシーズの公式ページを見てみたら、たしかに「※仮想通貨の入金・出金はお受けしておりません。」と書いてありました。

以前仮想通貨の普及について考えてみた記事で、「仮想通貨の銀行が出現する」というような書き方をしましたが、入出金が日本円だけってのは斜め上だけどある意味これなのかな……?w

SBIバーチャル・カレンシーズがSBI証券の延長線上にあるだけだと考えると、証券会社が金融商品の1つとして仮想通貨を扱っているようにも見えるかなと。
とは言え、やっぱり「仮想通貨取引所と言いながら仮想通貨自体の入出金ができない」のはコレジャナイ感がありますね。

イケハヤさんの言うように日本の行政がこの方向性で仮想通貨を取引させようとしているのも大いにありそうなことだと思います。
ただ私としては、SBIバーチャル・カレンシーズは「政府の許可を得る第1段階の妥協点として」これだけの縛りのもとでサービスをリリースしたのであって、今後これを広げて仮想通貨自体の入出金ができるようにする構想があると期待したいです。

保守的になりがちな大きな企業の中で、先陣を切って仮想通貨取引所を立ち上げるというリテラシーがあるのだから、仮想通貨自体の入出金ができない現状には不満があるんじゃないかと思うのはやや楽観的でしょうか。


今後の日本で仮想通貨業界が死なないためには?

私が思いつく意見としては、次の2点です。
(1) 仮想通貨決済できるコンテンツを増やす。
(2) 仮想通貨両替所を運営する。

(1) 仮想通貨決済できるコンテンツを増やす。

ビックカメラなどのビットコイン決済できる店舗が増加していった社会的背景から、「仮想通貨」が「通貨」として認められ、2017年7月に仮想通貨決済での消費税が撤廃されました。

このように、社会的な要請が強くなればそれに応じてルールも変えていく必要があります。

ここから学べることとしては、どんどんいろんなコンテンツで仮想通貨決済が導入されることで、「日本円を介さないと目的の仮想通貨を持てない状況の不便さ」を社会全体で感じるようになれば、縛りの強いルールは緩めざるを得ないようになるのではないでしょうか。

仮想通貨を盛り上げたい側からすればその有用性を説いて認知を広めていき、どんどんいろんなところに導入してもらう。
これが肝要なわけです。
そのためには技術的な発展はもちろん必要ですし、また発信者はあきらめずに発信した方がいい。

僭越ながら、自分も勉強を続けて理解を深め、有用性を発信できるように努めたいところです。

(参考)
消費税法等の改正(財務省)
教えて!仮想通貨法(bitFlyer)
ビットコインなどの仮想通貨の消費税が変わります!(やまばた税理士事務所)
ビットコイン(Wikipedia)
ビットコインが使える店舗はどこ?決済導入が続々と増えている理由は決済手数料の安さ!(カシコク)
ビックカメラが「ビットコイン」決済を導入した理由(ITmedia Mobile)
ビットコインの歴史-これまでの歴史を時系列ごとにピックアップ(QUOINEX)
【仮想通貨決済】主要交換業者の企業・サービスにおけるビットコイン決済など連携まとめ(bitpress)


(2) 仮想通貨両替所を運営する。

SBIの仮想通貨取引所では「日本円しか入出金できない」わけですが、このような扱いが主流になったとすると仮想通貨自体を入手するのが難しくなるのかな、とわりと心配に思っていたりします。

(1)とも関わりますが、仮想通貨自体が必要なのに仮想通貨自体は扱えないのは不便で、ではどうするかというと、仮想通貨と日本円の両替所は必要になるのではと思うわけです。

極端ですが、仮にすべての取引所がSBIのようになった場合を考えると、個人的には次のようなことな心配です。

仮想通貨Aを持っているXさんが、あるコンテンツで決済するのに仮想通貨Bが必要とします。
しかし、日本の取引所では入出金がどちらも日本円しかあり得ないために「Xさんは仮想通貨Bを持てず目的のコンテンツの決済ができない」という状況になるのではと。

こんな感じで仮想通貨が入手困難になると、仮想通貨決済は全然使えなくなります。
SBIの場合だとビットコインすら出金できないですし。
この状況だとまさしく仮想通貨が死んでいく……。

分散型取引所(DEX)というのもありますが、これが大衆に浸透するには難易度が高いように思えます。

ではどうするかと考えると、仮想通貨取引所ではなく、仮想通貨「両替所」がちゃんとあれば良いのかなと。
私の言いたい「両替所」は現在の言葉遣いだと「販売所」にあたるのかな……?

coincheckなど販売所業も行っている取引所はありますが、「取引所はやらずに両替所だけやる」という選択肢にすることで、取引所と両方やるよりも「行政が納得するセキュリティ担保」の難易度が下がる可能性があるのでは、と考えている次第です。

いずれにしろ、仮想通貨決済が広まることと仮想通貨間の両替ができることは切っても切れないでしょうし、仮想通貨決済自体を殺すのでない限りは必要なことだと思われます。

(参考)
分散型取引所(DEX)とは?/中央集権型取引所との違いについて解説(CoinPost)
分散型取引所(DEX)とは?絶対理解しておくべき次世代型の取引所! (CoinOtaku)


まとめ

日本の仮想通貨業界がどんどんシュリンクしそうな流れになっている話をしました。

その中で、今後の日本で仮想通貨業界が死なないために必要な流れとして、私なりの考えとして以下2点をご紹介しました。
(1) 仮想通貨決済できるコンテンツを増やす。
(2) 仮想通貨両替所を運営する。

強調しておきたいのは、(1)のところで触れましたが、やっぱり発信できる人はあきらめずに仮想通貨の有用性を発信した方がいいと思う、というところです。
メリットだけを強調してズッコケるような発信はむしろダメだと思いますが、行政のルールを緩めるにはやっぱり社会的な要請が強力で、社会的に要請されるようになるにはまず有用性の認知が必要と考えています。

なので、仮想通貨に有用性とか面白さを感じる発信者は、日本の市場から「仮想通貨」という言葉が消えるまではあきらめずに発信するのがいいのかな、というのが今回のメッセージです。

テーマ : 仮想通貨
ジャンル : 株式・投資・マネー

Keyword : 仮想通貨ビットコインブロックチェーン仮想通貨取引所SBIバーチャル・カレンシーズ

Solidity環境の準備で手こずっている話

どうも、ぺろりんです。

前回のつづきとして、「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」3章に入ってスマートコントラクトの開発環境として「Solidity」という言語の環境を整えようとしているんですが、案の定(笑)なかなか上手くいかず詰まりました。

さしあたっての妥協案として「Browser-Solidityをオンラインで使う」という方法が一応は上手くいきそうになってきたので、またすぐ詰まりそうだという不安は置いておいて、環境としてはしばらくこの方向で進んで行きたいかと思います。
ダメそうだったらまた考えますw

というわけで今回は、まずどんな感じで詰まっていたかという話と、「Browser-Solidityをオンラインで使う」やり方をここにまとめておきます。
Solidityの使い方に関しては、たぶんよくご存知の方からするとそれじゃダメだろってとこがあるのではと思っているので、そういう感想の方はぜひともメールフォームからご連絡いただけると非常に助かります。。


上手くいかないところ

理解が浅すぎてだいぶ色々問題が起こっていますw
棚卸ししてみるとだいたいこんな感じです。

コンパイルできない話

まず初めにやったのが、前回まで使っていたVM(仮想マシン)の環境で、いつもの教科書通りにSolidityのコンパイラをインストールしました。

で、本にある「Gethにsolcのパスをセット」するところまでは上手くいきました。

しかし、この次のコンパイルするところが上手くいかない。。
> sourceCompiled = eth.compile.solidity(source)


メモり損ねて記憶があいまいですが、たしか参考に挙げたリンク先にある以下のエラーが出てた気がします。
Error: The method eth_getCompilers does not exist/is not available
at web3.js:3104:20
at web3.js:6191:15
at web3.js:5004:36
at :1:1


教科書の注意書きで、Gethのバージョンが1.6以降はコンパイルが上手くいかないと書いているのですが、この本ではGethをインストールするときにv1.5.5にバージョンを切り替えていて、この通りにやっているのでコンパイルも上手くいくかと思っていたのですが、ちょっとよくわからない。

これだと上手くいきそうにないのと、教科書の先を見るとBrowser-Solidityを使っていたので、Browser-Solidityが出てくるあたりまでスキップしてこの環境を整えることにしました。

(参考)
go-ethereum(geth)でSolidityのコンパイルが出来ない場合(Qiita)


Browser-Solidityをローカルで上手く使えない話

さて、ここでも教科書べったりでやってみたのですが、まずはVM環境ではなく、VM Playerを載せているWindows 10でBrowser-Solidityをインストールしてみました。

が、「Environment」で「Web3 Provider」を選ぶところで無事死亡w



理解が浅いまま進んでいるのが原因ですが、「Web3 Provider Endpoint」がよくわからん。
どのIPアドレスを設定すべきかよくわからず、とりあえずlocalhostにしてみるも上手くいかず。


このあと「172.0.0.1」を試してみるも、やっぱりダメ。

参考に挙げたリンク先に「go-ethereum/gethがOS上にインストール済みであることを前提にしています。」と書いてあるのを見かけて、gethをインストールしたVM Player上のLinux(Ubuntu)ではなく、その外の(gethをインストールしていない)Windows 10でやっていたので「デスヨネー」となりました。

というわけで、VM Player上のLinux(Ubuntu)で再度同じことをやってみることにしました。

(参考)
Etherum Browser-Solidityを利用したコントラクト開発・デプロイ・実行(Qiita)


VMを作り直したらgethをビルドできない話

VM Player上のLinux(Ubuntu)でやろうとしたら、Browser-Solidityをデフォルトで入っているFirefoxで開くと固まる……w
Firefoxだと重いのかなーと、Chromeを入れて試してみることに。

すると、Chromeさんがインストールできない!
色々試した結果、最新バージョン(今回はv18.04で、以前のは過去記事を見るとv16.04)のUbuntuで仮想マシンを作り直してみたら、Chromeのインストールはできました。
ついでに言うとVM Ware Toolsも上手く入らない……(こっちはVM Playerのバージョンの問題……?)

仮想マシンを作り直してしまったので再度Geth環境を整えて、その上でBrowser-Solidityをインストールする必要があります。

なのでGethをまたインストールしました。
ところが!今度は「make geth」でビルドできないw
(VM Ware Toolsが上手くいってないせいでゲストOSとの間でコピペができないっぽいため画像で)


Go言語のバージョンが低いと怒られている感じがするんですが、実際バージョン確認するとこんな感じ。


これだけ見ると1.10みたいにも見えるんですが、「.」の後ろは「じゅう」ではなくて「いちぜろ」なのかな……?

というわけでGo言語のバージョンを変えたいんですが、この辺の扱いが不慣れすぎてまったく上手くできず(;´Д`)
これは参考リンクあたりを見ながら上手くいかないかなぁ。

ひとまず、仕方ないので代替案として、オンライン上でBrowser-Solidityを動かしてみることにしました。

(参考)
PINE64(Ethereumのマイニング、geth導入成功)(ねこめも)


Browser-Solidityをオンラインで使う

これはようやく上手くいきました(少なくとも、目的のコードが動いた)。
そんなわけで、途中のトラブルシューティングをはさみつつ、上手くいったところまでの手順を書いておきます。

まず、Browser-Solidity (Remix) のページに行きます。


とりあえずデフォルトで入っているballot.solはいらないのでファイル名横の「×」ボタンで消して、「+」ボタンからSample.solという名前のファイルを作ってみます。




ためしに教科書に載っていたテストコードを入れてコンパイルしてみます。


このままコンパイルすると、警告が4つ出てきます。


内容としては次の2種類です。
Static Analysis raised 3 warning(s) that requires your attention.

browser/Sample.sol:<何行目か>:<何文字目か>: Warning: No visibility specified. Defaulting to "public".
function <関数名>(<引数>){
^
Spanning multiple lines.


警告は出ていてもデプロイはできるようですが、気持ち悪いので対応したいところ。
調べてみると、「Warning: No visibility specified.」の方はどうも「visibility」という設定がないと警告が出るようです。(エラー内容そのままですが)

よくわからないままですが、調べた先の情報を参考に「visibility」として「public」(入れる位置は画像の位置が正しそう)というのを入れて再度コンパイル。
3つあった「Warning: No visibility specified.」という警告は消えましたが、残り1つが消えない。。


内容的に、「Warning: No visibility specified.」が消えたら消えるのかと思ったのですが。
これもよくわからないのでいったん放置。


「Run」タブの「Environment」で「JavaScript VM」を選びます。
これを選ぶことで、オンライン上で仮想環境を作ってデプロイできるようです。


「Deploy」を押してみます。



この状態でデプロイ成功みたいです。


下のプロンプトを見てみると(エディタ部分との境目くらいに広げるための矢印が出てくる)、contractAddress とかが割り当てられていることがわかります。(左の三角を押すと詳細が見られます)





文字入力部分に「"Hello, World!"」(「"」は必須のようです)を入れて「setGreeting」を押すと、プロンプトのところがさらに進みます。



「greeting」と「say」も押してやると、プロンプトにもこいつらに関する処理結果が返されて、「greeting」と「say」のところにも「Hello, World!」が出てきます。



ここまでで、場当たり的(というか力ずく?)にではありますが、一応は教科書にあるコードをBrowser-Solidity上で動かせました。

(参考)
手軽に“Solidity”言語でスマートコントラクト開発、開発環境「Remix」ってどう使う?(@IT)
Ethereum のスマートコントラクト実行環境を整える(Qiita)
【堅牢なスマートコントラクト開発のためのブロックチェーン】エラー改善メモ”No visibility specified. Defaulting to “public”.”(ICG -I can't graduate-)
Remixとbrowser-solidityの使い方(たったひとりのIT事業部。)


まとめ

紆余曲折のすえ、さしあたりローカルのオフライン環境でSolidityを使うことはあきらめ、オンライン上でBrowser-Solidityを使って勉強を続けることにしました。
オンライン上でVM環境を動かすには、Browser-Solidityの「Run」タブにある「Environment」で「JavaScript VM」を選べばいけそうです。

この環境でできそうなところを、前回のつづきとして、「はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」に沿ってすすんでみたいと思います。
またすぐ詰まりそうな気がしますが……w

Solidityの公式ドキュメントも読みつつちゃんとできるといいな。。

次回は「既存コントラクトへのアクセス」をBrowser-Solidity(Remix)からやってみます。

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

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

Ethereumテストネットワークで送金してみる(続き)

どうも、ぺろりんです。

はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」のつづきです。

前回はアカウント0からアカウント1へEthereumを送金してみました。
今回は、coinbase(=アカウント0)ではないアカウントから送金することで、手数料が発生する動きを見てみます。


Ethereumの送金手数料

送金にはGasという手数料がかかるのでした。

前回の送金ではcoinbaseであるアカウント0から送金したため実質的に見えなかったのですが、実際にはトランザクションの実行にはGasという手数料がかかっています。

たとえばcoinbaseではないアカウント1からアカウント2へ5[ETH]を送金してから2つのアカウントで残高確認してみると、こんな結果になりました。
> web3.fromWei(eth.getBalance(eth.accounts[1]),"ether")

4.99958
> web3.fromWei(eth.getBalance(eth.accounts[2]),"ether")

5

これを見ると、送り先のアカウント2には5[ETH]が確かに届いていますが、送り主のアカウント1に残っているのは5(=10-5)[ETH]よりも少ないです。

アカウント0の残高を見てると、この減った0.00042[ETH]はcoinbase(=アカウント0)に報酬として支払われていることが分かります。
> web3.fromWei(eth.getBalance(eth.accounts[0]),"ether")
1065.00042


「eth.getTransaction」と「eth.getBlock」というコマンドを使ってみると、手数料がどうなったか見えてきます。
というわけで、これらのコマンドを見てみましょう。

いちおう復習しておくと、前回と同じくアカウントをアンロックして「eth.sendTransaction」を実行して出てくるトランザクションIDを引数にして、まず「eth.getTransaction」を見るとこんな感じ。
> eth.getTransaction("0xdb06571f2f55e5adf9fd9949d81bef7385ddfdf73258b7e90de9312e5b3bb17c")
{
blockHash: "0xd401634e5373f73507f93658798a2204180b7018145ccc40c1951a15c8e29d7d",
blockNumber: 210,
from: "0x3a8e6c0304c761b88feeefb5cdefe27ced28d620",
gas: 90000,
gasPrice: 20000000000,
hash: "0xdb06571f2f55e5adf9fd9949d81bef7385ddfdf73258b7e90de9312e5b3bb17c",
input: "0x",
nonce: 0,
r: "0xf18b45285396c04ead1f4e7ed318df6e398f626fb5b0150e8d4f56e80c6ad735",
s: "0x61e82c4d16863c8186884ed09ecdd1974a8f7d8a5ecefd9758991aedd6bab86a",
to: "0xecac305a22ac002107cdac420e24042d430bcb26",
transactionIndex: 0,
v: "0x1b",
value: 5000000000000000000
}


さらに、ここで出てきたblockNumberの210を引数にしてブロックを見るとこんな内容になっています。
> eth.getBlock(210)
{
difficulty: 141844,
extraData: "0xd783010505846765746887676f312e362e32856c696e7578",
gasLimit: 109320930,
gasUsed: 21000,
hash: "0xd401634e5373f73507f93658798a2204180b7018145ccc40c1951a15c8e29d7d",
logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
miner: "0x8ade49123c81461e676fd2f8f2eb31885cdb07e0",
mixHash: "0x77f99c1901f72d3eaad2f5aea85dce821471f8d23a1f1f7e92853cc04d116417",
nonce: "0x3671259b945c8662",
number: 210,
parentHash: "0x0cd16490e3ceba375792cffd22f9ed4b4eecd6712485820f47ed04456de0fc66",
receiptsRoot: "0x895e49c7c281cdf956cd75f726596d7d3e7b68a9f08b462dfb1469ede1d2f812",
sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
size: 651,
stateRoot: "0x369a09f8fbb36aa7a7010f16bb8643cfda6dad78d861696cc5647939f38088a7",
timestamp: 1528018266,
totalDifficulty: 28692719,
transactions: ["0xdb06571f2f55e5adf9fd9949d81bef7385ddfdf73258b7e90de9312e5b3bb17c"],
transactionsRoot: "0x64f4d635547183f729941c809ba518280f8d426e8fdf509d392eb7f5d87f7f7f",
uncles: []
}


ここで注目するのは以下の2つです。
・「eth.getTransaction」の「gasPrice」
・「eth.getBlock」の「gasUsed」

以前お勉強したように、gasPriceというのが1Gasあたりの値段[wei]でした。
上述したコマンドの結果から、今はこれが20000000000[wei]とわかります。
で、使用されたGasが何[Gas]かというのは「gasUsed」で分かり、今は21000[Gas]と読み取れます。
(「eth.getTransaction」の「gas」は支払い可能な最大Gasを表す)

なので結局、手数料として
 gasPrice×gasUsed=20000000000[wei/Gas]×21000[Gas]
 =420000000000000[wei]=0.00042[ETH]
が支払われることになって、先ほどアカウントの残高を確認したときにアカウント1からcoinbase(=アカウント0)に移った0.00042[ETH]と一致します。

アカウント0から他のアカウントに送金したときには支払元のアカウント0は(今の場合)coinbaseなので、「手数料は支払元から引かれる」ことと、「手数料はcoinbaseに支払われる」ことから、自分から引いた手数料を自分が報酬としてもらうことになって、結果として差引0になります。
…というのが前回やったアカウント0からの送金でした。


まとめ

今回は、アカウント間の送金で、Gasと名付けられた手数料が送金元の残高から引かれ、coinbaseアカウントに報酬として支払われる動きを見ました。

送金元がcoinbaseの場合には、自分で払って自分がもらうため、実質手数料がかかってないようになっているのが前回の状況でした。

今回見たのはこんな感じです。

Ethereumテストネットワークで送金してみる

どうも、ぺろりんです。

はじめてのブロックチェーン・アプリケーション Ethereumによるスマートコントラクト開発入門 (DEV Engineer's Books)」でのお勉強のつづきで、今回はテストネットで送金してみます。
あと、途中で出てきたコマンド(eth.getTransaction)の出力についてちょっと調べています。

前回はアカウントを作ってマイニングしたのでした。

送金は
 送金元アカウントのロック解除→送金→マイニング
という手順でやっていきます。

ではやってみましょう。


テストネットでのEthereum送金

送金元アカウントのロック解除

まずはアカウントのロック解除をする必要があります。
アンロックせずに送金コマンドをたたくと、こんな感じで怒られます。
> eth.sendTransaction({from: eth.accounts[0], to: eth.accounts[1], value: web3.toWei(10, "ether")})
Error: account is locked
at web3.js:3119:20
at web3.js:6023:15
at web3.js:4995:36
at :1:1


教科書によると、トランザクション発行が有料なので、誤送金を防ぐためデフォルトでは送金できないようにロックされているそうです。
アンロックには「personal.unlockAccount(〈ロック解除したいアカウント〉,〈パスフレーズ〉,〈アンロック有効時間(秒)〉)」コマンドを使います。
引数のパスフレーズとアンロック有効時間は省略可能です。
アンロック有効時間を「0」にするとそのGethプロセス起動中ずっとアンロック状態になります。

たとえば、「アカウント0を100秒アンロックする」という内容をやってみるとこんな感じ。
> personal.unlockAccount(eth.accounts[0],"pass0",100)
true



送金

ロックが解除できたので、「eth.sendTransaction」コマンドで送金してみましょう。
引数は、
 from:送金元アドレス
 to:送金先アドレス
 value:送金額[wei]
を指定します。

アカウント0からアカウント1に10[ETH]送金すると、プロンプトにトランザクションIDか返されます。
> eth.sendTransaction({from: eth.accounts[0], to: eth.accounts[1], value: web3.toWei(10, "ether")})
"0xc0d2389ef187b3d6b5d88c88f301ab6ccac16a4439d38e4102a8c8c473f316d0"


送金トランザクションの発効後にマイニングしておらず、まだブロックが生成されていないため、この時点では今しがた送金したトランザクションを含むブロックがありません。
なので、まだ送金が完了しておらず、アカウント1の中身は0のままです。
> eth.getBalance(eth.accounts[1])
0


この状態でさきほど送金時に返ってきたトランザクションIDを入れてトランザクションの内容を確認してみると、実際、ブロック番号(blockNumber)がnullになっています。
> eth.getTransaction("0xc0d2389ef187b3d6b5d88c88f301ab6ccac16a4439d38e4102a8c8c473f316d0")
{
blockHash: "0x0000000000000000000000000000000000000000000000000000000000000000",
blockNumber: null,
from: "0x8ade49123c81461e676fd2f8f2eb31885cdb07e0",
gas: 90000,
gasPrice: 20000000000,
hash: "0xc0d2389ef187b3d6b5d88c88f301ab6ccac16a4439d38e4102a8c8c473f316d0",
input: "0x",
nonce: 0,
r: "0xc0a41f36a050c8ea2e2b2ccd6b85a749b40c1dc375c907340231b16d76b23a7f",
s: "0xa74113934ecf97130083a377728534ec8a1c7917e098f69e6fa8bb082ed7040",
to: "0x3a8e6c0304c761b88feeefb5cdefe27ced28d620",
transactionIndex: null,
v: "0x1c",
value: 10000000000000000000
}



マイニング

マイニングしてブロックを生成し、上でやった送金を完了させましょう。
マイニングはminer.start(〈マイニングするスレッド数〉)で始めるのでした。
> miner.start(1)
true


マイニング開始からしばらくは、「eth.pendingTransactions」で保留中のトランザクションを見てみると先ほど送金しようとしたものが出てきます。
> eth.pendingTransactions

[{
blockHash: null,
blockNumber: null,
from: "0x8ade49123c81461e676fd2f8f2eb31885cdb07e0",
gas: 90000,
gasPrice: 20000000000,
hash: "0xc0d2389ef187b3d6b5d88c88f301ab6ccac16a4439d38e4102a8c8c473f316d0",
input: "0x",
nonce: 0,
r: "0xc0a41f36a050c8ea2e2b2ccd6b85a749b40c1dc375c907340231b16d76b23a7f",
s: "0xa74113934ecf97130083a377728534ec8a1c7917e098f69e6fa8bb082ed7040",
to: "0x3a8e6c0304c761b88feeefb5cdefe27ced28d620",
transactionIndex: null,
v: "0x1c",
value: 10000000000000000000
}]


しばらくマイニングを続けながら「eth.pendingTransactions」を連打していると、そのうち結果が空になります。
この時点でマイニングをやめてOKです(やめるのは「miner.stop()」コマンドでした)。
> eth.pendingTransactions
[]



送金確認

先ほど送金したトランザクションIDの内容を見てみましょう。
今度はブロック番号(197)が発番されています。
> eth.getTransaction("0xc0d2389ef187b3d6b5d88c88f301ab6ccac16a4439d38e4102a8c8c473f316d0")
{
blockHash: "0x3ea566f775e49f4f58c7932713042b511ac60ecb9469b3d0558ab3663723eeba",
blockNumber: 197,
from: "0x8ade49123c81461e676fd2f8f2eb31885cdb07e0",
gas: 90000,
gasPrice: 20000000000,
hash: "0xc0d2389ef187b3d6b5d88c88f301ab6ccac16a4439d38e4102a8c8c473f316d0",
input: "0x",
nonce: 0,
r: "0xc0a41f36a050c8ea2e2b2ccd6b85a749b40c1dc375c907340231b16d76b23a7f",
s: "0xa74113934ecf97130083a377728534ec8a1c7917e098f69e6fa8bb082ed7040",
to: "0x3a8e6c0304c761b88feeefb5cdefe27ced28d620",
transactionIndex: 0,
v: "0x1c",
value: 10000000000000000000
}


fromに送金元、toに送金先、valueに10[ETH]=10000000000000000000[wei]が入っています。(r,s,vにつては後述)
一応アカウントのIDを確認しておきましょうか。
> eth.accounts[0]
"0x8ade49123c81461e676fd2f8f2eb31885cdb07e0"
> eth.accounts[1]
"0x3a8e6c0304c761b88feeefb5cdefe27ced28d620"


「eth.getBlock(〈ブロック番号〉)」で192番のブロックを見てみるとこんな感じです。
 eth.getBlock(192)
{
difficulty: 141158,
extraData: "0xd783010505846765746887676f312e362e32856c696e7578",
gasLimit: 111260474,
gasUsed: 0,
hash: "0xbcd39cbb3854b49a2b99d8e00f8d0990637fff7acb3b571bf2092ef80513d768",
logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
miner: "0x8ade49123c81461e676fd2f8f2eb31885cdb07e0",
mixHash: "0xcddd957dbba5b47b9343e55db72c65880351163733b6fbe86ab5d6c9fd28689f",
nonce: "0x37e12cf34c23c215",
number: 192,
parentHash: "0xee5743b3a3bdfb7c4fff360717ebb32e8a8051971172570c7dcba81da327f2e9",
receiptsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
size: 537,
stateRoot: "0xc7336773e050bc12a068699f4b91cb2f93c6b302664ddf575c70041c774b0af6",
timestamp: 1523976539,
totalDifficulty: 26144279,
transactions: [],
transactionsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
uncles: []
}


miner(マイナー)はcoinbaseアカウントのアカウント0になっていますね。

ちなみにマイニングをやめた時点でのブロック数は209です。
ペンディングが0になってすぐマイニングやめたつもりですが、意外と進行はやいw
> eth.blockNumber
209


興味本位で確認。。
209番目のブロックが今ある最後なので、このブロックには中身がありますが、210番目のブロック内容を見てみるとnullになります。

209番目のブロック内容。
> eth.getBlock(209)
{
difficulty: 141913,
extraData: "0xd783010505846765746887676f312e362e32856c696e7578",
gasLimit: 109427792,
gasUsed: 0,
hash: "0x0cd16490e3ceba375792cffd22f9ed4b4eecd6712485820f47ed04456de0fc66",
logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
miner: "0x8ade49123c81461e676fd2f8f2eb31885cdb07e0",
mixHash: "0x8ad56f8971fa16c901d3817837e19730f29a675daa38ad87c286cea60e768653",
nonce: "0x24014e4b135603da",
number: 209,
parentHash: "0xc8d6a2fde67cdd873ca2a69c1ee74f2e2b1b2624d4eed144de86499c2da5c47f",
receiptsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
size: 537,
stateRoot: "0xe194838290483fbaae5659796477b4614555d307ccd4ec4b2cae90ccd2aaa566",
timestamp: 1528010828,
totalDifficulty: 28550875,
transactions: [],
transactionsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
uncles: []
}


210番目のブロック内容。
> eth.getBlock(210)
null



eth.getTransactionの出力内容

「eth.getTransaction」コマンドで出力されたパラメータの意味でよくわからないところがあったので、かるく調べてみました。
どこかというと、「r」、「s」、「v」というの。なんだこれ。

調べた結果、どうやらECDSA署名という、トランザクションの署名に使うアルゴリズムで出てくるパラメータのもよう。
ECDSAというのはDSAというアルゴリズムの改良版だそう。
数学的なところを見ると時間がかかりそうなので置いておきます。。
ご興味のある方は、参考に挙げたあたりのURLをたどっていただけるともっと色々書いています。

数学的なところは、ひと通り勉強したらまた戻ってくるかも。

(参考)
ecrecoverでpublic keyが一意に定まる理由(アルゴリズムとかオーダーとか)
EthereumのTransactionHashの計算方法(アルゴリズムとかオーダーとか)
どうしてECDSA署名から公開鍵が復元できるのか?(Develop with pleasure!)
What does v, r, s in eth_getTransactionByHash mean?(StackExchange)
ECDSA: (v, r, s), what is v?(StackExchange)
ECDSA - 用語解説辞典(【公式】NTTPC)
楕円曲線DSA(Wikipedia)


まとめ

さて、今回はEthereumのテストネットワーク上で送金をしてみました。

今回のポイントは次の2点かなと思います。
(1)はじめにアカウントのロック解除をしないといけない
(2)マイニングしないと送金が完了しない

本を見ながらとかじゃないと1時間くらいハマる自信がある…w

あと、おまけで「eth.getTransaction」コマンドで出力されるr,s,vというパラメータの意味を調べました。
こいつらはECDSAという署名アルゴリズムで計算されるパラメータでしたが今回深くは触れませんw

と、こんな感じの内容でした。
次回は送金手数料の動きを見てみます。
ではでは。


プロフィール

ぺろりん

Author:ぺろりん
まだ始まってもいない暗号資産(仮想通貨)、今後が楽しみです。
基本的な技術をちゃんと知りたいなぁと思いつつ、まったりお勉強していこうかと思います。

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

カテゴリ
最新記事
最新コメント
月別アーカイブ
カレンダー
05 | 2018/06 | 07
- - - - - 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リンクの表示
メールフォーム

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

Bitcoin 取引情報
Ethereum 取引情報