blog機械式計算機の同人誌などを出しているサークルです。電子通貨のやり取り本システムでは、コインを、デジタル署名をつなげたチェーンの形で表現する。コインを支払う側は、前回までのコインの取引内容をハッシュ化した値と、受取人の公開鍵をハッシュ化した値とを合わせて、電子的に署名する。それをコインの最後に付け加え、受取人に送信する。受取人は電子署名を検証することにより、そのコインを誰が所有していたかという履歴を辿れる。ここの内容は、すでに概要の回で大半を解説してしまいました。「コインの使用履歴そのものをコインと定義する」ことの説明が、上の図です。ところで、コインを送るとはどういうことでしょうか。「利用者1の秘密鍵」から右上に「署名」の矢印が伸びていますが、この署名こそが、利用者1から利用者2へコインを送るアクションそのものになります。ハッシュ化という言葉が登場しました。本論文では、ハッシュ化とは数値や文字列を「暗号学的ハッシュ関数」に通すことを意味します。暗号学的ハッシュ関数とは、「xが分かればf(x)は簡単に求められるが、yが分かってもf(x)=yとなるxを求めるのは非常に難しい」ような関数fです。ビットコインでは主にSHA-256という関数を使用します。ビットコイン原論文ファイルをハッシュ関数に通してみましょう。bitcoin.pdf(180KB)↓SHA-256b1674191a88ec5cdd733e4240a81803105dc412d6c6708d53ab94fc248f4f553(16進数表示)180KBがたったこれだけの文字列になってしまったわけですから、当然情報は減っています。いうことは、同じハッシュ値になる元ファイルが、他にも多数存在するはずです。そのうちの一つでも見つけ出すのは、総当たりで試すしか無く、事実上不可能です。従って、ハッシュ値は元データの代理として取り扱っても問題ありません。一方で、元ファイルをハッシュ値に変換するのは一瞬です。ここでハッシュ値を使うのは、単に取り扱うデータサイズを小さくしたいからです。コインはそのコインの全取引履歴のデータそのものですから、サイズが大きく、毎回完全な形で処理しているとシステムに負荷をかけます。そのため、ビットコインでは、このようなコア部分の操作はデータをハッシュ化した上で行います。普段は小さいサイズのハッシュ値を使い、検証する時だけ元データを使えば、効率が良いわけです。検証時には、元の取引データをどこかから持ってこなくてはなりません。それも後の節で触れます。暗号論的ハッシュ関数には、サイズを小さくする以外に、もっと本質的な用途がありますが、これは後の節で解説します。ここで問題となるのは、受け取ったコインが、過去に多重使用されたかもしれないことである。これまでに提案された解決法は、信頼できる「造幣局」がすべての取引を監視し、多重使用がないことを保証するというものだった。取引が成立するたびにコインは造幣局に返され、新たなコインが発行される。造幣局が直接発行したコインであることが、多重使用されていないことの証明となる。これは、すべての取引を造幣局経由で行うのと同じで、金融システムの命運が造幣局を運営する組織に左右されるという、銀行と同様の問題を含んでいる。過去の所有者の誰もがコインを他に使用していないことを、受取人が検証できれば良い。そこで、コインが多重に使用された場合は最初の取引だけを有効とし、それ以降の取引は無効であるとする。このように取り決めておけば、すべての取引を調査し、自分の取引が2番目以降でないことを確認すれば良いだけである。造幣局ベースのモデルでは、造幣局が取引をすべて監視しているから、どの取引が先に行われたかが明確に分かる。これを、信頼できる機関無しで実現するには、取引が公開され[1]、それを元にした同一の取引履歴を、利用者全員が共有しているようなシステムが必要である。受取人は取引のたびに、コインが他人に送られていないことについて、ノードの大多数が認めるか否かを確認することになる。1998.前回解説したように、多重取引を防ぐには、「他に取引がない」ことを証明する必要があります。実際には、1番目の取引か2番目以降の取引かを調べるわけですが、「その取引よりも前の取引があるか否か」を調べるわけで、本質的には同じことです。「ない」ことを証明するには、すべての取引を調べる必要があり、何らかの方法で全参加者が同一の取引履歴を共有している必要があります。したら、悪意を持った人物が偽の取引履歴をネットワークに流すかもしれません。そのように各人が異なる取引履歴を主張している場合は、一種の多数決採決が行われます。