Lisk開発最新情報 - Core 1.0 メインネットへの道:2018年7月19日更新版

Translate this article into English

2018年5月最新! ▼当サイトで申込みが多い取引所

【1位】「GMOコイン」【10ヶ月連続1位!レバレッジ取引で人気!】

【2位】「bitflyer」【日本最大級取引所・人気No.1】

【3位】「ビットバンク」【セキュリティ対応No.1】

シェアする

Liskコミュニティの皆さん、こんにちは!

先週、Lightcurveの開発チームはLisk Core 1.0.0のメインネットでのリリースに向けて非常に大きな成果を上げました。水曜日に私たちはLisk Hub 1.0.0リリース候補をリリースしました。これはバージョン1.0.0で最初のリリース候補となるもので、Lisk Core 1.0.0のAPIと互換性があります。私たちはまた、多数の取引所と連絡を取り、Lisk Core 1.0.0リリースの進捗状況を伝えました。

さらに私たちはLisk Core 1.0.0のメインネットへの円滑な移行を確実に実施するために必要な多くの先進的手法を採用しました。私たちが取り組んできた多くの改良と変更については以下で詳しくご紹介します。

Lisk Core 1.0.0-rc.2 関連

課題番号#2199:Lisk Core 0.9.16から1.0.0への移行後も、従来のチェーンの方が新たに移行したチェインよりも早くブロック移動します。これは移行後も十分な数のデリゲートが旧いチェイン上で鍛造し続けようとする場合に起こり得ます。

誰かがこのチェーンの上で移行を実施し、このチェインを既に稼働している(より短いチェーンの)バージョン1.0.0のネットワークに公開する可能性もあります。これを防ぐため、私たちはブロック・プロパティ・バージョンを上げることにしました。

またブロックの署名を生成する処理を追加しており、既存のブロック用にブロックバージョン変更できないようにしています。開発者の間で徹底的に議論した結果、私たちは何をブロック・プロパティ・バージョンの要件とするべきかを明確にしました。以下はその議論の結果です。

  • ブロック・プロパティ・バージョンは今後、ブロック構造のどのような変更も識別する重要な識別子となり、ハードフォークが実施されるたびにバージョンが上がります。
  • ブロック・プロパティ・バージョンはソフトウェアを実装する際に利用するプロトコルのバージョンとも直接に結びつきます。
  • ブロックバージョンはプロトコル固有の属性なので、ネットワーク固有の設定に追加すべきではありません。

要件の特定に続いて、私たちは以下のソリューションを実装することにしました。

  • Lisk Core 1.0.0のブロックバージョンを0から1に上げます。
  • このため、1.0.0と今後のリリースではバージョン1のブロックのみ処理できます。
  • その結果、これより前のバージョンのブロックは(正当でありブロックチェーンの一部でもあるが)すべてバージョン0のブロックを含んでいるため、1.0.0のリリースで不正と見なされます。

不正と見なされたブロックの履歴を追跡し、同期処理とスナップショット処理でLisk Core 1.0.0リリースがこのようなブロックを受け入れるようにするため、私たちは以下の手順を取ります。

  • 特定のネットワーク(メインネットとテストネット)ではバージョン0のブロックを例外的に認めます。
  • この例外処理は、バージョン0のどのブロック高さ(最初のブロックから数えて何番目か)までが正当で受け入れられるものかをソフトウェアに通知します。
  • このブロック高さは実際の移行でのブロック高さと同じになります。
  • ブロック・プロパティ・バージョンの変更は双方のネットワークに対するハードフォークと見なされます。

課題番号#2154:P2Pレイヤーに対するSSLサポートを無効にすることについての課題は、前回の開発最新情報で既にお伝えしています。しかし、SSLオプションを有効にするノードオペレーターがこの課題を回避するのに役立つよう、私たちはこの課題をLisk Core 1.0.0バージョンに含めることが重要だと認識しました。

課題番号#2226:ノードでの鍛造を有効あるいは無効にするガイドラインを含めるようドキュメントを更新しました。

課題番号#2227:設定の移行時に設定データベースのユーザ名に空文字列が設定されることがあることに気付きました。データベースのユーザ名が空の場合はデフォルトのユーザ名として「lisk」を設定することでこの問題を解消しました。

課題番号#2208:移行スクリプトはこれまで、ユーザがデリゲートパスフレーズの暗号化に使用したパスワードを設定ファイル(config.json)のdefaultPasswordに保存していました。

この機能は暗号化されたパスフレーズの仕組み全体を損ねるので、開発目的でのみ使用でき、製品版では利用できません。そのため移行時にパスワードが設定ファイルに保存されることはもはやありません。

Lisk Core 1.1.0 関連

課題番号#1992:追加あるいは削除されたピアに関するロギングは、ピアのログレベルが各々異なっていたため、一貫性がありませんでした。私たちはピアに関連するログレベルを同じにすることでこの問題を修正しました。

課題番号#2148:標準が無いためログはテキスト形式で出力していました。このためログ解析処理を自動化することが困難でした。そこで私たちはロギングの仕組みを書き直し、ログを保存する新たな方法を導入することにしました。

  • コンソール出力は可読性を考慮してテキスト形式で保存します。
  • ファイルに保存されるログはJSON形式で保存され、特定のログの検索やデバッグ用の情報収集、そしてログ解析自動化ツールの利用が簡単にできるようにしています。ログのエントリーは例えば以下のようになります。

{
“name”:”logs/lisk.log”,
“hostname”:”my.local”,
“pid”:48673,
“module”:”peers”,
“level”:20,
“msg”:”Broadhash consensus: 0 %”,
“time”:”2018–06–29T09:48:13.966Z”,
“src”:{
“file”:”/lisk/modules/peers.js”,
“line”:879,
“func”:”calculateConsensus”
},
“v”:0
}

  • 最適な検索性を持たせるため標準的な形式と検索キーを利用します。

ロギング形式を変更することで、ログを扱うツールは互換性を失うことになります。

次の段階

開発フェーズとしてはLisk Core 1.0.0-rc.2の準備が整ったので、次はもっとも重要なQA(品質保証)フェーズに移ります。今回の移行は前回の1.0.0-rc.1リリースと同じやり方でテストすることになっています。

上で述べたブロックバージョンの変更により、1.0.0-rc.2のテストネットリリースはハードフォークとなる予定です。リリース日は今回のリリースのQAが完了した時点で発表されます。メインネットへの移行プロセスは当初の計画通りに進んでいます。

1.1.0リリースに向けた最初のQAは成功裏に終了しました。しかし私たちはバージョン1.1.0と1.2.0の間に発生した課題の振り分けを調整することにしました。Lisk Core 1.2.0で解決済みの課題は1.1.0のブランチにマージされ、リリースとテストが同時に行われます。GitHubでの1.1.0と1.2.0のプロジェクトの現在の分け方は、どの課題がどのリリースに含まれるのかを明確にしてくれます。1.2.0リリースのQAについては、影響の大きな設定ファイルの変更が完了した後、lisk-buildとlisk-scriptの課題が解決するまで待つことにしています。

来週の更新を楽しみにしています!

いつもご支援いただきありがとうございます!

– Liskチーム

Lisk(リスク)とは?基本情報 Lisk(リスク)は、分散型アプリケーションプラットフォームであり、その中で利用可能な仮想通貨が...

Development Update — Road to Core 1.0 Mainnet: July 19, 2018