NIS1 から Symbol へのマイグレーション

Symbol では以前に利用可能だった NIS1 の機能のほとんどが進化しました。このドキュメントは以前の NIS1 の機能を、新たに利用可能な Symbol の技術に あなたのアプリケーションをアップグレード する手助けになるでしょう。

注釈

あなたの NIS1 資産を Symbol へ移行する方法は Symbol オプトインガイド <https://nemplatform.com/symbol-migration/#acc-tb_mrzh282-5> を参照してください。

NIS1 と Symbol の比較
NEM NIS1 Symbol
ビルドイン機能  
モザイク モザイク
ネームスペース ネームスペース
デリゲートハーベスティング デリゲートハーベスティング
マルチシグアカウント マルチレベルマルチシグアカウント
モザイク制限 応用モザイク制限
アカウント制限
メタデータコントロール
アグリゲートトランザクション
インフレーション
クロスチェーンスワップ
プラグイン
プロトコル  
Java 製 C++ 製
POI (Proof of Importance) POS+ (Proof of Stake Plus)
Keccak-SHA3-512 SHA-512
固定手数料 変動手数料
レシート
マークル証明

テストネットワーク

現時点で Symbol のテストを開始するには、資産を使用しない 2 つの選択肢があります。

  • パブリックテストネットワーク: パブリックテストネットワークはパブリックメインネットワークと同じテクノロジーと機能を使用しています。テストネットを実験的に使用することで、貴重な資産を失うことなく、トランザクションセットを試すことができます。テストネットを使用するには、次の ガイド に従ってください。
  • プライベートテストネットワーク: プライベートテストネットネットワークを起動するには、 Symbol Bootstrap パッケージを使用します。このツールは開発と学習目的の構築を、コマンド一つで行うスクリプトが含まれています。

旧 API の非互換性

NIS1 ネットワークで動作していた旧 API 呼び出しは Symbol とは 非互換 です。REST API ノードのポート 3000 番を用いて API リクエストを行います。

いくつかの ソフトウェア開発キット - 開発中の Symbol 分散型レッジャー用コンシューマアプリケーション - があります。現在 計画中の SDK は Typescript / Javascript / NodeJS, Java, C#, Go, Python, Swift で書かれています。

はじめに TS/JS SDK を見てみることを推奨します。最も使用されている SDK であり documentation の先頭にあります。TS SDK のアーキテクチャは NIS1 向け NEM Library にインスパイアされています。

こちらも参照してください:

アカウントの管理

どちらのプラットフォームも Ed25519 というデジタル署名アルゴリズムを使用しますが、ハッシュアルゴリズムが異なります。NIS1 は Keccak-SHA3-512 を使用しますが、 Symbol は TLS をサポートするために SHA-512 に変更されました。

使用されているハッシュアルゴリズムの変更により、同じ秘密鍵でも NIS1 と Symbol では、異なる公開鍵とアドレスが使用されます。

こちらも参照してください:

旧トランザクション

NIS1 と Symbol でのトランザクションの シリアライゼーションフォーマットに互換性がありません。それでも、ほとんどの種類のトランザクションは進化し​​ただけで削除されたものはありません。より少ない変更で Symbol トランザクションへのアップグレードが可能であることを意味します。

トランザクションについての最初の注目すべき変更は、ステータスレスポンスが WebSocket チャンネル を通して受信されることです。NIS1 ではクライアントはトランザクションをアナウンスした直後に API 呼び出しの応答を受け取りました。Symbol は呼び出しの応答を非同期に受信し、呼び出しをブロックしません。

それに加え、 Symbol では TransferTransaction は1つのバージョンだけになります。基軸通貨は通常の モザイク としてトランザクションのモザイク配列に追加されるようになりました。

こちらも参照してください:

トランザクション手数料

Symbol のトランザクション手数料は動的であり、ネットワーク参加者によって決定されます。各トランザクションの 実効手数料手数料乗数トランザクションサイズ を掛けて算出されます。手数料乗数はトランザクションが承認されるブロックに付加され、ブロックをハーベストするノード所有者によって定義されます。

トランザクションの定義中に、送信者はトランザクションをブロックに含めるための最大手数料を制限します。

こちらも参照してください:

モザイク

モザイク の管理に関してプロトコルレベルで顕著な変更が行われ、いまや ネームスペース から 独立 した存在となりました。

実際に NIS1 ではネームスペースにリンクされたアセットも完全に期限切れとなる可能性があります。 Symbol ではモザイクは代わりにそれ自身の 期間 を持つように設定され、一意な nonce 値が割り当てられます。

最後に、 Levy は Symbol では使用できなくなりました。

こちらも参照してください:

ネームスペース

ネームスペースは依然として AliasTransactions によってモザイクを参照することができます。ネームスペースの所有者はアカウントまたはモザイク ID のいずれかをそのネームスペースのいずれかに添付できます。ネームスペース情報のエンドポイントはエイリアスフィールドにリンクされたオブジェクトを返します。

また Symbol ルートネームスペースには ブロック数で表される 期間 フィールドを持つことで、年間更新が必須ではなくなりました。

モザイクの転送を促進するためにモザイク作成者はネームスペースを登録し、そのネームスペースをモザイクのエイリアスにすることができます。エンドユーザーはモザイクの参照に エイリアスを使用してトランザクションを送信 することができます。

トランザクションがエイリアスを含む場合、 resolution はブロック内のそのエイリアスの解決された値を反映します。エイリアスアドレスやモザイクの背後にある実際の識別子を取得するには、クライアントアプリケーションはトランザクションが含まれるブロックにリンクされている関連の 解決レシート を取得する必要があります。

こちらも参照してください:

マルチシグネチャの管理

チェーン上で管理されたマルチシグネチャアカウントである Symbol のマルチシグネチャ実装は他の多くのいわゆるクライアントサイドのマルチシグネチャ実装とは異なります。

  1. マルチシグアカウント の作成

NIS1 と異なり、アカウントの変更エントリに 最低承認数最低削除数 のフィールドが追加されました。

  • 最小削除数: マルチシグアカウントから署名者を削除するトランザクションをブロードキャストするために必要な署名者の数を定義します。
  • 最小承認数: 他のタイプのトランザクションに必要な署名者の数を定義します。

さらに、マルチシグアカウントに追加される署名者は 署名 (オプトインプロセス)を送信して変更について承認する必要があります。このプロセスを促進するために ModifyMultisigAccount のトランザクションタイプは MultisigAccountModificationTransaction でラップされる必要があります。

  1. マルチシグネチャトランザクションは アグリゲートトランザクション と組み合わせて動作します。

新しい AggregateTransaction は異なる参加者が関わる複数のトランザクションをまとめてラップすることができます。すべての参加者がアグリゲートに共同署名すると、インナートランザクションはアトミックにブロックへ取り込まれます。それ以外の場合にはいずれのトランザクションも承認されません。

NIS1のようにマルチシグトランザクションを送信するには、トランザクションの開始者はそれをアグリゲートのインナートランザクションとして追加する必要があります。次にマルチシグで定義された最小数の署名者が、共有アカウントからのトランザクションのアナウンスを許可するために、アグリゲートに署名しなければなりません。

こちらも参照してください: