Ethereumアカウントの種類とDAG(ファイル)を理解する
今回は、マイニングしてみたところの記事で別途調べると予告した「アカウント」と「DAG(ファイル)」について調べましたので、そのまとめを書きます。
技術的な詳細をもっと調べて理解したいところですが、調べてみると時期尚早感があったので、これはコントラクトなんかにちゃんと触れてからまた戻ってこれたらいいなと思っています。
なので、今回は技術的な詳細には踏み込み過ぎない程度に調べた結果をまとめました。
一応、参考に挙げたリンクをたどっていただくともう少し詳細が書いていたりするのでご参考ください。
なお、理解が間違っていたりしたらメールフォームからこっそり教えていただけると幸いです。
EOAとContract account
EOA (Externally-owned Account:外部所有アカウント)
ユーザーと紐づくアカウント。コードは持たず、秘密鍵によって管理される。
ユーザーはEOAを通してブロックチェーンとやり取りする。
EOAは、宛先をEOA or Contract Accountとしてトランザクションを生成できる。宛先がEOAの場合は送金、宛先がContract Accountの場合は送金 or コントラクト(・コード)の実行をする。
Contract Account(コントラクト・アカウント)
ユーザーに紐づかないアカウント。ユーザーが持つことはできず、ブロックチェーン上に存在するアカウント。
コントラクト(・コード)のアドレス。オブジェクト指向言語での「クラス」に似たものというイメージらしい。
Contract Account自身はトランザクションを生成できない。(あくまでトリガーはEOA)
EOAとContract accountの違い
両者の違いとしてポイントになるようなのは、今回調べた感じだと
(1) ユーザーと結びつくか?
(2) トランザクションを生成できるか?
という2点のように思います。
(参考)
・トランザクションレベルで理解する。イーサリアムの具体的な仕組みを解説(ZOOM)
・技術者向け Ethereum(イーサリアム)の基礎知識(block-chain.jp)
・スマートコントラクトを作成し実行する(Ethereum入門)
DAG
DAGって何?
Directed Acyclic Graph(有向非巡回グラフ)のことです。
マルとマルを線で結んだものを「グラフ」と呼ぶのですが、この線に向きを付けて矢印にしたものが「“有向”グラフ」で、しかも閉路になっていないようなもの(“非巡回”)のことです。


詳しくは「グラフ理論」という数学のおはなしをググってみてください。「グラフ理論」自体は私もあまり知りません。。
この考えをマイニングのアルゴリズムに応用するためにあるのが、イーサリアムをマイニングするときに出てきたDAGファイルというやつです。
DAGを使った取引の仕組みは、参考に挙げた2つ目のリンクが個人的にわかりやすかったです。
DAGファイルをどう使うのかは、今回は調べきれずよくわからなかったです。だれか教えてw
(参考)
・有向非巡回グラフ(Wikipedia)
・DAG型暗号通貨のすすめ ブロックチェーンを代替しうる新技術(BTCN)
何のためにある?
マイニングにASIC(Application Specific Integrated Circuit)耐性を持たせるために、DAGファイルが作成されます。
(参考)
・技術者向け Ethereum(イーサリアム)の基礎知識(block-chain.jp)
ASIC耐性とは?
ASICというのはその名の通り「特定用途のために作られた集積回路」のことで、用途をしぼって必要最低限の機能だけを1つのチップにまとめ、しぼった特定の用途に関しては汎用チップよりも高速だったり低消費電力だったりで動作できるようなチップです。
そして「ASIC耐性」とは、こういった専用のICチップを持った人(特定の人)がマイニングで有利にならないよう、「ASICを作れない」もしくは「ASICを使う意味がない(ASICを使ってもマイニングで有利にならない)」という性質のことです。
(参考)
・ASIC(Wikipedia)
・ASIC(IT用語辞典)
・ASIC耐性とは(とってもやさしいビットコイン)
なぜASIC耐性が必要?
ASIC耐性がない(=ASICが有効)と「中央集権化を助長する可能性があり、これを防ぐためにASIC耐性が必要」と考えるからです。
なぜ中央集権化を嫌うかというと、ブロックチェーン技術はそもそも「“分散システムで”うまく合意形成できる」というのが売りで、中央集権化というのはこれに反するからです。
中央集権的な構造でないことにより、“第三者の承認なし”でAさんとBさんのやり取りが「確かに正しく行われた」ことが合意されるわけです。
“第三者の承認なし”というのが肝です。
ASIC耐性がなければ、ASICを使う人がマイニングにおいて有利になります。
ASICを使う人たちのコミュニティにより寡占が起こると、51%攻撃のリスクも生じます。
ただし、Bitcoinのように「ASICを使わないと実質的にマイニング不可能」な状況は悪意あるマイナーの参入障壁になっていたり、ASIC耐性がないことが完全に悪いというわけでもありません。
ASIC耐性を持たせるかどうかは賛否両論あるようで、たとえばTwitter上で以下のようなアンケートがありました。
Would you support a hard fork that obsceletes ETH ASICs? (Just wondering, this is not a proposal)
— Vlad ''not giving away ETH'' Zamfir (@VladZamfir) 2018年3月28日
(参考)
・ASICマイニング排斥の動き!ASICの性能と問題点とは(MoneyToday)
・ブロックチェーンの安全性を脅かす「51%攻撃」の仕組みと実態(ZOOM)
・ASICマイニング戦争|ユーザーはASICを許容すべきか否か (CoinPost)
なぜDAGでASIC耐性になる?
DAGにより計算が複雑化されるからです。
ASICというのは「やることを絞る」ことで性能を上げますが、DAGの考えを取り入れることで計算が複雑化し、高性能な計算ができる分野だけでは計算し切れないようにします。
単純な計算だからこそ特化して性能を上げられるのに、せっかく性能を上げた専門分野の計算だけではマイニングできないよう計算を複雑化し、「このような複雑な計算のためのASICはコストがかかり過ぎて作るメリットがない」状況を作ります。
これにより、「ASICを使う意味がない(ASICを使ってもマイニングで有利にならない)」状況になり、すなわちこれはASIC耐性なわけです。
(参考)
・Ethash DAG(ethereum/wiki)
・Dagger Hashimoto(ethereum/wiki)
・Ethashとは?(ETHEREUM JAPAN)
・暗号通貨 ハッシュ関数を学ぶ その1 SHA Ethash(草コイン、おかわりください)
・ASIC耐性とは(とってもやさしいビットコイン)
まとめ
今回は、過去の記事でよくわからなかった「アカウント」と「DAG」について調べてみました。
ざくっというと、アカウントはユーザーと結びついてトランザクションを生成できる「EOA」と、ユーザーとは結び付かずトランザクションを生成できない「コントラクト・アカウント」という2種類がありました。
「コントラクト・アカウント」はコントラクト・コードを実行するために必要なもののようです。
DAGは、これ自身は数学のグラフ理論で出てくる概念で、Ethereum(やブロックチェーン)の文脈では「この概念を応用した取引の仕組みが実装されている」というおはなしでした。
では何のためにかというと、「ASIC耐性」という、ブロックチェーンの(マイニングで)中央集権化を防ぐための性質を、そのブロックチェーンに持たせるためでした。
ASIC耐性の要不要については賛否両論あるようです。
とまぁ、現段階ではこのへんの理解にとどめて先へ進んでみようかと思います。
ではでは。
batchOverflowの記事(Medium)の日本語訳
4/22に掲載されたMediumの「New batchOverflow Bug in Multiple ERC20 Smart Contracts (CVE-2018–10299)」という記事の拙訳を載せておきます。
日本語訳があれば他の方の役にも立つかなというのと、個人的な勉強をかねて。
誤訳などありましたらメールフォームからお知らせいただけるととても助かります。
なお、本文や図などは上記リンク先(元記事)をご参照ください。
調べた内容についてはこちらの記事へ。
拙訳
EOSトークン[注1]に対する私たの以前の努力に基づいて、イーサリアム(ERC-20[注2])に基づいたトークン送金を自動的に探査および解析するシステムを開発してきました。特に、私たちのシステムでは何かしらの疑わしい送金(たとえば、明らかにおかしい大量のトークンを含むようなもの)が起きると自動的に警告を出します。
特に、2018年4月22日の午前03:28:52(UTC)、普通でないBEC[注3]トークンの送金について私たちのシステムが警告を上げました(図1)。この特定のトランザクションでは、
0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000
(16進数で「0」が63個。実際、たしかにこういう大量のトークン送金が同じビューティーチェーン(BeautyChain)のコントラクトで同じ量という内容の送金が2つありましたが、アドレスは2つで違っていました)という極めて大量のBECトークンを誰かが送金していました。
この異常により、私たちは即座に関連するスマートコントラクトのコードを調査する必要に駆られました。このような送金はコントラクトに関するこれまで知られていない脆弱性を利用した「野放し状態の」攻撃によるものだと、私たちの調査で明らかになりました。推敲のうえ、この脆弱性をバッチオーバーフロー(batchOverflow)と呼ぶことにしました。バッチオーバーフローは基本的に古典的な整数のオーバーフロー問題であるというのが私たちの指摘です。以下では、バッチオーバーフローという脆弱性についてもう少し詳しく調べてみます。
脆弱な関数はbatchTransferの中にあり、そのコードは図2に示した内容です。257行目で示しているように、ローカル変数amountはcntと_valueの積として計算されます。2つ目のパラメータ_valueは、
0x8000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000,0000
(63個の「0」がつく)という256ビットの整数値をとれます。極めて大きな_valueとともに2つの_receiversをbatchTransfer()に渡すことで、ローカル変数amountをオーバーフローさせて0にできます。値が0になったamountをもって攻撃者は258–259行目にある値の正常性チェックを通過し、261行目の引き算が無関係になります。最終的に興味ある部分は次のところです:262–265行目に示したように、攻撃者がびた一文支払うことなく、2つの_receiversによるbalanceに極めて大きな値の_valueが足されることになります!
これにより、私たちはこのシステムをさらに走らせて他のコントラクトでも調査および解析しました。結果として、数十以上のERC20コントラクトがbatchOverflowへの脆弱性を持つことが分かりました。実証のため、私たちの検証用コードとして1つの脆弱なコントラクト(どの取引でも交換できないもの)を用いたトランザクションを成功させました(図3)。
このブログ執筆時より、これらの脆弱なコントラクトをもつチームと連絡をとる努力もしてきました。しかしながら、イーサリアムのブロックチェーンでうたわれる「コードこそ法である(code-is-law[注4])」という原則により、このように脆弱なコントラクトに対処するための場所で、慣習的によく知られたセキュリティ対応のやり方がありません!さらに、これらのトークンに関連する潜在的な値に対し、不運にもセキュリティチームとは独立した第三者のような私たちは、多くの取引にある脆弱なトークンによる交換を停止するような対応をとれる立場にありません。幸い、実質午後4:12(GMT+8)にOKEx[注5]が、batchOverflowの影響を受けるトークンであるBeautyChain (BEC)の引き出しと取引を一時停止するというアナウンスを出しました。しかし他の交換でも同様の対応が必要で、batchOverflowに対して脆弱な他の取引可能なトークンがまだ残っています!オフライン取引サービスによる非中央集権的な交換の存在は、それらはまだ攻撃者によるトークンのロンダリングを止められていないという更なる問題を突き付けるかもしれません。
また私たちはさらに、深刻な複雑性にも直面しているかもしれません。特に、このように脆弱なコントラクトを実行することによって、攻撃者が大量のトークンを所有することは非常にありそうなことです。この攻撃者[注6]が暗号通貨取引所に行き、このトークンをETH, BTC, さらにはUSDと交換しはじめたらどうでしょうか?きわめて大量のトークン(ありそうなのは流通している全供給量よりも大きい値)を持つことで、攻撃者が暗号通貨間の価格を簡単に操作できてしまうでしょう。これはつい最近の先月はじめに起きた、犯人がBinance[注7]の顧客アカウントを操作し、アカウントから別のアカウントに売却することでViacoin[注8]の価格をつり上げたというBinance事件[1:Medium記事の引用文献を参照のこと]をすぐに思い起こさせます。
[注1] EOSトークン…イオスという仮想通貨のことみたいです。参考に挙げたCoinOtakuの記事によると「企業の業務サポートで使われることを目的とした、スマートコントラクトを利用して分散型アプリケーションを作ることに特化している仮想通貨」だそうです。
(参考)
・公式サイト
・仮想通貨EOS(イオス・EOS)とは?特徴・買い方・取引所・将来性・チャート・マイニング・ニュースを解説(CoinOtaku)
[注2] ERC-20…Ethereum Request for Comments: Token Standard #20という、イーサリアムベースで作るトークンの技術的な統一規格。この規格に準拠することで、別々のトークンでも同じウォレットで扱えたりする。
(参考)
・ERC20(Wikipedia)
・ERC20とは<初心者向け>(とってもやさしいビットコイン)
・ERC20とは?仮想通貨の名前じゃない?対応するウォレットまで完全解説!(CoinOtaku)
[注3] BEC…Beauty Ecosystem Coinというプラットフォームのことらしい。詳しくは参考に挙げたあたりなどをご参照のこと。
(参考)
・公式サイト
・仮想通貨Beauty Ecosystem Coin(BEC)のAirdrop(無料配布)に参加 テレグラム利用で簡単に貰えるぞ(仮想通貨で自由を買うブログ)
・OKEX上場中のBeautyChain(BEC)がエアドロップを開始(スーファミ世代の仮想通貨ブログ)
[注4] code-is-law(コード・イズ・ロー)…コードがすべてで、(イーサリアムという世界は)コードという自然法則によってできている、というような考え方です。個人的には法「律」というよりも法「則」のニュアンスなのかなと思っています。この(イーサリアムという)世界の自然法則なのでこれは変えられる(変えるべき)ものではないという考え方です。イーサリアムクラシック(ethereum classic)はこっち寄りの考え。
(参考)
・イーサリアムクラシック(ethereum classic)とは~イーサリアムが分裂してできた新たな仮想通貨の全貌~(MOBLOCK)
・イーサリアムクラシックとは?イーサリアムから誕生した背景や違いを紹介(nanairo)
・イーサリアムクラシックが支持され価値がなくならない理由(Code is Law とは)(墨汁の暗号通貨速報)
[注5] OKEx…中国にある仮想通貨取引所の1つ。
(参考)
・公式サイト
・OKEx(オーケーイーエックス)の特徴やメリット/デメリット、口座開設方法をわかりやすく解説!(MOBLOCK)
・海外取引所OKEx(オーケーイーエックス)の登録方法・使い方【画像で解説!】(はじめてのビットコイン)
[注6] ここの「she」ってたぶん直前の文にある「an attacker」のことかと思ったんですが、攻撃者って女性名詞なのだろうか…?教えてエライ人。。
[注7] Binance…中国の仮想通貨取引所の1つ。
(参考)
・公式サイト
・BINANCE(バイナンス)の登録,入金方法と使い方|アプリが使いやすい手数料激安の取引所(ゼロからはじめるビットコイン)
・中国の取引所 Binance (バイナンス) の登録方法を解説(いますぐ始める仮想通貨投資)
[注8] Viacoin…仮想通貨の1つ。詳細は参考に挙げたところなどをご参照のこと。
(参考)
・Viacoin 相場チャート (VIA/JPY)(CoinGecko)
・仮想通貨Viacoin(VIA)の将来性と詳細|Lightning Network対応済みコイン(兼業主夫ふくろうの「好きなことで生きていく?」)
・仮想通貨VIA(Viacoin)とは?特徴や将来性・取引所での買い方 (仮想通貨で稼ぐサイトCOINZ)
batchOverflowとは何だったの?
4月の後半くらいに、batchOverflowという脆弱性が界隈で話題になりました。
Ethereum(イーサリアム)のスマートコントラクトに関する重大なバグが発見されたとのことで、仮想通貨取引所ではメンテナンスのため取引が一時停止されたりしました。
私自身はまだ勉強中なので素人目にですが、どんなものか調べてみたのでここにまとめてみます。
いつ見つかったの?
発端となったのは、4/22に掲載されたMediumの「New batchOverflow Bug in Multiple ERC20 Smart Contracts (CVE-2018–10299)」という記事のようです。
別記事で拙訳を作ってみたので、よろしければご参考ください。
どういう内容?
原文からすると、「batchTransferという関数の中にある積計算をするときに整数値のオーバーフローを起こすことで、大量のトークンを不正に取引できる」という内容のようです。
今回の脆弱性はERC20(日本語訳した記事の注2をご参照ください)そのもののバグではなく、Ethereum自体の不具合ではないようです。
ERC20というのに準拠したトークンのうち、batchTransferという関数が実装されたものが対象です。
解決策としては、オーバーフローが起きる計算をするときにエラーになるような処理にすることだそうです。
技術的な詳細に関しては参考に挙げた記事で尽きているかと思いますので、そちらに譲らせていただきます。
(参考)
・ERC20トークンに起きた脆弱性問題について (BatchOverFlow)(Gunosy Blockchain Blog)
・ERC20のバグと誤報されたBatchOverFlowを体験してみる(アルゴリズムとかオーダーとか)
仮想通貨取引所の対応
先日ワールドブックのβ版を公開したQUOINEX(コインエクスチェンジ)では、4/25-26時点で以下のような対応が実施されました。
【Ethereumスマートコントラクトでの重大なバグ発覚に伴う緊急措置について(1)】
— QUOINE Japan 公式 (@QUOINE_Japan) 2018年4月25日
本日ニュース等で報道されておりますとおり、Ethereumのスマートコントラクトで重大なバグが発見されておりますので、影響を鑑みて当社ではERC20ベースのQASHトークンの取引をすべて停止させていただきます。(続く)
【Ethereumスマートコントラクトでの重大なバグ発覚に伴う緊急措置について(2)】
— QUOINE Japan 公式 (@QUOINE_Japan) 2018年4月25日
ほかの仮想通貨の取引については引き続き可能です。
また、出金につきましては、日本円・仮想通貨すべてにおきまして、影響が出ないと判断できるまでは停止させていただきます。(続く)
【Ethereumスマートコントラクトでの重大なバグ発覚に伴う緊急措置について(3)】
— QUOINE Japan 公式 (@QUOINE_Japan) 2018年4月25日
再開目処が立ちましたら、再度ご連絡申し上げます。引き続き、どうぞよろしくお願い申し上げます。
【復旧のお知らせ】Ethereumスマートコントラクトでの重大なバグ発覚に伴う緊急措置について(1)
— QUOINE Japan 公式 (@QUOINE_Japan) 2018年4月26日
昨日ご案内しましたとおり、イーサリアムのスマートコントラクトにおけるバグの影響で一部サービスを止めておりましたが、先程QASHマーケットでの取引を再開いたしました。
【復旧のお知らせ】Ethereumスマートコントラクトでの重大なバグ発覚に伴う緊急措置について(2)
— QUOINE Japan 公式 (@QUOINE_Japan) 2018年4月26日
また、出金も順次再開いたします。
この度はご迷惑おかけし、申し訳ございませんでした。
引き続き、QUOINEXをご愛顧いただけますようお願い申し上げます。
まとめ
バグの内容としては、関数batchTransfer中の計算でオーバーフローを起こして不正なトークンを取引できるものです。
影響範囲はEthereumすべてではなく、batchTransferという関数が実装されたトークンに限るようなものでした。
大手取引所でも対応されているようですし、調べてみた感じだとイーサリアム自体や多くのトークンではあまり気にしなくてもよさそうです。