Repository navigation
必ず入れ替えるもの
- ノード: catapult 1.0.3.10 のフォーク（
strictVrfPublicKeyCheck）に合わせた。この高さから、点に戻せない VRF の公開鍵による証明を通さない。メインネットは高さ 5,952,255、テストネットは 3,888,648 から。それより前のブロックは今までどおりに確かめる- この高さより前に入れ替えないと、そこで catapult と分かれる
- メインネットとテストネットの高さは heika に入っているので、設定ファイルはそのままでよい。自分で作ったネットワークは、
config-network.propertiesの[fork_heights]にstrictVrfPublicKeyCheckを書いたときだけ効く。書かなければ、今までどおりフォークしない
設定と DB の中身は変わっていないので、バイナリを入れ替えるだけでよい。
変わったもの
- CLI: ノードのコマンドを
heika peer start、heika peer copy、heika nemgenにした。「試験的」の扱いも外した。前のheika experimental …も、隠した別名としてそのまま動く - README の頭を「Symbol のノードを、アプリの部品にする」に書き直した
直したもの
- heika-chain: ハーベストの見込み（
heika_chain::outlook）で、ハーベストしている Importance の合計を小さく見積もっていた。ブロックが整数秒に作られることを考えて見積もり直す。ブロックの目標が 30 秒のネットワークで 5% ほど、5 秒で 3 割ほど小さかった
増えたもの
- ノード: REST に、catapult と同じ次のものを足した
GET /node/timeGET /finalization/proof/epoch/{epoch}。heika の REST だけのネットワークでも、ブラウザのノードが確定まで同期できる
- 例: ブラウザのノード（
examples/node-web）で、設定ファイルと Nemesis のハッシュを入れて、自分のネットワークも同期できる
heika-v… はコマンドラインツール、heika-gui-v… はウォレットの GUI。確かめ方と、署名していないものの入れ方は README の「インストール」にある。
- どのファイルも
SHA256SUMSと、gh attestation verify <ファイル> --repo <このリポジトリ>で確かめられる - CLI のコンテナイメージ（linux/amd64、linux/arm64）は
ghcr.io/hinablogchannel/heika:<この版>にある。gh attestation verify oci://ghcr.io/hinablogchannel/heika:<この版> --repo <このリポジトリ>で確かめられる - APK の署名の証明書の SHA-256 は
79b38fb9557cf0249f75aadf806805f3e5b4f6b196a69b6f986c075cdb64c5ad（apksigner verify --print-certsで見られる） - macOS の dmg は公証を受けておらず、Windows のインストーラーは署名していない
- iOS の IPA は署名していない。自分で署名し直さないと入らない
Full Changelog: v0.15.0...v0.16.0