-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
1062 lines (735 loc) · 99.5 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html lang="ja">
<head>
<!-- hexo-inject:begin --><!-- hexo-inject:end --><meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="generator" content="Nest of Owl">
<title>Nest of Owl</title>
<meta name="author" content="Owl">
<link rel="alternate" type="application/atom+xml" title="RSS" href="/atom.xml">
<meta property="og:type" content="blog">
<meta property="og:title" content="Nest of Owl">
<meta property="og:url" content="https://converghub.github.io/index.html">
<meta property="og:site_name" content="Nest of Owl">
<meta property="og:locale" content="ja">
<meta name="twitter:card" content="summary">
<meta name="twitter:title" content="Nest of Owl">
<!--STYLES-->
<link rel="stylesheet" href="/assets/css/style-pz4cc6y13wt2trzqa8l3n9v0yykr0sstdaheem7qj628nhjmhp9pfawvqawz.min.css">
<!--STYLES END--><!-- hexo-inject:begin --><!-- hexo-inject:end -->
</head>
<body>
<!-- hexo-inject:begin --><!-- hexo-inject:end --><div id="blog">
<!-- Define author's picture -->
<header id="header" data-behavior="5">
<i id="btn-open-sidebar" class="fa fa-lg fa-bars"></i>
<div class="header-title">
<a class="header-title-link" href="/ ">Nest of Owl</a>
</div>
<a class="header-right-picture "
href="#about">
</a>
</header>
<!-- Define author's picture -->
<nav id="sidebar" data-behavior="5">
<div class="sidebar-container">
<ul class="sidebar-buttons">
<li class="sidebar-button">
<a class="sidebar-button-link "
href="/ "
title="ホーム"
>
<i class="sidebar-button-icon fa fa-lg fa-home" aria-hidden="true"></i>
<span class="sidebar-button-desc">ホーム</span>
</a>
</li>
<li class="sidebar-button">
<a class="sidebar-button-link "
href="/all-categories"
title="カテゴリー"
>
<i class="sidebar-button-icon fa fa-lg fa-bookmark" aria-hidden="true"></i>
<span class="sidebar-button-desc">カテゴリー</span>
</a>
</li>
<li class="sidebar-button">
<a class="sidebar-button-link "
href="/all-tags"
title="タグ"
>
<i class="sidebar-button-icon fa fa-lg fa-tags" aria-hidden="true"></i>
<span class="sidebar-button-desc">タグ</span>
</a>
</li>
<li class="sidebar-button">
<a class="sidebar-button-link "
href="/all-archives"
title="アーカイブ"
>
<i class="sidebar-button-icon fa fa-lg fa-archive" aria-hidden="true"></i>
<span class="sidebar-button-desc">アーカイブ</span>
</a>
</li>
<li class="sidebar-button">
<a class="sidebar-button-link "
href="#about"
title="プロフィール"
>
<i class="sidebar-button-icon fa fa-lg fa-question" aria-hidden="true"></i>
<span class="sidebar-button-desc">プロフィール</span>
</a>
</li>
</ul>
<ul class="sidebar-buttons">
<li class="sidebar-button">
<a class="sidebar-button-link " href="https://github.com/converghub" target="_blank" rel="noopener" title="GitHub">
<i class="sidebar-button-icon fa fa-lg fa-github" aria-hidden="true"></i>
<span class="sidebar-button-desc">GitHub</span>
</a>
</li>
<li class="sidebar-button">
<a class="sidebar-button-link " href="https://twitter.com/owl_alt" target="_blank" rel="noopener" title="Twitter">
<i class="sidebar-button-icon fa fa-lg fa-twitter" aria-hidden="true"></i>
<span class="sidebar-button-desc">Twitter</span>
</a>
</li>
</ul>
<ul class="sidebar-buttons">
<li class="sidebar-button">
<a class="sidebar-button-link "
href="/atom.xml"
title="RSS"
>
<i class="sidebar-button-icon fa fa-lg fa-rss" aria-hidden="true"></i>
<span class="sidebar-button-desc">RSS</span>
</a>
</li>
</ul>
</div>
</nav>
<div id="main" data-behavior="5"
class="
hasCoverMetaIn
">
<section class="postShorten-group main-content-wrap">
<article class="postShorten postShorten--thumbnailimg-bottom" itemscope itemType="http://schema.org/BlogPosting">
<div class="postShorten-wrap">
<div class="postShorten-header">
<h1 class="postShorten-title" itemprop="headline">
<a class="link-unstyled" href="/2018/02/17/it-takes-a-community-to-raise-a-crypto/">
It takes a community to raise a crypto(日本語訳)
</a>
</h1>
<div class="postShorten-meta">
<time itemprop="datePublished" datetime="2018-02-17T19:01:26+09:00">
2018/02/17
</time>
<span>カテゴリー </span>
<a class="category-link" href="/categories/暗号通貨/">暗号通貨</a>
</div>
</div>
<div class="postShorten-content" itemprop="articleBody">
<h1 id="はじめに">はじめに</h1>
<p>QRLのアドバイザーになった，Counterpartyプロジェクトの共同設立者，Robby Dermody氏によるブログ更新記事の日本語訳になります。</p>
<h1 id="日本語訳">日本語訳</h1>
<p> 私は正式にQRLプロジェクトに助言し，支援することができてうれしく思います。2013年後半に，私はCounterpartyプロジェクトを共同設立しました。Counterpartyは，最初の分散型取引技術をはじめ，初期のブロックチェーンベースの金融契約のいくつかを開拓し，最初のイニシャル・コイン・オファリング（ICO）の多くを主催しました。私はまた，QRLのプレセールの投資家であり，私の初期投資から一つのquantaも売却していません。 <br> (※quantaはQRLの通貨の単位です) <br><br> 以前のQRLチームとのインタビューで述べたように，このプロジェクトは数多くの理由で私は関心がありました。比較的低い（すなわち正当な）資金調達額上限設定，技術的なホワイトペーパー，チームの爽やかな正直さ，斬新でギークな技術アプリケーション，そしてそれらのいくつかのユニークな価値命題です。そこにはたくさんのお金と通り道があったので，予定されたICOでこの特性の組み合わせを見ていたのは爽やかでした。 <br><br> この記事では，CounterpartyやQRLのような，あまり知られていない高品質のプロジェクトでのマーケティングについて少し話をしたかったのです。私がCounterpartyでこの面で学んだ主なことの一つは，ほとんどの人がこの技術を理解していないということでした。特に強気な市場では，人々は外見，ほかの人の口コミ，そしてできるだけ早くお金を稼ぐということに基づいて投資します。これは，全体的な市場の合理性を信じて，人々が当然堅実な技術の価値が分かっていると思っている，若くて理想的な市場自身のかなり失望的なものでした。実際には，わずかな割合しか実際に機能していませんが，しかし，QRLで起こったように，これらの人々が私たちのコミュニティの不可欠な核を形成しました。 <br><br> この気づきは，Counterpartyの全盛期(2014-2015)にも当てはまりました。そして，暗号通貨がメインストリームの聴衆から得ている関心が高まっているため，現在ではもっと真実味があります。私はこれは読者にとっては驚くことではないと確信していますが，残念ながら，QRLの素晴らしい技術的な仕事のすべてが大部分の人々にとってレーダーの下にあるということです。実際のファンダメンタルズは，私たちが最近経験したような双曲線の強気市場ではほとんど問題にはならないかもしれませんが，私たちが今市場のトーンが素早く変わることを目にしており，市場は，ファンダ的に堅実なプロジェクトとそれらのプロジェクトの投資家の両方に，長期的に報いる自然な方法を持っています。 <br><br> これは言及したように，より大規模なコミュニティの中でそれらに対する気づきがほとんどない場合，ファンダメンタルズの影響は大幅に減少します。私からしてみると，この気づきの種を植えるためにもっと早く働けば働くほど，それは良くなると思っています。プロジェクトが現在を含む(メインネットより前に)いつでも実行できる最高の"マーケティング"は，本当のマーケティングでは全くありません。<em>単純に耐量子とそれが何を意味しているのか，それについてQRLが何をしているかについての意識を高めるだけです。</em> 斬新な技術，定期的なコードの更新，素晴らしいチーム，そして膨大な価値提案についての意識を高めることです。何か誤解を招くような宣伝は必要ありません。－それは"それを手に入れる"人々のコミュニティを成長させるためだけに機能することであり，そうするためには，まず初めにプロジェクトに気づく必要があります。 <br><br> したがって，マーケティングはおべんちゃらを言う必要はなく，その性質上誤解を招くこともありません。今可能であることについて誠実な宣言に基づいて，あるいは，すぐに実現可能で検証可能なソフトウェア開発のためにすぐに可能になるであろうことに基づいて，それはアドボカシーと意識向上としてよりよく考えられます。私はCounterpartyでこれをもっとよく理解してもらいたいです。それは常識のように見えるかもしれませんが，技術者としての見方では，私は暗黙のうちに見ていたすべての誤解を招く「PRとマーケティング」に対して感情的な嫌悪感を抱かせてくれました。 <br><br> より適用されたレベルでは，これは，私たちのコミュニティが，より大きな暗号通貨コミュニティを気づかせていくことを意味し，QRL以外のReddit，bitcointalk，slack/telegram/discord chatなどの場所で，それは主に投機的な価格のチャットではない設定で，QRLを言及する努力をもう少ししていることを意味します。可能ならば，価格の話を避け，プロジェクトの中核的価値提案に焦点を当ててください。重要な進行中のコード更新で最新の状態に保ってください。一攫千金的な大部分に興味を示すのをやめて，少なくとも合理的かつ先見的な人材を集めて，少なくともプロジェクトをチェックしてください。これは，より大きなQRL専用コミュニティの拡大と，より大きな暗号通貨コミュニティにおけるQRLの高品質なインプットと表現の向上に役立つことでしょう。 <br><br> これはいくつかの人にとって「客寄せ」であるかもしれませんが，技術，開発されたコード，そして事実に基づいており，カルト性や感情的アピールおよび価格の投機予測に基づいていないので，それを恥らずにできます。ほとんどの人は何度も何度も何度も聞いてからチェックしてみてください。この情報過負荷環境では特にそうです。<em>スマートで永続的に，また迷惑にはならないようにしてください。また，新しいスレッドやメッセージを見ていない人たちにスパムするのではなく，情報が有用で価値がある機会を探してください。</em>コンテンツを氾濫させるよりも，説得力のある人と人を引き付ける友人が重要です。 <br><br> 真のボトムアップの耐量子というQRLの主な主張に対して意識しておかなければならないのは，今日でも「耐量子」として宣伝されているコインがいくつかあることです。私が持っている主な懸念は，上述した暗号技術の知識のギャップのために，ノイズが（技術的に不正確な）単語をより広げるため，このケースではノイズが信号よりも用意に重大になることです。これは間違ったプロジェクトが一つであれば問題にはならないかもしれません。しかしながら，量子計算が引き続き誇大宣伝を生み出すので，そのQRの主張は，（例えば，「QRを追加することは容易である」，「私たちはそれに取り組んでいる」）Vaporware(例えば，Nexusの主張など)の極限に近づいているにも関わらず，中規模及び大規模なプロジェクトがますます増えてその誇大宣伝を活用しようとしています。 <br><br> 簡単に言うと，これに対処するには積極的に対応する必要があります。実際の数学と技術に基づいて十分な人々が，「誤解を解かない」場合，デフォルトでは95%以上の人々が，ベストを尽くして一番声高く話した者を信じるでしょう。しかし，永続的で意識的な意識向上が流れを変えるでしょう。その一例として，Moneroが匿名通貨の主張で行ったことを目にしてください。何年もの間，彼らはDashやBitcoinの混合として一纏めにされていました。独自のプライバシー保護技術と十分に広く知識のあるコミュニティの十分な意識を養うだけで，このプロジェクトの流れが変わったようで，2017年以降，メインストリームのニュースやRedditなどで匿名を促進する主要な通貨としてMoneroが頻繁に言及されています。しかしその話はそこでは終わりません。この証拠に基づく伝道は，比較的無教練の初心者の入場や，Vergeのような技術的ではない匿名プロジェクトからの忌まわしい誇大宣言に直面して維持されなければなりません。 <br><br> プレスフロントでは，ボランティア，社内の社内PRチーム，プロのPR組織と協力して仕事をしていました。Counterpartyでは，Wired，New York Times，Venture Beat，International Business Times，Coindeskなどの出版物で言及されました。プロのPRチームは必要ではありませんが，プレスとの強い既存のつながりを持っているという点で有用でした。時間内にQRLチームはこれらのコネクションを獲得するでしょうが，それを有効にするには，チームは最初に開発の仕方やフレーズを取り巻く状況を把握しておく必要があります。なぜなら，下層のビットコイン・プレスはより多くの「インサイドベースボール」の部分をとるかもしれませんが，上位の出版物は一般的にそうではなく，実際に物語を伝える方法で表現できる情報で作業したく，原型に訴え，そして／または競合を示します。これは，読者に興奮と魅力をもたらし，クリック数と収益として解釈されます。 <br><br> 今後数か月にわたって，ジャーナリストによって価値がより簡単に（正確に伝えられる）ように，私はチームと協力してコンテンツを事前に消化するのを手伝っていきたいと思います。これは，一般に人員が不足しており，低品質のコンテンツと魅力があふれている暗号通貨プレスでは特に便利です。 <br><br> この情報のいくつかが役に立てばいいなと思います。QRLチームとQRLコミュニティと協力して，この偉大な通貨について語るのを楽しみにしています。そして，多くの皆さんとDiscordで話をすることを楽しみにしています！</p>
<h1 id="おわりに">おわりに</h1>
<p>今回の翻訳は以上になります。ここまで読んでくださってありがとうございました。</p>
<p>
<a href="/2018/02/17/it-takes-a-community-to-raise-a-crypto/#post-footer" class="postShorten-excerpt_link link">
コメント・シェア
</a>
</p>
</div>
</div>
</article>
<article class="postShorten postShorten--thumbnailimg-bottom" itemscope itemType="http://schema.org/BlogPosting">
<div class="postShorten-wrap">
<div class="postShorten-header">
<h1 class="postShorten-title" itemprop="headline">
<a class="link-unstyled" href="/2018/01/26/intro-adviser/">
Introducing Robby Dermody, QRL Adviser(日本語訳)
</a>
</h1>
<div class="postShorten-meta">
<time itemprop="datePublished" datetime="2018-01-26T07:13:43+09:00">
2018/01/26
</time>
<span>カテゴリー </span>
<a class="category-link" href="/categories/暗号通貨/">暗号通貨</a>
</div>
</div>
<div class="postShorten-content" itemprop="articleBody">
<p>先週，私はRobbyと膝を交えて，QRLコミュニティに紹介するのにいくつかの質問をしました。私たちは，顧問的な役割でプロジェクトにRobbyが加わることに非常に興奮しており，暗号通貨界隈における豊富な経験から学ぶことを非常に楽しみにしています。Robbyは彼の洞察力を私たちに提供してくれ，また，彼が経験してきたこともふまえて私たちを助けてくれます。</p>
<p><b>QRL</b>：Robby，バックグラウンドはなんでしょうか？何の出身でしょうか？ <br> <br> <b>Robby</b>：えっと，私は起業家としての専門的な背景がありますが，職業的にはソフトウェア開発者です。私はエンタープライズソフトウェア，VoIP(Voice Over Internet Protocol，ボイップ)ソリューション，デジタル信号処理に携わっていました。 <br> <br> <b>QRL</b>：ソフトウェア開発者としての自分をどのように見出しましたか？ <br> <br> <b>Robby</b>：私は計算機科学の学校に行きましたが，私は主に独学のコーダーです。私は9歳ごろからプログラミングを始めましたので，私の生涯にわたる情熱なものでした。 <br> <br> <b>QRL</b>：9歳から？本当に？ <br> <br> <b>Robby</b>：ええ，私は第4学年で"Bring a Book to School Day（学校での読書）"のためにMS-DOSのマニュアルを持ってきたギークな子供でした。成長すると，コンピュータはしばしば私の同僚よりも意味のあるものでした。 <br> <br> <b>QRL</b>：おお，確かにあなたはテクノロジーの人生のために運命づけられたようですね。暗号通貨／ブロックチェーンについて，どうやって知ったのでしょうか？ <br> <br> <b>Robby</b>：私がブロックチェーンと暗号通貨を知ったのは2012年でした。私の興味をそそる多くのことがあり，私が調査を始めたとき，情報過負荷に陥ってしまったので，まず最初に<a href="https://www.feathercoin.com/" target="_blank" rel="noopener">Feathercoin</a>のマイニングを始めました。それが機能レベルでどのように機能しているかを見て楽しみました。 <br> <br> <b>QRL</b>：何があなたを次のステップに踏み出させたんでしょうか？ <br> <br> <b>Robby</b>：2013年8月上旬，私は<a href="https://en.wikipedia.org/wiki/Omni_Layer" target="_blank" rel="noopener">Master Coin</a>に関するCoinDeskの記事を読みました。Bitcoinのブロックチェーンにデータを埋め込むという新しい概念について，彼らはその機能を拡張することについて話していましたが，すぐに興味深いと思いました。Mastercoinは事実上初めてのICOでしたが，「ICO」という用語は当時使用されていませんでした。Mastercoinは私の想像力を燃やしてしまい，すぐにMastercoinコミュニティの活発な部分に自分自身がいることに気づきました。実際に，<a href="https://counterparty.io/" target="_blank" rel="noopener">CounterParty</a>を設立した2人の他の人は，私自身と一緒に，Mastercoinの初期投資家とコミュニティメンバーでした。 <br> <br> <b>QRL</b>：Mastercoinへの投資から数か月後に，どのようにしてCounterPartyで独自の暗号通貨の開発を始めたのでしょうか？ <br> <br> <b>Robby</b>：私たち（他のCounterParty創設者と私）は，Mastercoinには変更や改良ができると思っていましたが，結局のところ，ほかの多くの人たちと同じように，この欲望を明かしたいと思っていました。カウンターパーティのXCPトークンをコミュニティに配布するために，Proof-of-Burn方式を使用することは，今日ではほとんど非現実的な，イデオロギー的な姿勢をとっていました。 <br><br> <a href="https://counterparty.io/news/why-proof-of-burn/" target="_blank" rel="noopener">Proof of Burn</a>では，人々は自分のBTCを復旧不能なアドレスに送信し，プロトコルはそれを確認して，対応する量のトークンが与えられます。この方法で，2,000BTC以上が失われ，約260万XCPが生成されました。明らかな欠点はすべてをブートストラップしなければならなかったことです。しかし，それはまた，小さく非常に効率的なコアチームととても専門的なコアコミュニティであることを意味します。また，2014年1月2日のローンチ日に，基本的に完全に機能するすべてのソフトウェアをリリースしました。約束や事前告知は必要ありませんでした。このうちのいくつかは，多くの人々が振り返ってみれば奇妙に思えるかもしれませんが，非常に面白い実験であり，多くの楽しみでもあります。 <br> <br> <b>QRL</b>：少しだけ巻きましょう。どうやってQRLと出会ったのでしょうか？ <br> <br> <b>Robby</b>：QRLと無関係のスレッドをbitcointalkで見ていたのですが，QRLに言及するコメントを目にしました—量子計算と暗号についての問題に取り組んでいるというコメントでした。だから私はホワイトペーパーを見ました，4月ごろだと思います。実行可能な量子コンピュータは，まだ先の話ですが，その分野には多額の資金と関心があります。そして実質的にすべての暗号化通信で使用される暗号化署名方式を含め，今日取り上げられている技術の多くを脅かす可能性のある，急進的な突破口の可能性が常にあります。 <br><br> だから私は部分的にエキサイティングなヘッジとしてプロジェクトを見ました。私はプロジェクトの3つの重要な要素が好きです—1つ目は，ファンダメンタルです。このホワイトペーパーは，実際にプロジェクトを支える技術的／数学的問題の多くを扱っていました。2つ目は，合理的なAskです。基本的なアプリケーションを作るために1億ドルも求めていませんでした。これは400万ドルで，合理的な人件費と営業支出に則していました。3つ目は，私がPeterとJPに直接接触して，彼らとやり取りしたとき，私は彼らが誠実で本気であるとわかりました。それはプレセール中の2017年5月頃でした。 <br> <br> <b>QRL</b>：プロジェクトの寿命に関して何らかの最初の懸念はありましたか？ <br> <br> <b>Robby</b>：私が最初にQRLを知ったとき，チームはまだ小さかったです。おそらく，チームがあまりにも急速に拡大するか，あるいは十分に急速に拡大しないであろうし，獲得した才能が目の前の作業負荷を処理できない可能性があることを心配しました。PeterとJPは医師であり，職業的には起業家やソフトウェア開発者ではありませんでした。しかし，彼らは非常に賢明で意欲的であるように思えました。そしてチームメンバーの数が増え，開発の進展が見られたので，これらの懸念が緩和されました。 <br> <br> <b>QRL</b>：私たちのコミュニティに何かコメントはあるでしょうか？ <br> <br> <b>Robby</b>：このような長期的な焦点を当てた技術に興味を持つコミュニティを見ることは本当に素晴らしいことです。選択した道のりに自信を持ってください。成功のために最も重要な要素は，チーム，ビジョン，コード，そしてこのプロジェクトが目指す方向にすでに存在しています。 <br><br> それらを背景に，QRLはプロフェッショナルでナンセンスではないプロジェクトとして，すでに少しの評判を得ています。これは，暗号通貨界隈が成熟し続けており，実際にはそれほど価値のないプロジェクトが明らかになっていくため，今後数か月数年間でQRLに対してうまく機能することでしょう。最後にコミュニティに私を大手を拡げて歓迎してくれてありがとうと言いたいと思います！のちに私はDiscordにいることになりましたが，そこでの議論や交流の質は素晴らしいです。 <br> <br> ※翻訳は以上になります。</p>
<p>
<a href="/2018/01/26/intro-adviser/#post-footer" class="postShorten-excerpt_link link">
コメント・シェア
</a>
</p>
</div>
</div>
</article>
<article class="postShorten postShorten--thumbnailimg-bottom" itemscope itemType="http://schema.org/BlogPosting">
<div class="postShorten-wrap">
<div class="postShorten-header">
<h1 class="postShorten-title" itemprop="headline">
<a class="link-unstyled" href="/2018/01/18/wots-jp/">
W-OTS+ — Shorter Signatures for Hash-Based Signature Schemes
</a>
</h1>
<div class="postShorten-meta">
<time itemprop="datePublished" datetime="2018-01-18T20:34:42+09:00">
2018/01/18
</time>
<span>カテゴリー </span>
<a class="category-link" href="/categories/暗号通貨/">暗号通貨</a>
</div>
</div>
<div class="postShorten-content" itemprop="articleBody">
<p>この記事は，論文のうち，必要な部分を抜粋し和訳したものです。</p>
<h1 id="the-winternitz-one-time-signature-scheme">The Winternitz One-Time Signature Scheme</h1>
<p>このセクションではW-OTS<span class="math inline">\(^+\)</span>について書きます。W-OTSのコアとなるアイデアは，ランダムな入力から始まる特定の数の関数の連鎖を使用することです。これらのランダムな入力は秘密鍵です。公開鍵は連鎖の最終の出力，つまり，連鎖の最後から構成されます。署名は，メッセージを各関数チェーンの一つの中間地にマッピングすることにより計算されます。以前のW-OTSのすべての変種は，単に使用される関数を反復した関数の連鎖（[BDE+11]の場合は関数族）によって構築されています。それとは対照的に，W-OTS<span class="math inline">\(^+\)</span>では，使用されているハッシュ関数族に衝突耐性を要求することなく厳密なセキュリティ証明を可能にする，特別な反復モードを使用しています。いくつかの準備から始めます。そのあとW-OTS<span class="math inline">\(^+\)</span>について話します。</p>
<h2 id="signature-scheme">Signature Scheme</h2>
<p>ここで，いくつかの表記法を固め，適応型選択メッセージ攻撃のもとでデジタル署名方式と存在的偽造不可能性を定義します(EU-CMA)。 この論文では，<span class="math inline">\(x\)</span>が一様分布を用いて集合<span class="math inline">\(\mathcal{X}\)</span>からランダムに選択されるとき，<span class="math inline">\(x \overset{\$}{\gets} \mathcal{X}\)</span>と書く。さらに log は <span class="math inline">\(\text{log}_2\)</span>とします。</p>
<p><b>Digital Signature schmes.</b><span class="math inline">\(\,\,\,\,\,\)</span> <span class="math inline">\(\mathcal{M}\)</span>をメッセージ空間とします。デジタル署名方式Dss=(<b>Kg</b>, <b>Sign</b>, <b>Vf</b>)は，確率的多項式アルゴリズムの3つです。</p>
<ul>
<li><p>Kg(1<span class="math inline">\(^n\)</span>) セキュリティパラメータ<span class="math inline">\(1^n\)</span>が入力されると，秘密署名鍵<b>sk</b>と公開検証鍵<b>pk</b>を出力する。</p></li>
<li><p>Sign(sk, <span class="math inline">\(M\)</span>) <span class="math inline">\(M \in \mathcal{M}\)</span>ならば，<span class="math inline">\(M\)</span>に対して<b>sk</b>の下で署名<span class="math inline">\(\sigma\)</span>を出力する。</p></li>
<li><p>Vf(<b>pk</b>, <span class="math inline">\(\sigma\)</span>, <span class="math inline">\(M\)</span>) <span class="math inline">\(\sigma\)</span>が<b>pk</b>の下で<span class="math inline">\(M\)</span>の有効な署名ならば1を出力する。</p></li>
</ul>
<p>次のようになります。 <span class="math inline">\(\forall\)</span> (<b>pk</b>, <b>sk</b>) <span class="math inline">\(\gets\)</span> Kg(1<span class="math inline">\(^n\)</span>) <span class="math inline">\(\,\,\)</span>,<span class="math inline">\(\,\,\)</span> <span class="math inline">\(\forall\)</span> (<span class="math inline">\(M\in \mathcal{M}\)</span>) <span class="math inline">\(\,\,\)</span>:<span class="math inline">\(\,\,\)</span> <b>Vf</b>(<b>pk</b>，<b>Sign</b>(<b>sk</b>,<span class="math inline">\(M\)</span>),<span class="math inline">\(M\)</span>)=1。</p>
<p><b>EU-CMA Security.</b><span class="math inline">\(\,\,\,\,\,\)</span> デジタル署名方式の標準的なセキュリティの考え方は，適応型選択メッセージ攻撃（EU-CMA）の下での存在的偽造不可能性（EU-CMA）であり，以下の思考実験を使用して定義されます。DSS(1<span class="math inline">\(^n\)</span>)とは，セキュリティパラメータ<span class="math inline">\(n\)</span>を持つ署名方式を意味します。 <br></p>
<p><b>Experiment.</b><span class="math inline">\(\,\,\,\,\,\)</span> <span class="math inline">\(\text{Exp}^{\text{EU-CMA}}_{\text{Dss}(1^n)}(\mathcal{A})\)</span> <br> (<b>sk</b>,<b>pk</b>) <span class="math inline">\(\,\,\gets\,\,\)</span> Kg(1<span class="math inline">\(^n\)</span>) <br> (<span class="math inline">\(M\)</span><em>, <span class="math inline">\(\sigma\)</span></em>) <span class="math inline">\(\,\,\gets\,\,\)</span> <span class="math inline">\(\mathcal{A}^{\text{Sign(sk,}\cdot)} (\textbf{pk})\)</span> <br> <span class="math inline">\(\{(M_i,\sigma_i) \}^q_1\)</span>を(,<span class="math inline">\(\cdot\)</span>)の問い合わせ／回答ペアとする<br> (,<span class="math inline">\(M*\)</span>,<span class="math inline">\(\sigma\)</span>*)=1かつ<span class="math inline">\(M^{*} \notin \{M_i\}^q_1\)</span>ならば1を返す<br> <br> 上記の思考実験における攻撃者<span class="math inline">\(\mathcal{A}\)</span>の成功確率については，次のように書きます。 <span class="math display">\[
\text{Succ}^{\text{EU-CMA}}_{\text{Dss}(1^n)}(\mathcal{A})
= \text{Pr} \left[\textbf{Exp}^{\text{EU-CMA}}_{\text{Dss}(1^n)}(\mathcal{A})=1 \right]
\]</span> これを使用して，次のようにEU-CMAを定義します。 <br> <br> <b>Definition 1 (EU-CMA).</b><span class="math inline">\(\,\,\,\,\,\)</span> <span class="math inline">\(n,t,p \in \mathbb{N}\)</span>，<span class="math inline">\(q=\text{poly}(n)\)</span>，Dssをデジタル署名方式とする。 DssがEU-CMA安全とは，上記思考実験で<b>Sign</b>へ<span class="math inline">\(q\)</span>個の問い合わせをして，時間<span class="math inline">\(t\)</span>以内に， 考えられるすべての攻撃者<span class="math inline">\(\mathcal{A}\)</span>のうち，最大の成功確率<span class="math inline">\(\textbf{InSec}^{\text{EU-CMA}}(\text{Dss}(1^n);t,q)\)</span>が<span class="math inline">\(n\)</span>において無視できるとすると， <span class="math display">\[
\text{InSec}^{\text{EU-CMA}}(\text{DSS}(1^n);t,q) \overset{def}{=}
\underset{\mathcal{A}}{\text{max}} \{ \text{Succ}^{\text{EU-CMA}}_{\text{Dss}(1^n)}(\mathcal{A}) \}
= negl(n)
\]</span> EU-CMA安全なワンタイム署名方式（OTS）は， 攻撃者のオラクルへの問い合わせの数が1に制限されている限り，すなわち<span class="math inline">\(q=1\)</span>である限りEU-CMA安全なDssです。</p>
<h2 id="w-ots">W-OTS+</h2>
さてW-OTS<span class="math inline">\(^+\)</span>について紹介します。以前のすべてのW-OTSの変種と同じように， W-OTS<span class="math inline">\(^+\)</span>はセキュリティパラメータ<span class="math inline">\(n\in\mathbb{N}\)</span>，メッセージ長<span class="math inline">\(m\)</span>，そして時間とメモリのトレードオフを決定するWinternitzパラメータ<span class="math inline">\(w \in \mathbb{N}, w > 1\)</span>によってパラメタライズされます。最後の2個のパラメータは次のものを計算するのに使用されます。 <span class="math display">\[
l_1 = \left\lceil \frac{m}{\text{log}(w)} \right\rceil,
\,\,\,
l_2 = \left\lfloor \frac{\text{log}(l_1(w-1))}{\text{log}(w)} \right\rfloor + 1,
\,\,\,
l = l_1 + l_2
\]</span> さらに，W-OTS<span class="math inline">\(^+\)</span>は鍵空間<span class="math inline">\(\mathcal{K}_n\)</span>で関数の族<span class="math inline">\(\mathcal{F}_n\,\,\{f_k:\{0,1\}^n \to \{0,1\}^n| k\in \mathbb{K}_n \}\)</span>を使用します。読者は，圧縮無しの暗号学的なハッシュ関数だと考えてもらって大丈夫です。 <span class="math inline">\(\mathcal{F}_n\)</span>を使って，次の連鎖関数を定義します。 <br> <br> <span class="math inline">\(c^i_k(x,\textbf{r})\)</span>：入力値<span class="math inline">\(x\in \{0,1\}^n\)</span>，イテレーションカウンタ<span class="math inline">\(i\in \mathbb{N}\)</span>，鍵<span class="math inline">\(k\in \mathcal{K}\)</span>，ランダム化要素<span class="math inline">\(\textbf{r}=(r_1,...,r_j)\in \{0,1 \}^{n\times j}(j\geq i)\)</span>とすると， 連鎖関数は次のように働きます。<span class="math inline">\(i=0\)</span>のとき，<span class="math inline">\(c\)</span>は<span class="math inline">\(x\)</span>を返します(<span class="math inline">\(c^0_k(x,\textbf{r})=x\)</span>)。<span class="math inline">\(i>0\)</span>のとき，再帰的に定義します。 <span class="math display">\[
c^i_k(x,\textbf{r}) = f_k(c^{i-1}_k(x,\textbf{r})\oplus r_i)
\]</span> つまり，各ラウンドで，関数は最初に中間値とビットマスク<span class="math inline">\(r\)</span>のビットごとのXORをとり， その結果に対して<span class="math inline">\(f_k\)</span>を評価します。の部分集合<span class="math inline">\(r_a,...,r_b\)</span>として，<span class="math inline">\(\textbf{r}_a,b\)</span>を書きます。<span class="math inline">\(b<a\)</span>の場合<span class="math inline">\(\textbf{r}_{a,b}\)</span>をからの文字列と定義します。パラメータ<span class="math inline">\(m\)</span>，<span class="math inline">\(w\)</span>，そして関数の族<span class="math inline">\(\mathcal{F}_n\)</span>は既知であると仮定します。さて，W-OTS<span class="math inline">\(^+\)</span>の三つのアルゴリズムについて記載します： <br> <br> - <span class="math inline">\(\textit{鍵生成アルゴリズム}\,\,\,\,\,\)</span> (Kg(<span class="math inline">\(1^n\)</span>))：<br> 単項のセキュリティパラメータ<span class="math inline">\(n\)</span>を入力として，鍵生成アルゴリズムは<span class="math inline">\(l+w-1\)</span>個の<span class="math inline">\(n\)</span>ビットの文字列をランダムに一様に選択します。秘密鍵<span class="math inline">\(\textbf{sk}=(\text{sk}_1,...,\text{sk}_l)\)</span>は，最初の<span class="math inline">\(l\)</span>個のランダムなビット列から構成されています。残りの<span class="math inline">\(w-1\)</span>個のビット列は，<span class="math inline">\(c\)</span>のためのランダム化要素<span class="math inline">\(\textbf{r}=(r_1,...,r_{w-1})\)</span>として使用されます。次に，<span class="math inline">\(\text{Kg}\)</span>はランダムに一様にファンクションキー<span class="math inline">\(k \overset{\$}{\gets} \mathcal{K}\)</span>を選択します。公開検証鍵<span class="math inline">\(\textbf{pk}\)</span>は次のように計算されます。 <span class="math display">\[
\text{pk} = (\text{pk}_0,\text{pk}_1,...,\text{pk}_l) =
( (\textbf{r},k), c^{w-1}_k (\text{sk}_1,\textbf{r}) , \cdots,c^{w-1}_k (\text{sk}_l,\textbf{r}) ).
\]</span> <br> <br> - <span class="math inline">\(\textit{署名アルゴリズム}\,\,\,\,\,\)</span> (Sign(<span class="math inline">\(M\)</span>,sk,))：<br> <span class="math inline">\(m\)</span>ビットのメッセージ<span class="math inline">\(M\)</span>，秘密署名鍵<span class="math inline">\(\textbf{sk}\)</span>およびランダム化要素<span class="math inline">\(\textbf{r}\)</span>を入力として，署名アルゴリズムはまず，<span class="math inline">\(M\)</span>の<span class="math inline">\(w\)</span>基底表現を計算します：<span class="math inline">\(M=(M_1...M_{l_1}) \,\,,\,\, M_i \in \{0,...,w-1 \}\)</span>。したがって，<span class="math inline">\(M\)</span>は自然数<span class="math inline">\(x\)</span>のバイナリ表現として扱われ，次に<span class="math inline">\(x\)</span>の<span class="math inline">\(w\)</span>変数表現が計算されます。<br> 次にチェックサムを以下のように計算します。 <span class="math display">\[
C = \sum^{l_1}_{i=1}(w-1-M_i)
\]</span> そして，その<span class="math inline">\(w\)</span>基底表現<span class="math inline">\(C=(C_1,...,C_{l_2})\)</span>を計算します。<span class="math inline">\(C \leq l_1(w-1)\)</span>より，<span class="math inline">\(C\)</span>の<span class="math inline">\(w\)</span>基底表現は，たかだか<span class="math inline">\(l_2\)</span>です。 <span class="math inline">\(M\)</span>と<span class="math inline">\(C\)</span>の<span class="math inline">\(w\)</span>基底表現の連結である<span class="math inline">\(B=(b_1,...,b_l)=M\,\,||\,\,C\)</span>を設定します。 署名は次のように計算されます。 <span class="math display">\[
\sigma = (\sigma_1,...,\sigma_l) = (c^{b_1}_k(\text{sk}_1,\textbf{r}),...,c^{b_l}_k(\text{sk}_l,\textbf{r})).
\]</span> チェックサムは，ある一つのメッセージに対応した<span class="math inline">\(b_i,0 < i \leq l\)</span>が与えられたとき， 任意の他のメッセージに対応する<span class="math inline">\(b'_{i} < b_i\)</span>が少なくとも一つあることを保証することに留意してください。 <br> <br> - <span class="math inline">\(\textit{検証アルゴリズム}\,\,\,\,\,\)</span> (Vf(<span class="math inline">\(1^n\)</span>,<span class="math inline">\(M\)</span>,<span class="math inline">\(\sigma\)</span>,))：<br> バイナリ長<span class="math inline">\(m\)</span>のメッセージ<span class="math inline">\(M\)</span>，署名<span class="math inline">\(\sigma\)</span>，そして公開検証鍵<span class="math inline">\(\textbf{pk}\)</span>を入力として， 検証アルゴリズムは，上述したようにまず<span class="math inline">\(b_i,1\leq i \leq l\)</span>を計算します。 それから以下のように比較されます。
<span class="math display">\[\begin{align}
\textbf{pk}
& = (\textbf{pk}_0,\textbf{pk}_1,...,\textbf{pk}_l) \nonumber \\
& \overset{?}{=}
( (\textbf{r},k), c^{w-1-b_1}_k(\sigma_1, \textbf{r}_{b_1 + 1,w-1}),...,c^{w-1-b_l}_k(\sigma_l, \textbf{r}_{b_l + 1,w-1}) )
\nonumber
\end{align}\]</span>
<p>比較が成立する場合はtrueを返し，そうでない場合はfalseを返します。 <br> 3つのアルゴリズムすべての実行時間は，<span class="math inline">\(f_k\)</span>の<span class="math inline">\(lw\)</span>個の評価によって決まります。 署名と秘密鍵のサイズは，<span class="math inline">\(|\sigma|=|\textbf{sk}|=ln\)</span>ビットです。 公開鍵のサイズは<span class="math inline">\((l+w-1)n+|k|\)</span>ビットで，ここで<span class="math inline">\(|k|\)</span>は<span class="math inline">\(\mathcal{K}\)</span>の任意の要素を表すために必要なビット数です。</p>
<h1 id="参考文献">参考文献</h1>
<ul>
<li>W-OTS+ — Shorter Signatures for Hash-Based Signature Schemes</li>
<li>[BDE$^+$11]:<br> Johannes Buchmann, Erik Dahmen, Sarah Ereth, Andreas Hulsing, and Markus Ruckert. On the security of the Winternitz one-time signature scheme. In A. Nitaj and D. Pointcheval, editors, <it>Africacrypt 2011</it>, volume 6737 of Lecture Notes in Computer Science, pages 363-378. Springer Berlin / Heidelberg, 2011.</li>
</ul>
<p>
<a href="/2018/01/18/wots-jp/#post-footer" class="postShorten-excerpt_link link">
コメント・シェア
</a>
</p>
</div>
</div>
</article>
<article class="postShorten postShorten--thumbnailimg-bottom" itemscope itemType="http://schema.org/BlogPosting">
<div class="postShorten-wrap">
<div class="postShorten-header">
<h1 class="postShorten-title" itemprop="headline">
<a class="link-unstyled" href="/2018/01/17/hash-based-signatures-4/">
ハッシュベース署名方式（４） XMSSとSPHINCS
</a>
</h1>
<div class="postShorten-meta">
<time itemprop="datePublished" datetime="2018-01-17T14:02:49+09:00">
2018/01/17
</time>
<span>カテゴリー </span>
<a class="category-link" href="/categories/暗号通貨/">暗号通貨</a>
</div>
</div>
<div class="postShorten-content" itemprop="articleBody">
<p>前回までの記事（１）～（３）を踏まえて，実際にの署名方式を見ていきます。</p>
<p><b>PQCrypto</b>が<a href="http://pqcrypto.eu.org/docs/initial-recommendations.pdf" target="_blank" rel="noopener">耐量子として推奨される署名方式についてリリース</a>しています。 二つの耐量子アルゴリズムは，<b>XMSS</b>と<b>SPHINCS</b>です。 以下，引用です。</p>
<blockquote>
<ol start="5" style="list-style-type: decimal">
<li>Public-key signatures<br><br> Similar to encryption, currently used signatures are based on problems that become easy to solve with a quantum computer. Signatures use cryptographic hash functions in order to hash the message and then sign the hash. Hash-based signatures use nothing but such a hash function and thus assume the minimum requirement necessary to build signatures. PQCRYPTO recommends the following two hash-based systems to achieve <span class="math inline">\(2^{128}\)</span> post-quantum security:<br><br></li>
</ol>
<ul>
<li><p>XMSS [7] with any of the parameters specified in [11]. XMSS requires maintaining a state.</p></li>
<li><p>SPHINCS-256 [5]. SPHINCS is stateless.</p></li>
</ul>
<p>Example of another choice under evaluation: the HFEv- [15] multivariate-quadratic signature system.</p>
</blockquote>
<p>XMSSはステートフル署名方式，SPHINCSはステートレス署名方式です。</p>
<h1 id="xmss">XMSS</h1>
<p>XMSS(<b>eXtended Merkle Signature Scheme</b>)は<a href="https://eprint.iacr.org/2011/484.pdf" target="_blank" rel="noopener">2011年に発表</a>され，<a href="https://datatracker.ietf.org/doc/draft-irtf-cfrg-xmss-hash-based-signatures/" target="_blank" rel="noopener">インターネット上のドラフト</a>は2015年にできました。</p>
<p>いくつかの点を除いて，Merkle木のような構成になっています。XMSS木には，親ノードがハッシングされる前に子ノードへXORされるマスクがあります。全てのノードでマスクは異なります。</p>
<p><a href="画像とってくること"></a></p>
<p>二つ目の特徴は，XMSS木の葉がOTS署名公開鍵のハッシュではなく，L木と呼ばれる別の木のルートであることです。</p>
<p>L木の葉の中には，WOTS+公開鍵の要素が格納されています。 WOTS+公開鍵をなぜ木に格納するのかはHuelsingが論文内で書いてあるので引用します。</p>
<blockquote>
<p>The tree is not used to store a WOTS public key but to hash it in a way that we can prove that a second-preimage resistant hash function suffices (instead of a collision resistant one).<br> 意訳：この木はWOTS公開鍵を格納するために使用されるのではなく，（衝突耐性の代わりに）第二原像攻撃耐性のあるハッシュ関数が十分であることを証明できるようにハッシングするために使われます。</p>
</blockquote>
<h1 id="sphincs">SPHINCS</h1>
<p>SPHINCSはステートフル署名です。PHINCSは多くの木で構成されています。</p>
<p><a href=""></a></p>
<ul>
<li><p>各ノードは一つ前のノードとレベルビットマスクを連結しXORしたハッシュです。</p></li>
<li><p>公開鍵はビットマスクされたルートハッシュです。</p></li>
<li><p>木の葉は，WOTS+ L木の圧縮された公開鍵です。</p></li>
</ul>
<p>ビットマスク部分は，SPHINCSのハッシュ木（レベルごとに一意のマスク）のように見える点を除いて，前述のXMSS L-treeと同じです。</p>
<p>1つのWOTSを含む葉は，もう一つの木に署名することが可能です。 4つのSPHINCS木の2番目のレイヤーは，WOTS+公開鍵を自分の葉に含んでいます。 最初に設定したパラメータの通りに進んでいき，最後のレイヤー0に到達すると，WOTS+署名はほかのSPHINCS木ではなくて，HORS木に署名します。</p>
<p><a href="SPHINCS画像"></a></p>
<p>HORST木やHORS木はL木と同様ですが，今回はWOTSの代わりにHORS FTSが含まれています。もし同じHORS鍵を使ってメッセージに署名しても問題ないので，それらを使ってメッセージに署名し，これが署名方式のセキュリティを向上させます。</p>
<p>以下は，WOTS+ L木のイメージ図（次のSPHINCS木への署名としてそれらを描くもの）で，メッセージへのパスを一つだけ示したものです。SPHINCSの論文から引用します。</p>
<p><a href="Virtual%20Structure%20of%20a%20SPHINCS%20signature"></a></p>
<p>メッセージMに署名するときには，最初にMと"ランダムな"インデックスで"ランダム化された"ハッシュを作成します（PHINCSのすべてが確定的にPRFで計算されるので，ランダムを強調して書いています）。インデックスは，Mのランダム化されたハッシュに署名するために，HORSTが何を選択するかを示しています。これがステートフルではなくなる方法です：メッセージに従って決定論的にインデックスを選ぶことによります。同じメッセージに再度署名する場合は，同じHORSTを使用する必要があります。異なる2つのメッセージに署名するには，2つの異なるHORSTを使用する必要があります。</p>
<p>
<a href="/2018/01/17/hash-based-signatures-4/#post-footer" class="postShorten-excerpt_link link">
コメント・シェア
</a>
</p>
</div>
</div>
</article>
<article class="postShorten postShorten--thumbnailimg-bottom" itemscope itemType="http://schema.org/BlogPosting">
<div class="postShorten-wrap">
<div class="postShorten-header">
<h1 class="postShorten-title" itemprop="headline">
<a class="link-unstyled" href="/2018/01/17/hash-based-signatures-3/">
ハッシュベース署名方式（３） Many-times Signatures
</a>
</h1>
<div class="postShorten-meta">
<time itemprop="datePublished" datetime="2018-01-17T13:21:47+09:00">
2018/01/17
</time>
<span>カテゴリー </span>
<a class="category-link" href="/categories/暗号通貨/">暗号通貨</a>
</div>
</div>
<div class="postShorten-content" itemprop="articleBody">
<p>前回までにOTSとFTSを見てきました。 次は，ハッシュ関数に基づいた実用的な署名体系はどのようにして構築されるかを見ていきたいと思います。 多くの回数使うことが出来て，理想的には何回も使うことができる署名方式です。</p>
<h1 id="dumb木">Dumb木</h1>
<p>最初に考えられるのはOTSを束にして使うことです（OTSは自分が使いたいもの）。 初めて署名する場合は，最初のOTS鍵ペアを使用し，二度とと使ってはいけません。二回目に何かに署名したい場合は，二番目のOTS鍵ペアを使用し，それもまた二度と使ってはいけません。これを繰り返すと最終的にどうなるかはよくわかると思います。公開鍵はすべてのOTS公開鍵で構成されるため，とても悪いことになるでしょう（その署名方式をたくさん使用することにしたい場合，かなり多くのOTS公開鍵を持つことになります）。</p>
<p>秘密鍵の記憶量を減らす一つの方法は，秘密鍵を生成するための疑似乱数生成器でシードをしようすることです。この方法では，秘密鍵を保存する必要はなく，必要なのはシードのみです。</p>
<p>しかしこれでも，公開鍵が大きくなりすぎるので実用的ではありません。</p>
<h1 id="merkle木">Merkle木</h1>
<p>OTS公開鍵すべてを，一つのメインの公開鍵にリンクする非常に簡単な方法が一つあります。それは<b>Merkle木</b>を利用することです。これは<a href="http://discovery.csc.ncsu.edu/Courses/csc774-F11/reading-assignments/Merkle-Tree.pdf" target="_blank" rel="noopener">Merkleによって1979年に考案された解決策</a>で，発表はその10年後でした。</p>
<p>簡単に定義すると次のようになります。 Merkle木は，すべてのノードがその子ノードのハッシュであり，ルートが公開鍵であり，葉がOTS公開鍵のハッシュである基本的な２分木です。</p>
<p><a href="画像割愛"></a></p>
<p>最初にこの木を使って何かに署名するとしましょう。 最初のOTS公開鍵(A)を使用し，それを二度と使いません。次にBのOTS公開鍵，次にCの，最後にDのOTS公開鍵を使用します。したがってこの木では，合計4つのメッセージに署名することができます。木が大きければ，より多くのメッセージに署名することができるのがわかりますね。</p>
<p>これの良いところは，公開鍵が木のルートのみで構成されていて，何かに署名するたびにその署名が少数のハッシュで構成されていることです。これが認証パスとなります。</p>
<p>この例では，OTS鍵(A)による署名は（<span class="math inline">\(1\)</span>，署名，公開鍵A，認証パス）となります。</p>
<ul>
<li>1は署名の葉の<span class="math inline">\({\it 番号}\)</span>です。繰り返して覚えておかなければいけないことは，葉のOTSを二度と使ってはいけないことです。このことが署名方式を<b>ステーフル</b>にします。</li>
<li><span class="math inline">\({\it 署名}\)</span>はOTSの公開された秘密鍵です。</li>
<li><span class="math inline">\({\it 公開鍵}\)</span>は，署名を検証するためのOTS公開鍵です。</li>
<li><span class="math inline">\({\it 認証パス}\)</span>は，ルート（主となる公開鍵）を再計算することを可能にするノードのリスト（ハッシュのリスト）です。</li>
</ul>
<p>認証パスについて考えてみます。 前の例を取り上げると，最初のOTS鍵(A)で何かを署名した後の認証パスがハイライトされています。</p>
<p><a href="認証パスの画像はここ"></a></p>
<p>OTS公開鍵と二つのハッシュ（Aの葉からルートまでの経路にあるすべての隣接ノード）とで，主となる公開鍵を計算できることが分かります。したがって，これが実際に，その主となる公開鍵に由来する署名であることを検証することができます。</p>
<p>このテクニックのおかげで，私たちは，主となる公開鍵を検証するために全てのOTS公開鍵を知る必要はありません。これにより，空間も時間も節約されることになります。</p>
<p>以上がMerkleの署名方式の簡単なイメージです。</p>
<p>
<a href="/2018/01/17/hash-based-signatures-3/#post-footer" class="postShorten-excerpt_link link">
コメント・シェア
</a>
</p>
</div>
</div>
</article>
<article class="postShorten postShorten--thumbnailimg-bottom" itemscope itemType="http://schema.org/BlogPosting">
<div class="postShorten-wrap">
<div class="postShorten-header">
<h1 class="postShorten-title" itemprop="headline">
<a class="link-unstyled" href="/2018/01/17/hash-based-signatures-2/">
ハッシュベース署名方式（２） Few-times Signatures
</a>
</h1>
<div class="postShorten-meta">
<time itemprop="datePublished" datetime="2018-01-17T12:03:55+09:00">
2018/01/17
</time>
<span>カテゴリー </span>
<a class="category-link" href="/categories/暗号通貨/">暗号通貨</a>
</div>
</div>
<div class="postShorten-content" itemprop="articleBody">
<p>同一の公開鍵，秘密鍵から1つ以上の署名をするにはどうすればいいでしょうか。</p>
<p>この記事では，ハッシュベース署名方式がどのように構築されるか確認するのが最終目標です。</p>
<p>One-time Signatures(OTS)だけでなくFew-times signatures(FTS)でも可能です。</p>
<h1 id="hors">HORS</h1>
<p>HORSは，2002年にReyzin親子によって発表された<a href="https://www.cs.bu.edu/~reyzin/papers/one-time-sigs.pdf" target="_blank" rel="noopener">Biba(Bins and Balls)を更新したもの</a>から作られています。</p>
<p>まず初めに，OTSのように一方向性関数に基づいて秘密鍵となる整数のリストを生成します。そしてそのあとそれぞれについてハッシングし，公開鍵を生成します。</p>
<p>ただし，署名するとき，メッセージ<span class="math inline">\(m\)</span>に対応したインデックスのリストを与えるための<b>選択関数</b><span class="math inline">\(S\)</span>が必要となります。</p>
<p>次の例では，パラメータ<span class="math inline">\(t=5\)</span>，<span class="math inline">\(k=2\)</span>として進めます。 このとき，メッセージ<span class="math inline">\(m\)</span>の小数値が10より小さくなるように署名できます。 また，（選択関数<span class="math inline">\(S\)</span>は2つのインデックスを出力するので）秘密鍵の長さは5であり，署名の長さは2となります。</p>
<p><a href="画像挿入すること"></a></p>
<p>良い関数（全単射関数）<span class="math inline">\(S\)</span>を使用すると，秘密鍵から生成される同一の要素で二つのメッセージに署名することは<b>不可能</b>です。しかし，その2つの署名のあとは，新しいものを偽造するのはかなり簡単なはずです。2個目に構築するのはHORS署名方式と呼ばれるものです。これは，一方向性関数の代わりに"サブセット・レジリエント"関数に基づいています。選択関数<span class="math inline">\(S\)</span>は，<span class="math inline">\(H(m_2) \subseteq H(m_1)\)</span>となるような2つのメッセージ<span class="math inline">\(m_1\)</span>，<span class="math inline">\(m_2\)</span>を見つけることが不可能である関数<span class="math inline">\(H\)</span>に置き換えることができます。</p>
<p>それよりも，複数回署名可能な方式にしたい場合，署名者が<span class="math inline">\(r\)</span>個の署名を与えたとき，<span class="math inline">\(H(m') \subseteq H(m_1) \cup \cdots \cup H(m_r)\)</span>となるメッセージ<span class="math inline">\(m'\)</span>を見つけることは不可能であるべきです。これが，実際には"サブセット・レジリエント"の定義となります。</p>
<p>選択関数<span class="math inline">\(H\)</span>は，攻撃者が多項式時間で，前の式を確認できる<span class="math inline">\(r+1\)</span>個のメッセージの集合を（たとえ小さな確率であっても）見つけられない場合，r-サブセット・レジリエントです。 定義に関する部分をそのまま引用します。</p>
<blockquote>
<p>Let <span class="math inline">\(\mathcal{H}=\{H_{i,t,k} \}\)</span> be a family of functions, where <span class="math inline">\(\{H_{i,t,k} \}\)</span> maps an input of arbitrary length to a subset of size at most <span class="math inline">\(k\)</span> of the set <span class="math inline">\(\{0,1,\cdots,t-1 \}\)</span>.(Note that for each <span class="math inline">\(t\)</span> and <span class="math inline">\(k\)</span>, contains a number of fuctions, which are indexed by <span class="math inline">\(i\)</span>). Moreover, assume that there is a polynomial-time algorithm that, given <span class="math inline">\(i, 1^t,1^k\)</span> and <span class="math inline">\(M\)</span>, compute <span class="math inline">\(H_{i,t,k}(M)\)</span>. <br><br> <b>Definition 1.</b> We say that <span class="math inline">\(\mathcal{H}\)</span> is <span class="math inline">\(\it{r-subset-resilient}\)</span> if, for every probablistic polynominal-time adversary A,<br> <span class="math display">\[
\underset{i}{\text{Pr}}
[
(M_1,M_2,...,M_{r+1}) \gets A(i,1^t,1^k) \\
\text{s.t.} \,\, H_{i,t,k}(M_{r+1})\subseteq
\underset{j=1}{\overset{r}{\cup}} H_{i,t,k}(M_j)
] < negl(t,k).
\]</span> Fix a distribution <span class="math inline">\(D\)</span> on the space of all inputs to <span class="math inline">\(H\)</span> (i.e., on the space of messages).</p>
</blockquote>
<p>しかし，ここでは選択関数は全単射ではないので，元に戻すのは難しいのです。 したがってメッセージの一つ前の署名を知っていても，どのメッセージがそれらのインデックスを使用するのかわかりません。</p>
<p>これは，理論上はランダムなオラクルを使用して，実際にはハッシュ関数を使用して行われます。これが，HORS(=<b>Hash to Obtain Random Subset</b>)と呼ばれる所以です。</p>
<p>他にも選択関数はあります。 メッセージ<span class="math inline">\(m\)</span>を署名するために，次の手順をふみます。</p>
<ol style="list-style-type: decimal">
<li><span class="math inline">\(h=Hash(m)\)</span></li>
<li><span class="math inline">\(h\)</span>を<span class="math inline">\(h_1,...,h_k\)</span>に分割する</li>
<li>それぞれの<span class="math inline">\(h_j\)</span>を整数<span class="math inline">\(i_j\)</span>と解釈する</li>
<li>署名は<span class="math inline">\(sk_{i_1},...,sk_{i_k}\)</span>となる</li>
</ol>
<p>
<a href="/2018/01/17/hash-based-signatures-2/#post-footer" class="postShorten-excerpt_link link">
コメント・シェア
</a>
</p>
</div>
</div>
</article>
<article class="postShorten postShorten--thumbnailimg-bottom" itemscope itemType="http://schema.org/BlogPosting">
<div class="postShorten-wrap">
<div class="postShorten-header">
<h1 class="postShorten-title" itemprop="headline">
<a class="link-unstyled" href="/2018/01/12/hash-based-signatures-1/">
ハッシュベース署名方式（１） One-time Signatures
</a>
</h1>
<div class="postShorten-meta">
<time itemprop="datePublished" datetime="2018-01-12T17:19:52+09:00">
2018/01/12
</time>
<span>カテゴリー </span>
<a class="category-link" href="/categories/暗号通貨/">暗号通貨</a>
</div>
</div>
<div class="postShorten-content" itemprop="articleBody">
<h1 id="lamport"><a href="https://www.microsoft.com/en-us/research/publication/constructing-digital-signatures-one-way-function/?from=http%3A%2F%2Fresearch.microsoft.com%2Fen-us%2Fum%2Fpeople%2Flamport%2Fpubs%2Fdig-sig.pdf" target="_blank" rel="noopener">Lamport</a></h1>
<p>1979年の10月18日にLeslie Lamportによって<b>ワンタイム署名</b>のコンセプトが発表された。</p>
<p>ほとんどの署名スキームはそのセキュリティの証明に，部分的に一方向性関数，典型的なハッシュ関数に頼っています。ランポート署名の美しさは，この署名がこれらの一方向性関数のセキュリティにだけ頼っているところ。</p>
<table>
<tbody>
<tr class="odd">
<td align="center">公開鍵</td>
<td align="center">$ h(x)|h(y)$</td>
</tr>
<tr class="even">
<td align="center">秘密鍵</td>
<td align="center">$ (x,y) $</td>
</tr>
</tbody>
</table>
<p>とても単純なスキームとして，<span class="math inline">\(x\)</span>，<span class="math inline">\(y\)</span>を整数とすると，単一のビットへの署名は， <br> - もし0なら，<span class="math inline">\(x\)</span>を公開する<br> - もし1なら，<span class="math inline">\(y\)</span>を公開する</p>
<p>それを2度と署名に使わないこと。 もし複数のビットに署名したい場合はどうすればいいか？ できることは，署名したいメッセージを固定長の出力となるようにハッシング することです。例えば，SHA-256など。</p>
<p>そのとき，256個の秘密鍵のペアが必要になって，次のようになる。<br></p>
<table>
<tbody>
<tr class="odd">
<td align="center">公開鍵</td>
<td align="center">$ h(x_0)|h(x_0), h(x_1)|h(x_2),...,h(x_{255}) | h(y_{255})$</td>
</tr>
<tr class="even">
<td align="center">秘密鍵</td>
<td align="center">$ (x_0,y_0),(x_1,y_1),...,(x_{255},y_{255}) $</td>
</tr>
</tbody>
</table>
<p>そしてもし，<span class="math inline">\(100110_2....\)</span>に署名したい場合は，<span class="math inline">\((y_0,x_1,x_2,y_3,y_4,x_5,...)\)</span>というように公開する。</p>
<p>詳細は，<a href="https://qiita.com/onokatio/items/689965fa484d40d851ce" target="_blank" rel="noopener">Qiita</a>にも取り上げられているので，そちらに譲る。</p>
<h1 id="winternitz-ots-wots">Winternitz OTS (WOTS)</h1>
<p>Lamportの発表から数か月あと，スタンフォードの数学学科のRobert Winternitzが，<span class="math inline">\(h(x)|h(y)\)</span>の公開の代わりに<span class="math inline">\(h^w(x)\)</span>を公開することを提案した。</p>
<p>例えば，<span class="math inline">\(w=16\)</span>として<span class="math inline">\(h^{16}(x)\)</span>を公開鍵として公開する場合，<span class="math inline">\(x\)</span>は秘密鍵。次のバイナリ<span class="math inline">\(1101_2\)</span>に署名したい場合，<span class="math inline">\(h^9(x)\)</span>を公開すればいい。</p>
<p>問題は，悪意のある人間が<span class="math inline">\(h^{10}(x)\)</span>を検索するために，この署名とハッシュを見られることで，それゆえ有効な署名を偽造しうること。</p>
<p>これはメッセージの後ろに短いチェックサム（同様に署名する必要がある）を追加することで回避可能。</p>
<h1 id="variant-of-winternitz-ots"><a href="https://eprint.iacr.org/2011/191.pdf" target="_blank" rel="noopener">Variant of Winternitz OTS</a></h1>
<p>長い長い年月のあと，2011年に，Buchmann et alがWinternitz OTSのアップデートを公開して，鍵でパラメータ化された族を利用して新しいWOTSの変種を紹介した。MACと呼ばれている。</p>
<p>MACで使用される鍵のリストが秘密鍵で，メッセージは何度MACを反復するかを指定することになる。以前の出力が鍵を置き換えるため固有の反復であり，常に同じ公開された入力を使用する。</p>
<p>メッセージ<span class="math inline">\(M=1011_2\)</span>があり，WOTSの変種が3を基底とするメッセージとして動作するとする（実際には任意の基底<span class="math inline">\(w\)</span>でも大丈夫）。<span class="math inline">\(M=(M_0,M_1,M_2)=(1,0,2)\)</span>は<span class="math inline">\(102_3\)</span>を表すとする。</p>
<p>これを署名するには，<span class="math inline">\((f^1_{sk_1}(x)=f_{sk_1}(x),\, f^0_{sk_2}(x)=sk_2 ,\, f^2_{sk_3}(x)=f_{\{f^1_{sk_3(x)}\}}(x) )\)</span>を公開すればいい。</p>
<p>まだメッセージに署名が必要なチェックサムが適用されるが，詳細割愛。 チェックサムにより，公開鍵の中で<span class="math inline">\(M_2=2\)</span>と知られていても関係がない。</p>
<p>直感的に，連鎖していくことで公開鍵により良いセキュリティを提供することになる。</p>
<h1 id="winternitz-otswots"><a href="https://huelsing.files.wordpress.com/2013/05/wotsspr.pdf" target="_blank" rel="noopener">Winternitz OTS+(WOTS+)</a></h1>
<p>変種の発表の2年後，Hulsingだけで，署名サイズを短くし，以前のスキームのセキュリティを向上させるアップグレード版を公開した。これは，鍵付き関数族に加えて，連鎖関数を使用する。今度は，鍵は常に同じで，それは一つ前の出力が入力となる。また，一方向性関数が適用される前にランダム値（またはマスク）がXORされる。</p>
<p>入力<span class="math inline">\(x \in \{0, 1\}^n\)</span>，反復カウンタ<span class="math inline">\(i\in \mathbb{N}\)</span>，ランダム要素<span class="math inline">\(\bf{r}\)</span><span class="math inline">\(=(r_1,...,r_j) \in \{0,1\}^{n\times j}(j\geq i)\)</span>とすると，連鎖関数は次のように働く。<br> <span class="math inline">\(i=0\)</span>のとき，連鎖関数<span class="math inline">\(c\)</span>は<span class="math inline">\(x\)</span>を返す<span class="math inline">\((c_k^0(x,\textbf{r})=x)\)</span>。<br> <span class="math inline">\(i>0\)</span>のとき，連鎖関数<span class="math inline">\(c\)</span>は再帰的に次のようになる。 <span class="math display">\[
c_k^i(x,\textbf{r}) = f_k(c_k^{i-1}(x,\textbf{r}) \oplus r_i)
\]</span> <span class="math inline">\(f_k\)</span>について，鍵空間<span class="math inline">\({\cal K}_n\)</span>とすると，関数族<span class="math inline">\({\cal F}_n:\{f_k : \{0,1\}^{n} \to \{0,1\}^{n} | \,\, k\in {\cal K}_n \}\)</span>を満たす。<br> 要は，圧縮なしの暗号学的なハッシュ関数。</p>
<h1 id="その他のotsについて">その他のOTSについて</h1>
<p>他にもいろいろ提案されている。<br> - 1994，<a href="ftp://ftp.inf.ethz.ch/pub/crypto/publications/BleMau94.pdf" target="_blank" rel="noopener">The Bleichenbacher-Maurer OTS</a><br> - 2001，<a href="http://www.netsec.ethz.ch/publications/papers/biba.pdf" target="_blank" rel="noopener">The BiBa OTS</a><br> - 2002，<a href="https://www.cs.bu.edu/~reyzin/papers/one-time-sigs.pdf" target="_blank" rel="noopener">HORS</a><br> - 2014，<a href="https://cryptojedi.org/papers/sphincs-20141001.pdf" target="_blank" rel="noopener">HORST, SPHINCS</a><br></p>
<p><a href="http://pqcrypto.eu.org/docs/initial-recommendations.pdf" target="_blank" rel="noopener">PQCRYPTO ICT-645622</a>によると，耐量子として，公開鍵署名に推奨されているものは，XMSSとSPHINCS-256。<br> （XMSSはステートフル署名，SPHINCSはステートレス署名）</p>
<p>
<a href="/2018/01/12/hash-based-signatures-1/#post-footer" class="postShorten-excerpt_link link">
コメント・シェア
</a>
</p>
</div>
</div>
</article>
<article class="postShorten postShorten--thumbnailimg-bottom" itemscope itemType="http://schema.org/BlogPosting">
<div class="postShorten-wrap">
<div class="postShorten-header">
<h1 class="postShorten-title" itemprop="headline">
<a class="link-unstyled" href="/2018/01/06/Get-ready-for-qrl-launch-ja/">
Get ready for QRL launch! (日本語訳)
</a>
</h1>
<div class="postShorten-meta">
<time itemprop="datePublished" datetime="2018-01-06T16:58:57+09:00">
2018/01/06
</time>
<span>カテゴリー </span>
<a class="category-link" href="/categories/暗号通貨/">暗号通貨</a>
</div>
</div>
<div class="postShorten-content" itemprop="articleBody">
<p><span style="color: #ff0000">※追加コメント等は赤字で記載いたします </span></p>
<p>暗号通貨のエコシステムにとっては何という年でしょう！価格については無視してプロジェクトに集中しようとしていましたが，暗号通貨全体が今年で約0.6兆ドルにまで拡大したことは見過ごせません。何年も前に気づいたことを世界の人々が納得するまで我慢強く待っていたので，2012・2013年からその現場にいた私たちにとってはとても信じられないことです。このような空間の革新と成長は畏敬の念をおこすものです。資産とインターネットのペイメント層としての暗号通貨は，本当の本当にやってきました。</p>
<p> </p>
<p>このブログは長くなるので，最初に大きなこと―ローンチのタイミングと詳細をお届けします！</p>
<p> </p>
<h1 id="ロードマップの変更ーメインネットローンチは-q1-2018">ロードマップの変更 ー メインネットローンチは Q1 2018</h1>
<p>できるだけ早くローンチするため，ロードマップを大きく変更しました。</p>
<p>プロジェクトをよく知っている人は，パブリックテストネットで数か月間Proof of Stakeのプロトコルを徹底的に繰り返しテストしていたことをよく知っています。</p>
<p>大きな進歩を遂げましたが，私たちの現在のプロトコルで低電力デバイス（Pi3以上）を投入する計画は挑戦的であり，ここ数週間でメインネットのリリースを押し戻してきました。</p>
<p>私たちはプロトコルにいくつかの変更を加える必要があり，これらをさらに広範にテストし，それを査読（ピアレビュー）に公開する必要があります。これは，商用レベルで適切に完了するために，少なくとも4～6か月かかるでしょう。</p>
<p>セキュリティはQRLのすべてです。私たちは，アカウントとトランザクションを保護するためにポスト量子として推奨される<i>XMSS</i>を使用しています。私たちのプロジェクトが現在どれほどの価値を持っているかを考えると，未成熟のPoSプロトコルを使用してローンチし妥協することはできません。</p>
<p>また，QRLとの統合を希望する将来のパートナーがチェーンを必要とし，私たちが＃１として立ち上げることが重要であるため，ローンチをさらに遅らせないことが肝心です。</p>
<p>このことを念頭に置いて，今月初めにMenero/XMRで使用されるcryptonightを一時的なPoWアルゴリズムとしてローンチし，さらにQ3 2018にPoSへとハードフォークする，という大きな決断を下しました。</p>
<p>PoWは2009年から何度も試されているアルゴリズムであり，非常に簡単に統合できます。<b>私たちはすでにプライベートデベロッパーテストネットでqrlcoreをPoWに完全に適合させており，mid Q1 2018にローンチすることを目指していて，内ではカウントダウンはすでに始まっています。</b>機能はすでに固まっています。私たちは外部監査（コード監査）の準備をしています。</p>
<h1 id="トークンの移行">トークンの移行</h1>
<p>ユーザーがERC20トークンの残高をBurnアドレスに移動し，メインネットのローンチ時に自動的に残高が含まれるというトークンの移行は，<b>来月開始される予定です</b>。そのプロセスの詳細を説明するブログ記事が新年の少し後にあります。メインネットローンチ時に移行しないユーザーは，もちろん，のちに安全にコインをアンロックするオプションがあります。<br> <span style="color: #ff0000">※トークンの移行は，現在のERC20トークンをユーザーがBurnアドレスに送信しまずBurnします。その時に①Burn用のアドレスと②QRLメインネットのアドレスが紐づけられるようです。メインネットローンチ時Genesis Block内に，Burnした残高に1:1対応して数値が反映されることになります。</span></p>
<p>取引所との協議は進行中ですー私たちは，今は何も新しいことを表にすることはできません！</p>
<h1 id="proof-of-stakeへの移行">Proof-of-stakeへの移行</h1>
<p>2018年を通して私たちは3つのQRLを維持することになります。</p>
<ol style="list-style-type: decimal">
<li>Mainnet-PoW.</li>
<li>Testnet-PoW.</li>
<li>Testnet-PoS.</li>
</ol>
<p>2018年を通してフルタイムの開発とプロトコルのテストは継続（実際，拡大）されます。ハードフォークのスケジュールとして，Q3 2018に純粋にPoSにハードフォークします。</p>
<p>QRLの排出スケジュールは，PoSへの移行やステーキングの前に採掘されると予想される2399544.94（利用可能な供給量の3.54%，総供給量の2.18%）と変わらないままです</p>
<h1 id="エフェメラルメッセージ">エフェメラルメッセージ</h1>
<p>私たちのブロックチェーンの上に置くメッセージング層は，もうコードベースに統合されていますー<i><a href="https://cryptojedi.org/papers/dilithium-20170627.pdf" target="_blank" rel="noopener">Dilithium</a></i>と<i><a href="https://eprint.iacr.org/2017/634.pdf" target="_blank" rel="noopener">Kyber</a></i>を実装しています。私たちは今，QRLに組み込まれた3つの異なるポスト量子セキュアな暗号システムを持っていることになります。</p>
<p>これにより，エキサイティングなレイヤーの2つの機能の多くがオンラインになりました！</p>
<h1 id="チームの拡大は2018年も続きます">チームの拡大は2018年も続きます</h1>
<p>UX，モバイル，およびコア開発者として働く追加の<b>チームの3人のフルタイム開発メンバー</b>をまもなく発表する予定です。これについてはもっと詳しく近日中に。QRLのリモートオフィスは忙しい場所になりつつあります。</p>
<p>さらに，<b>アドバイザーとしてRobby Dermody</b>をチームに加えることをとても嬉しく思います。彼はCounterpartyプロジェクトのFounderであり，私たちの成長するプロジェクトにすでに優れた付加価値を立証してくれています。</p>
<h1 id="年のカンファレンス">2018年のカンファレンス</h1>
<p><span style="color: #ff0000">(画像は省略) </span><br> QRLチームは英国，米国，カナダからオランダ，インド，オーストラリアと世界中に分散しています。</p>
<p>私たちは屋外に出向いて，次の会議に出席して，2018年上半期にプロジェクトの概要を公開する予定です。ーBlock Delhi，APAC Australia，CryptoValley，そしてBlockchain Global Expoです。 また潜在的にさらに多くの会議に出席し（例えばConsensus 2018），2018年の後半にはさらにもっとあるでしょう！</p>
<p>これらのイベントで多くの方々にお会いし，私たちのプロジェクトについて広めていただければ幸いです。青/紫のQRLロゴのTシャツを探しましょう！</p>
<h1 id="メインネットローンチ時のフィーチャーセット">メインネットローンチ時のフィーチャーセット</h1>
<p>Q1 2018に次のフィーチャーセットをお届けします。</p>
<ol style="list-style-type: decimal">
<li><p>マルチプラットフォームのqrlcoreノードのリリース</p></li>
<li><p>QRL(<i>XMSS</i>)の100%PQセキュアなアドレス空間</p></li>
<li><p>cryptonight PoWアルゴリズム，ブロック時間間隔1分，既存ソフトウェアを使用した既存プールでのマイニング</p></li>
<li><p>エフェメラル・メッセージング層機能（<i><a href="https://eprint.iacr.org/2017/634.pdf" target="_blank" rel="noopener">Kyber</a></i>および<i><a href="https://cryptojedi.org/papers/dilithium-20170627.pdf" target="_blank" rel="noopener">Dilithium</a></i>を利用するPQ-secure端末間データチャンネル機能）</p></li>
<li><p>ユニバーサルなgRPC APIによってノードを通過するすべてのウォレットベースのリクエストと，完全に分離されたウォレットとノードの機能性</p></li>
<li><p>スレーブXMSS木署名機能を使用して秘密鍵をオフラインに保つ安全なマイニングを可能にします</p></li>
<li><p>GUIベースのウェブウォレットとフルブロックエクスプローラ機能</p></li>
<li><p>PQトークン作成機能ーQRLチェーン上にトークンを作成・送信することができます</p></li>
<li><p>PQセキュア・データスタンプ機能</p></li>
</ol>
<p>さらに，Ledger Nano上で完全な<i>XMSS</i>署名を実装するために非常に努力しています。そして，私たちはエフェメラル機能を早期に発揮するために，Mainnetのローンチ時にプロトタイプとしてWhatsApp形式のPQ-secureメッセージングアプリを利用できると期待しています。</p>
<h1 id="tdlr">TDLR</h1>
<ol style="list-style-type: decimal">
<li><p>QRLはmid Q1 2018に利用可能になり，Q3 2018のハードフォークによってPoWからPoSへ移行します</p></li>
<li><p>ERC20トークンからQRLトークンへの移行は来月開始します</p></li>
<li><p>チームは新しいメンバーと新しいアドバイザーを加え成長します</p></li>
</ol>
<p><b>十分なポスト量子セキュアなブロックチェーンへのカウントダウンが開始されました。</b></p>
<p><b>Adam，Aidan，Andrew，Burke，Elliott，Jack，JP，Juan，Kaushal，Leon，Michael，Scott，そして私自身、QRLチームの皆さんにおめでとう！</b></p>
<p><br><br></p>
<h1 id="翻訳を終えて">翻訳を終えて</h1>
<p>今回の翻訳は以上になります。 最後に発行数等の情報を以下に記載します。</p>
<ul>
<li>通貨名：Quantum Resistant Ledger (QRL)<br></li>
<li>最終供給量： 105,000,000 QRL<br></li>
<li>最大供給量： 65,000,000 QRL<br></li>
<li>市場流通量： 52,000,000 QRL<br></li>
<li>アルゴリズム：PoW（cryptonight），後にカスタムPoS（Testnetで開発中） <br></li>
<li>使用署名方式：<i>XMSS</i>(=<a href="https://eprint.iacr.org/2011/484.pdf" target="_blank" rel="noopener">eXtended Merkle Signature Scheme</a>)<br> ※OTS(One-Time Signature) Schemeは<i><a href="https://huelsing.files.wordpress.com/2013/05/wotsspr.pdf" target="_blank" rel="noopener">Winternitz OTS+</a></i></li>
<li>エフェメラル・メッセージ層で使用される暗号鍵：<i><a href="https://cryptojedi.org/papers/dilithium-20170627.pdf" target="_blank" rel="noopener">Dilithium</a></i>，<i><a href="https://eprint.iacr.org/2017/634.pdf" target="_blank" rel="noopener">Kyber</a></i></li>
</ul>
<p>読んでいただきありがとうございました。</p>
<p>
<a href="/2018/01/06/Get-ready-for-qrl-launch-ja/#post-footer" class="postShorten-excerpt_link link">
コメント・シェア
</a>
</p>
</div>
</div>
</article>
<article class="postShorten postShorten--thumbnailimg-bottom" itemscope itemType="http://schema.org/BlogPosting">
<div class="postShorten-wrap">
<div class="postShorten-header">
<h1 class="postShorten-title" itemprop="headline">
<a class="link-unstyled" href="/2018/01/06/Statefullness-and-security-ja/">
Statefull and security (日本語訳)
</a>
</h1>
<div class="postShorten-meta">
<time itemprop="datePublished" datetime="2018-01-06T16:48:39+09:00">
2018/01/06
</time>
<span>カテゴリー </span>
<a class="category-link" href="/categories/暗号通貨/">暗号通貨</a>
</div>
</div>
<div class="postShorten-content" itemprop="articleBody">
<p><span style="color: #ff0000">※赤字は追加で解説，資料等記載します。 </span></p>
<h1 id="ステートフルとセキュリティ">ステートフルとセキュリティ</h1>
<p>QRLはステートフルなアカウントを保護するため，非常に珍しい署名方式であるXMSSを採用しています。<br> <span style="color: #ff0000">（論文は次を参照ください。https://eprint.iacr.org/2011/484.pdf ） </span></p>
<p>トランザクションがQRLのアドレスから署名されるたびに，<i>Winternitz OTS+</i>ワンタイム署名がXMSSウォレットで使用されます。</p>
<p>同一のワンタイム署名から再度署名（=同一のXMSS木のインデックスを再利用）し，有効な署名でトランザクションを作成することは可能です。一方で，ブロックが追加されたときルーチンの状態検証中にワンタイム署名の再利用を禁止するため，QRLのネットワークではこのトランザクションを拒否します。</p>
<p>しかしながら，同一のワンタイム署名のインデックスを再利用しつづける場合，XMSSのセキュリティは徐々に低下します。</p>
<p>理論的には，同一の木のインデックスから複数の署名と十分な時間があれば，ワンタイム署名の秘密鍵を推測することが可能です。</p>
<p>署名が2つの場合は2<sup>34</sup>，3つの場合2<sup>23</sup>，4つの場合2<sup>18</sup>のハッシュが必要になります。</p>
<p>明らかに，XMSSのこのステートフルなセキュリティの側面は，安全に使用できる実際の状況がほとんどないことを意味しています。その理由は，署名者（ウォレット）が同一のインデックスに繰り返し署名し，ウォレットのXMSS木の秘密鍵を危険にさらすことを許容することが絶対に致命的であるからです。</p>
<p>それゆえに，新しい状態とインクリメントされた木のインデックスを反映させるために，各々の署名のあとにウォレットファイルは更新されなければなりません。ウォレットが同一のインデックスから署名してる限りは，すべて問題ありません。</p>
<h1 id="qrlのウェブウォレット">QRLのウェブウォレット</h1>
<p>シンプルです。ウォレットファイルでqrlcoreを利用している場合や，のちにすべてを安全に保存するためにLedger Nanoを使用する場合は，すべてが自動的に処理されます。</p>
<p>しかし，古いウォレットファイルをバックアップから復元するとどうなるでしょうか？またはウォレットファイル無しのウォレットがある場合は？</p>
<p>私たちのウェブウォレットは現在機能しており（ https://wallet.qrlexplorer.info/ ），これはニーモニックフレーズまたはhexseedで開かれます。<br> <span style="color: #ff0000">（2017/12/20時点で，これはTestnet用のウェブウォレットです。BittrexでトレードされているQRLトークンはERC20トークンでありますので，このウェブウォレットは利用できません。メインネットをお待ちください）</span></p>
<p>1つのオプションとしては，各セッションの後にユーザーに対してウォレット・インデックス番号を覚えてもらうことを頼むことです。 しかし，これはユーザーが覚えた後で思い出すことに依存するので，問題が発生しやすくなります。 自分のウェブウォレットにアクセスすることがまれである場合，または単にウォレット・インデックスを忘れた場合，システムは失敗します。</p>
<p>しかし私たちは運がいいです。QRLのブロックチェーンは助けてくれます。</p>
<p>すでにチェーン内にあるXMSSインデックスはバーンされたと考えることができます。潜在的に，有効なXMSSインデックスは，まだトランザクションを署名するために使用されていないものです。ウェブウォレットがQRLのネットワークに接続すると，QRLのアドレスのトランザクション履歴をロードし，送信されたトランザクション数を使用して現在のXMSS木インデックスを計算します。<br> <span style="color: #ff0000">（XMSSの構造上ウォレットファイルは更新され続けなければなりません。それが何らかの破損をしても救助できるということであり，ウォレットのニーモニックフレーズ自体はしっかり保存してください）</span></p>
<p>ウェブウォレットブラウザのインスタンスとQRLのP2Pネットワーク間で中間者攻撃をしようとする悪意のあるノードによって，ウェブウォレットが欺かれることがあるでしょうか？</p>
<p>ウェブウォレットは，自分のアドレスの履歴にある各トランザクションを簡単に検証できます。悪意のあるノードが行うことができるのは，ウェブウォレットが正しくない誤った低いインデックスで署名するよう混乱させるために，極めて少ないトランザクションを送信させることくらいです。そのインデックス位置でのワンタイム署名がすでにQRLネットワークでブラックリスト化されますので，これは何も達成することができません。悪意のあるノードは，期待より高いインデックスから署名させるようウェブウォレットを欺くトランザクションを偽造することはできません。そうする正当な署名を生成することができないからです。</p>
<p>ここまでは順調ですね。</p>
<p>現在のインデックスから秘密鍵を危険にさらすのに十分な回数署名するよう，ウェブウオレットを欺くため，悪意のあるノードが意図的にトランザクションを伝播できないようにすることは可能でしょうか？</p>
<p>私たちのウェブウォレットは，トランザクションを複数のノードに伝播することによってこの可能性を緩和します。 さらに，別のランダムなノードからメモリプール・ブロック内のtxを見るまで，再びアクティブセッションで再度署名することはありません。</p>
<h1 id="nist">NIST</h1>
<p>しばらくの間，プレースホルダーのエフェメラルメッセージルーチンがin-situで実行されました。 私たちのend-endポスト量子セキュア・データ・チャネルは，両端に2つの公開鍵を含む<i>EPH</i>トランザクションによってリンクされています。これを分散格子公開鍵サーバと考えてください。 現在，それらは<i>ECC</i>公開鍵であり，一つは署名用でもう一つは暗号化用です。 しかし，NISTがリリース（そう長くない）するとすぐに，私たちは署名用の<i>dilithium</i>鍵と、エフェメラルなトラフィックを格子暗号化するための<i>kyber</i>鍵を用意します。<br> <span style="color: #ff0000">（dilithiumの論文： https://eprint.iacr.org/2017/633.pdf <br> kyberの論文： https://eprint.iacr.org/2017/634.pdf ）</span></p>
<h1 id="お知らせ">お知らせ</h1>
<p>今月下旬に発表する新しいメンバー変更と，ロードマップとタイムラインの両方に（とても興奮する）大きな変化があります！ <br> <br></p>
<p><span style="color: #ff0000">以上，翻訳でした。<br> （個人的な予想ですが，おそらくお知らせはパブリックテストネットの段階から次の段階へ移行する旨の発表ではないのかなと考えています）</span></p>
<p>
<a href="/2018/01/06/Statefullness-and-security-ja/#post-footer" class="postShorten-excerpt_link link">
コメント・シェア
</a>
</p>
</div>
</div>
</article>
<article class="postShorten postShorten--thumbnailimg-bottom" itemscope itemType="http://schema.org/BlogPosting">
<div class="postShorten-wrap">
<div class="postShorten-header">
<h1 class="postShorten-title" itemprop="headline">
<a class="link-unstyled" href="/2018/01/06/引っ越しのお知らせ/">
引っ越しのお知らせ
</a>
</h1>
<div class="postShorten-meta">
<time itemprop="datePublished" datetime="2018-01-06T14:23:52+09:00">
2018/01/06
</time>
<span>カテゴリー </span>
<a class="category-link" href="/categories/お知らせ/">お知らせ</a>
</div>
</div>
<div class="postShorten-content" itemprop="articleBody">
<p>はてなブログより引っ越ししました。</p>
<p>次回からこちらに記事等記載予定です。 レイアウト等は時間があればいじっていきます。</p>
<p>
<a href="/2018/01/06/引っ越しのお知らせ/#post-footer" class="postShorten-excerpt_link link">
コメント・シェア
</a>
</p>
</div>
</div>
</article>
<div class="pagination-bar">
<ul class="pagination">
<li class="pagination-number">page 1 of 1</li>
</ul>
</div>
</section>
<footer id="footer" class="main-content-wrap">
<span class="copyrights">
Copyrights © 2018 Owl. All Rights Reserved.
</span>
</footer>
</div>
</div>
<div id="about">
<div id="about-card">
<div id="about-btn-close">
<i class="fa fa-remove"></i>
</div>
<h4 id="about-card-name">Owl</h4>
<div id="about-card-bio"><p>新しいもの好きなフクロウです</p>
</div>