nem1からnem2で変わった、主な仕様の変更点を紹介します。
nem1では、foo.barのような3階層までのネームスペースを取得し、それぞれのネームスペース配下にbazというモザイクをfoo.bar:bazとして定義することができました。
nem2では、ネームスペースは、アドレスまたはモザイクに対してのエイリアスとして機能するようになります。
モザイクはネームスペース配下にではなく、独立して存在することとなり、16進数のMosaicIdが割り当てられます。
ゆえにモザイクの作成だけではfoo.bar:bazのような名前を持たないことになります。
このモザイクに対してネームスペースをリンクすることで、foo.barという名前でモザイクを特定できるようになります。
IPアドレスに対してドメイン名を割り当てるようなイメージです。
この変更はネームスペースとモザイクの命名などに影響があるため、旧仕様に則ったシステムを構築している場合は、仕様を大きく変更しないといけない可能性があります。
具体的には、ネームスペースが最大3階層という制限は同等ですが、その下にモザイクが作れなくなります。
foo.bar.baz:quxというモザイクを使っていた場合は、変わりにfoo.bar.baz-quxのようなネームスペースでリンクさせるなど、アプリケーションの仕様を変える必要があります。
無期限のモザイクを定義する仕様のために、これまでのようにネームスペース期限=モザイク期限という仕様では都合が悪くなったものと思われます。
ネームスペースの期限が切れても、無期限のモザイクは失われないので、その点でもサービス側の仕様変更の検討が必要かもしれません。
nem1では、モザイクとxemは区別され、アカウントの残高にはamountとしてxemの残高が表現されていました。
nem2では、そのような表現がなくなり、全てモザイクで表現されるようになりました。
nem1でもxemをモザイクとして保有を表現していたり、モザイクとして送受信できますが、その方式だけに統一されました。
nem1では、トランザクションの結果レスポンスは同期的だったので、結果はリクエストと対になっていました。
nem2では、リクエストがAPIサーバに届いたかどうかのレスポンスしか返さず、内容は常にOKを返却します。
モニタリングで実施したように、WebSocketで状態チャンネルに接続し、流れてくる結果で取得する必要があります。
この仕様変更の解決に関してnem2-camelという同期的にレスポンスを返す中間サーバのプロジェクトがあります。
nem1ではマルチシグ連署アカウントとして追加する場合、連署アカウントとして追加される側のアカウントでは特に操作が必要ありませんでした。
nem2では連署者として追加するアカウントへ、その参加承認を求める署名トランザクションの発信が要求されます。
また、アグリゲートボンドトランザクションによる操作が必要なので、マルチシグアカウントへ変換したいアカウントに、
最低でも10 cat.currencyと転送手数料が必要です。
連署者候補として追加した全員の署名トランザクションが承認されるまではマルチシグアカウントへの変換が進まないようになっています。
これはnem1で発生する、意図しない・間違った公開鍵を連署者として追加してしまい、資産が動かせなくなる問題を回避することができます。
構築したシステム仕様にこの挙動の違いが影響を及ぼす場合は確認してみてください。
マルチシグ変換トランザクションにはminRemovableDeltaという値の指定があります。
これは、連署者を削除する際に必要な署名数を示します。
nem1では最小連署者数しかなかったため、1-of-2構成で連署者数が1だと、どちらかのアカウントが一方を連署者から外すことができてしまいました。
nem2ではこのオプションにより、1-of-2でも相手方に署名が必要な状態を作り出せます。
連署者と同じ数にすることで、削除される当人を含め、全員一致してから削除することができます。
(例： 連署者数が2名として、最小削除承認者数に2を指定する)
従来のような、マルチシグアカウントの所有権移転のケースでは1を指定すれば良いでしょう。
アカウントがトランザクションに署名する際のsignメソッドの第二引数に初期ブロックハッシュを渡す必要があります。
GenerationHashにはhttp://localhost:3000/block/1で表示されるgenerationHashを使用してください。