【Web3.0の勉強】イーサリアム（Ethereum）とは何か（３）～DworkとNaorのアイデア～

 

 

Ethereum（イーサリアム）について学ぶシリーズ「イーサリアム（Ethereum）とは何か」第3回目です。前回は「イーサリアム（Etheruem）とは何か（２）～その目的と動機～」と題し、関連する用語とEthereum開発の目的について解説しました。

今回は、Ethereumに至るまでのブロックチェーン技術の基礎となる技術や、Etheruem以前の暗号通貨の試みについて、Ethereum Yellowpaper（イーサリアム イエローペーパー）で最初に名前が挙げられているCynthia DworkとMoni Naorの論文のアイデアについてご紹介します。

 

Proof of Workの発明

Cynthia DworkとMoni Naorは “Pricing via Processing or Combatting Junk Mail” と題した論文で、“Proof Of Work（PoW：プルーフ・オブ・ワーク）” の元となるコンセプトを1993年に発表しています。

論文のPDFは以下のリンクから閲覧可能です。

URL：https://www.wisdom.weizmann.ac.il/~naor/PAPERS/pvp.pdf

プルーフ・オブ・ワーク(PoW)とは？ビットコイン/仮想通貨のコンセンサスアルゴリズムの問題点を初心者にもわかりやすく解説！

 

研究の背景

インターネットは、物理的な郵便物に比べてメッセージ送信にかかるコストを大きく削減し、かつ相互の情報伝達にかかる時間も短縮しました。

物理的な費用と制約を解消したインターネットですが、その普及が深刻化させた問題も存在します。それは、“junk mail”いわゆる迷惑メールの問題です。

郵便物における迷惑メールは受取人にとって非常に迷惑です。しかし、印刷や発送の手間とそれにかかる費用を考えると、迷惑メールを送る側にとっても面倒なものと言えます。

一方、電子メールは文章の作成から送り先の選定までプログラムによって自動化が可能です。一通一通のコストも郵便物と比較して安価で、迷惑メールの送信者にほとんど負荷がありません。

したがって、電子的なメッセージ送受信は物理的な郵便物よりも悪用されやすく、大きな被害をもたらしうるものだと言うことができます。

 

如何に迷惑メールを防止するか

迷惑メールを防止するために一般的に考えられる手法は二つ。規則、そして利用料の設定です。

膨大な数の電子メールが送受信され、多種多様なユーザーがいる中で「迷惑メール」の定義を決定するのは非常に困難です。

サービス利用料をユーザーに課すことで、短時間のうちに大量の電子メールを送信するような行為を抑制することは可能です。しかし、電子メールの利点とは、郵便物に比べて金銭面においても物理的な側面においてもコストを著しく低くできることです。

よって、郵便物の郵送に必要な切手等以上のコストを利用料として課せば、インターネットの利点を損なう結果となります。また、切手とおおよそ同じ程度のコストを課したところで、郵便物における実態以上に迷惑メールを防止することは出来ません。

 

計算コストを課す、という提案

DworkとNaorは、金銭的コストが迷惑メールに対する抑止力になり得ないとして、コンピューターの計算処理を担うCPUに対する計算コストを課すことを提案しました。

簡潔には、ユーザーがメッセージを送信するとき、送信要求を行うユーザーに固有の値を引数にとって、計算が著しく困難な関数を送信元のユーザーに行わせるというものです。

DworkとNaorは、このような関数を “pricing function” と名付けています。

 

“pricing function”の性質

難易度

“pricing function” の難易度は、「せいぜい計算不可能ではない程度に難しく、少なくともほどほどに簡単である」ことが要求されています。

具体的な難易度は、実際の関数の実装によって異なりますが、現実的に計算結果を出力することが不可能なほど難しくはないこと、簡単と言えども一定の計算コストはかかることが重要な点です。

 

難易度パラメーター

“pricing function” はパラメーターを持ち、その計算における難易度を調整することができます。値が大きければ大きいほど難易度（特に、“pricing function” が必要とする計算の内、最も簡単な計算の難易度）が上昇します。

 

計算コストの特徴

ｎ個の引数を与えられたとき、これらについて順にかつ連続に“pricing function” を解いた時、計算コストの平均はｎの値に関わらず与えられた引数のいずれかについて関数を計算したときとほとんど同じである必要があります。

加えて、事前に何らかの処理を行うことによって、“pricing function”の計算が効率的に行えるようになってはなりません。

 

検証可能性

関数の引数にあたる値と戻り値にあたる値が与えられたとき、これらが関数を通して対応しているかどうかが容易に確定できなければなりません。

 

ショートカット

DworkとNaorが提案したPoWで特徴的なのは、計算を著しく易化させるショートカットを持つことです。これは、電子メールの迷惑メールに構想の端を発していることから、一度に同様の内容のメールを多数のユーザーに送信する必要のある企業や組織の存在を想定し、これらのアカウントが莫大な計算コストを回避することができるように設けられたものです。

このショートカットは、サービス管理者によって提供されます。

 

実際のメールシステムにおいて

“pricing function”となる関数ｆが一つ、ｆのショートカットｃにハッシュ関数が必要となります。

関数ｆと利用料の設定はサービスの管理者が行い、全ユーザーが管理者に従います。また、ショートカットの情報を受け取ることのできるユーザーが任意の数だけ存在します。

“pricing function”である関数ｆとハッシュ関数は全ユーザーに知られており、一部のユーザーや管理者のみがショートカットを保持しています。

メッセージ送信のリクエストに対して要求された（当該リクエスト固有の）計算を行う際、メッセージ本文の内容を使用します。ただし、本文そのままでは関数の引数とするのには長すぎます。したがって、メッセージ本文、リクエストを送信した日時、メッセージの送信先をハッシュ関数に通してハッシュ値を取得し、これを関数ｆに入れて計算することによって署名を作成します。

 

まとめ

今回の記事では、現在のPoWの元となる最も最初に考案されたコンセプトについて、その大まかな設定について説明してきました。

現在の多くのブロックチェーンは“Decentralized（分散型）”のネットワークですが、もとの発想やショートカット機能などに由来してDworkとNaorが提案したシステムは中央集権的なものでした。今回紹介した論文を受けて、分散ネットワークでの利用を想定した論文が後に出版されることとなります。これらは追々紹介していきます。

次回は、どのような数学的関数が実際にふさわしいものとして論文中で候補に挙げられているのか解説していきます。

 

＜第4回へ続きます＞