タグ: "仕組み"

イーサリアム(Ethereum)のブロック構造とその仕組み

イーサリアム(Ethereum)のブロック構造とその仕組み

2018/04/17 at 4:44 PM 0 comments
はじめに 今回の連載記事では、イーサリアム(Ethereum)ブロックの構造を、ビットコイン(Bitcoin)などと比較しながら解説します。 はじめに、イーサリアム(Ethereum)におけるユーザーのアカウントや、スマートコントラクトなどの情報がどのように管理されているかについて、解説します。次に、Ethereumブロックの構造をBitcoinなどと比較しながら解説します。 ぜひ、この機会にEthereumのブロックがどのような情報を持っていて、どのように承認されるかについて学んでいきましょう。 Ethereum Account イーサリアム(Ethereum)のアカウントには、以下の二種類があります。 外部アカウント・・・EOA(Externally Owned Account)とも呼ばれます。Ethereumを利用するユーザーが保持しているアカウント。秘密鍵によってコントロールされます。 コントラクトアカウント・・・CA(Contract Account)とも呼ばれます。コントラクトに紐づくアカウントでコントラクトに関するコードや情報を持つアカウント。コントラクトアカウントは、秘密鍵は持っていません。 これらのアカウントは、どちらも20byteのアドレスと状態(State)と呼ばれる情報を持っています。このStateについては以下で説明します。また、コントラクトアカウントは、外部アカウントから作成されます。 実際にどのようにしてアドレスが生成されるかなどの詳細は、以下の記事が参考になります。 (参考:イーサリアムアドレス 〜EIP-55によるチェックサムの導入〜https://consensysmediajapan.com/4443.html) Account State アカウントの状態には、以下の4つの情報が含まれます。 どちらのアカウントも共通して、「残高、nonce、コントラクトに関するデータ」を記録する部分を持っています。アカウントが持つnonceは、二重支払いを防ぐ役割をしています。着目しているアカウントが行うトランザクションの回数を記録するカウンターとして作用し、トランザクションは、このnonceの小さい方から順にブロックに詰められるようになっています。 そしてコントラクトアカウントのみが、codeというスマートコントラクトを保存する部分を持っています。外部アカウントの場合、コードは無く、空です。 このように、Ethereumでは、アカウントごとの残高が明示的に管理されています。これは、Bitcoinと異なる点です。Bitcoinでは、各アカウントごとに残高が管理されていません。散らばっているUTXOをかき集めることによって、着目しているアカウントがもつ残高を計算しています。そのため、Bitcoinではブロックチェーンから残高を導出する時間計算量も問題視されています。ビットコインのUTXOについては以下の記事が参考になります。 (参考:イーサリアムを理解するためにビットコインの基本を理解しようhttps://consensysmediajapan.com/2485.html) State Root 上であげた全てのアカウントの状態をEthereumのブロックに入れておこうとすると、ブロックのサイズがとてつもなく肥大化してしまいます。そこで、Ethereumでは以下の図に表すように、全てのアカウントの状態をマークルパトリシアツリー(下図の木構造のこと)によって構成しています。 これは、全てのアカウントのハッシュ値を掛け合わせて作られたState rootと呼ばれるハッシュ値のみをブロックの中に入れて記録することです。このState rootは全てのアカウントのハッシュから計算されるので、いずれかのアカウントの状態が改ざんされると、このstate rootも変わってきます。そのため改ざんなどを防ぐ役割も担っています。 ちなみに、アカウントのStateはブロック内には保存されませんが、マークルパトラシアツリーの状態で各ノードに保存されています。また、全てのアカウントのStateは、ブロック内に保存されている全てのトランザクションから推測、生成することができます。 一番下の段が各アカウントであり、複数のアカウントがもつStateを繋げてハッシュ化することで、全てのアカウントの情報を含む一番上のState Rootが作られます。(マークルツリーなどでは一番上の値をRootと呼びます。) 今回は、あくまでブロックの構造を知ってもらうことをメインに解説しています。 そのためマークルツリーについては次回の記事で詳しく取り上げることにします。 次に、ブロックの中に保存されている項目について整理していきましょう。 ブロック構造 イーサリアム(Ethereum)のブロック構造は、ビットコイン(Bitcoin)のそれに対して複雑です。まず、ハッシュ化されるブロックヘッダーと呼ばれる「ブロックの核」となる部分について比較してみましょう。 BitcoinのBlock Header Bitcoinの場合は,ブロックヘッダーには以下の情報が含まれます。 - nVersion・・・現在のBitcoinのバージョン - hashPrevBlock・・・一つ前のブロックのブロックヘッダーのハッシュ値 - hashMerkleRoot・・・複数トランザクションを先ほど述べたマークルツリーで処理したRoot値 - nTime・・・現在のタイムスタンプ(おおよそ現在の時刻が記録されます) - nBits・・・difficulty(難易度)に関する値。目標とするbit数が入り、この値よりも小さな値になるよう計算を行います。 - nNonce・・・マイナーが選べる任意の値。上にあげたハッシュなどと合わせて、現在のblockから計算されるハッシュが、設定されているtargetよりも小さな値になるように決定します。 これら6つの要素から成り立っています。 ビットコイン(Bitcoin)のブロックチェーンに内包されるBlock header(下図) EthereumのBlock Header 次に、Ethereumのブロックヘッダーについてです。こちらは、項目がBitcoinに比べ格段に多くなります。 Ethereumは、ブロック生成時間が10分であるBitcoinとは異なり、13~15秒と40倍も速い速度でブロックの生成が行われます。 しかし、承認速度が早いということは、計算の難易度が比較的に容易で、すぐにフォークが起きてしまいます。そのため、Ethereumには、承認されなかったブロックに対しても分け前を与えるシステムがあります。また、このときに、承認されずフォークしてしまったブロックのことをUncleブロックと呼びます。このUncleブロックのハッシュ値なども現在のブロックに取り入れられる構造になっています。また、Gasと呼ばれるマイナーに働いてもらうための手数料も特徴的です。 - ParentHash・・・一つ前のブロックのブロックヘッダーのハッシュ値 - UnclesHash・・・Uncle ブロックのブロックヘッダーのハッシュ値(OmmersHash/sha256Unclesとも呼ばれる) - Timestamp・・・現在のタイムスタンプ - Difficulty・・・ブロックを生成する難易度.これ以前のブロックの難易度とTimestampから算出される.Bitcoinとは異なり難易度調整はブロック毎に変動します。 - Nonce・・・マイナーが選べる任意の値。ここにあげたhashなどと合わせて、現在のblockから計算されるhashが、設定されているtargetよりも小さな値になるように決めます。 - TxTrieRoot・・・トランザクションをマークルツリーで処理したRoot値 - Coinbase・・・ブロック生成のマイニング報酬を受け取るアドレス(minerとも呼ばれる) - LogsBloom・・・トランザクションに関連する内容と、それに付随する内容がブルームフィルタと呼ばれる空間効率の良い形で保存されています。(詳しくは,次回以降の記事で紹介する予定です。) - Number・・・ブロック高,現在のブロック数を表します。 - GasLimit・・・このブロックで使用できる最大のGasサイズ - GasUsed・・・このブロックで使用されたGasの使用量 - ExtraData・・・ブロックに関連する任意の情報を記録する場所. - MixHash・・・このブロックで十分な計算が実行されたことを証明するハッシュ - ReceiptsRoot・・・ブロックに入っているトランザクションの実行結果を先ほどのマークルツリーで処理して保存しています。. - StateRoot・・・先述した通り、Ethereum上の全アカウントの情報から得られるハッシュ値(KECCAK-256)。アカウントのstateはblockの外で管理され、ノード値のみブロックに格納されます。 合計15個から構成されています。 下図のように、BitcoinとEthereumとの対応が取れるものについては、上図と同じ色で統一しました。 イーサリアム(Ethereum)のブロックチェーンに内包されるBlock header(下図) イーサリアム(Ethereum)ブロック構造のまとめ 今回は、Ethereumのブロック構造について解説しました。今までよりも、ブロックにどのようなデータが格納されているか、具体的に理解が深まったのではないでしょうか。 最後に、イーサリアムのブロック構造をまとめます。上で述べたブロックヘッダーは、ブロックの中でたくさんの要素が含まれている大切な部分です。 Ethereumのブロックには、他にも各ブロックごとに、その時起きたトランザクションを保管する部分があります。これには、Uncleブロックの分も含まれます。このように大きく分けると三つの要素からブロックが構成されています。(下図) このブロックが連続的に繋がっていくことでブロックチェーンが長く長く伸びて行くのです。 イーサリアム(Ethereum)のブロックに格納される3要素(下図) 次回以降は、今回触れることができなかったトランザクションの詳細や、どのブロックをメインチェーンに選ぶかを決定するGHOSTプロトコルなどについても解説していきます。
イーサリアムアドレス 〜ICAPとENSへの発展〜

イーサリアムアドレス 〜ICAPとENSへの発展〜

2018/04/11 at 4:38 PM 0 comments
ETHの送金などを行う際には、0xから始まる42文字のアドレスを使用します。このイーサリアムアドレスは一文字でも間違えると正しく送金することができません。通常、間違ったアドレスに実際に送金が起こってしまえば、送金したETHは戻ってきません。連載記事の前半では、このようなアドレスの打ち間違いによる誤りを検出する技術 -Capitals-based checksum-について解説しました。 連載の後半にあたる本記事では、イーサリアムアドレスをより使いやすく、送金時のミスを減らせるよう提案された、ICAP(Inter exchange Client Address Protocol)やENS(Ethereum Name Service)について解説していきます。 イーサリアムのアドレス形式 連載前半の記事にて、イーサリアムのアドレスはHEX(16進数)形式であり、この形式であることを示す0xから始まる42文字となっていることを示しました。 例:0x001d3f1ef827552ae1114027bd3ecf1f086ba0f9 HEX形式は、よりコンピューターが扱いやすい形式であって、一般的に私達人間が扱いやすいものではありません。試しにイーサリアムアドレスを暗記したり、書き写したりすれば、その難しさを簡単に実感できるでしょう。 またこのイーサリアムのアドレス形式は、チェックサムと呼ばれるアドレスが間違えているのかどうかを検証するための文字列を含みません。 これは後ににICAPやENSといった仕組みによってチェックサムを追加したり、より人間に読みやすい形式に見せたりする意図が設計時にあったために、あえてそのようなチェックサムの追加がなされなかったのです。 ICAP ICAP(Inter exchange Client Address Protocol)はイーサリアムのアドレスの誤りを検出可能にし、国際送金の規格に準じてアドレスを表記する方法として提案されました。ICAPは、銀行間で取引する際にその所在地や、支店、口座番号といった情報を特定する国際標準規格であるIBANコードを参考に設計されています。対応したICAPコードはIBANコードと互換性があります。 IBANコード IBANコードは最大で34文字のローマ字と数字からなる文字列です。ただし、最初の2文字は所在国を示すローマ字2文字、次の2文字は送金情報の誤りを検出するチェックサムに使われることが決まっています。 例えばイスラエルにある銀行では、IBANコードは以下の様になります。   例: IL## AAA BBB CCCCCCCCCCCC IL…イスラエルを表す国名コード ##…チェックサム AAA…銀行コード BBB…支店番号 CCC …口座番号   IBANコードを採用している国同士での送金であれば、IBANコードを使用することによって常に正しく送金を行うことができます。 3つのICAPコード方式 ICAPコードはIBANコードのイーサリアム版と言えます。全てのICAPコードは、どこの国にも属さないイーサリアムのアドレスを意味するXEから始まるという特徴があります。XEのEはEthereum、Xはextendedを表しています。 ICAPコードはその形式でDirect、Basic、Indirectの3つの方式があります。この中で、IBANコードとして使用することができるものは、DirectとIndirect方式のICAPコードの2つです。Basic方式は、IBANとの互換性も無く、チェックサム機能も無いため事実上利用する価値はあまり無いものです。よって以下でDirectとIndirect ICAPコードについて紹介します。 Direct ICAPコード この方式でのICAPコードは、数字とアルファベットを合わせた36種類の文字で表すことができ、最大で34文字となります。Direct ICAPコードの例を示します。   例: XE60HAMICDXSV5QXVJA7TJW47Q9CHWKJDA(34文字)   最初の”XE”はイーサリアムを表しており、次の”60”はチェックサム、それより後ろのHAMI….KJDの部分がイーサリアムアドレスを示しています。 元々のHEX形式のイーサリアムアドレスとの大きな違いは、チェックサムが付いていることによって、アドレス入力時の誤り検出ができることです。 またアドレスの部分が通常のアドレスと少し異なる形をしていることに気付きましたか?HEX(16進数)形式のイーサリアムアドレスでは、使用できる記号は数字およびa〜fまでのローマ字でした。Direct ICAP形式では、数字と全てのローマ字を表記に使用することが可能です。Direct ICAP形式ではbig-endianという方式で、HEX形式からローマ字と数字の形に変換されています。 これはIBANの形式に合わせて変換されていますが、依然として人間が読みやすい形にはなっていません。 Indirect ICAPコード Indirect ICAPコードは、より人間が読みやすい形式を意識した方式です。この方式もXEから始まり、2文字のチェックサムと続きますが、その後にアドレスの代わりになる任意の16文字の文字列(通常ある単語など)が続きます。例を示します。   例: XE##ETHXREGKITTYCATS(20文字)   ここでチェックサムの##部分の以降は、資産の種類を示す3文字(ETH)、4文字のネームーサービス名(XREG)、そして9文字のアカウント名(KITTYCATS)となります。この形式であれば、HEX形式に比べて人間でも覚えやすい形になっているかと思います。 しかし、このアドレスのKITTYCATSの部分から、実際の送金先のHEX形式のアドレスを明らかにすることはできません。Indirect形式では、事前にKITTYCATSというアカウント名に紐付いたイーサリアムアドレスをどこかに登録しておく必要があります。 事前に9文字の文字列とそれに対応するアドレスが対応したデータベースがあり、送金時にはこのデータベースを参照することによって、文字列に紐付いた送金先にイーサリアムを送金できることになります。 ICAPコード利用現状 IBANコードに準拠した形でチェックサムによる誤り訂正機能を持っているICAPコードですが、あまり使用されていないのが現状です。Direct ICAPコードは対応したウォレットを使うことによって生成することができますが、ICAPコードによる取引が可能な取引所はKrakenなど極一部に限られています。 またIndirect ICAPコードについては、文字列とイーサリアムアドレスを結びつけるデータベースをどのように作るのかという現実的な部分は提示されていません。 現状でもICAPの定義には曖昧な部分が多く、これはEIP-57, 70, 77で議論されています。とはいっても現在でも議論open状態として進行中のEIP-77についても、最後の投稿が2016年の3月であり、あまり活発な議論は進んでいないようです。 Indirect ICAPコードはイーサリアムアドレスをより人間が扱いやすい形にするという取り組みの試験的なものとして示されましたが、現在ではこの考え方をより一般的に拡張したENS(Ethereum Name Service)による解決が期待されています。 ENS ENS(Ethereum Name Service)は、イーサリアムのアドレスに対してある文字列を指定することで、送金時にその文字列を使って送金処理を実現させる技術です。 普段私達がインターネットブラウザからホームページにアクセスする際には、URLを使いますが、これはDNS(Domain Name Service)と言って、インターネット上の住所であるIPアドレスに対してURLという形の文字列を指定することによって実現しています。ENSはイーサリアムアドレスにおける、DNSのようなサービスだと言えます。 ENSを使うことによって、   例:0x001d3f1ef827552ae1114027bd3ecf1f086ba0f9   このようなHEX形式のイーサリアムアドレスを、   例:consensysmediajapan.eth   のような7文字以上のドメイン名として分かりやすい形に置き換える事が可能になります。ENSではチェックサムの様な機能はありませんが、アドレスに対して好きな文字列を選ぶことができます。人間が扱いやすい単語などを使うことができるため入力時の誤りを減らすことが期待できます。 ENSの取得手順 あるアドレスとそれに対応するドメイン名の関係は、イーサリアムブロックチェーン上のスマートコントラクトに保存されます。この登録は、MyEtherWalletなどから誰でも行うことができます。 ENSの取得は大きく分けて以下の手順になります。ドメイン名の取得は合計5日間のオークションによって行われます。オークションは、入札価格を公開しない3日間と公開できる2日間に分かれています。以下にその手順を示します。  1・準備 ドメイン名と紐付けるイーサリアムアドレスを選択します。そして、自分がオークションで支払える最大額のETHを指定します。(この時、オークションのトランザクションを処理するために0.01ETHが追加で必要です。)  2・オークションの開始(72時間/3日間) あなたは、名前と入札額を提示しますが、この情報はこの段階では公開されません。  3・入札額の開示(48時間/2日間) あなたは、この期間で自分の入札額を公開することができます。入札額を公開した場合、もしこのドメイン名を落札した際に、2番目に高い入札額と自分の入札額の差額の返金を受けることができます。  4・オークションの最終処理 合計5日間のオークションが終了すると、オークションでの落札者は最終処理を行い落札したドメインを自分のものに確定させます。3.にて入札額を公開していた場合は、差額の返金を受けることができます。もし入札者が自分だけだった場合には、トランザクションの処理にかかる0.01ETH以外の全てのETHが返金されることになります。 取得したENSの有効期限 このようなオークションプロセスによって落札したENSは、落札から1年間、所有権が有効になります。落札から1年が経過した時、落札者は所有権を放棄することでオークションによってロックアップしたETHの返却を得ることができます。 また、現段階で取得したENSには1年の期限が設けられていますが、今後永続的に取得したENSを保持できるようなシステムも開発途中です。有効期限が存在しないシステムに移行した場合には、既に所有している期限付きのドメインを、所有権が無期限なシステムに登録し直す事ができるようです。 ENSの価値 企業を立ち上げる際、”屋号” つまり会社名はとても重要なものです。同様にインターネット上で何かしらのサイトを立ち上げる際にも、取得したドメインの名前はサイトの認知度合いに何らかの影響を持つでしょう。もし今後、イーサリアムによる支払いやスマートコントラクトを利用したサービスが一般化したならば、イーサリアムアドレスのドメイン名もまた大きな価値を持ってくるでしょう。 既にこのENSの取得競争は始まっています。Cointelegraphによると既に、仮想通貨の取引所を意図するexchange.ethが6,660ETH、foundation.ethが300ETHなど、非常に高額な入札が行われています。 まとめ この2回の連載記事では、イーサリアムのアドレスにまつわる誤り訂正技術や、アドレスをより人間にとって可読性が高い形式に置き換える技術について紹介しました。現在は、まだ一般社会でブロックチェーンを利用したDappsが浸透してはいませんが、今後Dappsやイーサリアムを用いた支払いが一般的になったとき、このような誤りを訂正する技術がより重要になってくるでしょう。
イーサリアムアドレス 〜EIP-55によるチェックサムの導入〜

イーサリアムアドレス 〜EIP-55によるチェックサムの導入〜

2018/04/04 at 8:03 PM 0 comments
はじめに 今回の連載記事では、イーサリアムの”アドレス”について解説します。読者の皆さんは、自分が保有するイーサリアムアドレスについて気にかけたことはありますでしょうか?イーサリアムアドレスは0xから始まる合計42文字の文字列です。これを正確に記憶している人はなかなかいないのではないでしょうか。 イーサリアムに限らず仮想通貨におけるアドレスは、銀行口座の口座番号のようなものです。送金・受金の際に、この長いアドレスを1文字でも打ち間違えてしまうと、保有する仮想通貨を失うことになりかねません。このような背景から、打ち間違えた際に誤りを検出する技術や、より覚えやすい文字列に置き換える技術が開発されています。 連載記事の前半では、イーサリアムアドレス生成の流れと現状取り入れられている誤り検出の技術(Capitals-based checksum)を解説します。 後半では、イーサリアムのアドレスを国際送金の基準に準じ、より扱いやすくするICAPコードや、覚えやすい文字列に置き換えるENS(Ethereum Name Service)について解説します。 必要な知識 本連載記事を読み進めるにあたり、必要となる前提知識について、簡単に解説します。秘密鍵/公開鍵・一方向ハッシュ関数・チェックサムといった用語について既に知っている場合、読み飛ばしていただいて構いません。 秘密鍵/公開鍵 暗号技術を用いて、他者に知られたくないコミュニケーションをしたい場合は、内容を暗号化および復号化する必要があります。暗号化と復号化には、それぞれ”鍵”が必要となります。 暗号化と復号化に同じ鍵を用いる場合は、共通鍵認証と呼ばれています。一方で、イーサリアムをはじめとする仮想通貨においては、暗号化と復号化に異なる鍵を用いる公開鍵認証と呼ばれる暗号方式が利用されています。公開鍵認証自体にはいくつかのアルゴリズムが存在しますが、イーサリアムでは、楕円曲線DSA(ECDSA)を採用しています。 この公開鍵認証においては、秘密鍵と公開鍵と呼ばれる二つの鍵が存在します。両者の特徴は以下の通りです。 秘密鍵 他者には知られてはいけない鍵(銀行の暗証番号に相当) ランダムに生成 公開鍵 他者に知られても良い鍵(銀行の口座番号に相当) 秘密鍵を元にして生成 公開鍵から秘密鍵を推測することは困難 より詳しく知りたい場合は、ビットコインやイーサリアムの保管、仮想通貨の公開鍵と秘密鍵が参考になります。 一方向性ハッシュ関数 ハッシュ関数(要約関数)とは、ある任意の長さのインプットのデータを与えた時に、アウトプットとして固定長の文字列や数値列に変換する関数です。インプットとアウトプットは、それぞれ”メッセージ”と”ハッシュ値”と呼ばれます。このハッシュ関数の重要な特徴として、”一方向性”が挙げられます。 一方向性とは、メッセージからハッシュ値はアルゴリズムによって計算されるものの、ハッシュ値からメッセージを逆に計算することは非常に困難であることを意味しています。このような特徴から、一方向性ハッシュ関数と呼ばれています。またハッシュ関数にインプットするメッセージが僅かでも変化すると、アウトプットされるハッシュ値が大きく変化することから、データ改竄の検出等に使うことが可能です。 一方向ハッシュ関数の重要な特徴を以下にまとめます ハッシュ値は固定長の文字列/数値列となる メッセージが僅かでも変化するとハッシュ値は大きく異なる ハッシュ値からメッセージを推測することは非常に困難 チェックサム インターネットをはじめとする情報通信においては、必ずしも送信したデータが正確に受信されるとは限りません。データの一部が誤って受信側に伝わることは頻繁にあることです。そのような状況が生じた時に、受け取ったデータが”誤っている”ことを検出できれば、送信側に対して再度送信を要求するなどの対応を取ることが可能になります。このような誤り検出を可能にする手法の一つが、チェックサムです。 チェックサムの仕組みを簡略化して説明します。 例として、”462565”というデータを送信するとします。ただし、”462565”をそのまま送信するのではなく、ある数字Sを追加して誤り検出をできるようにします。 まず”462565”のそれぞれの桁の合計値をSとして、それを計算します。   S = 4+6+2+5+6+5   = 28   この合計値 S を送信するデータ”462565”の末尾に付けて送信することにしましょう。送信データは、”462565+S” = “46256528”となります。このチェックサムの仕組みを、受信側が理解していれば、受信したデータの一部が誤っていた場合に誤りを検出することができます(データの合計値と付加したSの間に不一致が生じるため)。 例えば、チェックサムをつけた状態の正しいデータは”46256528”ですが、何らかの原因によって”46256628”とデータが受信されたとします。   正しいデータ:”46256528” 誤ったデータ:”46256628”   この時、誤ったデータのチェックサムを取り除き、”462566”の合計値S’を計算してみましょう。   S’ =  4+6+2+5+6+6   = 29   受信したデータ“46256628”から、チェックサムSは28であることが分かっています。一方で、誤ったデータを元に再度計算して求めたチェックサムS’は29です。この違いから、データに誤りがあることがわかります。 上記の例では非常に簡略化した例を用いてチェックサムの概念を紹介しました。イーサリアムにおいては、Capitals-based checksumと呼ばれる手法を用いることで、入力したアドレスが誤っているかどうかをその場で判断することができます。Capitals-based checksumについては、後ほど詳しく説明することとします。 イーサリアムアドレス生成 生成の手順 前節において解説した前提知識を用いて、イーサリアムのアドレス生成の手順を説明します。手順は以下の通りです。 ※以下で用いられるアドレス等の文字列は、Mastering Ethereumから利用しています。   秘密鍵 k を生成(32バイト) 例:k = f8f8a2f43c8376ccb0871305060d7b27b0554d2cc72bccf41b2705608452f315   秘密鍵 k から楕円曲線DSA(ECDSA)を用いて公開鍵 K を生成(64バイト) 例:K = 6e145ccef1033dea239875dd00dfb4fee6e3348b84985c92f103444683bae07b83b5c38e5e2b0c8529d7fa3f64d46daa1ece2d9ac14cab9477d042c84c32ccd0   公開鍵 K から一方向性ハッシュ関数 Keccak-256を用いてハッシュ値を計算(32バイト)    例:Keccak256(K) = 2a5bc342ed616b5ba5732269001d3f1ef827552ae1114027bd3ecf1f086ba0f9   先頭12バイトの文字を消去し20バイトのイーサリアムアドレスを取得    例:001d3f1ef827552ae1114027bd3ecf1f086ba0f9   アドレスが16進数であることを示すために 接頭辞”0x”をアドレスに付加    例:0x001d3f1ef827552ae1114027bd3ecf1f086ba0f9   さてこのようにして得られるイーサリアムアドレスは、HEX(16進数)形式のアドレスと呼ばれています。HEX形式のアドレス生成においては、チェックサムを付加するステップはありません。つまり1文字でもアドレスを打ち間違えた場合には、誤りを検出することができず、ETHを失うことになります。 イーサリアムがチェックサムを持たない理由 イーサリアムのアドレスがチェックサムを持たない理由として、将来的にアドレスをより可読性の高いネーム形式(ENS: Ethereum Name Service)に移行するためだと言われています。ネーム形式とは、”consensysmediajapan.eth”のような任意の文字列が、あるHEX形式のアドレスに対応している形式です。ユーザーはHEX形式のアドレスを利用する代わりに、より可読性が高く、記憶のしやすい文字列を使えるようになります。これは現在のインターネットのURLのドメインに相当する概念です。 加えて、イーサリアムアドレスはICAP(Inter exchange Client Address Protocol)形式のアドレスといったフォーマットも検討されています。このICAP形式のアドレスは、デフォルトでチェックサムが付加されていることから、誤りを検出することが可能になっています。 上述のENSとICAPについては、連載の後半で詳しく説明します。 EIP-55 イーサリアムはICAP形式を用いることで、誤り検出が可能になると述べました。しかしICAPへの移行はあまり進んでおらず、多くのユーザー、取引所、ウォレットがHEX形式のアドレスを利用しているのが現状です。 しかしICAP形式が広まるまでHEX形式のイーサリアムアドレスの誤り検出ができないのは大きな問題です。そこで2016年1月にイーサリアム創設者のVitalik Buterin氏が提案したのが、Capitals-based checksumと呼ばれる誤り検出方法です。これはEIP-55において議論され、最終的に正式に採択されています。 Capitals-based checksumとは Capitals-based checksumとは、HEX形式アドレスのローマ字の小文字を、ある一定の手順によって大文字に置き換えることで、誤り検出の機能を持たすことが可能なチェックサムです。変換されたアドレスは大文字・小文字が混在していますが、小文字のみのHEX形式アドレスと下位互換性があります。 つまりCapitals-based checksumに対応していない取引所やウォレットおいて、Capitals-based checksumに基づいて変換されたアドレスを用いても何も問題は生じません。 先ほどアドレス生成の流れで説明したアドレスをCapitals-based checksumを用いて変化すると以下のように変換されます。ローマ字の一部が大文字に変換されています。 変換前:0x001d3f1ef827552ae1114027bd3ecf1f086ba0f9 変換後:0x001d3F1ef827552Ae1114027BD3ECF1f086bA0F9 自分のイーサリアムアドレスを取引所やウォレットで確認してみましょう。おそらく大文字と小文字が混在したアドレスが表示されているのではないでしょうか?これはCapitals-based checksumによって誤り検出を可能にした形式のHEXアドレスなのです。 Capitals-based checksumの仕組み Capitals-based checksumによってアドレスを変換する方法と誤りを検出する方法を解説します。 アドレス変換方法 変換前のイーサリアムアドレスから接頭辞である”0x”を削除し、一方向性ハッシュ関数Keccak-256を計算してハッシュ値を得ます。 ハッシュ値 = Keccak-256(“イーサリアムアドレス”) ハッシュ値 = Keccak-256("001d3f1ef827552ae1114027bd3ecf1f086ba0f9") = 23a69c1653e4ebbb619b0b2cb8a9bad49892a8b9695d9a19d8f673ca991deae1   アドレスのローマ字部分に対応するハッシュ値の値が、16進数で8以上の場合(8,9,A,B,C,D,E,F)は、アドレスのローマ字の小文字を大文字にします。   表1:ハッシュ値と変換後アドレスの関係 表1にアドレスとハッシュ値の先頭10文字を示しました。アドレスの4文字目はローマ字の”d”です。対応するハッシュ値は6ですので、8以下ですので大文字には変換しません。次にアドレスの6文字目を考えてみましょう。対応するハッシュ値はcですので、これは16進数では8以上の値です。よってアドレスのローマ字を大文字に変換します。この手順によって、アドレスの全てのローマ字を大文字に変換するかを確認します。この際、比較されるハッシュ値は先頭20バイト(40文字)のみです。これはアドレスの長さが20バイト(40文字)であるためです。 誤り検出方法 次に誤り検出の方法について説明します。今、変換されたアドレスの一部を誤ってウォレットにタイプしたとしましょう。最後から2文字目”F”を誤って”E”とタイプしてしまいました。   正しいアドレス:0x001d3F1ef827552Ae1114027BD3ECF1f086bA0F9 誤ったアドレス:0x001d3F1ef827552Ae1114027BD3ECF1f086bA0E9   誤ったアドレス(を全て小文字に置き換えて)の再度ハッシュ値を計算します。使用する一方向ハッシュ関数は、アドレス変換時と同じくKeccak-256です。   ハッシュ値(誤)  = Keccak-256(”誤ったアドレス”) ハッシュ値(誤) = Keccak-256( "001d3f1ef827552ae11114027bd3ecf1f086ba0e9") = 5429b5d9460122fb4b11af9cb88b7bb76d8928862e0a57d46dd18dd8e08a6927   このハッシュ値(誤)を、正しいアドレスの場合のハッシュ値(正)と比較してみます。   ハッシュ値(正):23a69c1653e4ebbb619b0b2cb8a9bad49892a8b9695d9a19d8f673ca991deae1   ハッシュ値(誤):5429b5d9460122fb4b11af9cb88b7bb76d8928862e0a57d46dd18dd8e08a6927   たった1値文字のアドレス違いから、全く異なるハッシュ値が得られました。このハッシュ関数の特性が誤り検出をする際のキーポイントとなります。 表2:アドレスの入力を誤った場合のハッシュ値(誤)と変換後アドレス 誤ったアドレスに基づいて得られたハッシュ値(誤)を元にして、もう一度元のアドレスの大文字小文字を変換しました。表1と表2の変換後アドレスを比較してみましょう。先ほどまでは小文字であったdが大文字に変換されていることがわかります(4文字目)。他にも大文字であったFが小文字に(6文字目)、小文字であったeが大文字(8文字目)などに変換されてしまっています。 上記の例に示したように、正しくCapitals-based checksumによって変換さえれていたアドレスを1文字でも打ち間違えると、元のアドレスとは異なった位置のローマ字が大文字・小文字に変換されてしまいます。 この違いを検出することで、入力されたアドレスに誤りがあることを示すことができます。Capitals-based checksumは99.986%の精度で誤りを検出できるとされています。また実装も簡単なことから、現状ではイーサリアムアドレスのチェックサムとして活用されています。 まとめ イーサリアムアドレスに関する連載の前半では、アドレス生成の流れとCapitals-based checksumを利用したアドレスの誤り検出について説明しました。連載の後半では、ICAPやENSといった将来的なイーサリアムのアドレスの進展について解説します。
イーサリアム資金盗難の救済措置 EIP-867にまつわる議論と平井氏の懸念

イーサリアム資金盗難の救済措置 EIP-867にまつわる議論と平井氏の懸念

2018/03/06 at 3:07 PM 0 comments
イーサリアムなどの仮想通貨/暗号通貨を利用したICOによる資金調達額は、2017年に約40億USドル相当に達しました。このように近年ICOによる資金調達の活発化に伴い、ICOプロジェクトを狙ったハッキングによる盗難や、実装されたコードの不備による資金凍結(誰も取り出せなくなること)の被害も増加しています。そこでETHが盗難・凍結した場合に、そのETHを取り戻す方法がEIP-867として提案されました。 本記事は盗難・凍結したETHを取り戻す方法を提案したEIP-867にまつわる連載記事の後半です。前半記事では、EIP-867で提案されたETH回収の仕組みについて解説しました。本記事ではこの提案に関する考察と、イーサリアムEIPコミュニティの編集者である平井氏が示した2つの懸念に焦点を当てて解説をします。 ハードフォークによる救済 当時最大級のハッキング被害が発生したThe DAO事件では、イーサリアムがハードフォークすることによってハッキングが無かったことになり、ETHは取り戻されました。ハードフォークではブロックチェーンに大幅な仕様変更を加えるために、それまでのブロックチェーンとの互換性は保たれなくなります。 ハードフォークする新たなブロックチェーンが提案された際、この新しいブロックチェーンを正当なものとして受け入れるかどうかは、ネットワーク上の各ノード(ブロックチェーンの管理やマイニングを行っている世界中に分散したコンピュータ)が選択します。 The DAO事件では、ある特定のハッキングのみを無効にするということが、ブロックチェーンの特長である ”過去に起こったことが変更不可能である” という性質に反するとして、1割程度のノードから反対されました。結果として、9割方のノードが採用した新しいブロックチェーンが正式なイーサリアムとなり、反対の立場にあるノードが元のブロックチェーンを運用し、これがイーサリアムクラシックとなりました。 このようにハードフォークを行うには、その提案を行う事自体の労力に加えて、ノード全体の半分以上の同意が必要であり、簡単に実現できるわけではありません。 EIP-867によるソフトフォーク EIP(Ethereum Improvement Proposals)コミュニティでは、現状のイーサリアムの問題に対する解決策が議論され、一般的に現状のイーサリアムに互換性のある形式の提案が承認され、アップデートとして配信されます。 EIP承認の流れやERCについての記事はこちら ネットワーク上のノードは、このEIPで承認されたアップデートをマイナーな公式アップデートとして受け取り有効化していきます。 EIP-867で提唱されたETHの救済方法は、このEIPの承認手順に則ったソフトフォーク的な方法だと言えます。 EIP Editorとは? EIPコミュニティには、EIP Editorという権限を持つ人物がいます。彼らは新たな提案を受け取り、その提案が適切である場合はEIPとして番号を与えて、EIPに関するGithubレポジトリに提案を検討(Draft)状態として公開します。 また、公開された提案に対する議論の末、EIPが公式アップデートとして取り込むべきと判断した場合には、提案を承認(Accept)し最終版を確認(Final)した上で公式なアップデートとします。 (提案されたEIPが経るプロセスフローチャート 引用:https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1.md ) 2018年2月22日現在、EIP Editorはイーサリアムの開発者であるVitalik Buterin氏を含め6名です。EIP EditorやEIPコミュニティの目的やガイドラインについてはEIPの1番としてGithub上に掲げられています。 EIP Editor 平井洋一氏の懸念と辞職 2017年2月上旬に、6名いるEIP Editorの一人であった日本人論理学者の平井洋一氏が、EIP-867に関する提案を以下の2つの懸念事項を理由に受け入れられないと表明しました。平井氏はその後、この件をきっかけにEIP Editorを辞職します。この一件は、今回巻き起こっているEIP-867に関する倫理的な議論を象徴する出来事だと言えるでしょう。以下に平井氏の懸念事項を紹介し考察します。 平井氏の懸念 ① 〜イーサリアムの分散自治的な側面〜 ブロックチェーン技術に根ざしているイーサリアムは、そもそも国家や政府はもちろんのこと、どの様な立場の人や組織も管理権限を持たない分散自治組織的な設計がされています。この組織では権限者が居ないかわりに、全ての意思決定で全ユーザーの投票により過半数以上の賛成を必要とします。 しかし、そうとは言ってもイーサリアムの技術的な変更も公平なユーザーの投票によって過半数を得る事が最善とは言い切れません。イーサリアムは元々Vitalik氏を中心とした天才的なプログラマ達によって開発されている緻密な暗号理論に基づいたシステムです。これを正しく更新し続ける為には高度な専門知識が必要になります。そのため、イーサリアムEIPではこの様な背景から、EIP Editorが改善案の承認を最終的に行う事で初めて公式なアップデートとなるような一部の管理権限を認める仕組みを設けています。 この様な理由から権限を持つEIP Editorは慎重に検討して、イーサリアムコミュニティ全体にとって公平な改善案のみを承認するべきだと言えます。 平井氏の懸念事項の一つ目はこの点です。つまり、もし今回提案されたEIP-867が承認されれば、今後不正(と思われる)ETHの盗難や凍結があった場合に、この資金を最終的にどのように処理するのかと言う、極めて特定の利益に関わる決定権をEIP Editorが持つことになります。 これは上述したイーサリアムの分散システムの哲学に反します。EIP Editorはイーサリアム利用者の信任を得て決定される訳でも無く、また、その存在についても一般に高く認知はされていません。よってEIP Editorが特定のアカウントの残高情報を変更する強い権限を持つべきではない、というのが平井氏の指摘です。 “I don't think anybody has the authority to make an irregular state change. I don't think I have the authority to review processes regarding who has the authority to make an irregular state change. These beliefs come from the lack of authorizations from Ethereum users. I don't think all users of Ethereum gave authorization to this EIP process, or know about the EIP process. The EIP process is not mentioned in the licenses of Ethereum clients. EIP editors are not chosen democratically either.” (引用: https://github.com/ethereum/EIPs/pull/867#issuecomment-365541405 ) 平井氏の懸念 ② 〜日本の刑法との抵触の可能性〜 また日本人である平井氏がEIP Editorとして今後このEIP-867で述べられたERPを承認した場合に、日本の刑法 ”電磁的記録不正作出及び供用” に抵触する可能性があることを述べています。この刑法は、ある電磁記録に関する権限を持っていない状態で記録を作り出す・改変することを罰するという内容のものです。 例えば他人の預金残高の記録を持ち主の許可無く改変することはこの刑法で罰せられる可能性があります。 平井氏は直接的にどのように抵触するかについては言及していませんが、おそらく、EIP Editorとして他人のETH資金の情報を所有者の許可なしに書き換えるERP案を承認する行為が、この刑法での犯罪の幇助にあたると考えているのでしょう。 The Japanese penal code defines a crime called "Unauthorized Creation of Electromagnetic Records". (edit: this item applies also outside of Japan) I'm currently not in Japan but in Germany. I suspect there might be a similar rule in Germany, and I don't know how broadly that applies. Once I thought it's enough not to touch individual cases because I had civil cases in mind. After realizing the penal code aspects, I'm not sure if I can do anything here in this pull-request. (引用: https://github.com/ethereum/EIPs/pull/867#issuecomment-365541405 ) 平井氏の辞職 平井氏は当初、上述した2つの懸念事項を理由にEIP-867に対する否定的なコメント寄せました。ただし平井氏はその後の議論を経て、イーサリアムの哲学に反するという①の懸念事項については解釈を無視することで解決できるとしました。しかし、②の刑法への抵触については無視できないとしました。 平井氏が否定的なコメントを寄せる一方、イーサリアムのコミュニティマネジメント及びParityのテクニカルコミュニケーションを担当しているアフリ氏は、今回のERPの提案を強く支持しています。 そして、アフリ氏はTwitter上にて、日本という一つの国の法律に抵触する恐れがあるという理由で、イーサリアムに有用な提案が拒否されることは、イーサリアムコミュニティで起こるべきではないという旨の意見を表明し、平井氏がEIP Editorを辞任することを呼びかけました。 平井氏はこれに応答し、もし平井氏自身が辞任したとしても、それは後続のEIP Editorが刑法を無視することになるだけだという意見を表明しました。結果として、その10時間後にEIP Editorを辞任するに至りました。 各国の規制と分散自治組織の対立 今回紹介したEIP-867に関する議論は、イーサリアムにて大きな問題となっている盗難・凍結された資金の回収に関するものでした。しかしここから、イーサリアムと言う分散型システムを開発・推進するコミュニティが実際に存在することによって発生する、日本の法規制との対立構造が浮き彫りになりました。 公開されたブロックチェーンによって作られるシステムは、一般的に国などの従来の枠組みを超えた分散自治的な特徴を持っています。しかし、そのコミュニティに参加する人々は、何処かしらの国籍を持ち、自国の法規制に束縛されます。 今後ブロックチェーンをベースとした分散自治的な組織が更に拡大するでしょう。そして、そこで発生する従来の国や政府などの枠組みによる規制との対立をどのように解決していくのかは、分散自治組織を現実社会で利用する上で非常に重要な視点となるでしょう。
イーサリアム資金盗難の救済措置 EIP-867の仕組みとは?

イーサリアム資金盗難の救済措置 EIP-867の仕組みとは?

2018/02/28 at 7:41 PM 0 comments
イーサリアムなどの仮想通貨/暗号通貨を利用したICOによる資金調達額は、2017年に約40億USドル相当に達しました。このように近年ICOによる資金調達の活発化に伴い、ICOプロジェクトを狙ったハッキングによる盗難や、実装されたコードの不備による資金凍結(誰も取り出せなくなること)の被害も増加しています。そこでETHが盗難・凍結した場合に、そのETHを取り戻す方法がEIP-867として提案されました。 本記事では2本連載にて前半ではこの提案の内容について、後半でこれにまつわる議論や出来事を整理して解説していきます。 ERCとEIPについて ERCとして公開された技術仕様に関する文章は、まず単なる問題提起からスタートします。提案された問題や技術が重要であれば議論が進み、最終的にはEIP(Ethereum Improvement Proposals)として採択されます。 EIP採択までの過程には、Draft(検討段階)→Accepted(承認済み段階)といったステータス(状態)があります。AcceptedされたEIPは最終的にまとめられ、イーサリアムの仕様として正式に採用(Final)されることになります。採用されたものは、イーサリアムの公式なアップデートとしてネットワーク上のクライアントに組み込まれていきます。 イーサリアムのバージョンアップや仕様変更などは、全てこのプロセスを経て行われることになっています。この一連のプロセスの解説については本メディアの過去の記事で解説しております。 EIP-867の概要について EIP-867は前述した通り、ICOなどによって調達したETHがハッキング被害やコードの不備などによって意図せず盗難・凍結した際に、被害者が資金を取り戻すリクエスト(ERP: Ethereum Recovery Proposals)を行い、これが承認された際にその資金が取り戻せる方法を標準化しようと試みた提案です。 これは2017年2月2日に、Musiconomiの開発者であるDan Phifer氏、そしてTapTrustの開発者であるJames Levy氏、Reuben Youngblom氏によって提案されました。 過去の被害と対処例 この提案が行われた背景には、過去に多発したICOで調達した資金の盗難・凍結があります。代表的な例として、The DAOでのハッキングやマルチシグウォレットサービスParityでのバグによる被害が挙げられます。 The DAO The DAOは非常に大きな注目を浴び、短期間で1億米ドル以上の資金を調達し、クラウドファンディングによる史上最高記録を塗り替えました。しかし調達直後に致命的なコードのバグによって、ハッキングの被害に遭い8000万米ドル相当の資金を盗難されました。 これはイーサリアム自体にとってもその価値を下げる大きな問題であった為に、イーサリアム自体がハードフォークし、このハッキングを無かったことにし、資金を元のウォレットに戻すという対応が取られました。最終的に、The DAOはこの対処によって盗難した資金を取り戻すことに成功しました。 Parity 次にParityの例について見てみましょう。 Parityは、スマートコントラクト上で実行されるウォレットサービスです。このParityの2017年7月20日にリリースされたバージョンにて、あるバグが報告されました。 このバグは、ある操作で通常のウォレットがマルチシグウォレットに意図せず変更されてしまい、この際にウォレットを開けるために必要な秘密鍵が資金と共にウォレットの中に保存されてしまうというものでした。 これはある部屋に入るために必要な鍵が部屋の中にある言わば”閉じこもり状態”であり、このマルチシグウォレットの中に保管されていたETHは事実上凍結されて、誰も移動することができなくなってしまうものでした。 プライベートブロックチェーンとパブリックブロックチェーンをリンクさせるというアイディアで、ICOにて1億4000米ドルを調達したPolkadotもこの被害にあっており、その調達資金のうちの60%が影響を受けているとされています。 Unfortunately, our multi-sig is among those frozen. @ParityTech is working on the situation and will provide updates when available. — Polkadot (@polkadotnetwork) 2017年11月7日 EIP-867の提案者であるDan氏が、ICOを行った音楽系のサービスMisiconomiも被害を受けています。そして昨今このような被害報告が急増しています。しかし、それに対する救済措置は殆ど行われていないのが現状です。むしろThe DAOで行われたハードフォークは、イーサリアム開発者の全面協力による特例的な対応であったと言えるでしょう。 そこで資金盗難・流出が発生した際に、大規模なハードフォークを行わずに資金回収をする方法がEIP-867で具体的に提案されました。 EIP-867で提案された資金回収方法 この提案では、実際に起こったParityの事件に限らず、ハッキングやコードの不備など様々な原因によって、あるウォレットからの資金が意図せず盗難・凍結した場合に、これを取り戻す方法が示されています。ここではある誤送金の例を用いて資金を取り戻すまでの一連の流れを解説します。 あるICOプロジェクトにてプロジェクト責任者が、誤ってテストネット(プログラムの評価や動作確認に使用する実際の金銭価値の無いネットワーク)で作成した振込先のアドレスをホームページ上に掲載した場合を考えます。 このアドレスはメインネット(金銭価値がある本物のネットワーク)でも有効ではありますが、秘密鍵はテストネットのものとは異なるために、この責任者はここに振り込まれた資金を利用することはできません。 問題が発覚した時には既に100人の投資家によってこの間違ったアドレスに500ETHが送金され、この500ETHは実質的に凍結されてしまいました。 ここでこの責任者は凍結した資金を解除するリクエストERP(Ethereum Recovery Proposals)によって、500ETHを投資家の元のアドレスに戻すような送金をすることを試みます。 まず責任者は、ERPの提案者としてイーサリアムのEIPコミュニティに、ERPの原案をEIP-xxx(xxxには提案番号が入る)として投稿します。 ERPの原案の中身 ERP原案には主に以下の内容が含まれています。 Verification script(検証コード) Verification scriptとは、イーサリアムのブロックチェーン上に存在するデータなどの事実を使って、State Change Actionsによって凍結資金の解除を実行するかどうかを決定する検証を行うコードです。 検証コードに具体的に記述された条件が満たされた場合に、検証コードはイーサリアムクライアントが実行できる形式のState Change Objectを生成して、凍結資金解除のトランザクションを生成します。 ここでは検証コードの例として、 ブロック番号○○~xxまでの取引にて誤ってメインネット上のテストネット用アドレスに500ETHが送金されたこと テストネット上でのこのアドレスには確かにICOプロジェクトのスマートコントラクトが実装されていたこと(つまり確立論的にメインネット上にこのアドレスの所有者は存在し得ないこと) 上記の全てが真実である場合には全ての送金者に投資されたイーサリアムを返却するState Change Objectを生成する と言った内容が書いてあるとします。 State Change Object これはイーサリアムネットワークのクライアントによって実行されるファイルの標準形式です。 この中には、ERPの番号(ERP id)や変更を要するブロック番号(Target Block)、そして検証コードを実行した際のブロック高(sourceBlock)と検証コードのバージョン(version)に加えて、資金返還を行うトランザクションがState Change Actionsとして記述されます。 State Change Actions この中には送金元のアドレス(凍結資金が保管されているアドレス)と送金先のアドレス(合計500ETHを送金した100人のアドレス)と返金するべき金額など、トランザクションの情報が具体的に記載されます。 (ERPの構造) ERPが承認されるまでの流れ EIPコミュニティに投稿されたERP原案は、以下の2つの立場の人たちからのフィードバックを受け、最後にEIP編集者の承認を受けます。 この資金凍結の関係者 プロジェクト関係者や実際に送金を行った投資家などがあたります。 特に被害に遭った投資家は、ERP原案のState Change Actionの中に確かに振り込んだ金額のETHが自分のアドレスに戻るようなコードが書かれているかを確認し、何かしらの誤りがあればコミュニティ上で指摘することができます。 非関係者 この資金凍結に関係が無い立場の人間が、検証コードに書かれている内容などが正しく実際に発生した事を記述できているか、これが実行された際に正しい資金凍結の解除がされるのかを判断します。これは裁判で言う陪審員や裁判官の役割に近いでしょう。 EIP編集者(EIP Editorship)による承認 フィードバックの期間は最低でも30日程度が必要だと述べられています。このフィードバック作業は、公開にて行われコミュニティ上では色々な議論が巻き起こるはずです。そして最終的にEIPの編集者が、コミュニティでの議論内容を踏まえてこのERPの提案を承認(Accept)するかを決定します。 ここで承認された提案はEIP可決案となり、公式なイーサリアムのアップデートとしてイーサリアムネットワークに拡散されることになります。 (ERP承認までの流れ) ERP承認から資金凍結解除までの流れ クライアントノードに伝わったERP可決案は、それぞれのクライアントノードで実行されていきます。まず検証コードが実行され、この時確かに検証内容が正しいと判断された場合には、State Change Actionsを含むState Change Objectを生成し、実際に資金凍結解除のトランザクションがイーサリアムネットワーク上に書き込まれていきます。 通常のトランザクション同様に、この凍結解除処理トランザクションも一定の時間が経過すれば有効となり、無事凍結した資金は送金者の元に戻っていくことになります。 (可決されたERP案はクライアントノードにて実行される) 以上がEIP-867で提案された凍結されたETHの取り戻しに関する仕組みになります。しかし凍結資金の取り戻しは非常にセンシティブな問題であり、議論が間違った方向に進めば誤って人の資金を不正に送金するツールになってしまう可能性も孕んでいます。後半の記事ではこの様なEIP-867に関して巻き起こっている様々な議論について解説していきます。
Lightning&Raiden ビットコインとイーサリアムのオフチェーン技術とは?

Lightning&Raiden ビットコインとイーサリアムのオフチェーン技術とは?

2018/02/10 at 3:28 PM 0 comments
  スケーラビリティ問題 ビットコインやイーサリアムを始めとした仮想通貨は近年非常に注目されており、利用者は急激に増加しています。そこで問題になるのが利用者の増加にシステムが追いつかなくなり送金・着金に非常に長い時間がかかってしまう「詰まり」と呼ばれる現象です。 本メディアでは過去の記事で、この「詰まり」がなぜ発生してしまうのか解説しています。これの問題はスケーラビリティ問題と呼ばれており、これを解決する有力な方法の一つとして、ステートチャネルを利用したオフチェーン処理が開発されています。 これは具体的にはビットコインでは「Lightning」、イーサリアムでは「Raiden」という名前で開発が進められています。 本記事ではステートチャネルについて簡単に触れた上で、LightningとRaidenについて紹介します。 オフチェーン処理 オフチェーン処理とは、本来ブロックチェーンの上で行われる取引を、ブロックチェーンに書き込まずに行うことを意味します。 トランザクションの詰まりの原因は、そもそもブロックチェーンがある時間内に処理できるトランザクションの量に限りがあるからです。この時間内で処理できる取引数は、ビットコインで1秒あたり7件程度、イーサリアムで15件程度とされています。 そこで、取引の一部をブロックチェーンに書き込まないオフチェーン処理を利用することによって、実際のブロックチェーンに書き込まれる取引数を減らし、時間あたりの取引数制限の影響を大幅に減らすことができるようになります。 オフチェーン処理の分かりやすい例として、「取引所内での取引」を挙げましょう。本来ビットコインの取引が成立するまで30~60分待つ必要がありますが(詰まりが起こればこれ以上に待ち時間は長くなります。)、取引所内での取引が一瞬のうちに完了するのは、取引所内での取引はブロックチェーンに書き込まれず、取引所のサーバー上でのみ処理されているからです。 ただし、取引所におけるオフチェーン処理のセキュリティ管理は各取引所によるため、オンチェーン処理ほど安全ではありません。そこで、このようなオフチェーンの取引をセキュアに個人間でも実現しようとしているのがLightningやRaidenです。 ステートチャネル ​LightningとRaidenは共に、ステートチャネルと言われる技術に根ざしています。ステートチャネルとは「ある2者間でオフチェーン取引を行うための場」の事を指します。 一つのステートチャネルでは、チャネルが開かれてから決められた時間内で起こった取引については、ブロックチェーン上に記録されません。 そしてチャネルを終了する時(予め決められた時間内か、又は両者がチャネルを閉じる事に同意した時)、元々の2者の残高から、チャネル内の全ての取引を行った後の2者の残高になるよう、ブロックチェーンに取引が記録(オンチェーン処理)されます。 特に金銭の支払いに関するステートチャネルのことを、ペイメントチャネルと呼びます。 ここで、AさんからBさんへのペイメントチャネルを用いた支払いについて考えます。 Aさんは、Bさんが経営するカフェの常連客で、週に5回もやって来て数百円のドリンクを注文し、ビットコインで支払おうとしています。ビットコインでの送金手数料が1回0.001BTCだとすると、Aさんは手数料だけで週に0.005BTC(1BTC=100万円だとして5000円)も支払うことになります。 また支払いがブロックチェーン上で承認されるまで、毎回1時間ほど待たなければいけません。 そこでAさんは、Bさんとの間にペイメントチャネルを作りました。このチャネルの有効期間が1週間だとすると、この期間の間にAさんがカフェで支払った5回の支払いは全てペイメントチャネル上で行われブロックチェーンに記録されません。そして、1週間が経過してペイメントチャネルを閉じる時、AさんからBさんへ支払った総額が計算され、一つのトランザクションとしてブロックチェーンに記録されます。 このような取引の方法を取ることで、ペイメントチャネルの中で取引を行う分には手数料が掛からず、またマイニングによる承認も必要ない為、ブロックが承認される時間を待つ必要ありません。 ペイメントチャネルを利用するために掛かる手数料は、最後にチャネルを終了する際に、Aさん・Bさんの最後の残高の状態を反映する為に行うトランザクションにかかる手数料だけになります。 ステートチャネルを利用したオフチェーンでの支払いの仕組みについては、こちらの記事で詳しく解説されています。 LightningやRaidenが実現されれば、この手数料の掛からない2者間でのステートチャネルが、複数の参加者の間に複数ある場合でも、ネットワークを辿って支払いが可能になります。この仕組みを利用することによって、以下のメリットがもたらされます。 スケーラビリティ問題の解決 ステートチャネル内で行われた支払いは、ブロックチェーン上には記録されません。そのため、十分なステートチャネルが存在すれば、理論的には現在の数千〜数万倍の数のトランザクションの処理が可能になると言われており、現在問題になっているトランザクションの詰まりの問題を解決することが期待されています。 手数料の削減 1つのステートチャネルを使用する際の手数料だけを支払えば、ステートチャネル内での支払いに対する手数料は実質掛からなくなります。これは一回のトランザクションの手数料を大幅に安くすることを意味しています。 トランザクション処理の高速化 ステートチャネルでの支払いは、マイニングによる承認が必要ないので非常に高速に行う事ができます。 LightningとRaidenの相違点 Bitcoin Lightningとイーサリアム Raidenの考え方は、どちらもステートチャネルが複数繋がったネットワークを利用して、オフチェーンで取引を行うという仕組みを採用しており、基本的にアイディアは同じです。但し両者の間には、利用目的の違いがあります。 ビットコインは元々、ブロックチェーンを利用した新しいお金として開発されており、Lightningネットワークはビットコインを通じた支払いを、より便利に行う事を目的にしています。 対してイーサリアムは、お金としての機能に加えて、分散型アプリケーション(DApps)やスマートコントラクト機能を持つトークンが利用できるプラットフォームとして開発されており、RaidenネットワークではDAppsの運用やトークンの交換をサポートしています。 例えばRaidenを使うことによって、Youtubeに代わる分散型のDTubeというサービスを作ることもできます。DTubeはイーサリアム上で動作するDAppsであり、DTuber(YoutubeでのYoutuber)は一定の金額以上を獲得しないと広告料が引き出せないYoutubeと違い、自分の動画が見られたその瞬間に少額の広告料の支払いを得る事が可能になります。 “Additionally, many decentralized applications can run on the speed and scalability of the Raiden Network. For example, a decentralized payment appreciation service. Think of dTube, Steem's decentralized video service, yet instead of creators being paid only when the user chooses to upvote them, they get paid constantly for every second watched. This can set things up to compete better with Youtube, where creators are paid for every ad watched, yet get rid of all of the paywalls and ads in the process.” (引用:https://steemit.com/bitcoin/@mooncryption/scaling-cryptos-bitcoin-lightning-network-vs-ethereum-raiden-network) その他にもRaidenでは、イーサリアム準拠のトークンを扱えることから、分散型取引所(DEX)への応用にも期待されています。DEXについては本サイトのこちらの記事に詳細が解説されています。 LightningとRaidenの開発状況 LightningのDeveloperチームがMediumに掲載したポストによると、Lightningは全てのテストを完了し、現在実際のビットコインのメインネットで動かすことができる1.0RC版がリリースされています。 実際にLightning LaboのYoutubeページでは、Lightningを使って高速にコーヒーの支払いを行っているデモ動画が上がっており、たった1秒ほどで支払いが完了している事が確認できます。 また2018年1月24日には、シリコンバレー地区のあるコーヒーショップでBitcoin Lightningを利用した支払いが始まったようです。 Setup Backyard Brew https://t.co/aGFHfUOfMP with a Lightning-Mainnet coffee storefront interface. If you are near Palo Alto come by if you want to test buying coffee with Lightning! I bought the first cup, coffee tastes so much better with Lightning 😬 pic.twitter.com/8JWo3gcCbR — Alex Bosworth ☇ (@alexbosworth) 2018年1月23日 イーサリアムのRaidenについても、既にイーサリアムのテストネットであるRopsten上で動かすことができるRiden Network v0.1.0が公開されています。 LightningとRaidenの懸念点 これら2つのアルゴリズムが用いているステートチャネルには、いくつかの懸念や問題点が提起されています。 ルーティング問題 1対1でのステートチャネルでの支払いの考え方はとてもシンプルです。しかし、これがステートチャネルを連結させたネットワーク上での話しになると、どのステートチャネルを経由すれば目的の取引を効率的に成立させられるのかを計算する必要があります。 これはルーティング問題として議論されていましたが、現在ではインターネットで用いられているBroader Gateway Protool(BGP)に似た手法を用いて解決されています。 流動性の問題 ステートチャネルを介した多くの支払いが成功するには、ある程度の金額がデポジットされたステートチャネルができるだけ多く開かれていて、かつオンラインである必要があります。 しかし、ユーザーが多くの仮想通貨をデポジットしておくことは、オフチェーン処理にとって良いことではありますが、そのユーザー個人には何の利益もありません。 よって、ステートチャネルネットワークには十分な流動性が確保されないという問題があります。数学的なシミュレーションからも、ステートチャネルネットワークを利用したシステムが非合理的であるといった厳しい批判も見られます。 まとめ 近年急激にユーザーが増加し、スケーラビリティ問題に直面しているビットコインやイーサリアムについて、それぞれの解決策として開発されているLightningとRaidenについて解説しました。 ステートチャネルネットワークを利用することによって、大きく利便性を向上することが期待されますが、まだモデルとしては不完全な部分があるのが現状です。しかし、両者共に積極的に新しい解決策が提案されており、問題が解決されリーズナブルな処理が実現されるのも時間の問題なのかもしれません。
ビットコインやイーサリアムの保管、仮想通貨ウォレットの種類や仕組み

ビットコインやイーサリアムの保管、仮想通貨ウォレットの種類や仕組み

2018/02/08 at 7:42 PM 0 comments
ビットコイン(Bitcoin,BTC)やイーサリアム(Ethereum,ETH)をはじめとした仮想通貨、ホット/コールドウォレットやハードウェアウォレット等、様々な保管方法があり、セキュリティ対策が必要です。日本の大手取引所コインチェックで盗難事件が起き、仮想通貨のセキュリティに関心を寄せた方も多いでしょう。 本記事では、仮想通貨取引所に保管するリスク、ウォレットの種類や特性を解説し、適切な保管方法を考察します。仮想通貨における暗号技術や送金の仕組み、セキュリティに関する基礎について詳しく知りたい方は、こちら。 取引所で頻発していた盗難事件 コインチェック事件 2017年1月26日に、ビットコインやイーサリアムなどを取り扱う日本最大手の仮想通貨取引所/販売所の「Coincheck」に保管されている、5億2300万XEM(約580億円相当)がハッキングされました。読者の皆さんにも被害に遭われた方がいたのではないでしょうか。Coincheckは被害に遭った26万人に対する全額保証を発表しましたが、日本では仮想通貨への不安感を強く印象付ける事件となりました。 過去の盗難事件 しかし、日本のメディアではあまり報道されていないだけで、同様の被害は世界中で発生しています。仮想通貨に関するハッキング被害は一番有名なもので、2011年にあったマウントゴックス(Mt.Gox)での75万ビットコインの消失事件(2018年1月31日の価値にして約8000億円に相当)。最近では、2017年12月19日にも、韓国の仮想通貨取引所Youbitが、当時での換算レートで約7600万円相当の資金をハッキングによって盗難されています。 過去にあった仮想通貨取引所の大規模なハッキング被害についてはCoinDatabaseにまとめられています。 取引所に預けている仮想通貨は安全? これらの事件から総じて学べることは、取引所に預けることが安全とは言い切れないという事です。そこで本記事では取引所より安全と言われている仮想通貨の保有方法であるウォレットでの保管の基本的な仕組みや、種類、そしてそれぞれの特徴について解説します。 仮想通貨のウォレットとは? 仮想通貨はブロックチェーン技術に基づいています。ブロックチェーンの基本的な仕組みについては過去の記事を御覧ください。また、この記事をより深く理解するために、仮想通貨の取引で用いられる公開鍵と暗号鍵に関する記事を読むことをお勧めします。 仮想通貨のウォレットとは簡単に言ってしまえば、その名の通り仮想通貨を保管する ”お財布” です。ですが厳密には仮想通貨の所有権を示す ”秘密鍵” と呼ばれる文字列がその中に保管されています。 仮想通貨の管理は全て秘密鍵によって行われます。秘密鍵を使うことでその鍵に紐付いた資金をブロックチェーン上で動かすことができます。逆にこの秘密鍵が盗み出されることは、その鍵に紐付いた資金が盗まれることと同然だと言えます。 仮想通貨取引所が被害に合っているハッキングでは多くの場合、顧客から預かっている大きな金額の仮想通貨が紐付いた秘密鍵が盗み出される事で被害が発生しています。 取引所での保管 取引所で仮想通貨を管理していると、パソコン・スマートフォンのブラウザから、取引所のサイトにアクセスして利用することができます。取引所では、秘密鍵の管理を自分で行う必要はなく、必要な処理は全て取引所側が行います。 そのため、仮想通貨に関する知識が無くても、メールアドレスとパスワードでログインするだけで送金・受金・交換などの取引ができ、便利である反面、セキュリティは取引所に委ねられます。また取引所によって、セキュリティの高さはまちまちであり、そのセキュリティレベルは外部の利用者からはなかなか分かりません。 加えて、どんなにサービス自体のセキュリティが高くとも、サービスにログインするパスワードを盗み出されてしまってハッキング被害に合うというケースもあります。TNWの記事によると、香港の仮想通貨取引所「Binance」の偽サイトを通じて、ログインパスワードが盗み出された被害が報告されています。 bitFlyerでは、この様な事態に備えて、三井住友海上火災保険と保険契約を提携しており、不正ログインにて日本円が出金された際には500万円まで保証するサービスを行っています。 セキュリティレベルを高める努力を行なっている仮想通貨取引所ですが、多くのユーザーの資金を一括で管理している限り、ハッキングの攻撃対象になることは避けられません。この点で、取引所に仮想通貨を預けるということは、ウォレットでの保管よりも危険と言えるでしょう。 取引所のメリット・デメリット ○仮想通貨の知識が無くても簡単かつ便利に利用できる ○どこからでもブラウザを通じてアクセスできる ○場合によっては取引所側での補償制度がある ☓セキュリティレベルは取引所に委ねられている ☓ハッキングの対象になりやすい 仮想通貨のウォレットでの保管 ウォレットと一口に言っても、その形や特長に幾つかの種類があります。以下に代表的なウォレットとそのメリット・デメリットをまとめます。 ローカルウォレット(クライアントウォレット) ローカルウォレットは、自分のパソコンやスマートフォンに、それぞれの仮想通貨専用のソフトウェアをインストールして使うタイプのウォレットです。ビットコインのBitcoin coreが代表的なものとして挙げられます。 ローカルウォレットでは、秘密鍵の情報は自分のパソコン・スマートフォンに保存されるので、紐付けられた仮想通貨を完全に自分の手元で管理していることになります。ローカルウォレットでは、状況に応じてオフラインでの管理なども可能であり、自分で適切に管理することで、取引所より安全に仮想通貨を管理できます。 しかし、秘密鍵はウォレットがインストールされている端末に保存されているので、他の端末では仮想通貨を管理できないことや、その端末がウィルスに感染したり故障した際に、仮想通貨が盗まれてしまったり、取り出せなくなってしまうことがありえます。 ローカルウォレットのメリット・デメリット ○仮想通貨を自分で管理(取引所の倒産・サービス停止の影響を受けない) ○仮想通貨取引所に比べて安全性は高い ▲自分で秘密鍵の管理が必要(ある程度の仮想通貨の知識が必要) ☓パソコンのウィルス感染によるハッキング、故障による損失の可能性 ペーパーウォレット 仮想通貨の秘密鍵を紙に印刷して保存する方法が、ペーパーウォレットです。ペーパーウォレットはインターネットから隔離されているので、ハッキングをすることはできず、印刷された秘密鍵を誰にも見られることが無い限り、最も安全に仮想通貨を保管することができます。 ペーパーウォレットは以下の作成支援サイトから印刷して作成することができます。 Bitcoin: https://www.bitaddress.org/ Ethereum: https://www.myetherwallet.com/ しかし、ペーパーウォレットはただの暗号文字列が書かれた紙であり、他のコンピューター上で使うウォレットでできる、残高の確認や取引の作成などの基本的な機能はもちろんありません。 このような作業をペーパーウォレットで行うには、ウィルスに感染していない安全なパソコンを使ってペーパーウォレットの暗号鍵を読み込む必要があります。また、物理的にペーパーを紛失した際に、仮想通貨が取り戻せないので管理方法には気をつけなければいけません。 ペーパーウォレットのメリット・デメリット ○ハッキングされることはない ○紙などに印刷して簡単に管理可能 ☓操作性が悪い(資金移動、残高の確認などが単体でできない) ☓盗難や紛失の可能性 ビットコインペーパーウォレットの例(https://www.bitaddress.org/にて作成) ハードウェアウォレット ハードウェアウォレットはペーパーウォレットの安全性と、ローカルウォレットの利便性を併せ持ったウォレットです。その見た目は小さなデバイスであり、数多くの仮想通貨の保管に対応している「Ledger Nano S」や、古くからハードウェアウォレットとして定評のある「Trezor(トレザー)」があります。 ハードウェアウォレットでは、ペーパーウォレット同様に秘密鍵がインターネットから隔離されます。この秘密鍵は、ハードウェアウォレットの中の専用のICチップに保管されており、パソコンやスマートフォンから簡単にアクセスして、秘密鍵に紐付いた資金を移動させたりすることができます。 ハードウェアウォレットに保存した秘密鍵を使用する際には、専用のパスコードの入力が求められるようになっているので、ペーパーウォレットと違い、もしそのウォレットを誰かが盗んでも悪用することは簡単にはできません。 また、紛失や故障の際には、事前に紙に書き留めた復元用キーワードを使って、全ての資金を新しく購入したハードウェアウォレットに移動が可能です。 総合的に見ても、数あるウォレットの中でも便利かつ安全なハードウェアウォレットですが、唯一のデメリットとしては、購入時のコストや手に入れるまでの時間がかかることです。 ハードウェアウォレットは、改造されている可能性などを避けるために新品を正規販売社から購入する必要があります。2018年1月31日現在、Legder Nano Sは79EUR(約10,700円)、Trezorは89EUR(約12,000円)であり、Ledger Nano Sについては在庫がなく最短の発送まで2ヶ月程待つ必要があります。 ハードウェアウォレットのメリット・デメリット ○ハッキングの可能性は極めて低い(ペーパーウォレット並のセキュリティ) ○操作性が高い(資金移動、残高確認などPCに接続して簡単に行える) ○紛失時の安全性・バックアップ ☓購入時のコスト、時間 (左: Ledger Nano S, 右: Trezor, それぞれ公式サイトより) ハードウェアウォレットでの保管が現実的か? ここまでで、ハッキングの攻撃対象になりやすい仮想通貨取引所に対して、ローカルウォレット、ペーパーウォレット、ハードウェアウォレットで保管する方が原理的に安全であるという事を解説しました。 これら3つのウォレットは、確かに原理的にはどれも安全であると言えます。しかし、現実的にこれらのウォレットを準備する流れを考えると、ローカルウォレットは常にウィルスに感染していないコンピューターで使用する必要があり、ペーパーウォレットも作成から印刷までの経路では、ウィルスに感染していない事が確認できたコンピューターを使用する必要があります。どれだけ安全なウォレットであっても、作成時にその情報が誰かに盗まれてしまえば、対策のしようはありません。 ハードウェアウォレットは購入コストがかかってしまいますが、この安全なコンピューターを用意するという最も面倒な問題を解決します。 詳細な説明は割愛しますが、ハードウェアウォレットでは組み合わせて使用するコンピューターに、マルウェア・キーロガー・ウィルスといったものが侵入していても、秘密鍵の作成や使用時にコンピューター単体ではその情報が読み取れない仕組みがあります。 この仕組みによって、正しい方法で購入したハードウェアウォレットさえあれば、併せて使用するコンピューターの安全性を証明できない状態であっても、安全な仮想通貨の保管や取引を実現することができます。 保有する仮想通貨の金額にもよりますが、自分が所有している仮想通貨に対する安全をお金で購入することができるのがハードウェアウォレットの特徴だと言えるでしょう。 ウォレットにまつわる事件簿 本記事では仮想通貨をより安全に保存する各種のウォレットについて紹介しました。記事ではそれぞれのウォレットが何故安全なのかを簡単に示しましたが、現実にはウォレットの仕組みを悪用して内部の仮想通貨が抜き取られる事件が多数起こっています。 仮想通貨の保管については、100%安全な手法は存在しません。例え最も安全だと言われているハードウェアウォレットでも、幾つかの被害事例が報告されており、その安全性を過信するべきではありません。むしろ自分の保管方法が潜在的に孕んでいる危険性を知っておくことが、最大のリスクヘッジになると筆者は考えています。 そこで本記事では、最後に過去に起こったそれぞれのウォレットのハッキング事件について紹介します。仮想通貨の保管は、ハッキングや偽物のサービスを提供する詐欺師とのイタチごっこです。過去の事例を学んで自分の保管方法を再度考え直してみましょう。 ペーパーウォレットにまつわる事件 ペーパーウォレットが作成できるMyEtherWalletの偽サイトMyEther”a”Walletが発見される。https://steemit.com/ethereum/@dhumphrey/scam-warning-fake-myetherwallet-phishing-site また同サービスのiOS版にも偽物が登場し、一時App Storeランキングで3位になる。(既に削除済)https://www.blockchain-labo.jp/news/fake-app ハードウェアウォレットにまつわる事件 非正規販売者から購入したハードウェアウォレットに付属のキーワードを使用したことが原因で、保存した仮想通貨が盗難。本来自分で決定する復元用コードが、紙に印刷されて販売者によって同梱されていた。http://doublehash.me/do-not-buy-hardware-wallet-from-amazon/ ハードウェア的な脆弱性を利用して、Trezorの復元用キーワードを本体から抽出に成功。 (これは本体のファームウェアバージョン1.5.2以上で対策済) https://www.wired.com/story/i-forgot-my-pin-an-epic-tale-of-losing-dollar30000-in-bitcoin/
ビットコインやイーサリアムの保管、仮想通貨の公開鍵と秘密鍵

ビットコインやイーサリアムの保管、仮想通貨の公開鍵と秘密鍵

2018/02/08 at 7:35 PM 0 comments
ビットコイン(Bitcoin,BTC)やイーサリアム(Ethereum,ETH)をはじめとした仮想通貨、ホット/コールドウォレットやハードウェアウォレット等、様々な保管方法があり、セキュリティ対策が必要です。日本の大手取引所コインチェックで盗難事件が起き、仮想通貨のセキュリティに関心を寄せた方も多いでしょう。 本記事では、仮想通貨における暗号技術や送金の仕組み、セキュリティに関する基礎を技術的に解説します。どのウォレットに保管すべきか詳しく知りたい方は、ウォレットの記事をご覧ください。 Coincheck NEM盗難事件 2018年1月26日、日本の大手取引所 Coincheckから5億2千3百万XEM(時価580億円相当)がハッキングされるという事件がおきました。XEMの総発行数は約90億ですので、全体の6%ほどが盗まれたことになります。また実際に被害を受けたアカウント数は、約26万とアナウンスされています。被害総額・人数が非常に大きいことから、仮想通貨史に名を残す大事件であったと言えるでしょう。 この事件を巡っては、Coincheckのセキュリティ管理の甘さが指摘されています。確かに、取引所として然るべきセキュリティ対策を怠っていたことは、重大な問題です。ただ、この事件を取引所だけの出来事として捉えるのではなく、ユーザー側の仮想通貨に関するリテラシーを改善する機会として捉えることもできます。 今回の記事では、仮想通貨のセキュリテイを支える公開鍵暗号方式(公開鍵/秘密鍵)とその他の技術(マルチシグ/コールドウォレット)を紹介します。この記事を読むことで、仮想通貨をより深く理解し、安全に保管できるようになるでしょう。 公開鍵暗号方式 ビットコインやイーサリアムをはじめとする仮想通貨を送金する際には、“秘密鍵”と“公開鍵”と呼ばれる二つのペアになった暗号鍵が使われています。この秘密鍵と公開鍵を用いた仕組みは、公開鍵暗号方式と呼ばれています。この暗号化の仕組みは、仮想通貨だけではなく、暗号化を必要とする様々な通信において利用されています。 秘密鍵、公開鍵は、その名前からイメージできるように、それぞれ“秘密にしておくべき鍵”と“公開してもよい鍵”です。秘密鍵はランダムに生成され、公開鍵は秘密鍵から生成されます。しかし公開鍵から秘密鍵を知ることはできません。ですので公開鍵が公開されているからといって、他人があなたの秘密鍵を推測できる訳ではありません。 まずは、仮想通貨における秘密鍵と公開鍵の役割を解説する前に、公開鍵暗号方式をより深く学んでみましょう。データの送信者と受信者の間において、どのようにして秘密鍵と公開鍵を利用して暗号化/復号化を実行するか説明します。 データの送信者は、受信者が公開している公開鍵を取得する。 データの送信者は、取得した公開鍵を用いてデータを暗号化&送信する。 データの受信者は、秘密鍵を用いてデータを復号化する。  公開鍵を用いて暗号化されたデータは秘密鍵でしか復号化することができません。つまり、公開鍵暗号方式のポイントは、開けることしかできない鍵と閉めることしかできない鍵が存在するということです。 このやり取りは、“南京錠(公開鍵)”と“南京錠の鍵(秘密鍵)”の関係に非常に近いです。南京錠と南京錠の鍵の例を用いて、再度、暗号化/復号化の手順を考えてみましょう。 データの送信者は、受信者から南京錠をもらいます。この時、南京錠の鍵は開いたままです。 送信者は、もらった南京錠を用いてデータに鍵をかけ、送信します。 データの受信者は、南京錠の鍵を用いてデータに付けられた南京錠を開けます。 南京錠を使った例は非常に分かりやすいですね。この例を通じて、開けることしかできない鍵(南京錠の鍵)と閉めることしかできない鍵(南京錠)の重要性がわかったかと思います。 電子署名 さて、先ほどの例では公開鍵を暗号化、秘密鍵を復号化に使用しましたが、この逆は可能でしょうか。つまり秘密鍵を暗号化、公開鍵を復号化に使用するということです。 これは実際に可能で、秘密鍵を閉めることしかできない鍵、公開鍵を開けることしかできない鍵、として利用することができるのです。 ここで疑問となるのが、公開鍵は公開されているのだから、秘密鍵で暗号化したところで、誰にでも復号化されてしまうのではないか?ということです。一見すると、このような暗号化は無意味に思えるかもしれません。 しかし秘密鍵での暗号化は、送信者の「電子署名」として利用することができるのです。例を考えてみましょう。 データの送信者は、自分自身の秘密鍵を用いて、データを暗号化する。 データの送信者は、同時に、自分自身の公開鍵を公開する。 データの受信者は、公開鍵を取得し、データを復号化する。  この一連の流れによって、受信者は、データが確かに送信者のものであると確かめることができます。なぜならば、受信者がデータを公開鍵で復号化できるということは、そのデータが送信者の秘密鍵で暗号化されていることに他ならないからです。秘密鍵は送信者しか持っていませんので、署名したのが送信者本人であるという理屈は成り立ちます。 秘密鍵を用いた仮想通貨送金プロセス 仮想通貨における秘密鍵・公開鍵の利用方法を考えて行きましょう。送金は以下の手順で実行されます。 Aさんは、送金情報を自分自身の秘密鍵を用いて“電子署名”する。 Aさんは、この電子署名された送金情報と自分自身の公開鍵をセットにして、ビットコインネットワークに送信する。 Bさんは、公開鍵を用いて、電子署名された送金情報の有効性を確認する。 このように秘密鍵を用いた電子署名によって、送金情報がAさんのものであると証明することができます。 では秘密鍵が盗まれてしまった場合はどうなるでしょう?秘密鍵を盗んだ人は、その秘密鍵を使って電子署名ができる=送金することができるので、あなたの仮想通貨は盗まれてしまうことになります。秘密鍵は仮想通貨を送金できる唯一の鍵です。絶対に他人に知られてはいけません。 秘密鍵の管理 取引所での管理 Coincheckのハッキング事件でも問題になりましたが、多くの人が取引所に仮想通貨を預けているのが現状です。通常、取引所に預けている仮想通貨の秘密鍵は、取引所が保管しており、ユーザーが目にすることはありません。 秘密鍵は絶対に他人に知られてはいけないものですが、それを取引所が管理している(預けている)ということは、ユーザーが取引所を信用していることに他なりません。 取引所も秘密鍵の保管には細心の注意を払っていますが、残念ながらハッキングによって秘密鍵が盗まれ、送金されてしまう事件は度々起きています。 取引所に預けているからといって、あなたの仮想通貨が100%安全であるという保証はどこにもないのです。 ウォレットでの管理 取引所に仮想通貨を預ける以外に、ウォレットを利用する方法があります。 ウォレットには、その種類・性質に応じてホットウォレット、コールドウォレット、ハードウェアウォレット、ソフトウェアウォレットなどの分類が存在しますが、どれもお財布のようなものだと思っていただいて構いません。ウォレットに関する詳細は、本メディアのウォレットに関する記事が参考になるでしょう。 ウォレットの利用においては、秘密鍵の保管はユーザー自身に任されています。取引所に秘密鍵を預けていない分、セキュリティが高いように思えます。しかし、あなたが保管する秘密鍵が誰かに盗まれてしまう可能性がありますし、また秘密鍵を紛失してしまう可能性もあります。あくまでも自己責任において保管しなければならず、盗まれてしまった場合は誰も補償してはくれません。 セキュリティを高める技術 秘密鍵の保管が仮想通貨の保有において非常に大切であることは、先に述べた通りです。以下では、秘密鍵をより安全に保管するいくつかの方法について解説します。 マルチシグ 秘密鍵を複数に分割し分散して保管する手法があり、これは”マルチシグ”と呼ばれています。複数に分割された秘密鍵が一定数以上揃わない限り、送金が実行できない仕組みになっています。 いくつの秘密鍵を揃えば送金ができるかに関しては、“2/3”のように表記されています。この意味は、3つに分割された秘密鍵のうち、2つで署名が行われた場合に送金を実行する、ということです。 分割された秘密鍵は、通常異なる場所に保管されるため、ハッキングによる仮想通貨流出のリスクを下げることが可能です。マルチシグに対応した一部の取引所やウォレットは、高いセキュリティを提供していると言えるでしょう。 マルチシグを用いることで、確かにハッキングのリスクを下げることができますが、100%安全という訳ではありません。もし取引所が保管する分割された秘密鍵が一箇所で保管されていたらどうなるでしょう。これは秘密鍵を分割していないに等しく、ハッキングされた場合はマルチシグの意味がありません。 実際に取引所がどのようにして分割された秘密鍵を保管しているかは明らかにされていない場合が多く、ブラックボックスとなっています。とはいえ、マルチシグに対応した取引所が絶対に安全であるという確固たる保証はありませんので、取引所の利用には十分に注意しましょう。 コールドウォレット 秘密鍵が盗まれてしまうことが問題ならば、インターネットから隔絶したウォレットに保管すれば安心かもしれません。このようなインターネットから切り離されたウォレットのことを“コールドウォレット”と呼んでいます。一方で、インターネットに接続されたウォレットのことを“ホットウォレット”と呼びます。 コールドウォレットの種類としては、秘密鍵を紙に書き出して保管する“ペーパーウォレット”や、特別なデバイスに入れて保管する“ハードウェアウォレット”が存在します。 しかしコールドウォレットも100%安全であるとは言えないでしょう。例えばペーパーウォレットを物理的に盗まれたり、紛失してしまった場合には、仮想通貨を失ったことと同じになります。金庫等で保管するといった、さらなる対策も必要になるでしょう。 まとめ 仮想通貨のセキュリティを支える技術として公開鍵暗号方式を紹介しました。その中でも特に、秘密鍵が仮想通貨の送金において重要な役割を果たしていることは理解していただけたと思います。 秘密鍵の管理に細心の注意を払うことはもはや大前提です。確かに、マルチシグやコールドウォレットを使うことで、ハッキングの被害に遭う確率は下げることができます。しかし、今回の事件のように、取引所内に保管していては、肝心の秘密鍵は取引所任せとなってしまいます。取引所にある、あなたの仮想通貨も自身のコールドウォレットに移した方がいいかもしれません。