Aidos Kuneen White Paper (Japanese Draft)Version 0.02

このホワイトペーパ及び原文はDRAFTであり、今後変更されます。

目次Abstract (概要)1章 Introduction (序論)2章 Related Works (関連研究)3章 Signature Scheme (署名方法)4章 iMesh5章 Proof of Work6章 Cooperative Proof of Work7章 AK shuffle8章 Network9章 Leaves in iMesh10章 Conclusion References(参考資料)

Abstract(概要)本書は、仮想通貨「Aidos Kuneen（ADK）」について説明するものです。Aidos Kuneenは、量子コンピュータ時代にふさわしく、ブロックレスで匿名性に優れており、分散処理とスケーラビリティを一切の手数料なしに実現した仮想通貨です。このコインでは、トランザクションが互いに参照しあい、DAG（Directed Acyclic Graph）構造を形成する「iMesh」を採用しています。悪意のある二重決済を防ぐためにDAG構造を調べ、どの取引が高い確率で正規のものであるかを「SPECTRE」に基づき判断します。署名には、数ある耐量子

コンピュータのアルゴリズムのなかで最も実用的で、署名サイズと公開鍵サイズが比較的小さいハッシュベースの署名「XMSS」を採用しています。耐量子コンピュータのためのゼロ知識証明「ZKBoo（ZKB ++）」も備え、AKShuffleと呼ばれる匿名転送にも利用されます。IoT機器への対応については、coPoW(cooperative Proof of work)を導入し、コインの送信者は、共同でPoWを実行することができます。最後に、あるトランザクションをDAG上で確定させるために必要な、最小の参照トランザクション数を求めるために、iMeshにおける末端トランザクション数ごとにおきうる状況のシミュレーションを行いました。これは、トランザクションサイズにできるだけ影響を与えない形で、より短い承認時間になるシステムを目指すために行われました。

1章 Introduction(序論)2008年にSatoshi Nakamoto [1] により発明されたビットコインは現在、世界中で広く使われています。ビットコインは10分に一度、Proof of Work(PoW)により周期的にブロックチェーンにトランザクションが保存されており、トランザクション利用者が手数料をマイナーに支払います。トランザクションは入出力により構成されており、前のトランザクションをElliptic Curve DigitalSignature Algorithm (ECDSA:楕円曲線電子署名アルゴリズム)を使い署名する事でオーナーが正規であるかを確認しています。然しながら近年ビットコインは以下の様な問題を抱えている事が明らかになっています。

・低いスケーラビリティ　ビットコインはブロックサイズに限りがあり、上限を超えたトランザクションの保存ができません。その為、多くのトランザクションが送信された場合に現行ブロックにトランザクションの保存がされなくなってしまうスケーラビリティ問題が生じてしまいます。その上でビットコインの取引が増え、更に多くのブロックが10分で生成されてしまうと、より多くのトランザクションの確定に10分以上待たなくてはならなくなってしまいます。

・高い手数料　トランザクションの利用者はインセンティブとしてブロックのマイナーに手数料を払わなければなりません。ビットコインの取引が増えビットコインの価格が上昇すると、ビットコインの手数料も相対的に高くなります。手数料より少額の決済を行う場合は、少額決済の為の複雑なスキームが必要となってしまいます。(例：マイクロペイメントチャンネル)

・量子コンピューターに対する脆弱性　　2017年時点で量子コンピューターの開発は未だ初期段階ですが、量子演算の実験は着々と進められています。Googleは量子演算技術の商用実用化を5年以内に実現するとレポートしています。[11]その一方でShor’sアルゴリズム [10] によると、ビットコイン等に使われているECDSAを含む楕円曲線離散対数署名は量子コンピューターの圧倒的な演算力により容易に突破されてしまいます。

・脆弱な匿名性　　ビットコインを利用する為には、過去に利用されたトランザクションを参照してトランザクションを実行せねばならず、これらのトランザクション情報は全て公開されています。故に、誰でもアドレス間のビットコインの移動を見ることができるのです。

私たちはこれらの問題を解決する新しい暗号通貨"Aidos Kuneen"を紹介します。Aidos KuneenはiMeshと呼ばれるDAG(Directed Acyclic Graph:有向非巡回グラフ)技術を採用しています。これはブロックやブロックチェーンが存在せず、トランザクションが直接別のトランザクションを参照する技術です。トランザクションの確定はDAG構造に基づく別トランザクションの投票(vote)により決定されます。iMeshにより、スケーラビリティと手数料なしの恩恵を受けることができるのです。

・スケーラビリティの向上　iMeshではトランザクションのPoWが相対的に容易に行え、即時にiMeshに保存されます。故に、iMeshにトランザクションが保存されるのを待つ必要はありません。iMeshの利用が増え、より多くのトランザクションが行われると、トランザクション確定はより早く強固になっていきます。

・手数料なし　マイナーが存在しないので、手数料を払う必要がありません。つまり、極少量の通貨を特別な技術なく送金する事が可能です。

・量子コンピューター耐性Aidos KuneenはECDSAに代わり強力な量子コンピューターセキュリティを持つハッシュ構造ベース署名を採用しています。量子コンピューター時代には、Ring-LWEを含む多くの格子構造ベースやハッシュ構造ベースの署名があります。しかし、その多くは暗号鍵や署名のサイズから実用的とは言えません。Ring-LWEや格子構造ベースの署名の暗号鍵のサイズは数キロバイトになります。それはつまり、アドレスが非常に長い文構造となり、それをウェブサイト上にコピー＆ペーストしなければならなくなります。これは、暗号通貨の一般的な使い方としては実用的ではありません。SPHINCSの様なハッシュ構造ベースの署名でも、公開鍵サイズは1 KByteにもなってしまいます。ハッシュ構造ベースの暗号鍵サイズは確かに相対的に小さいけど、現実で使うにはまだ足りません。その為、私たちはeXtended Merkle Signature Scheme(XMSS)を利用することにしました。これにより1000回以上の公開鍵に利用が可能となり、公開鍵と署名鍵のサイズが3KByteになりました。加えて、XMSSは128bitsの量子コンピューターセキュリティにも対応しているので、長期に渡って量子コンピューターシステムでの利用に耐えられます。 [12]

・強い匿名性耐量子コンピューターの匿名性ではゼロ知識証明(ZKBoo) [7] を採用しています。コインをハッシュに送る際にはインプットしか分かりません。そして、コインはそのインプットが明かされる事なく利用されることで匿名性を保ちます。

このホワイトペーパー上では複雑な方程式を極力除き、厳密な理論ではなく直感的な理解のための説明を行っております。これは、より多くの方にAidos Kuneenの全体像を理解してもらいたいからです。また、複雑な公式により暗号通貨の僅かな部分だけを説明したホワイトペーパーで誤解を生じさせたり悩ませることを私たちは望んでいません。より詳細な理論やセキュリティレベルの証明に関しては、参考文献をご参照頂ければと思います。

2章 Related Work

匿名性のために、Monero1やByteCoin2はCryptoNote [13] で言及されているリング署名を利用しています。しかし、残念なことに、リング署名は、（公開鍵暗号のような）一方向性関数を使っていますが、ハッシュベースの署名には一方向性がありません。Zcoin3はzk-SNARKsと呼ばれるゼロ知識非対話証明(zero-knowledge non-interactive proof)を使用していますが、zk-SNARKsは、量子コンピュータ時代に安全とは言えません。なぜなら、Zcoinの開発者が議論しているように4ペアリングベースの暗号を用いているためです。ここの議論において言及されているように、量子コンピュータ時代に安全なペアリングベースの暗号を私たちは見つけることができませんでした。その代わりに、Aidos KuneenではZK-Booと呼ぶハッシュ関数と暗号関数(AES等)のみを用いて、量子コンピュータに対しても安全な署名を使用します。

次に、手数料の掛からないDAGベースの暗号通貨であるIOTA5との対比について、いくつか記述します。

1つ目は、Curlと呼ばれる独自のハッシュ関数です。彼らはIOTAのプログラムコードが安易に流用されないように、意図的にデータ異常を起こすハッシュ関数を開発しました。これは誰もが自由にソースコードを使えるオープンソースの暗号通貨界隈では画期的な発明でした。残念なことに私たちには、故意に衝突が起きるようなハッシュ関数を開発する余裕がないため、既に存在するハッシュ関数であるSHA256を利用することにします。

2つ目に、彼らはバイナリ(binary, 訳注:二進法)ベースの署名の代わりにトライナリ(trinary, 訳注:三進法)ベースの署名を使用しています。これは、理論的にはトライナリの方がバイナリよりも効率的であるためで、彼らは新しいトライナリベースのアナログ処理を行う回路を開発しはじめています。数十年前から、半導体は小さな電力とサイズで二進計算が可能なCMOS(complementaryMOS:相補型金属酸化膜半導体)がベースとなっています。半導体を設計するためのツールも、複雑なアルゴリズムを用いて完全にCMOS向けに最適化されています。例えば七十億(7 × 109)ものトランジスタが搭載されているIntelの(22-core Xeon Broadwell-E5)チップの面積はたった680mm = 2.6cm × 2.6cmで、このチップは現実的なプロセスサイズ(14nm)で生産されており、御存知の通り大変速い計算能力をもっています。このチップのうち大した領域を使わずとも、伝統的なハッシュ関数の計算やそれを使ったPoWの演算ができることは、誰しも容易に想像がつくことでしょう。また、半導体業界の大量生産においては、チップを製造するために多額の初期投資が必要です。そのため、大量にチップを売るか、チップあたりの単価を驚異的に高価格にするほかありません。これこそが、半導体業界でたくさんの合併・買収が起きてきた理由になります。さらに、IoT用途のチップのうち幾つかはSHA-2ベースのハッシュを生成する専用の回路を既に持っています。このような状況にもかかわらず、IOTAの開発者は小型で省電力な性能の良い専用チップをアナログ回路ベースで作る方法を知っていて、それを小さいコストで大量に売る方法を知っていると主張しています。私たちにはそのような性能のチップを設計するノウハウが全くないためSIMD命令、専用SHA拡張などの既存のCPUの機能を最大限利用した、従来通りのバイナリベースの署名を使用します。更に、PoWをたくさんのIoT機器で協調して行う方法についても紹介します。(協調型」PoWは6章で言及します。)

3つ目に、「ネットワークの2/3が悪意のあるノードの場合のみ、ネットワークが破壊される」とIOTAの開発者は主張しています。しかし、参照トランザクション数を加算していくだけのIOTAの認証方式に従うと、DAG上に多量の末端トランザクションが存在する場合（それは普通に起きる状況ですが）、攻撃者は彼らの悪意のあるトランザクション群を容易に成長させることができる、とい

うことに直感的に気がつくことになります。彼らは末端トランザクション数を最小にするため（つまりDAG上のトランザクションを確定させていく）ために、たった２つのトランザクションだけを参照すれば十分であることを知っている、と主張していますが、その理由はホワイトペーパーにおいてもトップシークレットということで明らかにされていません。(ホワイトペーパーでは「L(t)(末端トランザクション数の総和)は安定し続けることが期待できる」とだけ書かれています。）

私たちは文献 [9] で言及されているSPECTREベースの確認手順を紹介します。SPECTREではトランザクションの承認数は、参照トランザクション数だけでなく、そのトランザクションに投票した他のトランザクションの数も含みます。したがって、末端トランザクションの集合(訳補：ここは悪意のある末端トランザクションの集合という意味合いが重要だと考えます。)が、分岐していたとしても、攻撃者は悪意のあるトランザクションを成長させることはできません。しかし、私たちはより速い承認のため、より速いDAGの収束が必要となります。そのため、私たちはiMeshにおける末端トランザクションの振る舞いをシミュレーションして、DAGの収束がより早く行われることを確認しました。

最後に、私たちはDAGベースの手数料なしの暗号通貨という革新を行ったIOTAに対して心から敬意を表します。

3章 Signature Scheme(署名方法)

図1: WOTS+署名による鍵の生成、署名、検証

署名方法にはXMSSを採用し、そのパラメータにはIETFのRFCドラフトに記載されている設定を使います。XMSSはヴィンターニッツ・ワンタイム署名(WOTS+: Winternitz One Time Signature)を元にしています。図1は公開鍵の生成方法、メッセージの署名方法と、署名の検証方法を表しています。公開鍵を作るためには、まず67個の32バイト長(256bit)のランダムバイナリデータを秘密鍵Privj, j = 1...67とします。そして、それぞれの32バイト長のバイナリデータPrivjはSHA256で16回ハッシュ化します。ハッシュ化を施す前に、PRF（擬似乱数関数）より生成された値とランダムバイナリデータの排他論理和(XOR)を取ります。この処理は、セキュリティレベルはそのままに署名のサイズを削減するための秘訣です。これにより67個の32バイト長バイナリデータが作れます。これが公開鍵Pubj, j = 1...67です。

署名については、まず最初にメッセージを一度ハッシュ化し、ハッシュ化されたメッセージのチェックサムを算出します。すると、4bitバイナリ毎にハッシュ化されたメッセージから値を取得する事ができます。これらの値は上図のN1等となります。次に、公開鍵の各4bitバイナリは公開鍵生成時に利用した物と同じ乱数値を使って排他論理和(XOR)を取りながらNn回ハッシュ化されます。すると、これらの結果を連結する事で署名が作成されます。

このチェックサムは悪意のあるメッセージからの攻撃を守るために使用されます。例えば、攻撃者が000…0のハッシュを持つメッセージをチェックサムなしでつくったとき、署名が秘密鍵と一致してしまい、これにより、攻撃者は秘密鍵を知ることができてしまいます。

署名の確認には、署名生成と同様にメッセージからNjを計算します。そして、署名Sigjを、公開鍵生成時に使用した乱数で排他論理和を取った後、ハッシュ化することを(16 − Nj)回繰り返し、Pub ′j (j = 1...67)を得ます。そして、Pub

′jが公開鍵Pubjと一致するかどうかを確認します。

なお、、WOTS+の公開鍵は一度しか使用できないということを付け加えて記載しておきます。

図2: XMSSの鍵生成と認証経路(auth path)

図2は、XMSSによる鍵の生成方法を表しています。簡単に言うと、XMSSは、一つの秘密鍵からできる全ての公開鍵を集めマークル木と呼ばれる木構造を構築したものです。したがって、一つの公開鍵を何回も使用することができます。まず、複数個の秘密鍵Privijと対応するWOTS+公開鍵Pubij(j = 1...67)を作る必要があります。このとき、一つの’ltree’は、それらの公開鍵のうち１つをハッシュ化することで作られます。公開鍵１つは67個の32bitバイナリデータであることを思い出してください。公開鍵の67個のバイナリデータに対し、隣同士(Pubij と Pubij + 1 等 )を繰り返し結合しハッシュ化することで、最終的に32バイトのバイナリデータが得られます。ltreeを作ることを、公開鍵の個数iだけ繰り返します。つまり、2h(h: マークル木の階層)回だけ繰り返します。これらが、マークル木の末端です。マークル木のルートハッシュは、ltreeと同じ方法でltreeのルート(根)をハッシュ化することで得られます。このルートハッシュがXMSSの公開鍵です。

署名については、以前に使用されていない秘密鍵と対応する公開鍵を選び、WOTS+署名を得ます。XMSS署名は、WOTS+署名に「認証パス」(auth path)がついたものです。認証パスは、マークル木のルートハッシュを計算する為の追加ハッシュデータです。例えば、図2において3番の秘密鍵と公開鍵を署名に使用するものとします。この場合、WOTS+署名から3番の公開鍵が計算できます。3番のハッシュデータは既にありますが、12番のハッシュデータを得る為には4番のハッシュデータが必要になります。そのため、認証パスには4番のハッシュデータが必要です。同様に、31番のルートハッシュ(すなわちXMSS公開鍵)を得るためには、4番、11番、22番のハッシュデータが必要です。

検証時にはWOTS+署名と認証パスを使い、マークル木のルートハッシュを計算することで、ルートハッシュがXMSS公開鍵と一致するかどうかを確認します。

付け加えておくと以下の特徴があります。

署名者はどの秘密鍵が使用済みを記憶する必要がある。同一の秘密鍵は使用できない。公開鍵は、32バイトの擬似乱数のシードと32バイトのマークル木のルートから構成される。これまで説明した疑似乱数は全て、この３２バイトの疑似乱数シードを元に生成される。署名の鍵サイズは約3KB

SHA256ハッシュは原像計算困難性を持ち、ハッシュの出力値から入力値の特定は極めて難しい。これは仮に量子コンピューターであっても、公開鍵から秘密鍵を暴くことは難しい。

更に付け加えておくと、もしh(マークル木の階層数)を更に増やすと、公開鍵も更に何回も使用できる様になりますが、これを行うと、最初の公開鍵の生成時に時間がかかるようになります。したがって、Aidos Kuneenでは、３種類のマークル木を用意しています。

表1: 鍵の生成とXMSSの使用時に関する、マークル木の階層数別のシングルコアあたりの推定所要時間

表1に、その4種類を表しています。1回ごとにアドレスを変えたり、1000回もコインを送らないような一般ユーザは、公開鍵の生成には計算量の少ない高さ10を使用します。一つの公開鍵で何度もコインを送るような企業や事業主は、高さ16や20を使用します。ここで留意すべき点は、[2] で言及されているXMSSMTは鍵の生成時間は短いものの、XMSSと比べると署名データのサイズが約40KBと大きくなるので利用できないという事です。

4章 iMesh

階層数h 鍵の個数 鍵の生成時間 利用者

1 1 1秒未満 ワンタイムユーザー

10 1,024 1~2秒 通常ユーザ

16 65,536 数分 企業

20 1,048,576 約30分 大企業

図3: iMesh

コインの送信者がトランザクションを送るとき、そのトランザクションにはいくつかの承認された以前のトランザクションが直接的に含められます。図3はiMeshと私たちが呼ぶトランザクションのDAG構造です。iMeshでは、送信者がDAGの末端トランザクション（どのトランザクションにも参照されていないトランザクション）と、親トランザクションが有効かどうかを確認し、有効なものを選びます。最終的に、送信者は有効だと確認されたトランザクションを送信者のトランザクションに含めます。

ビットコインなどブロックチェーンベースの暗号通貨に利用されるブロックは１つ前のブロックを参照しているため、構造は1つの線状になります。しかし、DAG構造は1つのトランザクションでたくさんのブロックを参照可能です。ブロックチェーンは一定時間ごとにに1つずつ成長していきますが、対してDAGはたくさんのトランザクションが一斉に成長していきます。すなわち、DAGはブロックチェーンよりスケーラブルとなりうるわけです。

しかし、トランザクション間で不整合が生じた際、DAGのスケーラビリティ上の利点が想定外の事態を引き起こしてしまいます。例えば、アドレスAに10枚のコインがあり、AがBに10枚のコインを送信するトランザクションをT1、AがBに10枚送信するもう一つのトランザクションをT2とします。この結果として、2つの衝突したトランザクションがアドレスAにできます。ブロックチェーンベースの暗号通貨の場合、片方(例えばT1)が一度ブロックに保存されると、もう一つ(例えばT2)は決してブロックに保存されることはないでしょう。つまり、T2は有効化されることは決してないのです。一方DAGにおいては、衝突したトランザクション(図3に赤く色付けした部分)のどちらが有効か知ることは難しいです。この問題の解決のため、私たちは’SPECTRE’ [9] の投票の仕組みを利用します。これにより、何の根拠もなくコインを作り出すことはできない為、攻撃者は上記の「二重決済」攻撃を含む如何なる攻撃も試行することができなくなります。

図4: 簡易なDAG上における投票の手順の例

SPECTREでは、それぞれの衝突したトランザクションに対して、衝突したトランザクションを投票したトランザクションを数えます。図4に投票の手順を示します。この図ではトランザクションxとyが不整合を起こしています。トランザクションxとトランザクション6 ~ 8は、自身の過去履歴にyではなくxを持つため、トランザクションxに投票します。同様に、トランザクションyとトランザクション9 ~ 11はyに投票します。トランザクション12はトランザクション10, 11, 12を含まないDAG

上の再帰呼び出しに基づき投票を行います。トランザクション1 ~ 5は、後続トランザクションにおいてyの投票者よりxの投票者の方が多いことからxに投票します。結果としてxの投票者がyの投票者より多くなることから、xが正当だと判断されるのです。

DAGの幾何学的観点から、なぜ投票により正しくトランザクションが決定されるかを解説します。

1. トランザクションxを親とする、あるトランザクションはトランザクションxに投票します。正当に生成されたトランザクションは秘匿的なトランザクション群に投票されることで、正当なノードは後続に向けて新しいトランザクションを生成し続けます。

2. あるトランザクションがxとyを親として持つとき、そのトランザクションは投票者の多い方に投票します。新しいトランザクションが投票する事で前の決定に従い且つその投票を強化する事で、多数派を増幅させることを保証します。

3. あるトランザクションがxもyも親として持たないとき、そのトランザクションは投票者の多数いる方のトランザクションに投票します。このルールにより、xの親の(更にxの子)が、yを贔屓にする票に反対して、xの票数を拡大させることが可能です。これは万一yが長い時間隠れていたときのためです。これは、プレマイン攻撃方法、(すなわち、攻撃者が大きなトランザクションの塊(block)をネットワークから隠して作っておく方法)への対抗手段となります。

4. xがyの親である場合すべてのブロックは満場一致でxに投票します。

ここで注目すべきは、SPECTREは33%ではなく50%の演算力攻撃に耐えることができることです。ビットコインのように、コインの送信者はトランザクションが、十分な数のトランザクションによって確認されるまで待たなければなりません。文献 [9] において、どれくらいの時間(コインの)受信者が待つことになりそうか言及されています。もし私達が5確認まで待ち、ビットコインネットワーク内に30%攻撃者がハッシュパワーを持つと仮定すると、攻撃ができる可能性は17.8%[1]です。SPECTREの投票スキームで同様に17.8%の攻撃可能性を得るには約130個の参照トランザクションが必要となります。iMeshでより早くトランザクションが来れば、より待ち時間も短くなるでしょう。反対にいうと、Aidos Kuneenネットワークの初期段階においては、長い時間待つ必要があります。更に、攻撃者がハッシュパワーの半分以上保つ場合、悪意あるトランザクションが不正に承認されることでiMeshは攻撃されてしまいます。とくにiMeshに少ないトランザクションしかない初期の段階ではこれが起こりうるでしょう。したがって、私たちはiMeshの早い段階においてトランザクションを確定的に確認するメカニズムを導入します。そして、もう一つ記載しなければならいこととして、iMeshにたくさんの末端トランザクションがあるとき、1つのトランザクションを参照するトランザクションは少なくなります。そのため、私達はどれくらいの個数のトランザクションが1つのトランザクションから参照されるべきかを考慮する必要があります。この問題については、9章で紹介します。

SPECTREでは、多くのトランザクションが過去のトランザクションを参照するため、送信者は可能な限り多くのトランザクションを参照する意義があります。なぜなら、トランザクションの承認数は「そのトランザクションが参照しているトランザクション数」と「そのトランザクションが将来的に別のトランザクションにより参照される数」に依存するからです。つまり、より多くの過去ト

ランザクションを参照すれば、より早くトランザクションが承認され、受信者に確実にコインを届けることができるのです。言い換えれば、トランザクションの参照数が少ない場合は承認に時間がかかるので受信者に支払いを拒否されるかもしれません。

5章 Proof of Work

トランザクションを送信するとき、コインの送信者は、ビットコインでマイナーが行うようにProofof Work(PoW)をする必要があります。それぞれのトランザクションにはノンス欄(訳注：暗号通信で用いられる使い捨て乱数データのこと。PoWにおいては暗号学的ハッシュ関数の出力を変えて特定の条件を満たさせるために使われ、難易度調整に用いられる。条件を満たすノンスを総当たりで探す作業をPoWと呼ぶ)があり、トランザクションのハッシュは特定の値にならなければなりません。Proof of Workの目標時間は5～10分に設定されています。Aidos KuneenのPoWはビットコインに比べDDoS攻撃や、二重決済攻撃からネットワークを守るために必要な作業量が少ないので処理が比較的軽いです。

さらに、PoWは、トランザクションの発生分布を分散させることができます。なぜならλ1が次に発生するPoWされていないトランザクションのtimeを表す乱数X1の分散だと仮定し、λ２ がPoWの必要時間を表す乱数X2だと仮定た場合、X1とX2は 独 立 し て い る た め 乱 数 X1の ト ラ ン ザ ク シ ョ ン 発 生 分 布 が λ1 + λ2 > λ1$になるからです。そのため、私たちは、iMeshが大きくなった際にPoWのdifficultyを再設定することができるでしょう。

PoWでは、BLAKE2b-256の後にSHA256を使用しています。その理由は以下のとおりです。iMeshはビットコインのブロックと比べて多くのトランザクションが存在し、iMeshのフルノードは全てのトランザクションに対するPoWを計算しなければなりません。つまり、ビットコインのフルノードと比べてPoWの計算量が多くなります。そのため、主にASIC耐性を持つように開発された(cryptonightやscryptなど)重いハッシュ関数を使用すべきではありません。更に、Aidos Kuneenには、高いハッシュパワーを与えることに対する報奨がありません。他方で、全体の半分以上のハッシュパワーを持つ人は、二重支払トランザクションを作ることができます。そのため、ASICの中では比較的マイナーであり、ASIC耐性を持つハッシュ関数より大幅に軽いBLAKE2を選択します。また、私達は既存のASICやCPUのSHA拡張命令を～使用することを防ぐために、2つの別の種類のハッシュ関数を選択します。

6章 Cooperative Proof of Work

IoT機器などCPUの性能が低い端末のために、coPoWと呼ばれる協調型Proof of Workを紹介します。これは、それぞれの送信者のトランザクションが混ぜ合わせられ、それぞれのコイン送信者が1つのトランザクションを一緒にPoWを行う事ができます。coPoWによって、膨大な数の多種多様なIoT機器を利用することができます。Powは分散合意アルゴリズムによって、ビットコインのマイニングプールの様な非中央集権方式で動作します。

1. coPoWに参加したい者はフルノードを介してネットワークにリクエストをブロードキャストします。

2. coPoWに参加している、または参加したい他の方々はそのリクエストにcoPoW応答を返します。

3. coPoWネットワークに参加して、リーダーを選択するか、誰がリーダーであるかの情報を取得します。

4. トランザクションをリーダーに送り、そのグループに関するトランザクションをリーダーから取得します。

5. リーダーから混ぜ合わされたトランザクションを取得します。6. PoWを行います。7. 周期的にPoWの結果をリーダーに送信します。8. 周期的に、リーダーからグループのPoWの結果を取得します。9. リーダーは一定周期で送らなかったり、間違えた結果を送信する者を拒否します。　この場合、リーダーはグループのメンバーにcoPoWを再実施するよう司令を出します。

10. 誤った結果を返す者がグループから去ります。11. 一度正しい結果(PoWの目標値)を受信すると、PoWを停止します。

加えて、グループのメンバーは匿名性のためにTorを使用することができます。周期的に、coPoWのグループは、目標より簡単(PoWのproofに一致する)な結果(トランザクションのnonce)を送らなければなりません。これは、coPoWに参加しながらPoWを行わない、タダ乗りを防ぐためです。proofの目標はAidos Kuneenでは可変です。例えば、性能の低いCPUを備えるIoT機器のグループはproofの目標をtarget × 25にすることができ、通常のPCに対してはtarget × 22に設定することが可能です。

7章 AKShuffle

匿名性を担保するために、私達はAKShuffleという技術を使用します。 AKShuffleでは、匿名性を保ってコインを送信するためにゼロ知識非対話型（ZKNI）証明を利用しています。 ZKNIによって、誰でも自身の値を明らかにすることなく、いくつかの関数を満たすことを証明することができます。 例えば、アリスが、暗号化関数fk（ x） に対して入力xを暗号鍵kで入力し、xという入力はyを出力、すなわちy = fk （ x） であるとします。 ボブはアリスが実際にfk(x)がyを返すようなkを持っていることを知りたいとします。しかし、アリスは彼女のkを明らかにしたくありません。ZKNIはこういった目的のための技術です。私達はZKNIの実装として [8] で言及されたZKBoo（ZKB ++）を利用します。 ZKBooは、量子コンピュータ耐性(筆者注:量子計算機に対して耐性がある暗号方式)なハッシュと暗号化関数（AES）のみを使用します。

図5

図5は、AKShuffleに関するトランザクションを図示しています。コインをシャッフルしたいと思う人は、彼のコインをシャッフルアドレスに送ります。シャッフルアドレスというのは、暗号化関数fkmy(xmy)の出力です。kmyは彼の秘密鍵であり、xmyは彼の公開入力です。しばらくした後、彼はシャッフルされたコインを回収します。彼は、彼の通常のアドレスPKmy2（彼のXMSS公開鍵）に送る1つのトランザクションを作成します。そのトランザクションは、他人のAKShuffleアドレスfk1 （ x1 ） , fk2 （ x2 ） , …fkn （ xn ）と彼のAKShuffleアドレスfkmy(xmy)を混ぜてインプットアドレスとして利用します 。 これの意味する所は、どのアドレスが実際に支払いに利用されたか、外部からは分からないということです。

署名において、彼はZKNI証明を満たすことで、トランザクションに含まれるAKShuffleアドレスのうち一つが、fkmy(xmy)の出力と等しくなるようなkmyを知っていることを証明します。 iMeshではAKShuffleアドレスfkmy(xmy)が一度でも利用されたことが記録されており、アドレスが再利用されることを防いでいます。このため、トランザクションには公開入力xmyが含まれます。トランザクションに含まれる金額はすべて同じでなければならないことに注意してください。また、AKShuffleの署名方式と通常支払いの署名方式が異なることにも注意してください。AKShuffle（ZKBoo）は、だれかのコインをシャッフルすることにのみ利用されます。つまり、AKShuffleを別の誰かに支払うために使うことはできません。これは、ZKBooのシグネチャサイズが大きいためです（入力アドレスの数が5の場合は約500 KBytesにもなる）。

8章 Network

図6: AidosKuneenにおけるフルノードとクライアント(ウォレット)

Aidos Kuneenのネットワークはフルノードを伴ったP2P形式で構築されています。クライアントはこれらのフルノードもしくは自らのフルノードに接続し、通常はウォレットのアプリケーションによりトランザクション等を送信するためのAPIを送ることができます。フルノード間でのトランザクションの送受信には、Bitcoinなどで使われているパケットサイズを削減するための可変長整数を包含したプロトコルを使用しています。公開されたフルノードとクライアントとの間の接続には匿名化のためにTorも使用しています。フルノード間の通信については速度が重要となるためTorは使用しません。トランザクションはフルノードの間を中継されるため、ネットワーク上のトランザクションを誰が送信したのかを知る方法がありません。そのためフルノード間の通信には匿名性を付与する必要はありません。一方でフルノードは、クライアントのIPアドレスとクライアントが何を送信したのかを知ることができます。またピア検索に利用するためにKademliaネットワークを構築しています。今のところ、KademliaのDHTは使用されていませんが、将来的には独自の匿名ネットワークを計画する際の分散トランザクションの保持にはKademliaを利用します。残念ながらTorは耐量子コンピュータではありませんが、Torには多数の参加者がいるため非常に強力な匿名化の恩恵を享受することができます。また将来的には多数のAidosKuneenの参加者の存在により独自の匿名ネットワークを構築できるようになります。分散トランザクションの保持により、トランザクションの分散化を計画しています(フルノードがすべてのトランザクションを保持していなくても、フルノード同士が他のフルノードが持っていないトランザクションを共有し合うことでよりスケーラビリティを高めることができます)我々はこの手法を開発している最中です。表2はパケットのコマンドを示します。

表2: 標準パケットコマンド

9章 Leaves in iMesh

command description

ping ping to another node

pong resoponse of ping

find_node requests node infos

resp_node response node infos

req_transactions requests transactions contents with hashes

resp_transactions responds transactions contents

req_leaves requests leaves’hashes

resp_leaves responds leaves’hashes

invent invent a new transaction hash

ack_invent ack of invent

invent_coPoW invent nodes are searching for coPoW

ack_coPoW ackofinvent_coPoW

find_value reserved for future use.

store_value reserved for future use.

図7: Leaves in iMesh

セクション4で述べたように、承認の速度はiMeshの末端(#leaves)の数に依存します。これは多くの末端トランザクションが存在すると、ある1つのトランザクションが参照される確率が低くなるためです(図7)。しかし、いくつかのシナリオにおいては末端トランザクションが増えてしまう可能性があります。一つ目のシナリオは、意図的に非協力的な送信者が自分のトランザクションのために非末端トランザクション(non-leaves)を参照した場合、末端トランザクションの数を減らすことなく末端トランザクションを一つだけ増やすことになります。しかし、その送信者はこのような非協力的な姿勢を後悔することになるでしょう。というのも、既に述べられている通り承認のための時間は参照されているトランザクションの数にも依存するので受信者が送信者のことを意図的に非協力的だと判断した場合、受信者は支払いを拒否するからです。二つ目のシナリオは、あるトランザクションT1がiMeshに入ってきた際にもう1つのT2がPoWを行っている最中で、T1とT2が同じトランザクションを参照してしまった場合です。このような場合でも末端トランザクションの数は増加してしまいます。このシナリオは送信者の意図にかかわらず偶然に発生するため避けることができません。三つ目のシナリオは、攻撃者が多くのトランザクションをブロードキャストし、大量の末端トランザクションを増やして承認を遅延させようとする場合です。このようなシナリオは、PoWによりある程度阻むことができますが、それでも未だ発生する可能性があります。一方で、1つあたりのトランザクションが参照するトランザクション数を増やすことになるため、このことが末端トランザクション数を減らす(iMeshの収束)助けとなることが期待できます。しかし、そのことはトランザク

ションのサイズを大きくしてしまいます。我々にはiMeshを収束させるための最適な数値を知ることが求められます。受信トランザクションのプロセスは、ポアソン過程(Poisson Flow)によってモデル化されると仮定しています。そしてPoWを完了するための期間は指数分布によってモデル化することができるのでλと1 /λ をそれぞれポアソン過程のレートと指数分布の期待値とします。送信者は自分のトランザクションをλ のレートで生成し、トランザクションを参照することを含めて平均して1 /λ でPoWを完了します。PoWを行っている間にも他の送信者もまたトランザクションを生成し、同じトランザクションを参照するかもしれません。時刻tにおける末端トランザクション数は、時刻t − t ′の(すなわち、時間の経過に伴い変動する)末端トランザクション数に依存するので、末端の数を表す式を解くことは困難です。したがって、我々は末端トランザクション数について振る舞いをシミュレートします。Algorithm1は、iMeshにおける末端トランザクション数をシミュレートするアルゴリズムを示しています。1 /λ = 10minutes (平均10分でPoWが完了することを意味する)として固定し、1つのトランザクション内の参照トランザクション数をN = 2, 4, 8, 16, 32とします。そして4種類のλ をシミュレートします。

1. 毎分 1トランザクション (1tx/min)iMeshの初期段階：トランザクションが徐々にiMesh内で生成される

2. 毎秒 1トランザクション (1tx/sec)3. 毎秒 5トランザクション (5tx/sec)※2017年5月のBitcoinの最大値4. 毎秒10トランザクション (10tx/sec)

in pow

in pow

pow

ref in

付録の図8～12にシミュレーション結果を示します。λ = 1 tx/minに対するN = 8, 16, 32の結果についてはN = 4の結果と酷似しているため示しません。これらの結果から、末端トランザクション数はN の数にほぼ比例して減少します。λ = 1 tx/min かつ N = 2の場合でもDAGのを収束させるには不十分です（＃leave = 3-26）。N

= 4であればより良いでしょう（#leaves = 1-18）。他のλ についてはN = 2が他のN よりも明らかに悪いです。例えば、 λ in = 5 TPSで、Nref = 2ではNleaves = 3800,Nref = 8ではNleaves = 500です。もしiMeshにビットコインと同じスピードでトランザクションが入ってくると仮定するのであれば、Nref = 2は使うべきではありません。上記のケースにおいて、ある一つのトランザクションに対し、そのトランザクションを参照するトランザクション数がどのように増えるかについてもシュミレートします。 付録の図13-16に結果を示します。

in ref ref

ref

in ref

ref in ref ref

これらの図では、X軸はiMeshが安定した後にiMeshに追加されたtransactionの数を示し、Y軸はあるランダムなトランザクションに対するトランザクション(子トランザクション)の参照数Ndecendantを示します。グラフは理想には対角線となります。λ =1 tx/minの場合の任意のN グラフはほぼ対角になります。しかし、λ が増加するとNdecendantは少なくなります。例えば、λ in = 5TPSでは、Ndecendantは、Nref = 2で25000トランザクション後（つまり平均 25000 ∗ 0.2秒 ≒ 1.39時 間 ）でも対角線とはなりません。 Nref = 8では4000トランザクション後（つまり平均 4000 ∗ 0.2秒 ≒ 13.3分 ）に一次線形に増加し始めます。

私たちは、ある1つのトランザクションに対するトランザクションの参照数を変数にして、今はデフォルトの数を8に設定することとしました。iMeshがBitcoinの最大TPS(transactions persecond)である毎秒λ = 5tx/secに成長したとしても、N = 8であればiMeshは＃leaves = 500付近でうまく収束させます。さらに、N = 8もあれば攻撃者が末端トランザクションを増やそうとするのを防ぐことが期待できます。攻撃者が全体のハッシュパワーの半分を保持しているとしても、追加できる末端トランザクションは多くても1トランザクションあたり1つ程度です。もし正規なトランザクションが8つのトランザクションを参照するのであれば毎秒40個の末端トランザクションが参照されることとなり、攻撃者の末端トランザクションもすぐに参照されてしまうでしょう。　またiMeshが大きくなればこのデフォルトの数字も見直すことになります。

10章 Conclusion

私たちは新しい暗号通貨"Aidos Kuneen"を提示しました。Aidos Kuneenは全てのトランザクションが直接的に互いを参照し合うDAG(Directed Acyclic Graph:有向非巡回グラフ)構造をもつiMeshを採用しています。二重決済を防ぐため、DAG構造から高い確率で正規のトランザクションを確定できる"SPECTRE"を活用しています。量子コンピューター耐性としては、署名スキームとしてハッシュベースの署名である"XMSS"を採用しています。匿名性に対しては、量子コンピュータに向けてゼロ知識証明「ZKBoo(ZKB++)」を使ったAKShuffleを備えています。IoTに向けてはcoPoWと呼ばれ、送信者が互いにPoWを行い合う協調型PoWを紹介しました。最後に、私たちはiMeshの末端トランザクション数をシミュレーションし、iMeshの振る舞いを検証しました。

Aidos Kuneenでは、トランザクションのサイズ問題は未だ解決できていません。通常トランザクションではサイズは3 KBytes、AKShuffleトランザクションでは500 KBytesになります。私たちは引き続き量子コンピューター時代に向けたより良い署名スキームとゼロ知識非対話型証明の調査を行っていきます。

表3: Aidos Kuneenの仕様

in ref

in

in ref

ref

References(参考文献)[1] Satoshi Nakamoto, ‘Bitcoin: A Peer-to-Peer Electronic Cash System,’ 2008.[2] Crypto Forum Research Group, draft-irtf-cfrg-xmss-hash-based-signatures-10‘XMSS:Extended Hash-Based Signatures,’ 2017.[3] Serguei Popov, ‘The tangle,’ 2017.[4] Sheldon M. Ross, ‘Introduction to Probability Models. 10th Edition,’ 2012.[5] Sergio Demian Lerner, ‘DagCoin: a cryptocurrency without blocks,’ 2015.[6] Johannes Buchmann, Erik Dahmen, Andreas Hülsing, ‘XMSS — A Practical ForwardSecure Signature Scheme Based on Minimal Security Assumptions,’ 2011.[7] Irene Giacomelli, Jesper Madsen, Claudio Orland, ‘ZKBoo: Faster Zero-Knowledge forBoolean Circuits,’ 2016.[8] Melissa Chase, David Derler, Steven Goldfeder, Claudio Orlandi, Sebastian Ramacher,Christian Rechberger, Daniel Slamanig, Greg Zaverucha, ‘Post-Quantum Zero-Knowledgeand Signatures from Symmetric-Key Primitives,’ 2017.[9] Yonatan Sompolinsky, Yoad Lewenberg, and Aviv Zohar, ‘SPECTRE: Serialization ofProof-of-work Events: Confirming Transactions via Recursive Elections,’ 2016.[10] Peter W. Shor, ‘Polynomial-Time Algorithms for Prime Factorization and DiscreteLogarithms on a Quantum Computer,’ 1995.[11] Masoud Mohseni, Peter Read, Hartmut Neven, ‘Commercialize early quantumtechnologies,’ 2017.[12] PQCRYPTO, ‘Post-Quantum Cryptography for Long-Term Security, Initialrecommendations of long-term secure post-quantum systems,’ 2015.[13] Nicolas van Saberhagen, ‘CryptoNote v 2.0,’ 2013.

付録A　シミュレーション結果

Title Description

Unit ADK

Total Supply 25,000,000 ADK

Minimum Unit 0.00000001 (8 Digits) ADK

PoW Algorithm BLAKE2b-256 after SHA-256

Anonymity AKShuffle (post quantum zero knowledge proof) and Tor

Distributed Ledger iMesh (transaction DAG)

Signature Scheme XMSS (post quantum hash based signature)

Usage IoT, Finance, Banks, Commerce

図8: λ in=毎分1トランザクション、Nref=2の末端トランザクション数

図9:λ in=毎分1トランザクション、Nref=4時の末端トランザクション数

図10:λ in=1TPS時の末端トランザクション数

図11:λ in=5TPS時の末端トランザクション数

図12 :λ in=10TPS時の末端トランザクション数

図13: λ in=毎分1トランザクション時のNdecendantの成長

図14: λ in=1秒1トランザクション時のNdecendantの成長

図15: λ in=5TPS時のNdecendantの成長

図16: λ in=10TPS時のNdecendantの成長