Symbol では以前に利用可能だった NIS1 の機能のほとんどが進化しました。このドキュメントは以前の NIS1 の機能を、新たに利用可能な Symbol の技術に あなたのアプリケーションをアップグレード する手助けとなるでしょう。
注釈
オプトイン によって、NIS1 資産を Symbol のアカウントへ移行することができます。より詳細は ローンチ後オプトインで XYM を取得する を参照してください。
現時点で Symbol のテストを開始するには、資産を使用しない 2 つの選択肢があります。
パブリックテストネットワーク: パブリックテストネットワークはパブリックメインネットワークと同じテクノロジーと機能を使用しています。テストネットを実験的に使用することで、貴重な資産を失うことなく、トランザクションセットを試すことができます。テストネットを使用するには、次の ガイド に従ってください。
プライベートテストネットワーク: プライベートテストネットネットワークを起動するには、 Symbol Bootstrap パッケージを使用します。このツールは開発と学習目的の構築を、コマンド一つで行うスクリプトが含まれています。
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 にインスパイアされています。
こちらも参照してください:
プロトコル: ノードアーキテクチャ
リファレンス: REST Gateway
Reference: REST API contract
どちらのプラットフォームも Ed25519 というデジタル署名アルゴリズムを使用しますが、ハッシュアルゴリズムが異なります。NIS1 は Keccak-SHA3-512 を使用しますが、 Symbol は TLS をサポートするために SHA-512 に変更されました。
使用されているハッシュアルゴリズムの変更により、同じ秘密鍵でも NIS1 と Symbol では、異なる公開鍵とアドレスが使用されます。
こちらも参照してください:
ガイド: アカウントの作成と開設
ガイド: アカウント情報の取得
NIS1 と Symbol でのトランザクションの シリアライゼーションフォーマットに互換性がありません。それでも、ほとんどの種類のトランザクションは進化しただけで削除されたものはありません。より少ない変更で Symbol トランザクションへのアップグレードが可能であることを意味します。
トランザクションについての最初の注目すべき変更は、ステータスレスポンスが WebSocket チャンネル を通して受信されることです。NIS1 ではクライアントはトランザクションをアナウンスした直後に API 呼び出しの応答を受け取りました。Symbol は呼び出しの応答を非同期に受信し、呼び出しをブロックしません。
それに加え、 Symbol では TransferTransaction は1つのバージョンだけになります。基軸通貨は通常の モザイク としてトランザクションのモザイク配列に追加されるようになりました。
こちらも参照してください:
プロトコル: トランザクションライフサイクル
プロトコル: Serialization schemas
Symbol のトランザクション手数料は動的であり、ネットワーク参加者によって決定されます。各トランザクションの 実効手数料 は 手数料乗数 に トランザクションサイズ を掛けて算出されます。手数料乗数はトランザクションが承認されるブロックに付加され、ブロックをハーベストするノード所有者によって定義されます。
トランザクションの定義中に、送信者はトランザクションをブロックに含めるための最大手数料を制限します。
こちらも参照してください:
プロトコル: トランザクション手数料
モザイク の管理に関してプロトコルレベルで顕著な変更が行われ、いまや ネームスペース から 独立 した存在となりました。
実際に NIS1 ではネームスペースにリンクされたアセットも完全に期限切れとなる可能性があります。 Symbol ではモザイクは代わりにそれ自身の 期間 を持つように設定され、一意な nonce 値が割り当てられます。
最後に、 Levy は Symbol では使用できなくなりました。
こちらも参照してください:
ガイド: モザイク作成
ネームスペースは依然として MosaicAliasTransaction によってモザイクを参照することができます。ネームスペースの所有者はアカウントまたはモザイク ID のいずれかをそのネームスペースのいずれかに添付できます。ネームスペース情報のエンドポイントはエイリアスフィールドにリンクされたオブジェクトを返します。
また Symbol ルートネームスペースには ブロック数で表される 期間 フィールドを持つことで、年間更新が必須ではなくなりました。
モザイクの転送を促進するためにモザイク作成者はネームスペースを登録し、そのネームスペースをモザイクのエイリアスにすることができます。エンドユーザーはモザイクの参照に エイリアスを使用してトランザクションを送信 することができます。
トランザクションがエイリアスを含む場合、 resolution はブロック内のそのエイリアスの解決された値を反映します。エイリアスアドレスやモザイクの背後にある実際の識別子を取得するには、クライアントアプリケーションはトランザクションが含まれるブロックにリンクされている関連の 解決レシート を取得する必要があります。
こちらも参照してください:
ガイド: ネームスペースの登録
ガイド: サブネームスペースの作成
ガイド: ネームスペースをモザイクへリンクする
ガイド: ネームスペースをアドレスへリンクする
チェーン上で管理されたマルチシグネチャアカウントである Symbol のマルチシグネチャ実装は他の多くのいわゆるクライアントサイドのマルチシグネチャ実装とは異なります。
マルチシグアカウント の作成
NIS1 と異なり、アカウントの変更エントリに 最低承認数 と 最低削除数 のフィールドが追加されました。
最小削除数: マルチシグアカウントから署名者を削除するトランザクションをブロードキャストするために必要な署名者の数を定義します。
最小承認数: 他のタイプのトランザクションに必要な署名者の数を定義します。
さらに、マルチシグアカウントに追加される署名者は 署名 (オプトインプロセス)を送信して変更について承認する必要があります。このプロセスを促進するために MultisigAccountModificationTransaction のトランザクションタイプは アグリゲートトランザクション でラップされる必要があります。
マルチシグネチャトランザクションは アグリゲートトランザクション と組み合わせて動作します。
新しい AggregateTransaction は異なる参加者が関わる複数のトランザクションをまとめてラップすることができます。すべての参加者がアグリゲートに共同署名すると、インナートランザクションはアトミックにブロックへ取り込まれます。それ以外の場合にはいずれのトランザクションも承認されません。
NIS1のようにマルチシグトランザクションを送信するには、トランザクションの開始者はそれをアグリゲートのインナートランザクションとして追加する必要があります。次にマルチシグで定義された最小数の署名者が、共有アカウントからのトランザクションのアナウンスを許可するために、アグリゲートに署名しなければなりません。
こちらも参照してください:
ガイド: マルチシグアカウントの作成
ガイド: マルチシグトランザクションの送信
