Gunosy Blockchain Blog

Gunosyの開発メンバーが知見を共有するブログです。

blockchain.tokyo#4が開催されました!

f:id:ikutyy:20171006111444p:plain

こんばんは、新規事業開発室の生田です。

1月16日に、blockchain.tokyo#4がメルカリさんのイベントスペースで開催され、新規事業開発室のメンバーで参加してきました!今回はその発表内容を紹介させていただきます。

Bitcoin Improvement Flow @yamarkz

最初の登壇者はGunosy新規事業開発室メンバーである山口の発表です。

ビットコインは当初の仕組みからSegwitなどの改善が多数行われてきています。通常のwebサービスでは、中央のサーバーで全て情報を持っていますが、ビットコインはそれぞれのマイナーがブロックの情報を持っているため、アップデートを行った際に、マイナー同士で情報に差異が生まれトラブルになる可能性があります。その差異を無くし、トラブルが起きないようにするために、ビットコインの中に改善フローの仕組みが組み込まれているということでした。

より詳しい内容はこちらの記事をご覧ください。 blockchain.gunosy.io

Hash for BlockChain @keita0q

2人目はメルカリR4Dの中村さんです。

コインのハッシュアルゴリズムについてお話していただきました。ビットコインのマイニングはPoW(プルーフオブワーク)と呼ばれるコンセンサスアルゴリズムを用いており、特定の値(Target)を下回るハッシュ値を見つけることができたらマイニング成功となり、報酬を受け取ることが出来ます。ハッシュ値はSHA-256というハッシュアルゴリズムを用いて計算されており、メモリをほぼ使用せず実装が容易といった特徴を持っています。SHA-256のハッシュアルゴリズムはブロックハッシュの生成以外にも、ビットコインアドレスの生成などにも利用されています。

ビットコインに次ぐ時価総額のイーサリアムではPoWをベースとしつつも、DAGと呼ばれるメモリを必要とする手法を加えることによって、ASIC耐性を持ちました。その他にもScryptやCrypto Nightなど、オルトコインなどで利用されているアルゴリズムも多数紹介して頂きました。

特にスライドの終盤にあった「ブロックチェーンの特性はコンセンサスアルゴリズムとハッシュアルゴリズムである」という言葉が腑に落ちました。

ASICについて @mistakah

3人目は同じくメルカリの高橋さんです。

高橋さんには、PoWにおけるハッシュ計算を高速化するためのASICという集積回路の技術と現状についてお話して頂きました。より性能の良いASICはマイニングの収益性に直結します。マイニング専用のASICが半導体業界を牽引するようになってきているという話は衝撃でした。

実用的なDappsは出るのか @sodefrin

LT1人目はdely株式会社の田添さんに、Dappsの開発方法や開発してみての課題についてお話して頂きました。Dappsはイーサリアムのスマートコントラクトを用いての開発が主流です。ICOの際に配布されるトークンもスマートコントラクトを用いて開発されていたりしますが、今回はアクセストークンとして認証に利用してみようということでした。実際にアプリケーションを作ってみた方のお話を聞けることはあまりなく、開発しているからこそ発表内容に説得力がありました。

Decentralized Logistics @shao1555

LT2人目はスタートアップの立ち上げなどを経て、現在はフリーランスのエンジニアとして活躍されている澤田さんより、Dappsについてのお話でした。

この発表ではiPadを用いてプレゼンをしていただき、Apple Pencilを使ってスライドに書き込みながら話を進めるというプレゼンスタイルにまず驚きました。スライドに書き込みながらの説明は、スライド、トークと手の動きがリンクして、内容がすっと頭に入ってきました。

物流管理の分散化により、お互いのことをよく知らなくても複数社で協力できたり、トラッキングも可能になるという話です。不正を防ぐための保険金や、与信のようなトークンの話も興味深く、実現すれば非常に大きな市場になると感じました。

匿名性が気になってZerocashの White Paperを追ってみた @MasashiSalvador

最後のLTは、弊社Gunosyで新しい取り組みである「ライブ動画」の開発を担当しているMasashi Salvadorさんです。

ZeroCashという仮想通貨の匿名化の仕組みに関する紹介でした。 ビットコインやイーサリアムでは「誰に」「いくら送金されたのか」を誰でも確認することが出来ます。これらの通貨は送金情報がパブリックになっていることで、プライバシー問題があるとされています。このプライバシー問題を解決する通貨として、ZeroCashが開発されました。ZeroCashではトランザクションを匿名化することでプライバシー問題を解決しています。

トランザクションの匿名化は、文字通り「送金額」や「送金の宛先」を全く見えなくする技術であり、ZeroCashにおける実現方法をSalvaさんにトークしていただきました。この匿名化技術はイーサリアムでも導入が進められており、ZeroCashで用いられた匿名化技術を流用する形で開発が進んでいます。この匿名化技術は今後注目が高まるのは間違いありません。これからの進展に期待していきたいなと思いました。

まとめ

これまでのblockchain.tokyoも内容が濃かったですが、今回も同様に非常に実のある会でした。これまで全ての回に参加していますが、最も様々なテーマが取り扱われていたのではないかと思います。また触れられている内容は日本語の情報も少なく知らないことばかりで、普通にブロックチェーンを勉強していたのでは学べない貴重なお話を聞くことができました。発表終了後の懇親会でも、他の参加者の皆様とお互いに取り組んでいることなど様々なお話をすることが出来ました。今回のトークで気になったポイントをさらに深堀りして自らの知見をどんどん広げていきたいと思う勉強会でした。

宣伝

弊社ではブロックチェーンを始めとしてスマートスピーカー、VR/ARと言った新規領域での研究・開発を進めており、メンバーを募集しています。ご興味のある方はぜひ以下のリンクをチェックしてみてください。

www.wantedly.com

ビットコインのブロック伝搬とCompact Block Relay

はじめに

こんにちは。開発本部の @yamarkz です。

今回はビットコインネットワーク上のやりとりに注目して、マイニングされたブロックの伝搬手法を紹介します。

また、ブロック伝搬が抱える問題とその問題を解決する Compact Block Relay と呼ばれる新たな伝搬手法も紹介したいと思います。

f:id:yamarkz:20180109190820p:plain:w400

※今回はフルノードのブロック伝搬を想定しています。

ビットコインネットワークでのブロック伝搬

f:id:yamarkz:20180109235938p:plain:w400

ビットコインでは Proof of work と呼ばれる取引の証明作業 (マイニング) が行われ、ブロックが生成されます。生成されたブロックはチェーンに繋がれていきブロックチェーンを形成します。

また、マイニングされたブロックはノード間を伝搬 (以下、リレー) し、ビットコインネットワークに接続されている全てのノードに共有されます。

ブロックは無作為に関連ノードにリレーされるわけではなく、ノード間でメッセージのやりとりを行い、互いの状況を把握し、状況に応じてリレーを行っています。

具体的なリレーの流れを見てみます。例として、 送信元ノードA 受信元ノードB があり、AからBへブロックリレーを行う場面を想定します。

f:id:yamarkz:20180110181436p:plain:w400

  1. 送信元ノードAが invメッセージ をノードBへ送信

    invメッセージとは、 inventryメッセージ (在庫メッセージ) のことで、新しくチェーンに繋がれたブロックを関連ノードにアナウンスします。

  2. ノードBが getheadersメッセージgetdataメッセージ をノードAに送信

    ノードBはノードAからのinvメッセージにより、新しいブロックの存在のアナウンスを受けます。ノードBこの新しいブロックが自身のチェーンに繋がれていないことを知ると、ノードAにぶろっくをリレーするようにメッセージを送ります。このブロックを要求するのが getheadersメッセージgetdataメッセージ です。

  3. headersメッセージ でブロックヘッダーをノードBへ送信。続いて blockメッセージ でブロックデータをノードBへ送信

    ノードAはノードBからの要求に応じて、該当するブロックをノードBにリレーします。この時ブロックヘッダーとトランザクションの一覧が含まれるブロックデータは別々にリレーされます。

  4. 受け取ったブロックヘッダーとブロックデータの正当性を検証。正当性が証明されたブロックは自身のチェーンに追加され、関連ノードに invメッセージ を送信しアナウンスしていく。

このように、ブロックリレーではノードの状況 (チェーンの最新状態) をinvメッセージでアナウンスし、自身のチェーンに最新ブロックの追加が必要である場合にのみブロックを要求しリレーを行います。

ブロックリレー時の問題

invメッセージを用いたブロックリレーは、互いに関連ノードの状況を把握しリレーを行いますが、これはあまり効率の良い方法ではありませんでした。 それはブロックのリレー時にノードがトランザクションを2度受け取る状況になっており、通信帯域を無駄に使用してしまっているからです。

f:id:yamarkz:20180110002307p:plain:w400

1度目のトランザクション受け取りは、ネットワーク上にトランザクションがブロードキャストされるタイミングです。 ブロードキャストされたトランザクションはノードが持つメモリ空間の mempool (メモリプール) に保持され、ブロックと同様に関連ノードにトランザクションが共有されていきます。

f:id:yamarkz:20180111134036p:plain:w400

2度目のトランザクションの受け取りは、マイニングされたブロックがリレーするタイミングです。 mempool に存在するトランザクションがリレーされてきたブロック内にも含まれていた場合、そのブロックを受け取ることはノードで同一のトランザクションを受け取ることになります。

この様に、2度に渡って同一トランザクションをやりとりすることは、ネットワークの通信帯域を無駄に使用することになります。

実際に通信帯域が狭いネットワークに存在するノードがブロックリレーを行うことで、帯域が混雑しクリティカルなスパイクが発生していました。 その結果、ネットワークが一時的に切断されたり、通信遅延が発生するという状況が生まれていました。これによりユーザー側はトランザクションの承認が遅れたりする状況に遭遇することになります。

こういった問題を解決するために、効率的なブロックリレーの手法として Compact Block Relay が後発で考えられました。

使用する帯域幅を減らした Compact Block Relay という手法

Compact Block Relay (以下、CBR)は、BIP-152で定義されているノード間でのブロックリレー手法の1つです。CBRは上記で紹介した通常のブロックリレーよりもネットワーク帯域幅の使用量を減らしてリレーを行います。 その結果、ネットワークが一時的に切断されるなどのクリティカルな帯域幅スパイクを削減することができます。 また、帯域幅の使用量を減らすことは副次的にブロックリレーのレイテンシーを減らすことにもなります。

CBRは 2016/08/25 にリリースされた bitcoin core 0.13.0 から導入された PeerServiceレイヤー の機能で、後方互換性があります。 また、初期リリース後も都度改善が行われ、bitcoin core 0.14.0 ではsegwitトランザクションに対応した version 2 がリリースされています。

Compact Block Relay の基本的な仕組み

CBRでは「スケッチ」と呼ばれるcompact blockデータを用いてブロックリレーを行います。

CBRには2つのモードが存在します。 高帯域モード 低帯域モード です。

どちらもスケッチのやり取りを行いますが、若干手順が異なります。この2つのモードの仕組みとその違いを見ていきます。

先ほどと同じく、ブロックの送信元をノードA、ブロックの受信元をノードBとし、ノードAからノードBへスケッチをリレーする場面を想定します。

スケッチ (compact block)

CBRでは「スケッチ」と呼ばれるデータを送受信します。 スケッチでは新たに定義された、「HeaderAndShortIDs」「PrefilledTransaction」というデータ構造が用いられます。

スケッチに含まれるデータは以下

  • BlockHeaderAndNonce
    • 80バイトのブロックヘッダーとnonce値 (nonce値は送信先ノードごとにランダムに付与する)
  • ShortTransactionID
    • 短縮されたトランザクション識別子(計算式から算出する短略化されたトランザクションID)
  • PrefilledTransaction
    • 受信側のピアがおそらく持っていないと思われるトランザクションデータ (ex: コインベーストランザクション)

上記のデータをやりとりし、ブロックリレーを行います。

高帯域モード (High band width)

f:id:yamarkz:20180111124307p:plain:w400

高帯域モードでスケッチの送信を有効化するため、ノードBはノードAに sendcmpct を送信します。この時メッセージの第1引数には 1 をセットします。

高帯域モードでは、 ブロックの検証終了前 に関連ノードにスケッチを送信します。

ブロックヘッダーの正当性検証が終了後、ノードAはノードBに対してスケッチを送信します。 スケッチにはBlockHeaderとnonce値、ShortTransactionIDの一覧、そしてPrefilledTransactionの一覧が含まれており、受け取ったノードBはこのスケッチを基にブロックを再構築します。

以降、高帯域と低帯域 同一のブロック再構築フロー ↓

ノードBはブロックを再構築するため、受け取ったスケッチを基にブロックに含められたトランザクションの探索を行います。 トランザクションの探索は自身のmempoolにある未承認トランザクションからShortTransactionIDを算出し、スケッチで受け取ったShortTransactionIDと比較します。 この比較でIDが一致するものを探していきます。この探索により発見されたトランザクションはブロックにセットしていきます。

ShortTransactionIDの計算はスケッチで受け取ったBlockHeaderのハッシュ値とnonce値、そして自身のmempoolに存在する未承認トランザクションのIDを基に行います。

算出は下記の図の様に行われます。実際の算出ロジックは こちら に定義されています。

f:id:yamarkz:20180111124351p:plain:w400

全ての未承認トランザクションの探索を行い、該当するトランザクションを揃えることができた場合、受け取ったブロックヘッダーとPrefiiledTransactionで受け取ったトランザクションと共にブロックを構築し正当性検証を行います。

もし、探索で該当するトランザクションが見つからなかった場合は、送信元であるノードAに不足分のトランザクションをリクエストします。

ノードAはこのリクエストに応じて該当するトランザクションをレスポンスとして返します。

そして、全てのトランザクションが揃った時点で、ブロックヘッダーとPrefiiledTransactionで受け取ったトランザクションと共にブロックを構築し正当性検証を行います。

検証後、正当性が証明されればブロックを自身のチェーンに追加し、自身の関連ノードにブロック情報をinvメッセージでアナウンスしていきます。

低帯域モード (Low band width)

低帯域は高帯域と比較するとスケッチリレー部分が異なっており、ブロックの再構築は高帯域と同じフローで行われます。

f:id:yamarkz:20180111124233p:plain:w400

低帯域モードでスケッチの送信を有効化するため、ノードBはノードAに sendcmpct を送信します。この時メッセージの第1引数には 0 をセットします。

低帯域モードでは、 ブロックの検証終了後 に関連ノードにスケッチを送信します。

ノードAはブロックの検証が終了後、そのブロックの正当性が証明された場合はブロックを自身のチェーンに追加します。 そして自身のチェーンに追加後、invメッセージ でノードBにアナウンスします。

メッセージを受け取ったノードBは、自身のチェーンよりもノードAのチェーンが伸びていることを知ります。 ノードBは自身のチェーンを最新状態に保つために、自身のチェーンに不足しているのブロックをスケッチで送信するよう getdata(CMPCT) メッセージを送信します。

このメッセージを受け取ったノードAは該当するブロックのスケッチを送信します。

スケッチにはBlockHeaderとnonce値、ShortTransactionIDの一覧、そしてPrefilledTransactionの一覧が含まれており、受け取ったノードBはこのスケッチを基にブロックを再構築します。

以降、高帯域と同一のブロック再構築フローになります。

2つのモードの違いとまとめ

2つのモードで異なるのはスケッチリレーの部分。

高帯域は一方的にリレーを行いますが、低帯域はメッセージのやりとりを行い、要求があった場合にのみリレーを行います。

通常のブロックリレーも使われるが、最新のブロックを追う場合はCBRを用いたリレーを行う方がメリットが大きい。

(余談ですが、高帯域と低帯域という表現の意味は以下の理由からです。)

高帯域モードは関連ノードの状況を考慮せずリレーを行います。 これは一方的にリレーを行うので、結果的に不要なリレーも発生することになります。 発生した不要なリレーは帯域を無駄に使用すること (帯域幅の浪費) に繋がるので、 高帯域 という表現がされている。

低帯域モードはリレー前にメッセージやりとりを行い、リクエストがあった場合にのみリレーを行います。 高帯域より多くのメッセージを介すものの、リクエストがあった場合にのみリレーが行われます。 状況に応じてリレーを行うことは帯域の使用量を減らすこと (帯域幅の節約) に繋がるので、 低帯域 という表現がされている。

Compact Block Relay の 技術仕様

詳細な技術仕様の紹介は今回割愛させていただきますが、詳細が気になる方に「ここは見るべき!」と思った情報ソースをまとめておきます。

恐らく疑問思うと思われる「短略トランザクションIDの衝突確率」や「バージョン1とバージョン2の共存の仕組み」などは BIP-152 に解説が記載されているのでそちらをご覧ください。

まとめ

今回の内容をざっくりとまとめると。

ブロックはメッセージのやり取りを介してリレーを行う。

通常のブロックリレーは帯域を無駄に使用することになりクリティカルなスパイクが発生する問題があった。

スパイクが発生する問題を解決するために、効率的なブロックリレーの手法としてCompact Block Relayが考えられた。

CBRは1Mのブロックをリレーせず、ブロックヘッダー、短略トランザクションID、特定のトランザクションをリレーするのでリレーするデータの容量が小さくて済む。

リレー後は渡ったデータを基にブロックの再構築を行いチェーンに繋げていく。

最後に

今回はビットコインネットワークに注目して、基本的なブロックリレーの流れと新しく考えられた Compact Block Relay という手法を紹介しました。

PeerServiceレイヤーの改善はあまり注目されていませんが、Compact Block Relay はフルノードを持つユーザーにとっては大きな機能追加でした。

今回詳細な技術仕様までは触れることができなかったのですが、Compact Block RelayはBIPやリリースノートに詳細に解説が記載されていますので気になる方はそちらご覧ください。

宣伝

Gunosyではブロックチェーンを始めとしてスマートスピーカー、VR/ARと言った新規領域での研究・開発を進めており、メンバーを募集しています。

少し話を聞いてみたい!という方も歓迎していますので、下記のリンクからの応募お待ちしております。

www.wantedly.com

また弊社は、blockchain.tokyo を主催するなど、ブロックチェーンや仮想通貨に関する調査を行っています。

次回は1/16に、メルカリさんに会場をお借りしてイベントを開催します。残念ながら今回の募集は終了してしまいました。 来月は弊社を会場に開催する予定です。少しでも興味のある方は下記リンクからのご参加お待ちしております。 また、イベントグループへメンバー登録をしていただくとイベント参加者募集の通知が来るのでこちらもぜひ登録してみてください。

blockchain-tokyo.connpass.com

ビットコインのフォークとアクティベート方法のまとめ

はじめに

こんにちは。開発本部の @yamarkz です。

昨今ビットコインのスケーリング問題がさらに顕在化してきていますね。

最近では主要取引所での手数料改定も行われました。

スケーリング問題を解決するための手段は日々IRCで議論され、現在も改善へ向けた開発が進められています。

直近では2017/8にアクティベートされた「segwit」や、2017/11に中止となった「segwit2x」などが解決手段として注目を浴びました。

今回はこれらの解決手段がどういったフローでアクティベートに到っているのかを紹介したいと思います。

※ 今回紹介するのはソフトフォークによるコンセンサスレイヤーの新規機能追加、バグ改善のフローです。

本文中の各用語は以下のように棲み分けています。

  • リリース
    • ソフトウェアのリリースのこと (例: bitcoin core 0.15.1)
  • ソフトフォーク
    • 特定の機能をアクティベートに到るまでのフロー全般
  • アクティベート
    • ソフトフォークを実施した際のゴール。 機能が実際に本番環境のノードで適用されることを意味します。
  • クライアント
    • マイナーなどのフルノードを想定しています

ソフトフォークとハードフォーク

アクティベートに到るまでの流れを見て行く前に、前提知識として必要な「フォーク」について触れておきます。 ビットコインに興味がある人なら「フォーク」と呼ばれるワードは1度は耳にしたことがあるのではないでしょうか。 フォークには大きく分けて2種類存在します。「ソフトフォーク」と「ハードフォーク」です。

ソフトフォーク

ソフトフォークとは、ブロックチェーン後方互換性のある ソフトウェアのアップデートのことです。 「後方互換性のある」という部分がポイントで、これは既存の仕様よりも厳しい規約を設けることです。

ハードフォーク

ハードフォークとは、ブロックチェーン後方互換性のない ソフトウェアのアップデートのことです。 「後方互換性がない」とは、既存の仕様よりも緩い規約を設けることです。

上記2つのフォークの仕組みについては、Blockchain Tokyo #2 のLTで発表していただいた @sonatard さんの資料がとてもわかりやすくまとめてられています。 理解に不安がある方は下記スライドを参考にしてみてください。

speakerdeck.com

それでは、ソフトフォークを行う方法を見ていきます。

ソフトフォークを行う3つの方法

ソフトフォークを行う方法は主に3つ存在します。

  • flag day activation (フラグデイ)
  • IsSuperMajority (ISM)
  • version bits (BIP9)

※ 現在はBIP9を用いてソフトフォークが行われています。

flag day activation (フラグデイ)

初期のビットコインで用いられていたソフトフォークの方法がflag day activation (以下、フラグデイ) です。

フラグデイは特定の期日を設け、「期日以降に新しいルールを適用しますよ。」と事前にマイナーに勧告を行ってからアクティベートを実施します。 マイナーは事前の勧告を受け、期日前にクライアントのアップデート対応を行います。

実際にフラグデイを用いて行われた BIP16 のソフトフォークは 2012/04/01 09:00:00 にアクティベートされました。 BIP16の実行コードは こちら に記載されています。

f:id:yamarkz:20171227144544p:plain:w400

フラグデイの仕組みはシンプルですが、これは危険なソフトフォークの方法でもあります。なぜなら、フラグデイはマイナーのハッシュパワーのバランスを全く考慮していないソフトフォークだからです。

ハッシュパワーのバランスを考慮していないソフトフォークでは、リオーガニゼーションの問題が発生する可能性があります。

リオーガニゼーション (Reorganization)

リオーガニゼーション (以下、reorg) とは「チェーンの再編成」という意味で、分岐したブロックチェーンが1つのメインチェーンに収束することです。

f:id:yamarkz:20171228094847p:plain:w400

ビットコインでは 「チェーンが分岐した場合、長い方のチェーンを有効なものとする」 というルールがあります。このルールにより、reorgが発生します。 reorgは実は頻繁に発生している現象で、同じタイミングでマイナーがブロックを生成した時にも起きています。 この場合、reorg自体は一時的なもの (2~3ブロック分) で最終的に1つの長いチェーンに収束するためそれほど問題にはなりません。 reorgが発生したチェーンは収束時に削除されます。

問題はソフトフォークをきっかけに中途半端 (1日単位 約144ブロック分など) にチェーンが伸びてしまった場合です。

この問題を下記で解説します。※ わかりやすさを求め単純な例を用いています。

リオーガニゼーションにより起こる問題

f:id:yamarkz:20171228121242p:plain:w400

フラグデイによりアクティベートが実施され、旧仕様チェーンAと新仕様チェーンBが作られた場合を想定します。例えとして、マイナーグループA (50%) とマイナーグループB (50%) に別れてマイニングが行われました。これはハッシュパワーが拮抗している状況です。

AとBは元々同じ仕様のチェーンでマイニングしていましたが、グループAがフラグデイのアップデート勧告を忘れるなどして、アップデートを行わず、そのまま旧仕様チェーンでマイニングを続けてしまいます。

グループBは勧告通りアップデートを行い、期日後は新仕様が適用されたチェーンでマイニングを続け、チェーンを伸ばして行きます。

f:id:yamarkz:20171228121932p:plain:w400

グループAは途中でこの状況に気づき、急遽ソフトウェアのアップデートを行いグループBに合流します。(チェーンAはこの時点で、既にいくつかのブロックがマイニングされています。)

AからBにマイナーが移動したため、チェーンAは止まり、ハッシュパワーが100%になったチェーンBが伸び続けメインチェーンとして認識されることになります。 これにより、新仕様のチェーンBがメインチェーンとなりソフトフォークは成功します。

しかし、この状況で問題が発生します。問題として注目すべき点はチェーンAが伸びた後、グループAのマイナーがグループBに移るタイミングです。

f:id:yamarkz:20171228121901p:plain:w400

このタイミングでは既にマイニングされたブロックがチェーンAにはいくつか存在しています。これらのブロックはマイニングとして成功し、チェーンAに繋がれたものです。この時、メインチェーンとして認められなかったチェーンAは最終的に 削除される (reorgされる) ことになります。

reorgが起きることで、「チェーンAでは承認済みトランザクションが、チェーンBでは未承認トランザクションとして存在している」という状況が生まれます。これにより送金の整合性が保たれていない混乱した状況が引きおこされる可能性があります。

具体的には、ある商品を購入した対価としてビットコインを支払ったにもかかわらず、reorgにより支払いのトランザクションが参照している未使用トランザクションアウトプットが消失します。 その結果、ビットコインの受け取り側は無効なトランザクションを受け取ったことになり、受け取り側に損失が生まれます。

また、チェーンAのマイニングで得られた報酬もなくなるため、この報酬を参照しトランザクションを作成したとしてもそのトランザクションは無効なトランザクションになります。

f:id:yamarkz:20171228132918p:plain:w400

このようにソフトフォークを起点に途中まで繋がれたチェーンAが削除される (reorgされる) ことによって、送金の整合性が保たれない混乱した状況が生まれてしまう可能性があります。

フラグデイは一見シンプルなソフトフォークの実施方法に見えますが、一歩間違えると送金の整合性が保たれないという危険なソフトフォークの手段なのです。 こういった状況が想定されるソフトフォークはやめるべきだとして、新たに考えられたのがIsSuperMajorityと呼ばれるソフトフォークの手段です。

flag day activationを用いて行われたソフトフォーク

IsSuperMajority (ISM)

IsSuperMajority (以下、ISM) とは、直近マイニングされた1,000ブロックの内、950ブロックがソフトフォークのversion値に対応したブロックであった場合に、アクティベートが実施される方法のことです。

f:id:yamarkz:20171226182744p:plain:w400

ISMを用いてソフトフォークが実施される場合、クライアントをソフトフォークの実装が含まれた最新バージョンにアップデートすると、生成されるブロックのversion値が変わります。

この特定のversion値が含まれたブロックが直近1,000ブロック中何ブロックに含まれているのかをカウントし、アクティベートを実施する判定に用いています。

そして、1,000ブロック中、950ブロック (全体の95%) に特定のversion値が含まれていた場合にアクティベートが実行されます。

このように完全にマイナーの準備が整った段階 (95%の準備) でアクティベートが実施されるため、フラグデイの様にブロックチェーンが中途半端に伸びることで混乱が発生する問題を防ぐことができるようになりました。

実際にどういったブロックがソフトフォークに対応しているのか見てみます。↓

f:id:yamarkz:20171226121413p:plain:w400

2016/02/25に生成されたブロック高400,000のブロックでは、version値が4となっています。 このversion値4は BIP65 のソフトフォークに対応したマイナーが生成したブロックということになります。 ISMではこの値が含まれるブロックの数をカウントしています。

ISMの実行コードは こちら に記載されています。

フラグデイの問題点を解決したISMですが、ここにもいくつかの問題がありました。

  • ISMには期限 (limitTime) という概念が存在しません。その結果、ソフトフォークが完了しない限り実質無限にアクティベート待ちの判定が続きます。
  • ISMでは同時並行で複数のソフトフォークを行えません。その結果、前に開始されたソフトフォークが完了しない限り次のソフトフォークが実施できないため改善サイクルが止まっています。

これらの問題を解決し、現在用いられている方法がBIP9として定義されている「version bits」と呼ばれるものです。

ISMを用いて行われたソフトフォーク

version bits (BIP9)

version bits (以下、BIP9) とは、ブロックのnVersionフィールドの値に含まれるbits値 (以下、シグナル値) を元にマイナーの対応状況を把握し、一定期間中に生成されたブロックの内、全体の95%のブロックにシグナル値が含まれている場合にアクティベートを実施する方法です。

BIP9では、クライアントをソフトフォークの実装が含まれた最新バージョンにアップデートすると、生成するブロックのnVersionフィールドの値にシグナル値が追加されます。 このシグナル値が含まれたブロックを retarget period と呼ばれる区切りでカウントします。(retarget periodとは2016ブロックごとの区切りのこと)

カウント期間中に全体のブロックに対して95%のブロックにシグナル値が含まれた段階でアクティベートがロックインされます。(95%という値は2016ブロック中、1916ブロック以上に特定のシグナル値が含まれているということ)

ロックインとはソフトフォークの導入が確定することで、ロックインされた次のretarget periodでアクティベートが実施されます。 法律で例えると、ロックインは「法案成立」ということになり、アクティベートは「法律施行」の部分に該当します。

f:id:yamarkz:20171227144627p:plain:w400

また、BIP9ではstartTimeとtimeoutという値を設定します。

startTimeはシグナルの集計が開始する時間で、このstartTime以降の最新のretarget period以降から集計が始まります。

timeoutはシグナルの集計が終了する期限で、基本的にはstartTimeの1年後を設定するようになっています。

f:id:yamarkz:20171226143902p:plain:w400

そして、BIP9では複数並行でソフトフォークを進めることができます。

ISMでは前に開始されたソフトフォークが完了していない限り、次のソフトフォークが行われない仕様でした。(順番通りソフトフォークを行わなければいけない)

その結果、1つのソフトフォークの実施に時間がかかってしまった場合、改善のサイクルが遅くなるという問題が発生します。

この問題をBIP9では解決し、前のソフトフォークの完了を待たずに後方のソフトフォークを行うことが可能になりました。

例えると、「ソフトフォークA(シグナル値 1) の浸透率は30%だが、ソフトフォークB(シグナル値 4) の浸透率は95%を超えたため、先にBをロックインする。」といった感じです。

実際に複数のソフトフォークが走っていた時のシグナル値を見て見ます。↓

f:id:yamarkz:20171227151244p:plain:w400

ブロック高 #477039 は 2017/7/22 にマイニングされました。

このブロックのバージョンは 0x20000012 となっています。このバージョン値の下2桁に注目です。

1(bits4)と2(bits1)という値はシグナル値で、このブロックは複数のソフトフォーク(bits4とbits1)のシグナルを発しています。

ちなみに、この時のbits1は「BIP141」のシグナルで、bits4は 「 BIP91 」のシグナルです。

シグナル値は1~29番まで変えることができるので、最多で29個のソフトフォークを同時並行で実施すること可能です。

BIP9を用いて行われたソフトフォーク

まとめ

今回の内容をまとめると。

ソフトフォークの実施手段は主に3つある。「flag day activation (フラグデイ) 」「IsSuperMajority (ISM) 」「version bits (BIP9)」。

これらの手段は実行して挙げられた問題点を解決し、改善されてきている。

最後に

今回はビットコインのソフトフォークの手段を見てきました。フラグデイから始まり、ISM、BIP9と手段の進化を本記事で掴んでいただければ嬉しいです。ビットコインはまだまだ発展途上で今後もソフトフォークを実施し、機能改善が続いて行くと思われます。今回の内容を踏まえ、今後ソフトフォークが実施される際にはどういった手段で、進んでいるのかウォッチしてみてください。

宣伝

Gunosyでは、blockchain.tokyo を主催するなど、ブロックチェーンや仮想通貨に関する調査を行っています。

次回は来月、メルカリさんに会場をお借りしてイベントを開催する予定ですので、興味がある方はぜひ下記のイベントページからのご参加お待ちしております。

blockchain-tokyo.connpass.com

また、弊社ではブロックチェーンを始めとしてスマートスピーカー、VR/ARと言った新規領域での研究・開発を進めており、メンバーを募集しています。

www.wantedly.com

【ビットコイン】ウォレットの概要とHDウォレットの仕組み

このブログについて

データ分析ブログテックブログ のスピンオフとして今回ブロックチェーンブログを作りました。

本ブログでは社内の研究開発の一環として調査しているブロックチェーン技術に関連したコンテンツを書いていきます。

はじめに

こんにちは、 開発本部の @yamarkz です。

この記事は Gunosy Advent Calendar 15日目の記事です。(少し投稿が遅れてしまいました、すみません。)

昨日は @hoshitocat さんの Headless ChromeをDocker上で動かして、E2Eのテスト でした。

また、ブロックチェーン Advent Calendar で @mosa_siru さんが 仮想通貨マイニングに関するまとめ を書いてくれました。

今回はビットコインのウォレットの概要と仕組みについて紹介します。

ウォレットのイメージが湧かない方は先に (おまけ) として紹介した 様々なウォレット を見てみてください。

この記事のレベル感としては初級~中級の間をイメージして書いたので、既に知ってる内容ならガンガン読み飛ばしちゃってください。

f:id:yamarkz:20171214213305p:plain:w300

※ 文中ではわかりやすさを取るため仮想通貨という表現に統一させてもらいます。

※ 今回は入門者を意識した書き方になっており、例え話などが本来の仕組みとは少しズレた内容になっている部分もありますがご了承ください。

秘密鍵と公開鍵、ビットコインアドレス

ウォレットの仕組みの話に進む前に、前提知識として必要な「秘密鍵」「公開鍵」「ビットコインアドレス」について少し触れておきます。

ビットコインでは様々な部分で暗号化技術が用いられています。その暗号化技術の1つが「秘密鍵」と「公開鍵」です。

秘密、公開と言われてもイメージしにくいかと思いますが、秘密鍵は自分だけが知っている鍵のことで、公開鍵は全世界の人が知ることができる鍵のこと。

2つの鍵の仕組みは「公開鍵で文章を暗号化して、秘密鍵で暗号化された文章を解読する」といった感じです。自分しか秘密鍵は知らないので自分だけが文章を解読して読むことができます。

ビットコインの世界ではこの2つの鍵とビットコインアドレスを用いてビットコインの送金が行われています。

ビットコインアドレスは公開鍵から生成される値で、実際に送金を行う際の宛先として利用されます。

実際のアドレス: 1PEfGuBeXwxWqxreSVc2Qy8ezX96YBs44K

ちなみにこれが僕のビットコインアドレスです。 このアドレス宛にビットコインを送金してくれれば僕のお小遣いになります。(笑)

また、これら3つの値には生成の順序があり 秘密鍵 => 公開鍵 => ビットコインアドレス の順序で生成されます。

なので 鍵の所有主 = ビットコインアドレスの宛先主 と同義になります。

f:id:yamarkz:20171220085733p:plain:w400

今回はアドレス生成過程には触れませんが、上記の順序は送金の仕組みを理解する上で重要なプロセスなのでぜひ覚えてください。

送金のイメージを掴んでもらうために銀行ATMを例にしてみます。(※実際の送金は銀行ATMのように行われていません)

秘密鍵がお金を引き出す際に必要になる暗証番号で、公開鍵から生成されたビットコインアドレスが自身の口座番号に当たる部分になります。

送金者に自身の口座番号 (ビットコインアドレス) を教えて、お金を入金 (送金) してもらいます。

出金者は教えた自身の口座番号 (ビットコインアドレス) に入金されたお金を、自身が持つ暗証番号 (秘密鍵) を元に口座の所有権を証明し、お金を取り出します (使用します)。

このように口座番号 (ビットコインアドレス) 宛にお金を入金してもらい、暗証番号 (秘密鍵) を用いて取引を行います。

f:id:yamarkz:20171218174813p:plain:w300

ざっくりとした説明でしたが、まとめると。

それでは鍵の知識を踏まえてウォレットについて見ていきましょう。

ビットコインのウォレット

ビットコインの世界にはウォレット (財布) というものが存在します。

「ウォレット」という名前からはビットコインを保存しておくストレージなどを連想してしまいますが、ウォレットは 「鍵」 を保持し管理します。 ここでの鍵とは先ほど紹介した「秘密鍵」と「公開鍵」 のことです。

ビットコインアドレスは鍵から作られ、このアドレス宛に送金されることは先ほど紹介しました。

では、ビットコインを使用する時はどうするのでしょうか?

答えは、受け取ったビットコイン秘密鍵 (の署名) を用いて「このビットコインは自分の物である!」と証明を行い、この証明が成立することで初めて自分が次の用途に使うことができるようになります。

受け取りに必要になるビットコインアドレスは鍵から作られる。受け取ったビットコインを使う時に必要になるのは秘密鍵の署名による証明。

つまり、やりとりで必要なのは鍵であり、この鍵だけを管理すれば良いのです。

なので、ウォレットで鍵を所有すること = 鍵に紐づいたビットコインを所有すること になるのです。

f:id:yamarkz:20171215183221p:plain:w300

<鍵束のイメージ>

ウォレットは鍵の管理手法を軸に大きく分けて2種類に分類されます。

1つ目が 「ランダムウォレット」 、2つ目が 「HDウォレット」 です。

ランダムウォレットはビットコインが開発された初期の頃に用いられていたウォレットで、HDウォレットは後発で開発されました。

現在はHDウォレットの仕組みが主流となっています。

次にこの2つの特徴と仕組みを見ていきます。

(余談ですが、通貨取引所に預けるよりも自身のウォレットを持って管理することをオススメします。多くの人が取引所で通貨の売買を行なっていますが、取引所は常にGOX (悪意のあるユーザによる攻撃を受け通貨を喪失、紛失すること) される危険性があるからです。 今日もウクライナの仮想通貨取引所 「liqui」でBTCが盗まれたという情報を目にしました。自分の通貨は自分の管理下に置くことが一番安全ですね)

ランダムウォレット (非決定性ウォレット) とは?

非決定性ウォレット (以下、ランダムウォレット)とは、秘密鍵と公開鍵を1:1の関係で生成し管理するウォレットのことです。

ランダムウォレットはビットコインの初期に用いられていました。

仕組みは至ってシンプルで、ランダムウォレットを用いるクライアントでは初期起動時にランダムな秘密鍵を100個生成します。 *1

f:id:yamarkz:20171214212120p:plain:w400

<ランダムウォレットのイメージ>

この生成した100個の秘密鍵から公開鍵を1:1で生成し、さらに公開鍵からビットコインアドレスを生成して初めて利用できるようになります。

つまり、既にこの時点で100個の鍵の管理責任を負わなければいけない状況になるのです。これはなかなか大変ですね

「100個も鍵を作らずに1つの鍵を使い回せば良いのでは。。。。?」

と、思うかもしれませんが。基本的に個々の鍵はプライバシーの関係上、1度しか使われません。 これは鍵から生成されるアドレスから特定の個人が所有しているビットコインの額が割り出されることを防ぐためです。

(余談ですが、ビットコインでは特定のアドレスにいくら入っているのかを簡単に確認することができます。ここ の「サーチ」でアドレスを検索してみると... ?)

初期生成した100個を使いきった場合、さらに多くの秘密鍵を生成し管理しなければいけません。 こうなると保持する鍵の数が200...300と膨れ上がり管理コストが膨大になります。

さらに、鍵を紛失した場合にはその鍵に結びついていたビットコインは全て凍結する (誰も取り出せなくなる) ことになります。 この凍結を防ぐためにも、所有者は都度秘密鍵のバックアップを取る作業が必要になります。

このようにランダムウォレットは構造がシンプルではありますが、実際に使用するという点で見るとあまり使い勝手が良いとは言えません。

簡略まとめ

  • ランダムウォレットは構造がシンプル。秘密鍵:公開鍵が1:1の関係でできている
  • 構造がシンプルが故に複数の秘密鍵を保持、管理しなければいけない状況が作られる

次は、このランダムウォレットが抱える問題を階層構造によって解決したHDウォレットを紹介します。

Hierarchy Deterministicウォレット (階層的決定性ウォレット) とは?

階層的決定性ウォレット (以下、HDウォレット)とは、1つの「シード (Seed) 」と呼ばれる値から秘密鍵を生成し、階層構造を用いて管理するウォレットのことです。

HDウォレットの全てはシードと呼ばれる数値から始まります。

シード例: 381e5fb888a599b44b9341b2cdb8d08d13bf7333187be6ee3ab5fd63e9d22159d0980f8e80dfbba3ead7dd646634cd46a8984a6d2ee71c7f28eb5b885b0fa029

このシードを起点に暗号学的ハッシュ関数を用いて鍵を生成していきます。 シードから生まれた鍵を親鍵とすると。親鍵が子鍵を、子鍵が孫鍵を。というような順番で階層的に鍵を生成することができます。

親鍵、子鍵と言われてもパッとイメージしにくいと思うので下記のイメージを参考にしてみてください。

f:id:yamarkz:20171214212617p:plain:w400

<HDウォレットのイメージ>

HDウォレットでは1つのシードから階層的に鍵を実質無限に生成できます。

この鍵の生成過程はBIP *2 で定義されているものが使われているため、シードがあれば何度でもHDウォレットを再構築することが可能です。

階層構造の仕組みにより管理すべき対象が1つのシードに絞られるため、ランダムウォレットのように秘密鍵を複数保持して管理する責任から解放されます。

実際には鍵の生成過程で秘密鍵が生成されるので保持管理し続けますが、注力して管理すべきものが「シード」のみになるので管理コストが大幅に下がるというわけです。

逆にシードが他人に知られてしまえばウォレットを再構築されてしまい、自分が保有するビットコインの全てを支配されてしまうリスクが生まれます。

これはHDウォレットの欠点でもあります。

簡略まとめ

  • シードと呼ばれる数値から鍵を階層構造に生成する
  • シードがあれば何度でもHDウォレットを再構築することが可能
  • 注力して管理するべき対象が「シード」のみに絞られるため管理コストを大きく下げることができる
  • シードが他人に知られた場合、そこに結びついていたビットコインを全て失うリスクが存在する

次にHDウォレットの仕組みで、最も重要な鍵生成過程を見ていきたいと思います。

HDウォレットの鍵はどのようにしてつくられるのか

先ほども紹介した通り、HDウォレットの全ては「シード」から始まります。 そしてシードがあれば何度でもHDウォレットの鍵階層を再構築することが可能です。

まずは鍵生成のイメージを掴んでもらいたいので下記の図を見てください。 下記の図はシードとマスター秘密鍵 (1番最初に生成される秘密鍵)の生成過程です

f:id:yamarkz:20171218162704p:plain:w400

<HDウォレットの鍵生成過程>

ぱっと見ただけではよくわからないですよね。

1つ1つ見ていくと。

  1. 暗号学的に安全な乱数生成器でシード (数値)を作成
  2. HMAC-SHA512 (一方向性ハッシュ関数) に乱数をかける
  3. 関数から512ビットの値が生成される。これを256ビットずつ前半と後半に分ける
  4. 前半部分 (left) を「秘密鍵」後半部分 (right) を「ChainCode」とする
  5. ChainCodeは子秘密鍵の生成に用いる

ここまでで、乱数生成器から「シード」が生成され、HMAC-SHA512から「秘密鍵」と「ChainCode」が生成されました。

f:id:yamarkz:20171218171124p:plain:w400

<実際に生成したSHA512の値>

ここから、「秘密鍵」「ChainCode」「index」を用いて階層鍵を作成していきます。

「ChainCode」とは、シードのことで子鍵生成のために用いられる値です。

「index」とは、生成される子鍵を識別する値です。0なら第1子、1なら第2子、2なら第3子というように子供の識別子として用いられます。

f:id:yamarkz:20171218143237p:plain:w400

<HDウォレットの子鍵生成過程>

  1. 秘密鍵」「ChainCode」「index」を用意する
  2. 上記3つの値を左から順に組み合わせる。組み合わせた値をHMAC-SHA512 (一方向性ハッシュ関数) にかける
  3. 関数から512ビットの値が生成される。これを256ビットずつ前半と後半に分ける
  4. 前半部分 を「秘密鍵」後半部分 を「ChainCode」とする
  5. ChainCodeは子秘密鍵の生成に用いる

あとは上記の1~5の過程を何度も繰り返せば階層的に無限に鍵が作れます。

さらに、過程で生成された秘密鍵からは公開鍵が生成でき、公開鍵からはビットコインアドレスが作られ送金に利用されます。

上記を端的に話すと、

秘密鍵」「ChainCode」「インデックス値」を組み合わせることで無数に鍵が生成することができるということです。

以上が鍵の生成フローです。

パスフレーズとBIP32とBIP44

最後にHDウォレットのパスフレーズ、そしてBIP32とBIP44を見ていきます。

f:id:yamarkz:20171214212835p:plain:w400

<HDウォレットの鍵階層のイメージ>

https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki

HDウォレットで階層的に鍵を管理すると何かと良いことのはわかりました。 では、特定の階層に存在する特定の鍵を指定したい場合どのように鍵を一意に特定するのでしょうか?

答えは、「パスフレーズ」と呼ばれるフォーマットを鍵に適用し管理します。

パスフレーズとは、どの階層にどの鍵が存在するのかを一意に表したもので階層をスラッシュ ( / ) 区切りで表現します。

例: m/2/0/3

上記は、マスター鍵(m) から作られた 3番目の個鍵(2) から作られた1番目の個鍵(0) から作られた4番目の個鍵(3) という意味です。

BIP32ではこのパスフレーズに標準的な意味づけを定義しています。

BIP32の標準規格: m/a'/c/i

上記では、マスター鍵 (m) から作られた アカウント番号 (a') から作られた 用途が受け取りかおつりかの識別子 (c) から作られた秘密鍵を元に使いまわすビットコインアドレス部分 (i) という意味です。

このパスフレーズとBIP32の標準規格を用いて構造を形式化し管理しています。

これらを踏まえ、BIP32の標準規格を踏襲し、新たに階層を形式化を行い定義したものがBIP44です。

BIP44の標準規格: m / purpose' / coin_type' / account' / change / address_index

各階層ごとの意味を分解してみると下記の様になります。

  • (m) マスター鍵
  • (purpose') 目的階層。 44に設定された定数
  • (coin_type') コインの種類階層。Bitcoinは0 / Bitcoin Testnetは1
  • (account') 使用目的階層。寄付目的 / 貯蓄目的 / 共通経費 など使用するユーザー側で決めることができる
  • (change) 受取階層。外部送金者からの受け取りが0 / 自身のトランザクションからのおつりの受け取りが1
  • (address_index) アドレス階層。インデックス値が振られる

この様にBIP32よりも多くの階層を設けて鍵を管理するのがBIP44です。 これらの具体的な内容は こちら で紹介されています。

簡略まとめ

  • HDウォレットの鍵はパスフレーズとBIPの標準規格で管理される
  • BIP32とBIP44は互換性がない。
  • BIP32を踏襲し、新たに規格を制定したのがBIP44

HDウォレットのメリットとデメリット

HDウォレットの仕組みの話を振り返り、メリットとデメリットを整理してみます。

メリット

  • 管理に注力すべき対象がシードのみに絞られるため管理が楽
  • ツリー構造になっていることで、「特定の鍵階層以下を特定の支払いにのみ使う」という使い方ができるようになる

デメリット

  • シードを紛失した場合、関連したビットコインは全て凍結してしまう
  • シードを誰かに知られた場合、関連したビットコインは全て盗まれてしまう

まとめ

今回の内容をまとめると

  • ビットコインの送金では暗号化技術が用いられている。「秘密鍵」「公開鍵」
  • 秘密鍵」=> 「公開鍵」 => 「ビットコインアドレス」の順で生成でき、ビットコインアドレスは送金の宛先になる
  • ビットコインのウォレットとは鍵束のこと
  • ウォレットは管理手法を元に分けると2種類ある 「ランダムウォレット」と「HDウォレット」
  • ランダムウォレットは 秘密鍵と公開鍵を1:1で生成し管理する。鍵の数が増え続けて管理コストが大きくなる問題がある
  • HDウォレットは階層的に鍵を生成し、ランダムウォレットが抱える管理課題を解決する
  • HDウォレットの鍵の生成過程には暗号学的計算が用いられている
  • 秘密鍵」「ChainCode」「index」を用いて階層鍵は生成される
  • 階層上に存在する鍵の位置は「パスフレーズ」を用いて特定する
  • パスフレーズに意味を持たせて鍵を管理する仕組みを取っている
  • BIP32で定義したパスフレーズの拡張として新たに階層の意味を定義したのがBIP44
  • BIP32のパス構造とBIP44のパス構造には互換性がない

これらの内容に関連した BIP一覧

様々なウォレット (おまけ)

様々なウォレットを紹介します。 ウォレットには web/アプリ/ハードウェア と様々なタイプが存在していますが、今回はその中でも特徴のあるウォレットをいくつかピックアップしました。

Bitcoin Core (公式)

Bitcoinの公式クライアントです。このクライアントでは実際にブロックチェーンを構築するため、初期同期時には65GB以上のデータをネットワーク上からダウンロードします。なので起動には多くの時間を要するため 我慢が必要です。 必要な容量は同期時間などを考えると、カジュアルな支払いに利用することには向いてませんね。

f:id:yamarkz:20171219184750p:plain:w300

ダウンロード - ビットコイン

bread (アプリ)

breadはiOS, Androidのウォレットアプリです。 最近ICOも行われていました。Bread - JP

f:id:yamarkz:20171219185209p:plain:w300

bread

Copay (アプリ)

Copayはマルチシグネチャと呼ばれる技術を用いたウォレット。コペイという呼び名が僕は好きです

iOS, Androidをはじめ、様々なデバイスで動きます。また、オープンソースとしてソースコードが公開されているのも特徴です。

f:id:yamarkz:20171218160634p:plain:w300

Copay – 安全な共有ビットコインウォレット

Trazor (ハードウェア)

ハードウェアのウォレット、Trazor (トレザー)。

Trazorは界隈で最も信頼の置けるウォレットとして人気です。 バーチャルな通貨でも、最終的には実物で管理するのが一番安全だと言われています。(笑)

f:id:yamarkz:20171218160856p:plain:w300

TREZOR Bitcoin Wallet | The original and most secure hardware wallet.

最後に

長くなってしまいましたが、ウォレットの概要を掴むために主要なトピックを抜き出して紹介しました。ランダムウォレットからHDウォレットへの管理方法の進化を本記事で掴んでもらえたら嬉しいです。また、今回は内容の関係上触れることができていない技術や仕組みがたくさんあります。後日機会があればこれも紹介したいと思います。

宣伝

Gunosyでは、blockchain.tokyo を主催するなど、ブロックチェーンや仮想通貨に関する調査を行っています。

次回は来月、メルカリさんに会場をお借りしてイベントを開催する予定ですので、興味がある方はぜひ下記のイベントページからのご参加お待ちしております。

blockchain-tokyo.connpass.com

また、弊社ではブロックチェーンを始めとしてやスマートスピーカー、VR/ARと言った新規領域での研究・開発を進めており、メンバーを募集しています。

www.wantedly.com

*1:ビットコインコアクライアントでの話

*2: BIPとは (Bitcoin Improvement Proposal) のこと、直訳すると「ビットコイン改善案」。改善案という表現がされていますが、BIPではビットコインの仕様を定義する場としても用いられています。bips