イタロケ

イタロケ

勉強とか旅とか趣味とか

テーマとカテゴリーの整理

これまで何も考えず思ったこととか勉強したことを書いてきており、技術書の概要とかも書いてきたのですが、同じ技術について勉強しているときは、技術は事実なので、どの本も大体同じことが書かれており、それを毎回書くのは気持ち悪いし意味がないと思ったので、自分の中でテーマのルールを決めようと思い、ちょっとまとめてみました。

感想とかが書かれた本や、技術としてまとめきれない本についてだけ概要を書くようにして、それ以外はいくつかの本をまとめて、技術の紹介という形で記事を書こうと思います。

要するに、小説などはその本について記事にして、技術書はいくつかの本を総合して自分なりに理解した技術を記事にしようと思います。

ただ、読んだ技術書はいずれまとめたいと思います。

そして、カテゴリーも深く考えずに分けてきたのですが、やっぱり整理されていた方が良いと思い、自分なりに整理しました。

旅:旅行・観光

udonta.hatenablog.com

関東:関東地方の観光など

udonta.hatenablog.com

近畿:近畿地方の観光など

udonta.hatenablog.com

東海:東海地方の観光など

udonta.hatenablog.com

アウトドア:公園の紹介やヒッチハイク、野宿など、外の活動全般

udonta.hatenablog.com

歴史:人類の歴史や、昔の文化や伝統、歴史的建造物など

udonta.hatenablog.com

暗号通貨:ビットコインなどのいわゆる仮想通貨などでブロックチェーンの仕組みの記事にこのカテゴリを追加するか迷ったのですが、取りあえず入れています。

udonta.hatenablog.com

IT:ITとはInformation Technologyすなわち情報技術で、AIなどそれっぽいことに関する記事に付けています。

udonta.hatenablog.com

FinTech:これまでのお金のシステムを変える新しい技術とか、電子決済などで正直FinTechの定義はイマイチ分からないので自分なりに分けています。

udonta.hatenablog.com

ブロックチェーン:そのままでブロックチェーンについてで、今は暗号通貨と結びつけられることが多いですが、非常に応用範囲の広い技術です。

udonta.hatenablog.com

勉強:数学や物理、機械系の科目についての知識や勉強の方法などですが、機械系の科目は別にカテゴリを作るか迷っています。また、技術の紹介が勉強に入りそうでそこでもちょっと迷っています。

udonta.hatenablog.com

稲美町:私の地元稲美町の人気スポットなどを紹介しています。

udonta.hatenablog.com

芸術:美術や映画など芸術全般

udonta.hatenablog.com

思想:私が思っていることについて

udonta.hatenablog.com

金融:お金・投資に関すること

udonta.hatenablog.com

経済:社会・投資について

udonta.hatenablog.com

スポーツ:野球・サッカーについて

udonta.hatenablog.com

ブログ:グーグルアドセンスはてなブログについて

udonta.hatenablog.com

他にも料理関係やお笑い関係、プログラムに関する記事も書いていきたいと思っています。

スケーラビリティへの対応【ブロックチェーン】

ビットコイン等の暗号通貨の課題として、トランザクションの取引内容が確定するまでに時間がかかるという問題と処理件数が少ないという問題があります。

基本的なことは以下の記事で説明しているので是非参考にして頂ければと思います。

udonta.hatenablog.com

その原因として、ビットコインでは10分間に1ブロックが生成されるように調整されているのですが、ブロックサイズの上限が現在1MBであることが挙げられ、これでは短時間に大量のトランザクションを処理することができません。

この一連の問題をスケーラビリティ問題といいます。

それを解決する方法として、ブロックチェーンの外側で複数回分の取引を実施し、1つのトランザクションに集約した後にブロックチェーンに記録するオフチェーン技術が考えられています。

f:id:udonta:20190623120652p:plain

マイクロペイメントチャネル

解決方法の1つがマイクロペイメントチャネルで、単方向マイクロペイメントチャネル、双方向マイクロペイメントチャネル、HTLCを利用した双方向ペイメントチャネル があります。

いずれも大まかな流れとしては、最初のトランザクションで資金をチャネル用(オフチェーン上の取引するための経路)にデポジットし(預け)、その後オフチェーンの取引で残高を更新し、取引が終了したら残高に応じて最後のトランザクションをブロードキャストする(ブロックチェーンに記録する)、といった感じです。

単方向マイクロペイメントチャネル

二者間の取引で、片方向の支払いが可能です。

取引を具体的にみていきます。

1.オープニングトランザクションの作成

チャネルを確立する際にやり取りされるトランザクションをオープニングトランザクションとよびます。

オープニングトランザクションでは、アウトプットのlocking scriptに2-of-2マルチシグを設定することで、資金を移動するには両者の合意が必要となる宛先に資金をデポジットします。

2.払い戻し用トランザクションの作成

送金先が応答しなくなった場合に、デポジットした資金が返ってくるようなトランザクションを作成しておき、これはチャネルの有効期限後にブロードキャストできる状態になります。

3.オープニングトランザクションのブロードキャスト

送金者が作成、署名したオープニングトランザクションを送金相手に渡し、送金相手はこれをブロードキャストすることで、チャネルが確立されます。

要するに、送金者の署名により使えるようになったインプットと、2人の署名が必要なアウトプットを持つトランザクションブロックチェーン上に記録されます。

4.コミットメントトランザクションの作成

コミットメントトランザクションとは取引を行うたびに作成するトランザクションで、インプットにはオープニングトランザクションのアウトプットを設定します。

送金者は署名してから送金相手に渡すため、送金相手が署名すればいつでもブロードキャストできる状態になります。

5.コミットメントトランザクションのクローズ

送金相手は最後に受け取ったコミットメントトランザクションに署名し、ブロードキャストすると、チャネルがクローズします。

6.まとめ

送金者の資金を2-of-2マルチシグにデポジットした後に、送金者が署名済みのコミットメントトランザクションを送金相手に渡すと、後は送金相手が署名すればいつでもブロードキャストできる状態になるので支払いが完了したとみなせます。

そして、オープニングトランザクションのブロードキャスト前に払い戻し用トランザクションを作成しておくことでチャネルの有効期限が過ぎれば資金は戻ってくるようにできます。

双方向マイクロペイメントチャネル

二者間の取引で、相互に支払いが可能です。

双方向マイクロペイメントチャネルを実現するためには、Segwitの仕組みが必要です。

理由は、コミットメントトランザクションを作成する際に、オープニングトランザクションの署名前にオープニングトランザクションのアウトプットをUTXOとして参照し、それはトランザクションIDを用いて行いますが、署名前と署名後でトランザクションIDが変わらない必要があるからです。

ちなみにSegwitは以下の記事で紹介しています。

udonta.hatenablog.com

取引を具体的に見ていきます。

1.オープニングトランザクションの作成

二者のUTXOをインプットに設定し、オープニングトランザクションを作成します。

2.シークレットの作成、シークレットハッシュの交換

二者はそれぞれ、作成者しか知りえない文字列であるシークレットを作成し、そのシークレットのハッシュを交換します。

これはコミットメントトランザクションを更新した後に、最新でない過去のコミットメントトランザクションを不正にブロードキャストすることを防ぐためのものです。

3.コミットメントトランザクションの作成、交換

コミットメントトランザクションは二者がそれぞれ作成し、インプットにはオープニングトランザクションのアウトプットを設定します。

アウトプットには、自分のアドレス宛と、特別なlocking script宛のアウトプットがあり、それは以下のいずれかの条件で解除できます。

a.一定期間後、相手の秘密鍵で解除できる

b.相手から受け取ったシークレットハッシュの元となるシークレットを知っていれば、自分の秘密鍵で解除できる(コミットメントトランザクションの作成時点では、シークレットハッシュは知っているが、シークレットは知らないため、解除できない)

作成したトランザクションに自分の署名を加え、相手に渡すことで、お互いが受け取ったトランザクションは、自分が署名すればいつでもブロードキャストできる状態になっています。

4.オープニングトランザクションのブロードキャスト

オープニングトランザクションはどちらが作成しても良く、一方が自分の署名を加えたオープニングトランザクションをもう一方に渡し、その相手は署名してブロードキャストします。

5.シークレットの作成、シークレットハッシュの交換

それぞれ新たにシークレットを作成し、そのシークレットハッシュを交換します。

6.コミットメントトランザクションの作成、交換

チャネルのオープンで作成した時と同様に、取引内容に応じて送付する暗号通貨の量を変えたコミットメントトランザクションをそれぞれが作成し、交換します。

7.シークレットの交換

1つ前のコミットメントトランザクションを作成する際に使用したシークレットを交換します。

このとき、一方が1つ前のコミットメントトランザクションをブロードキャストしたとすると、相手のアドレスと特別なlocking scriptに送金されることになり、先程述べたように、ブロードキャストした側は一定期間経つまで、秘密鍵を使って入手はできないのに対して、された方は、シークレットを知っておりすぐに入手できます。

結果的に全てブロードキャストされた方のものになってしまうため、最新のものだけがブロードキャスト可能な状態となっています。

8.クロージングトランザクションの作成、ブロードキャスト

最終的な金額に双方が合意し、チャネルをクローズすることに同意できたら、どちらかがクロージングトランザクションを作成します。

インプットにはオープニングトランザクションのアウトプットを設定し、アウトプットには同意した最後の残高をそれぞれのアドレスに設定します。

双方が署名した後、ブロードキャストしますが、意見が合わないときは、クロージングトランザクションではなく、最後のコミットメントトランザクションをブロードキャストすることでチャネルを強制的にクローズすることができます。

9.課題

過去のコミットメントトランザクションを不正にブロードキャストすることをロックタイムにより防止していましたが、そのためにはブロードキャストを検知し、ロックがかかっている間に資金を取り戻す処理が必要で、ブロックチェーンの監視やコストを誰が負担するのかという課題があります。

HTLCを利用した双方向ペイメントチャネル

HTLC(Hashed TimeLock Contract)とは決済相手に直接送金するのではなく、中間者を経由して送金する仕組みで、これを利用すると、取引者それぞれが中間者とチャネルをオープンしていれば、相手と直接チャネルを開くことなく、中間者を経由して送金できます。

取引を具体的に見ていきますが、取引者それぞれは中間者とペイメントチャネルをオープンしているため、始めからコミットメントトランザクションをそれぞれ保有しており、最終的には、コミットメントトランザクションの残高が更新され、手元に残る状態になります。

1.シークレットの作成、シークレットハッシュの連携

送金相手は自分しか知らないシークレットを作成し、シークレットハッシュを中間者と送金者に連携します。

2.コミットメントトランザクションの作成、交換(送金者と中間者)

受け取ったシークレットハッシュを用いて、コミットメントトランザクションを作成します。

送金者は双方向ペイメントチャネルのアウトプットに加えて3つ目にHTLCを用いた中間者への支払いを設定します。

そのlocking scriptの解除方法は、以下のようになっています。

a.一定期間が過ぎた後、送金相手のシークレット(1で作成)が分かれば中間者の秘密鍵で解除できる

b.中間者のシークレットが分かれば、送金者の秘密鍵で解除できる

c.一定期間が過ぎた後、送金者の秘密鍵で入手できる

中間者も3つ目のアウトプットに以下の条件で解除できるlocking scriptを設定します。

a.初めのシークレットが分かれば中間者の秘密鍵で解除できる

b.送金者のシークレットが分かれば、中間者の秘密鍵で解除できる

c.一定期間が過ぎた後、送金者の秘密鍵で解除できる

aは中間者への支払いのため、bは過去のコミットメントトランザクションをブロードキャストする不正を防止するため、cは引き換え期間内にシークレットが中間者から送金者へ渡されない場合に資金を回収するためのもの(中間者が送金相手にコインを払ったことの証明になる)です。

3.コミットメントトランザクションの作成、交換(中間者と送金相手)

2で作成したトランザクションと同等の内容のトランザクションを作成しますが、cでOP_CLTY(ロックタイムを設定するスクリプト)の引数として設定するシークレットの引き換え期間は2と比べて短くなっています。

4.シークレットの連携(中間者と送金相手)

送金相手は、交換したコミットメントトランザクションをシークレットの引き換え期間内(送金者と中間者)にブロードキャストすることで、チャネルをクローズしコインを入手できる状態です。

しかし、チャネルをクローズせず、オープンした状態を維持することもでき、その場合、シークレットを送金相手から中間者へ明かし、両者が合意したうえで残高を更新したコミットメントトランザクションを作り直す(5でも説明)ことでチャネルの維持が可能です。

中間者はシークレットを受け取ることで、送金者からコインを入手できる状態になります。

5.残高を更新したコミットメントトランザクションの作成、交換(中間者と送金相手)

中間者から送金相手への支払いを確定する意味で、残高を更新したコミットメントトランザクションを作成します。

6.シークレットの連携(送金者と中間者)

中間者も送金者と交換したコミットメントトランザクションをブロードキャストすることで、チャネルをクローズしコインを入手できる状態ですが、シークレットを送金者に明かすことで、送金相手にコインを支払ったことの証明ができ、チャネルを維持できます。

7.残高を更新したコミットメントトランザクションの作成、交換(送金者と中間者)

取引内容に応じて残高を更新したコミットメントトランザクションを作成し、交換します。

8.まとめ

HTLCを利用した双方向ペイメントチャネルでは、チャネルの状態を変化させることなく、コミットメントトランザクション残高を更新するだけで、中間者を経由する送金が完了します。

チャネル確定済みの相手を経由して支払うことで、デポジットされる資金が少なく済むようになります。

ライトニングネットワーク

次に、名前は聞いたことあるかもしれませんが、ライトニングネットワークについて説明します。

これは、HTLCを利用した双方向ペイメントチャネルの応用例で、ペイメントチャネルを開いている参加者をルーティング(経路制御)することで、ネットワーク上の任意の参加者同士が資金を授受できるようになっています。

ライトニングネットワークは各社が独自に実装を行っていて、各社の仕様の互換性がなく、相互互換するための仕様としてBOLTというものが検討されているらしいです。

Teechan

スケーラビリティを解決する仕組みは他にもあり、それがTeechanで、これは上の2つと似ているんですが、TEEsと呼ばれる実行環境を信頼点として利用しているところが異なっています。

Teechanのメリットとしては、Segwitを利用することなく、現状の仕様で双方向ペイメントチャネルを構築可能であることと、取引の手順がライトニングネットワークに比べてシンプルなことが挙げられます。

シンプルになった理由は、ハードウェアを全面的に信頼し、秘密鍵をハードウェアに預けているからで、その分ハードウェアが壊れたときのダメージは大きいです。

Segwitの仕組み【ブロックチェーン】

ビットコインの課題として、署名検証に影響を与えずにTXID(トランザクションの識別子)の異なるトランザクションを作れてしまうという、トランザクションのmalleability問題が存在します。

この問題がどうやって起きているのかというと、まずトランザクションに署名するということは、トランザクションの署名対象データ(unlocking script以外)のハッシュ値を生成し、そのハッシュ値秘密鍵で署名し、その署名データをunlocking scriptにセットすることです。

そして、検証はこれを復号したものと署名対象データのハッシュ値が一致するかどうかを見ます。

以上から、unlocking scriptを改ざん(署名スクリプトの処理に影響のないデータをプッシュするなどしてできる)しても署名検証には影響を与えないことが分かります。

しかし、TXIDは、unlocking scriptも含めたデータから生成されるので、malleability問題が起こってしまいます。

トランザクションの検証とかは以下の記事でも紹介しているので是非参考にしてください。

udonta.hatenablog.com

それを根本的に解決するのがSegregated Witness(Segwit)です。

f:id:udonta:20190623154203p:plain

Segwitでは、トランザクションのインプットから署名を分離し、署名を別のデータ領域(witness)に移動することでこの問題を解決します。

未署名の状態でもTXIDが確定するので、未署名なトランザクションをインプットにしたトランザクションチェーンを作ることができるようになります。

この特性がLIghtning Networkなどで利用される双方向のマイクロペイメントチャネルの構築の際にも利用されています。

Segwitがアクティベートされても、それ以降作成するトランザクションがすべて無条件にSegwitのトランザクションになるわけではありません。

P2PKHやP2SHの形式で記述されたlocking scriptを持つUTXOを使用する際は、今まで通りインプットに署名をセットすることになります。

では具体的にSegwitが利用できるケースはというとlocking scriptに特別な意味を持つスクリプトがセットされているケースになります。

その場合の形式はP2PKHに対応する形でP2WPKH、P2SHに対応する形でP2WSHと呼ばれます。

また、これまではビット列を文字列に変換する際Base58というフォーマットを使っていましたが、SegwitではBech32という新しいフォーマットを使うそうです。

以上のように、Segwitを使うには色々ルールの変更があるみたいで、他にもブロックサイズの計算ルールが変更され、block weightと呼ばれる概念が追加されます。

これにより、ブロックに入れられるトランザクションの数が多少増えるみたいですが、恐らくこれは副次的な効果で、本質は初めにも述べたようにmalleability問題を解決することで、オフチェーンを使うペイメントチャネルを構築し、スケーラビリティ問題の解決を目指すという所だと思います。

ブロックチェーンの基本的な流れについては以下の記事で説明しているので参考にして頂ければ幸いです。

udonta.hatenablog.com