近々アクティベートされる予定の Waves-NG について簡単に書きたいと思います。（12月1日付）
NG はそもそも Bitcoin で提案されたスケーラビリティのボトルネックに対処できるとされるプロトコルでした。
皆さんもご存知の通り Bitcoin は10分に1 MB 以上のトランザクションでネットワークが氾濫してしまいます。
このスケーラビリティを解決するためにオンチェーン（レイヤ1）での方法が議論そして提案されてきました。
具体的にはブロックサイズの引き上げや，そのスケジューリング調整があげられます。
しかし，分散型アルゴリズムの性質上，ブロックサイズを拡大させたりブロックの作成間隔を短くするとフォークがより発生しやすくなります。
フォークはブロックチェーンのブランチが剪定（プルーニング）された際に起こるものです。
プルーニングされたブロックを作成したマイニングパワーはネットワーク全体のセキュリティに関与しません。
したがって多くのブロックがプルーニングされた（フォークが多く発生した）場合，51%攻撃を以前より容易に行う事が出来ます。
さらに，ネットワークにうまく接続されていない小規模マイナーは，大きなプールに合流するインセンティブが増え，それによって集中化が引き起こされます。
同様の現象を wavesplatform でも確認する事ができます。（約30％のハッシュレートを持つ WavesGO のマイニングパフォーマンスは期待値以上です。）
セキュリティの見地外でも肥大化したブロックチェーンを伝播するノードのリソースの問題等が存在しており，伴うボトルネックは既存の決済システムに到底対抗できるものではありません。
結果として，ユーザ・マイナー・開発者の間で統一した”ビットコインとしてのコンセンサス”をとるのはかなり難しく，オンチェーンスケ―リングは容易には実現しませんでした。
そんな中 Bitcoin-NG はスケーラビリティの制限を排除するプロトコルとして提案されました。
トランザクションのスループットが向上し，待ち時間も短縮されます。
Bitcoin のマイナーが行っている事を簡単に説明すると，memorypool に一時保存されたトランザクションを
秘密鍵の所有者からのブロードキャストである事を検証し，任意のトランザクションのハッシュ等を含めて，求められた難易度に基づくハッシュ値になるようなナンスを割り出しています。
同じ様な検証作業をマイナーやノードは行っているので，十分に検証されていないトランザクションが含まれている場合はプルーニングされ，別のブロックが伸長されます。
つまり，Bitcoin では，既に時間をかけて検証している（正当性があり確実性のある）トランザクションからブロックを生成している事がわかります。
これに対して NG プロトコル（以下 NG）は異なるアプローチをとっています。
NG はまず，キーブロックと呼ばれる一定の間隔で作成されるブロックをマイニングしたマイナーをエポックリーダーに選びます。
リーダーは次のリーダーが選ばれるまで（次のキーブロックが作成されるまで）トランザクションをマイクロブロックにシリアライズしていきます。
このマイクロブロックは Proof-of-Work によってではなく，リーダーの秘密鍵でミリ秒単位で署名されていきます。
簡単に言うとキーブロックをマイニングしたマイナーは，改ざんする余地のないマイクロブロックの作成権を取得するという事です。
従ってブロック生成に成功したとき，ヘッダのみをパブリッシュする SPV マイニングが行えます。
万が一，マイクロブロックの伝播が何かしらの理由で揺らいだ場合はキーブロックが新しく生成されてリーダーが選ばれます。
検証されていないトランザクションを含んで署名されたマイクロブロックが伝播された場合，以降のマイクロブロックの作成は次のキーブロック作成者に引き継がれます。
マイクロブロックによってネットワークに取り込まれたトランザクションの手数料は，署名したリーダー
自身と次に選ばれるリーダーによって4:6の割合で分配されます。
この比率は前述したオンチェーンスケジューリングの原始的な問題点に由来したものです。
4:6の比率では自分が生成したブロックを直ぐに報告せず，そのハッシュを含んだ次のブロックの生成を始めるセルフィッシュマイニングでは採算が取れません。
そしてキーブロックを作成してエポックリーダーとなったマイナーが，直前のマイクロブロック参照して次のマイクロブロックを作成しないインセンティブがありません。
ここまでで，オンチェーンでスループットの向上とレイテンシの短縮が実現でき，数秒でトランザクションが確認される NG は，小規模マイナーに公平さをもたらす事で集中化の動機づけを減らし，フォークの低減とセキュリティの強化を行う素晴らしいプロトコルだとわかりました。
しかしながら，いくつかの問題点も存在します。
問題点1: パブリッシュする情報が多い
ノードの負担が増加します。
問題点2: 悪意を持ったマイナーが存在する場合
マイナーによる二重支払いはネットワークに遅延という深刻なダメージがもたらされます。
問題点3: 比率4:6を変更できる事を前提として，変更するインセンティブが発生した場合
ユーザがマイナーに直接手数料を支払えば比率が100:0になり，それに伴ういくつかの問題が浮上します。
以上を踏まえて，wavesplatform でアクティベートされる予定の Waves-NG の詳細を見ていきましょう。
前提として wavesplatform ではブロックサイズの引き上げや，ブロック作成インターバルの短縮を（2,3パラで）上述した理由と同様の理由で否定しています。
それに対しての解決策として Waves-NG は用意されました。
wavesplatorm では連続的に増加するキーブロックとマイクロブロックのチェーンで構成されたブロックを液体ブロックと定義しています。
マイナーは定期的に空のキーブロックを作成し，次のキーブロックが作成されるまで3秒毎にマイクロブロックを作成してパブリッシュします。
マイクロブロックには，作成者のパブリックキー・トランザクションデータ・直前のブロックID（署名）・トランザクションデータのすべてのハッシュと直前のブロックIDを含むID（署名）・2進数からテキスト形式に変更されたID（署名）が含まれています。
トランザクションを盗む行為の収益性は4:6の比率によって低いものとなっています。
そして手数料の設定など，ネットワークに悪影響を及ぼさない範囲でマイナーが調整できるパラメータが用意されています。
さて，Bitcoin-NG と Waves-NG に大きなプロトコルとしての変更は見受けられませんでした。
ここからは Bitcoin-NG で挙げられていた問題点を個人的に検証してみます。
まず問題点1に関してです。
2017年12月1日現在確認できるノードの数は206台，その内10000枚以上（現在は1000枚）保有またはリースされマイニングが許可されているノードは71台となっています。
API によって独自のノードを持つ必要性は低く，1つのノードしか参照しない公式の waves-lite-client が普及しているので，ノードの数は多いとは言えません。
wavesplatform ではリースと呼ばれる「コインの貸し付け」を行う事ができ，基本的に多くの貸し手が集まるノードを参照すれば正しい情報を受け取る事ができます。
WavesGo は世界1のリース高を誇るノードであり，ブロックチェーンエクスプローラを運営しています。
ユーザはいつでもワンクリックでWAVESをそのノードから引き上げることができるので，大規模な貸し付けを受けているノードが悪意のある行動をとれば信用は失墜します。
逆にマイニングが許可されていないノードを参照する方がリスクとなっているのが現状です。
基本的にマイナーや開発者以外ノードを運営する必要性がなく，リソースを食いつぶすために負担が多くなって集中化が云々という議論はナンセンスだと思います。
次に問題点2に関してです。
前述の通り wavesplatform のリースによって，ユーザが合理的な選択をする場合に限り，ノード（プール）の規模は簡単に変動します。
Proof-of-Sake アルゴリズムでプラットフォームを維持する際の通説である，「コインを持ってる人は悪意ある行動をとってプラットフォーム全体の価値を下げる事はしない」がもろに当てはまるのが wavesplatform です。
ユーザにとって最善といえる行動をとることで，ノード運営者自身の利益を上げることにつながります。
例えば wavesnode.net では WNET を分配しており，それを用いて様々なサービスを受けることができます。
リース機能によって例え10,000枚保有しているユーザでも独自のプールを運営するインセンティブは収益率の観点からはありません。
そもそもそのような仕組みのため，ユーザが誤った判断をしてリースの集中化が起きない限り，マイニングノードの数は現状のままで問題ないと思います。
最後に問題点3に関してです。
PoS 通貨だからこそ度外視できるのではないかなと思います。
もしこのような事態が発生したら（発生できるのだとしたら）wavesplatform はその価値を下げ，プラットフォームの利用者が減るのではないでしょうか。
通常トランザクションの利用者はもちろんですが，DEX ユーザにとっても Waves-NG を妨害するメリットはなく，価値保存として機能していないWAVESでそれを行うインセンティブは限りなく低いと考えています。
起こったらその時はその時で考えればよいのではないでしょうか。
参考文献
https://github.com/wavesplatform/Waves/wiki/Waves-NG-Protocol
http://arxiv.org/abs/1510.02037
http://hackingdistributed.com/2015/10/14/bitcoin-ng/
https://www.slideshare.net/JyouMiyamoto/7-bitcoin-ng