OpenTimestamps
ざっと翻訳。
私はここ数週間、古いプロジェクトであるOpenTimestampsに取り組んできて、アルファ版のリリースの準備が整った。タイムスタンプのインフラには、既存の代替手段にくらべて3つの大きな利点がある。 1. トラスト:OpemTimestampsは、分散型で公に監査可能なBitcoinブロックチェーンを使用し、信頼できるオーソリティの必要性を排除する。OpenTimestampsのアーキテクチャは、将来的に複数のクロスチェックされる公証方法をサポートするよう設計されている。
2. コスト:OpenTimestampsは無制限に拡張できるため、無制限のタイムスタンプを1つのBitcoinトランザクションに組み合わせることで、タイムスタンプを無料で作成できる。
3. 利便性:OpenTimestampsはサードパーティが検証可能なタイムスタンプを約1秒で作成できる。Bitcoinの承認を待つ必要はない。
この記事では、タイムスタンプでできること、できないこと、OpenTimestampsを使ってファイルにタイムスタンプをつける方法、OpenTimestampsが内部でどのように機能するかについて説明する。OpenTimestampsは、Gitのコミットにタイムスタンプをつけることもできる。Gitとの統合については後続の投稿で説明する。
謝辞
Verisart は、私が昨年行った OpenTimestamps の初期バージョンの開発作業に資金を提供しました。現在、Verisart のデジタル アート来歴ソリューションで使用されています。さらに、BTCC は私のビットコイン開発に資金を提供してくれています。OpenTimestamps は特にその一部ではありませんが、その資金のおかげで開発に取り組むことができました。最後に、Riccardo Casatta は開発とテストに貢献し、OpenTimestamps の初期バージョンを彼の Eternity Wall サービスに実装しました。 1. タイムスタンプで証明できることとできないこと
タイムスタンプは、メッセージがある時点より前に存在したことを証明する。タイムスタンプはproof of existenceと呼ばれることもある。データがある時点より前に存在していたことを証明できることは、驚くほど役に立つ。その理由を理解するためにいくつかのユースケースを見てみよう。
1.1 記録の完全性
私たちのコロケーションセンターから、昨夜、バックエンドサーバーが置かれているケージに何者かが侵入したとの連絡があった。最後のオフサイトバックアップは一週間前だった。監査人は、侵入者が侵入後にどの記録を変更した可能性があるかを知りたがっている。監査人は何を言えばいい?
侵入がいつ発生したかわかっていて、サーバー上のすべての記録の信頼できるタイムスタンプがあれば、それらのタイムスタンプを使用して、侵入前にレコードが存在していたことを証明できる。これにより、侵入後の監査とリカバリーの取り組みを、より小規模なデータセットに集中させることができる。
ただし、タイムスタンプが侵入がいつ起こったか分からない場合には役に立たない。また、それ以降に作成されたレコードにも役に立たない。侵入者は変更したデータに対しても同様に簡単にタイムスタンプを作成できた可能性がある。それでも、これはタイムスタンプの優れた使用法であり、通常は役に立ち、問題をこれ以上悪化させることはない。
1.2 ソフトウェア署名とPGP
古い記録を復元するには、この2年前のソフトウェアパッケージをインストールする必要があるが、開発者は6ヶ月前にラップトップが盗まれPGP鍵を無効にしたようだ。
PGPの失効には日付が含まれているため、失効の日付がソフトウェアの署名より後であり、その署名に有効なタイムスタンプがある場合は、問題なく実行できる。繰り返すが、これは優れたタイムスタンプの使用例だ。
1.3 証拠の信頼性
被告のWebサイトの2年前のスナップショットをパブリックなアーカイブサービスで発見したけど、これは本物?
Webサイトのスナップショットのタイムスタンプは、必ずしもスナップショットが本物であるこを意味するわけではないが、データを改ざんした可能性のあるユーザーの範囲は大幅に制限される。訴訟が起こることを知るずっと前に、誰かがアーカイブサービスにハッキングした可能性はどれほどあるだろう?
私はWebサイトのアーカイブサービスを運営しているが、監査人やセキュリティコンサルタントを雇うリソースがない。アーカイブが事後に変更されていないことを証明するにはどうしたらいい?
簡単な答え:タイムスタンプは問題を改善するだけで、悪化させるものではない。
昨年、私の同僚はIRCチャットでXと言ったのだけど、プロジェクトが失敗して以来、今ではYと言ったと主張する。彼らが嘘をついていることをどうやって証明すればいい?
タイムスタンプはメッセージが存在したことを証明するだけであり、メッセージ自体ではない。去年、XとYの重要性を知っていた?その場合、競合する2つのIRCチャットログにタイムスタンプがつけられている可能性がある。
匿名の暗号通貨ByteCoinは、とてもクールで、技術は合法で、2年前から存在するコミュニティがある。偽のコミュニティを使用して、最近作成されたプレマイン詐欺ではないよね?
タイムスタンプはここでは役に立たない。ByteCoinの作成者は何もタイムスタンプをつけなかっただろう。さらにたとえつけたとしても、暗号通貨をゼロから作るには、2年はかかる可能性が非常に高いことを覚えておいてほしい。これは一般の人が目にすることのないものに、完全に有効なタイムスタンプを作成するのに十分な時間だ。
1.4 所有権
土地の所有権をタイムスタンプ付きでオンチェーンで確保したい。
タイムスタンプ自体は、二重使用問題を解決しない。Bitcoinはデータにタイムスタンプをつける単なる手段ではない。
そうはいっても、タイムスタンプは所有権記録が正確であるという証拠を提供できる。私のクライアントであるVerisartは、アートの出所の記録においてまさにそれを目指している。ギャラリーの販売領収書などの、美術品の来歴記録のタイムスタンプは、それ自体ではその記録が有効であることを証明するものではないが、潜在的な詐欺の範囲を限定することができ、来歴調査員が対処しなければならない可能性のある詐欺シナリオの多くを排除することで、取り組みを集中させることができる。
2. タイムスタンプの作成と検証
まず、OpenTimestampsクライアントバージョン0.2.0を入手し:
cd opentimestamps-client
git checkout opentimestamps-client-v0.2.0
依存ライブラリをインストール
pip3 install -r requirements.txt
システム全体のインストール プロセスはないため、リポジトリから直接実行する。タイムスタンプの作成は迅速かつ簡単。
$ ./ots stamp README.md
README.md.otsが作成されたことが分かる。すぐに検証することはできないが、
$ ./ots verify README.md.ots
Assuming target filename is 'README.md'
タイムスタンプがBitcoinブロックチェーンで承認されるまでには数時間かかる。タイムスタンプ毎に1つのトランザクションを実行する訳ではない。
ただし、クライアントには、すぐに検証できるサンプルタイムスタンプがいくつか付属している。OpenTimestamps クライアントが RPC インターフェース経由でノードに接続できるようにするには、~/.bitcoin/bitcoin.conf で rpcuser および rpcpassword オプションが設定されたローカル Bitcoin Core ノード (プルーニングされたノードでも可) が必要。セットアップが間r尿したら、 examples/hello-world.txtを検証してみよう。
$ cat examples/hello-world.txt
Hello World!
$ ./ots verify examples/hello-world.txt.ots
Assuming target filename is 'examples/hello-world.txt'
Success! Bitcoin attests data existed as of Thu May 28 15:41:18 2015 UTC
シンプル!
3. OpenTimestampの仕組み
既にBitcoinとハッシュ関数に精通している場合は、コミットメント操作までスキップしていい。
しかし、実際にはどのように機能したのだろうか?verboseフラグを指定して検証を再実行してみyいおう。
$ ./ots -v verify examples/hello-world.txt.ots
Assuming target filename is 'examples/hello-world.txt'
Hashing file, algorithm sha256
Got digest 03ba204e50d126e4674c005e04d82e84c21366780af1f43bd54a37816b6ab340
Attestation block hash: 000000000000000003e892881a8cdcdc117c06d444057c98b6f04a9ee75a2319
Attested time: 1432827678
Success! Bitcoin attests data existed as of Thu May 28 15:41:18 2015 UTC
3.1 公証人と時間証明
すべてのBitcoinのブロックヘッダーには、nTimeというフィールドがある。Bitcoinブロックがネットワークに受け入れられるには、Bitcoinプロトコルによって、そのフィールドがブロックが作成された時刻にほぼ設定されていなければならない。ブロックが有効になるために、そのフィールドがどの程度正確でなければならないかは複雑な問題だが、我々の目的からすると、たとえ少数のBitcoinマイナーが無効なタイムスタンプを作成しようとしたとしても、2〜3時間以内の精度になる可能性が非常に高く1日以内であるkとおはほぼ確実だ。
したがって、Bitcoinは公証人であり、Bitcoinのブロックヘッダーを時間証明として使用できる。つまり信頼する公証人が、ある時点で何らかのデータが存在したという事実を証明したという証明。Bitcoinが正しく動作している場合、これらの80バイト(ブロック358,381のヘッダー)は2015年5月28日に存在している。
02000000b96394585a281b7e5f438fd1c9ed492645a1fd61cb3802040000000000000000007ee445
d23ad061af4a36b809501fab1ac4f2d7e7a739817dd0cbb7ec661b8a1e376755f58616186272def6
3.2 マークルツリー
もちろん、メッセージ「Hello Wordl!」はこの80バイトには含まれていない。しかし、どちらもトランザクションではない。ではBitcoinはどのようにしてブロック内のトランザクションをブロックヘッダーにリンクするのだろう?マークルルートと呼ばれる別のフィールドを太字で示す。
02000000b96394585a281b7e5f438fd1c9ed492645a1fd61cb3802040000000000000000007ee445d23ad061af4a36b809501fab1ac4f2d7e7a739817dd0cbb7ec661b8a1e376755f58616186272def6
マークルルートの値は、ブロック内のすべてのトランザクションを取得し、マークルツリーを作成することで計算される。これはマスタリングビットコインにの以下の図に示されている。
https://petertodd.org/assets/2016-09-15/msbt_0702.png
各矢印は、暗号学的ハッシュ関数を表し、可変長のメッセージを受け取り、それを固定長のダイジェストに変換する。重要なのは、安全なハッシュ関数には同じダイジェストにハッシュされる2つのメッセージを見つけることができないという特性があること。衝突して同じダイジェストを生成するメッセージのペアは存在するが、その数は膨大なため、実際に衝突を見つけることは物理的に不可能であると考えられている。
これらの数値はデバイスの技術とは何の関係もない。それらは熱力学が許容する最大値だ。そしてコンピューターが物質以外のものから構築され、空海外のものを占有するまでは、256 bitの鍵に対するブルートフォース攻撃は実行不可能であることを強く示唆している。ブルース・シュナイアー、応用暗号学
これは、ツリーのない株にあるトランザクションのいずれかを変更すると、変更されたトランザクションの上にあるすべてのダイジェストが変更され、最終的にツリーの先端にあるマークルルートが変更されることを意味する。たとえば、ブロック358,391のトランザクションの最終バイト0x00から0x01に変更すると、マークルルートは完全に変わる。
元の値: 007ee445d23ad061af4a36b809501fab1ac4f2d7e7a739817dd0cbb7ec661b8a
変更後: 87808e5a6a196e401bde8ebaf5b453825cdc3b66b87526bb355d519ae52ba42b
最終的に、メッセージ「Hello Wordl!\n」をハッシュすると次の結果が得られることが分かる
RIPEMD160(SHA256('Hello World!\n')) => 1df8859e60bc679503d16dcb870e6ce91a57e9df
このダイジェストは、Bitcoinのトランザクション7e9f0f7d9daa2d9e51b2e22f4abe814c3f90539afa778a9bef88dc64627cb2ec4にある。したがって、このメッセージを変更すると、ダイジェストが変更され、トランザクションが代わり、マークルツリーが変わり、最終的にブロックヘッダーが変わる。ブロックヘッダーを変更せずにメッセージを変更することはできないため、ブロックヘッダーが作成される前からメッセージが存在していたことが証明された。これがタイムスタンプ証明だ。
3.3 コミットメント操作
この証明を別の方法で説明すると、ブロックヘッダーがマークルツリーにコミットし、マークルツリーがトランザクションにコミットすると言える。トランザクションを変更するとヘッダーも変更されるため、トランザクションはブロックヘッダーによりコミットされる。また暗号学的ハッシュ関数はコミットメント操作であると言える。操作への入力は、結果を変えずに変更できないため。
コミットメント操作のさらに単純な例は、append操作となる:
"Foo" -> append("Bar") -> "FooBar"
これがコミットメント操作である理由は簡単。入力を経h校すると、結果が分かることは明らかで、結果には入力自体が含まれる。
OpenTimestampsにおけるタイムスタンプのプルーフは、メッセージに順に適用されるコミットメント操作の単なるリストだ。プルーフを検証するために、必要なのは操作を再実行し、最終結果が特定の時点で既に存在ていたことが分かっているメッセージであることを確認するだけ。すべてのコミットメント操作では、異なる入力に対して、異なる結果が得られることが保証されているため、結果を変更してタイムスタンプを無効にすることなく、タイムスタンプを付与したメッセージを変更する方法はない。
実際の操作派以下のようにタイムスタンプで確認できる。
$ ./ots info examples/hello-world.txt.ots
File sha256 hash: 03ba204e50d126e4674c005e04d82e84c21366780af1f43bd54a37816b6ab340
Timestamp:
ripemd160
prepend 0100000001e482f9d32ecc3ba657b69d898010857b54457a90497982ff56f97c4ec58e6f98010000006b483045022100b253add1d1cf90844338a475a04ff13fc9e7bd242b07762dea07f5608b2de367022000b268ca9c3342b3769cdd062891317cdcef87aac310b6855e9d93898ebbe8ec0121020d8e4d107d2b339b0050efdd4b4a09245aa056048f125396374ea6a2ab0709c6ffffffff026533e605000000001976a9140bf057d40fbba6744862515f5b55a2310de5772f88aca0860100000000001976a914
append 88ac00000000
sha256
sha256
prepend a987f716c533913c314c78e35d35884cac943fa42cac49d2b2c69f4003f85f88
sha256
sha256
prepend dec55b3487e1e3f722a49b55a7783215862785f4a3acb392846019f71dc64a9d
sha256
sha256
prepend b2ca18f485e080478e025dab3d464b416c0e1ecb6629c9aefce8c8214d042432
sha256
sha256
append 11b0e90661196ff4b0813c3eda141bab5e91604837bdf7a0c9df37db0e3a1198
sha256
sha256
append c34bc1a4a1093ffd148c016b1e664742914e939efabe4d3d356515914b26d9e2
sha256
sha256
append c3e6e7c38c69f6af24c2be34ebac48257ede61ec0a21b9535e4443277be30646
sha256
sha256
prepend 0798bf8606e00024e5d5d54bf0c960f629dfb9dad69157455b6f2652c0e8de81
sha256
sha256
append 3f9ada6d60baa244006bb0aad51448ad2fafb9d4b6487a0999cff26b91f0f536
sha256
sha256
prepend c703019e959a8dd3faef7489bb328ba485574758e7091f01464eb65872c975c8
sha256
sha256
append cbfefff513ff84b915e3fed6f9d799676630f8364ea2a6c7557fad94a5b5d788
sha256
sha256
prepend 0be23709859913babd4460bbddf8ed213e7c8773a4b1face30f8acfdf093b705
sha256
sha256
verify BitcoinBlockHeaderAttestation(358391)
この方法でタイムスタンプを表現することの大きな利点は、タイムスタンプの作成方法が関係ないこと。OpenTimestampsプロトコルがサポートするコミットメント操作の有効なリストを抽出できる限り、OpenTimestamps互換の検証ツールが検証可能なタイムスタンプを作成できる。
タイムスタンプの操作ツリー
さらに、操作の線形リストに限定されることなく、タイムスタンプは実際には操作のツリーで、ツリーのルートは、メッセージおよびコミットメント操作で、リーフは証明。カレンダーについて説明する際に、この機能が現在どのように使用されているかを確認する。将来、これにより、他隠逸のメッセージを複数の公証人でタイムスタンプすることができる。たとえば、BitcoinやLitecoinなどの複数のブロックチェーンを同時に使用できる。また、従来のRFC-3161タイムスタンプや Certificate Transparency サーバーなど、さまざな信頼モデルと精度保証を提供する公証人も同時に使用できる。
3.4 集約によるスケーラビリティ
コミットメント操作によって得られる柔軟性を活用する重要な方法はスケーラビリティだ。たとえば、10,000個の異なるファイルにタイムスタンプを付けたいとする。既存のほとんどのBitcoinタイムスタンプソリューションでは、10,000個のBitcoinトランザクションが必要になるが、これは非効率的でコストがかかる。しかし、OpenTimestampsを使用すると代わりに、10,000個のファイルのマークルツリーを作成し、そのツリーの先端に1つのトランザクションでタイムスタンプを付けることができる。ファイルごとのタイムスタンプは、最初のマークルツリーを上がって、次にBitcoinのマークルツリーを上がって、最終的にブロックヘッダーに到達するパスを構成するコミットメント操作のリストにすぎない。検証者にとっては、他のタイムスタンプと同じように一連の操作に過ぎない。
次に、集約サーバーのシステムによってさらにこれを改善する。これはタイムスタンプを付与するために誰でもダイジェストを送信できる公開されているミーティングポイント。これを書いている時点では、a.pool.opentimestamps.orgとb.pool.opentimestamps.orgという2つの公開集約サーバーがある。
ダイジェストが集計のために送信されると、保留中のダイジェストのリストに追加される。定期的にそのリストは1つのマークルツリーに結合され、そのツリーの先端にBitcoinのタイムスタンプが付けられる。次にサーバーは送信されたダイジェスト毎に、個別のタイムスタンプの証明を返す(概念的に言うと。実際にどのように機能するかについては次のセクションを参照)。このプロセスはマークルツリーがマーっっくるツリーの先端にタイムスタンプを付与し、マークルツリーの先端にタイムスタンプを付けることで、複数の階層で実行できる。毎秒無制限の数のメッセージにタイムスタンプを付与でき、システムはタイムスタンプの検証方法を変更することなく、1人のユーザーから無制限のユーザーまで拡張できる。
集約プロセスは集中化によって最も効率的に機能するが、本質的にトラストレスであることに変わりはない。集約サーバーが最悪の場合オフラインになると不便だ。タイムスタンプの有効性を証明するのは、集約システムではなくBitcoinであるため、集約システムは偽のタイムスタンプを生成できない。
3.5 公開カレンダー
集約サーバーは効率的だが、便利ではない。基礎となるBitcoinトランザクションが承認されるまで待たなければならない。これには平均10分かかるが、さらに長くかかる可能性もある。一部のアプリケーションではこれは問題ではない。OpenTimestampsクライアントは基礎となるBitcoinトランザクションが承認されるまで待機する--waitフラグをサポートしている。
しかし、多くのアプリケーションにとって、これは十分な速度とはいえない。たとえば、タイムスタンプ付きのPGP署名メールを送信する場合や、タイムスタンプ付きのGitコミットに署名する場合、タイムスタンプ処理は最大でも1秒か2秒以内に完了する必要がある。これは既存の分散型コンセンサスのシステムでは不可能だ。
OpenTimestampsは、公開カレンダーサーバーという妥協案を講じることで、この問題を解決する。カレンダーは単なるタイムスタンプのコレクション。カレンダーサーバーはカレンダーへのリモートアクセスを提供する。この記事の執筆時点では、alice.btc.calendar.opentimestamps.org と bob.btc.calendar.opentimestamps.org という 2 つの公開カレンダーサーバーが稼働している。
カレンダーサーバーは集約サーバーと連携して動作する。集約システムが実際に行うのは、保留中のダイジェストがBitcoinによってタイムスタンプが付与されるまで待つのではなく、送信されたすべtねおタイムスタンプを1秒間隔でマークルツリーに集約し、そのツリーの先端(コミットメント)を公開カレンダーサーバーに送信すること。カレンダーサーバーは2つの約束をする:
1. カレンダーに追加されたすべてのコミットメントは、適切な時間内にBitcoinブロックチェーンによってタイムスタンプが付与される。
2. 完了したコミットメントのタイムスタンプは一般公開され、無期限に保存される。
カレンダーサーバーを使用して作成されたタイムスタンプを不完全なタイムスタンプと呼び、以下に例を示す:
$ ./ots info examples/incomplete.txt.ots
File sha256 hash: 05c4f616a8e5310d19d938cfd769864d7f4ccdc2ca8b479b10af83564b097af9
Timestamp:
append e754bf93806a7ebaa680ef7bd0114bf4
sha256
append b573e8850cfd9e63d1f043fbb6fc250e
sha256
prepend 57cfa5c4
append 6fb1ac8d4e4eb0e7
最後の行が見える?タイムスタンプを検証しようとすと、この行は、タイムスタンプをリモートカレンダー「アリス」に問い合わせるよう指示する。
$ ./ots verify examples/incomplete.txt.ots
Assuming target filename is 'examples/incomplete.txt'
Success! Bitcoin attests data existed as of Wed Sep 7 05:56:43 2016 UTC
したがって、公開されている集約およびカレンダーのインフラの助けを借りて、約1秒でタイムスタンプを作成できるが、後から誰でも分散化されたトラストレスなBitcoinブロックチェーンを使用してタイムスタンプを検証できる。
もちろん、この利便性には代償も伴う。公開カレンダーは障害の中心になる。このため、公開カレンダーサーバーの支援を必要とするタイムスタンプを不完全なタイムスタンプと呼ぶ。OpenTimestampsはさまざまな方法でこのリスクを軽減する。
3.5.1 カレンダーの使用はオプション
まず第一に、--waitオプションを使用することでカレンダーに依存しないタイムスタンプを作成できる。有効にすると、クライアントはタイムスタンプがBitcoinブロックチェーンによって完全に承認されるまで待機するだけ。結果のタイムスタンプには、Bitcoinでタイムスタンプを証明するために必要なすべてのデータが含まれており、検証を完全んいローカルで行うことができる。
3.5.2 タイムスタンプのアップグレード
不完全なタイムスタンプは、後で、ots upgradeコマンドでアップグレードできる。完全なBitcoinの証明がカレンダーからダウンロードされ、タイムスタンプの一部として保存される。その結果は最初から、--waitオプションを使用したかのようになる。
3.5.3 冗長性
デフォルトでは、タイムスタンプを作成する際に2つの公開カレンダーが同時に使用され、両方から応答が返された場合のみタイムスタンプが保存される:
$ ./ots info examples/two-calendars.txt.ots
File sha256 hash: efaa174f68e59705757460f4f7d204bd2b535cfd194d9d945418732129404ddb
Timestamp:
append 839037eef449dec6dac322ca97347c45
sha256
-> append 6b4023b6edd3a0eeeb09e5d718723b9e
sha256
prepend 57d46515
append eadd66b1688d5574
-> append a3ad701ef9f10535a84968b5a99d8580
sha256
prepend 57d46516
append 647b90ea1b270a97
タイムスタンプがコミットメント操作ツリーであるという事実をどのように利用しているかに注目してほしい。sha256操作の後にパスが分割される。すくなくとも1つのカレンダーが利用可能である限り、タイムスタンプを検証できる。
もちろん、公開カレンダーの代わりに、または公開カレンダーに加えて、独自のカレンダーを使用することもできる。たとえば、Example Inc. は独自のカレンダーを設定し、そのカレンダーで公開カレンダーを使用して実際に Bitcoin 証明を作成できる (公開カレンダーがダウンしている場合は、独自のウォレットにフォールバックする可能性がある)。このようなタイムスタンプは次のようになる。
$ ./ots info <some file>.ots
File sha256 hash: 522cf38077181bf09ce229d2bf49d23b8d7a4e9fcf7e23d7455ad2e665bf17cd
Timestamp:
append 839037eef449dec6dac322ca97347c45
sha256
sha256
append 1467861d8186c1df176ef2efc08d553d2dd183aadec403335d707f1e90fe3e92
sha256
prepend 192e8f15b77bdc5a85e346d081c995f7459dcde9f68a3523e0ae453c5a693ef9
-> append 6b4023b6edd3a0eeeb09e5d718723b9e
sha256
prepend 57d46515
append eadd66b1688d5574
-> append a3ad701ef9f10535a84968b5a99d8580
sha256
prepend 57d46516
append 647b90ea1b270a97