タグ: "EIP"

イーサリアムアドレス 〜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に関して巻き起こっている様々な議論について解説していきます。
【イーサリアム】EIP156が脆弱性を改善

【イーサリアム】EIP156が脆弱性を改善

2017/11/20 at 7:52 PM 0 comments
  イーサリアムのParity(パリティ)事件後、EIP(Ethereum Improvement Proposal:イーサリアム改善提案)No.156が見込みのある解決策として提案されました。パリティ事件以外にも、EIP-156は改善に大きく役立つことになります。 THE DAO事件(イーサリアム上のスマートコントラストを利用した新プロジェクトICO時に起きたハッキング事件)の数か月後、2016年10月14日、イーサリアムの創設者であるVatalik ButerinがGitHub上でEIP-156を提案しました。仮想通貨/暗号通貨ウォレット「パリティ」におけるバグの影響で500,000イーサリアム以上が凍結したことを受けて、この案は「凍結したイーサリアムの復活システム」と評されました。 EIP-156はハードフォーク(ブトックチェーンを分岐させ新ルールを適用する仕様変更の方法)によって実行され、パリティの深刻な問題に見込みある解決策として挙がっていたのです。あいにく、ブロックチェーン企業ConsenSysの開発者Alex Millerは、それを単純な問題ではないと注意しています。 Note: EIP156 does not apply to the Parity situation. EIP156 covers contracts with no code. Parity multisigs have code - dependency is erased — Alex Miller (@ethereum_alex) 2017年11月7日 パリティの件を考えなくとも、とにかくEIP-156はイーサリアムの脆弱性の改善に成功し、完全にその脆弱性を修正できた、ということなのでしょうか。 理論的に考えると、「EIP-156はコードを用いず誤ってつくられたコントラクトから資産を引き出すことを可能にする」とButerinは説明しました。よりわかりやすく言うと、あなたが存在しない事業に間違って小切手を送ってしまったことを想像してください、EIP-156が適切に働けばその取引を元に戻すことができるということです。 実行されれば、そのプロトコルは「イーサリアムアドレスを間違った計算した旧Ethereum JavaScript library」の脆弱性を改善します。さらにEIP-156は、「ETC(イーサリアムクラシック)で作成されたコントラクトによるリプレイアタックの損失や、ETHでコントラクトが作成されていないETHの送金」も処理するとButerinは記述しています。 EIP-156が悪意を持って使われることを心配する暗号通貨/仮想通貨の持ち主もいます。しかし昨年、Buterinはこの心配は不要だとしており、「すべての場合で資産の〝正当な所有者〟は明らかで数学的に証明可能であり、資産が奪われるユーザーもいない、そしてこの提案は個人のアカウントや申請に対して贔屓することはない。」と言及しました。 Buterinは先制して分析しています。「これらの提案は以上の理由でこれまでより立ち入ったものではあるが、EIP-156は、議論を伴って“技術改良”というより”救済”といった観念で、議論を伴い、またみなされるリスクがあるかもしれない。EIP-156の提案はコミュニティーの議論や討論を可能にするためにつくられたもので、完全な支持を表しているわけではない。」   (ソース元記事:https://www.ethnews.com/rescuing-stranded-ether-with-ethereum-improvement-proposal-156)
イーサリアム改善提案(EIP)No20が完了し、ERC20規格を正式に制定

イーサリアム改善提案(EIP)No20が完了し、ERC20規格を正式に制定

2017/09/12 at 9:18 PM 0 comments
2017年9月11日、Ethereum Improvement Proposal (EIP) 20 (イーサリアムプラットフォームの基準を改善するために、Github上で数々の提案が行われている:そのNo20)がEthereumブロックチェーンに正式に採用されました。 このEIP20の提案は、ERC20トークンの標準を定めるために起票され、Ethereum Foundationの開発者であるFabian VogelstellerとVitalik Buterin(Ethereumの創設者)によって、記述されたものです。2015年11月19日に作成され、現在「完了したEIP」として承認されたことによって、正式にERC20トークンの標準が制定されました。 これはEthereumベースのトークン、ERC20のAPI標準を正式に確立したことを意味しています。 EIP20の要約で下記のように説明されています。 "この標準[ERC-20]は、トークンを転送するための基本的な機能を提供するだけでなく、トークンを承認して、他のチェーン上の第三者が使用できるようにします"   標準化されたAPI(アプリケーション・プログラミング・インターフェース)は、ウォレット、取引所、およびその他のアプリケーションの互換性をサポートすることになります。 過去数ヶ月にわたって、非公式のERC20標準に準拠した多くのトークンが発行されました。ERC20の起源と相互運用性の重要性を探った記事はこちらです。   ライター:マシュー・デ・シウバ/MATTHEW DE SILVA マシューは新技術への情熱を持ったライターです。ETHNewsへ参加する前、彼は米国証券取引委員会とOECDのインターンでした。彼はジョージタウン大学で国際経済を専攻、優等で卒業しました。余暇の時間マシューはバスケットボールをプレイするのとポッドキャストの視聴を楽しんでいます。ロスアンゼルス在住。 ETHNewsは自らの編集方針にコミットしています。 (ソース元記事:https://www.ethnews.com/ethereum-improvement-proposal-20-finalized-formally-establishes-erc20-standard)