Statefulness and security（日本語訳）
※赤字は追加で解説，資料等記載します。
ステートフルとセキュリティ
QRLはステートフルなアカウントを保護するため，非常に珍しい署名方式であるXMSSを採用しています。
（論文は下記参照ください。
https://eprint.iacr.org/2011/484.pdf）
トランザクションがQRLのアドレスから署名されるたびに，Winternitz OTS+ワンタイム署名がXMSSウォレットで使用されます。
同一のワンタイム署名から再度署名（=同一のXMSS木のインデックスを再利用）し，有効な署名でトランザクションを作成することは可能です。一方で，ブロックが追加されたときルーチンの状態検証中にワンタイム署名の再利用を禁止するため，QRLのネットワークではこのトランザクションを拒否します。
しかしながら，同一のワンタイム署名のインデックスを再利用しつづける場合，XMSSのセキュリティは徐々に低下します。
理論的には，同一の木のインデックスから複数の署名と十分な時間があれば，ワンタイム署名の秘密鍵を推測することが可能です。
署名が2つの場合は234，3つの場合223，4つの場合218のハッシュが必要になります。
明らかに，XMSSのこのステートフルなセキュリティの側面は，安全に使用できる実際の状況がほとんどないことを意味しています。その理由は，署名者（ウォレット）が同一のインデックスに繰り返し署名し，ウォレットのXMSS木の秘密鍵を危険にさらすことを許容することが絶対に致命的であるからです。
それゆえに，新しい状態とインクリメントされた木のインデックスを反映させるために，各々の署名のあとにウォレットファイルは更新されなければなりません。ウォレットが同一のインデックスから署名してる限りは，すべて問題ありません。
QRLのウェブウォレット
シンプルです。ウォレットファイルでqrlcoreを利用している場合や，のちにすべてを安全に保存するためにLedger Nanoを使用する場合は，すべてが自動的に処理されます。
しかし，古いウォレットファイルをバックアップから復元するとどうなるでしょうか？またはウォレットファイル無しのウォレットがある場合は？
私たちのウェブウォレットは現在機能しており（ https://wallet.qrlexplorer.info/ ），これはニーモニックフレーズまたはhexseedで開かれます。
（2017/12/20時点で，これはTestnet用のウェブウォレットです。BittrexでトレードされているQRLトークンはERC20トークンでありますので，このウェブウォレットは利用できません。メインネットをお待ちください）
1つのオプションとしては，各セッションの後にユーザーに対してウォレット・インデックス番号を覚えてもらうことを頼むことです。 しかし，これはユーザーが覚えた後で思い出すことに依存するので，問題が発生しやすくなります。 自分のウェブウォレットにアクセスすることがまれである場合，または単にウォレット・インデックスを忘れた場合，システムは失敗します。
しかし私たちは運がいいです。QRLのブロックチェーンは助けてくれます。
すでにチェーン内にあるXMSSインデックスはバーンされたと考えることができます。潜在的に，有効なXMSSインデックスは，まだトランザクションを署名するために使用されていないものです。ウェブウォレットがQRLのネットワークに接続すると，QRLのアドレスのトランザクション履歴をロードし，送信されたトランザクション数を使用して現在のXMSS木インデックスを計算します。
（XMSSの構造上ウォレットファイルは更新され続けなければなりません。それが何らかの破損をしても救助できるということであり，ウォレットのニーモニックフレーズ自体はしっかり保存してください）
ウェブウォレットブラウザのインスタンスとQRLのP2Pネットワーク間で中間者攻撃をしようとする悪意のあるノードによって，ウェブウォレットが欺かれることがあるでしょうか？
ウェブウォレットは，自分のアドレスの履歴にある各トランザクションを簡単に検証できます。悪意のあるノードが行うことができるのは，ウェブウォレットが正しくない誤った低いインデックスで署名するよう混乱させるために，極めて少ないトランザクションを送信させることくらいです。そのインデックス位置でのワンタイム署名がすでにQRLネットワークでブラックリスト化されますので，これは何も達成することができません。悪意のあるノードは，期待より高いインデックスから署名させるようウェブウォレットを欺くトランザクションを偽造することはできません。そうする正当な署名を生成することができないからです。
ここまでは順調ですね。
現在のインデックスから秘密鍵を危険にさらすのに十分な回数署名するよう，ウェブウオレットを欺くため，悪意のあるノードが意図的にトランザクションを伝播できないようにすることは可能でしょうか？
私たちのウェブウォレットは，トランザクションを複数のノードに伝播することによってこの可能性を緩和します。 さらに，別のランダムなノードからメモリプール・ブロック内のtxを見るまで，再びアクティブセッションで再度署名することはありません。
NIST
しばらくの間，プレースホルダーのエフェメラルメッセージルーチンがin-situで実行されました。 私たちのend-endポスト量子セキュア・データ・チャネルは，両端に2つの公開鍵を含むEPHトランザクションによってリンクされています。これを分散格子公開鍵サーバと考えてください。 現在，それらはECC公開鍵であり，一つは署名用でもう一つは暗号化用です。 しかし，NISTがリリース（そう長くない）するとすぐに，私たちは署名用のdilithium鍵と、エフェメラルなトラフィックを格子暗号化するためのkyber鍵を用意します。
（dilithiumの論文：
https://eprint.iacr.org/2017/633.pdf
kyberの論文：
https://eprint.iacr.org/2017/634.pdf
）
お知らせ
今月下旬に発表する新しいメンバー変更と，ロードマップとタイムラインの両方に（とても興奮する）大きな変化があります！
以上，翻訳でした。
（個人的な予想ですが，おそらくお知らせはパブリックテストネットの段階から次の段階へ移行する旨の発表ではないのかなと考えています）
