速習Symbolブロックチェーン9章、マルチシグ化編です。

URLとしてはこちら。

それではやっていきます。

実践編

注意事項に1つのマルチシグアカウントに登録できる連署者の数は25となります。つまり、1つの子アカウントに対し、親になれるのは25ということなんでしょう。

また、最大3階層までとのことです。

この値については、apiノードの/network/propertiesにアクセスすると、確認できます。

こういう値はおそらく、ハードフォークすることで変更できる値なんでしょう。

9.0 アカウントの準備

マルチシグを構成するためのアカウントを用意します。

var takashi = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(takashiPrivateKey), sym.NetworkTypeEnum.testnet);

var carol1 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol1PrivateKey), sym.NetworkTypeEnum.testnet);
var carol2 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol2PrivateKey), sym.NetworkTypeEnum.testnet);
var carol3 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol3PrivateKey), sym.NetworkTypeEnum.testnet);
var carol4 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol4PrivateKey), sym.NetworkTypeEnum.testnet);
var carol5 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol5PrivateKey), sym.NetworkTypeEnum.testnet);

print("takashi: ${takashi.address.toString()}");
print("carol1: ${carol1.address.toString()}");
print("carol2: ${carol2.address.toString()}");
print("carol3: ${carol3.address.toString()}");
print("carol4: ${carol4.address.toString()}");
print("carol5: ${carol5.address.toString()}");

こんな感じで。速習Symbolではbobとcarol1-5でやっていました。

秘密鍵をランダムでやると(1日で終わるとは限らない僕のペースでは)困ってしまうので、定数化しています。

過去の分も似たような形でやっていたため、名前の重複すると(自分で)混乱する可能性が高いため、bobの代わりにtakashiとしました。よろしくtakashi。

9.1 マルチシグの登録

説明の通り、Symbolのマルチシグアカウントは新規で生まれるわけではなく、既存のアカウントを利用します。つまり、先ほどのtakashiをそのままマルチシグにするような感じです。

var takashi = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(takashiPrivateKey), sym.NetworkTypeEnum.testnet);

var carol1 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol1PrivateKey), sym.NetworkTypeEnum.testnet);
var carol2 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol2PrivateKey), sym.NetworkTypeEnum.testnet);          
var carol3 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol3PrivateKey), sym.NetworkTypeEnum.testnet);          
var carol4 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol4PrivateKey), sym.NetworkTypeEnum.testnet);          

// マルチシグの追加アカウントたち。
var cosigners = [carol1, carol2, carol3, carol4];

// マルチシグの追加アカウントたち(アドレス)
var cosignersAddr = List.generate(cosigners.length, (index) => cosigners[index].address);

// 速習では承認/除名で必要な署名者数が同数となっているが、値の判別のため、それぞれを別とする。
// また、(元SDKの引数順を見ていないが)速習では承認、除名という引数順であった。
// 理由は不明だが自作では除名、承認となっている。
var multisigTx = sym.MultisigAccountModificationInfoV1.create(
  takashi.publicAccount,
  Int8(2),    // 除名のために必要な最小署名者数増分
  Int8(3),    // 承認のために必要な最小署名者数増分
  cosignersAddr,  // 追加アドレス。
  []
);

// Transaction設定を行う。  
var transSetting = sym.TransactionSetting(
  signer: takashi, // マルチシグ化したいアカウント(発行者)
  generationHash: generationHashSeed, 
  networkType: sym.NetworkTypeEnum.testnet, 
  deadline: sym.Deadline.create(epochAdjustment),
  fee:sym.FeeMultiplier(100),
  cosignatoriesQ: cosigners.length);     // 手数料は100%。

// トランザクションの通知。アグリゲートである必要があるらしい。         
var transactionSender = TransactionSender();

await transactionSender.sendAggregateComplete(transSetting, [multisigTx], cosigners);

MultisigAccountModificationInfoV1を作っているところで、ちょっと変更している部分はありますが、速習と同じ感じかなと思います。

なお、アグリゲートコンプリートトランザクションで実行しています。

長くなってしまいましたが承認されました。

9.2 確認

takashiがマルチシグ化されているのか？　を確認するようです。

同様にcarol1から見て、takashiが子となっているかを確認します。

// アドレスを取得するため、takashiとcarol1を生成する。
var takashi = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(takashiPrivateKey), sym.NetworkTypeEnum.testnet);

var carol1 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol1PrivateKey), sym.NetworkTypeEnum.testnet);


// 使用するネットワークホストの取得と、RestAPIのアクセス用クラスをインスタンス化。
var networkHostInfo = await TransactionSender.getNetworkHost();

// マルチシグ情報を取得する。
var httpMultisig = sym.MultisigRoutesHttp(networkHostInfo.networkHost);


print("マルチシグ化したアカウントの確認(takashi)");

print((await httpMultisig.getMultisigInformation(takashi.address)).baseMap.toString());

print("連署者アカウントの確認");

print((await httpMultisig.getMultisigInformation(carol1.address)).baseMap.toString());

マルチシグ化したアカウントの確認(takashi)

takashi側でマルチシグ化されているのが確認できます。

minApprovalが3、minRemovalが2と、先ほどの設定どおりです。

cosignatoryAddressesにはcarol1-4が(おそらく)並んでいます。

multisigAddressesは自分が親となる、子どものアドレスが設定されるようです。takashiは誰の親でもないため、空となっているのが確認できます。

連署者アカウントの確認

こちらはcarol1で確認しています。こちらはマルチシグアカウントではないため、minApprovalおよびminRemovalは0となっています。同様に親が存在しないため、cosignatoryAddressesは空になります。

子どもとなるtakashiのアドレスがmultisigAddressesに登録されています。

9.3 マルチシグ署名

マルチシグ化されたアカウントは自身でやるのではなく、親アカウントが操作する必要があります。

そのため、この先の例ではtakashiのアカウントから送信するが、実際にそのトリガとしてアクションを起こすのはcarol1となっています。

アグリゲートコンプリートトランザクションで送信

アグリゲートコンプリートトランザクションで実行するコードは以下。

// 必要アカウントを作成する。
var takashi = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(takashiPrivateKey), sym.NetworkTypeEnum.testnet);
var carol1 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol1PrivateKey), sym.NetworkTypeEnum.testnet);
var carol2 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol2PrivateKey), sym.NetworkTypeEnum.testnet);
var carol3 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol3PrivateKey), sym.NetworkTypeEnum.testnet);

// carol1は起案者になるため、連署はcarol2、carol3のみ。
// (takashiのminApprovalが3のため、3名が署名すれば、連署は成立する)
var cosigners = [carol2, carol3];

// aliceが送信を受ける。
var alice = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(alicePrivateKey), sym.NetworkTypeEnum.testnet);

// 転送トランザクション作成。
var transTx = sym.TransferInfoV1.create(
  takashi.publicAccount,      // 実行する(送信元)アカウントをtakashiとする。
  alice.address,
  [sym.Mosaic(id: sym.NamespaceId("symbol.xym").getUnresolvedMosaicId(), amount: sym.Amount(1000000))],
  sym.PlainMessage.create('konichiha!!'),
);

// Transaction設定を行う。
// 署名者はcarol1。takashiのアカウントから送信するが、takashiは子のため、自身で起案を行わない。
var transSetting = sym.TransactionSetting(
  signer: carol1,
  generationHash: generationHashSeed, 
  networkType: sym.NetworkTypeEnum.testnet, 
  deadline: sym.Deadline.create(epochAdjustment),
  fee:sym.FeeMultiplier(100),
  cosignatoriesQ: cosigners.length);     // 手数料は100%。

// トランザクションの通知。
print('アグリゲートコンプリートトランザクションで送信');
var transactionSender = TransactionSender();

await transactionSender.sendAggregateComplete(transSetting, [transTx], cosigners);

僕の作り上、 transactionSender.sendAggregateComplete()でアグリゲートコンプリートトランザクション実行後、承認を待って承認内容を出力しています。

アグリゲートトランザクション内にて、実際の転送トランザクション部分は以下。

ウォレットで確認すると下記の形。

takashiのアドレスは末尾HDY。carol1のアドレスは末尾JBI。

署名者(Signer起案者)はcarol1となっているが、トランザクション詳細の送信者は末尾HDYのtakashiとなっています。

takashiの署名は関係なく、carol1がtakashiのトークンを転送できたことが確認できます。

アグリゲートボンデッドトランザクションで送信

takashiの親アカウントの連署を集めるのに、全員がトランザクションに即時署名ができるとは限らないため、アグリゲートボンデッドトランザクションでも実行可能となっています。

ちょっと冗長ではありますが、takashiがaliceに転送トランザクションを実行するアグリゲートボンデッドトランザクションをcarol1が起案として実行します。

なお、過去のアグリゲートボンデッドトランザクションの連署と同じく、トランザクションハッシュをチェーンから取得してきて、carol2、carol3が連署するようにします。

アグリゲートボンデッドトランザクションを通知してから、30秒待機しているので、ちょっと長いですね。

// 必要アカウントを作成する。
var takashi = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(takashiPrivateKey), sym.NetworkTypeEnum.testnet);
var carol1 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol1PrivateKey), sym.NetworkTypeEnum.testnet);

// aliceが送信を受ける。
var alice = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(alicePrivateKey), sym.NetworkTypeEnum.testnet);

// 転送トランザクション作成。
var transTx = sym.TransferInfoV1.create(
  takashi.publicAccount,      // 実行する(送信元)アカウントをtakashiとする。
  alice.address,
  [sym.Mosaic(id: sym.NamespaceId("symbol.xym").getUnresolvedMosaicId(), amount: sym.Amount(1000000))],
  sym.PlainMessage.create('zuttomo dayo!!'),
);

// Transaction設定を行う。
// 署名者はcarol1。carol1以外の連署者が署名すればよいため、連署者数はcarol2,carol3の2が必要。
var transSetting = sym.TransactionSetting(
  signer: carol1,
  generationHash: generationHashSeed, 
  networkType: sym.NetworkTypeEnum.testnet, 
  deadline: sym.Deadline.create(epochAdjustment),
  fee:sym.FeeMultiplier(100),
  cosignatoriesQ: 2);     // 手数料は100%。

// トランザクションの通知。
print('アグリゲートボンデッドトランザクションで送信');
var transactionSender = TransactionSender();

var transHash = await transactionSender.sendAggregateBonded(transSetting, [transTx]);


// ここから連署を行う。
var carol2 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol2PrivateKey), sym.NetworkTypeEnum.testnet);
var carol3 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol3PrivateKey), sym.NetworkTypeEnum.testnet);

var cosigners = [carol2, carol3];

var networkHostInfo = await TransactionSender.getNetworkHost();

var transHttp = sym.TransactionRoutesHttp(networkHostInfo.networkHost);

var transInfo = await transHttp.getPartialInformation(transHash.value);

transInfo as sym.TransactionInfoDTO;

var aggTrans = transInfo.transaction;

aggTrans as sym.AggregateTransactionDTO;

print('署名対象ハッシュ');
print(transInfo.meta.hash.value);

print("連署を行う");
for (var element in cosigners) {
  
  var signature = await element.sign(transInfo.meta.hash.serialize());

  var cosignature = sym.DetachedCosignature(element.publicKey, signature, transInfo.meta.hash);

  await transHttp.announceCosignature(cosignature);
}

実行結果は以下の通り。

連署関係は過去の章と同じ処理で。

ウォレットで確認すると同様にトランザクションが承認されていることが確認できました。

9.5 マルチシグ構成変更

現在、takashiは承認のために3アカウント、除名には2アカウントとなっています。

この数値をいじれたり、また親アカウントの構成を変えることができるようです。

マルチシグ構成の縮小。

除名および承認に必要な連署者数を-1とするようです。

また、carol3についてもマルチシグ構成から除名するようです。

// 必要アカウントを作成する。
var takashi = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(takashiPrivateKey), sym.NetworkTypeEnum.testnet);
var carol1 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol1PrivateKey), sym.NetworkTypeEnum.testnet);
var carol2 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol2PrivateKey), sym.NetworkTypeEnum.testnet);
var carol3 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol3PrivateKey), sym.NetworkTypeEnum.testnet);

// carol1は起案者になるため、連署はcarol2、carol3のみ。
// (takashiのminApprovalが3のため、3名が署名すれば、連署は成立する)
var cosigners = [carol2, carol3];

// マルチシグアカウント情報変更設定を行う。
// takashiの必要な最小署名者を-1にし、carol3を除名する。
var multisigTx = sym.MultisigAccountModificationInfoV1.create(
  takashi.publicAccount, 
  Int8(-1),   // 除名のために必要な最小署名者数増分
  Int8(-1),   // 承認のために必要な最小署名者数増分
  [], 
  [carol3.address]);

// Transaction設定を行う。
// 署名者はcarol1。takashiのアカウントから送信するが、takashiは子のため、自身で起案を行わない。
var transSetting = sym.TransactionSetting(
  signer: carol1,
  generationHash: generationHashSeed, 
  networkType: sym.NetworkTypeEnum.testnet, 
  deadline: sym.Deadline.create(epochAdjustment),
  fee:sym.FeeMultiplier(100),
  cosignatoriesQ: cosigners.length);     // 手数料は100%。

// トランザクションの通知。
print('アグリゲートコンプリートトランザクションで送信');
var transactionSender = TransactionSender();

await transactionSender.sendAggregateComplete(transSetting, [multisigTx], cosigners);

完了した。

9.2 確認で行った動作を再度実行します。

takashiのminApprovalが2、minRemovalが1となっているのが確認できます。

また、cosignatoryAddressesもcarol3が除名されたことで、3件となっていることが確認できます。

これでtakashiのマルチシグ構成を減らすことを確認しました。

連署者構成の差し替え

連署者構成の差し替えを行います。

現在、takashiの親アカウントはcarol1、carol2となっています。

これをcarol2をout、carol5をinとしていきます。minApprovalおよびminRemovalについては変動させません。

// 必要アカウントを作成する。
var takashi = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(takashiPrivateKey), sym.NetworkTypeEnum.testnet);
var carol1 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol1PrivateKey), sym.NetworkTypeEnum.testnet);
var carol2 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol2PrivateKey), sym.NetworkTypeEnum.testnet);
var carol5 = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(carol5PrivateKey), sym.NetworkTypeEnum.testnet);

// carol1は起案者になるため、連署はcarol2のみ。
// (takashiのminApprovalが2のため、2名が署名すれば、連署は成立する)
// ただしcarol5を追加するため、carol5の連署も必要となる。
var cosigners = [carol2, carol5];

// マルチシグアカウント情報変更設定を行う。
// 署名者数増分を0にして、変更なし。
// carol2を削除し、carol5を設定する。
var multisigTx = sym.MultisigAccountModificationInfoV1.create(
  takashi.publicAccount, 
  Int8(0),   // 除名のために必要な最小署名者数増分
  Int8(0),   // 承認のために必要な最小署名者数増分
  [carol5.address], 
  [carol2.address]);

// Transaction設定を行う。
// 署名者はcarol1。takashiのアカウントから送信するが、takashiは子のため、自身で起案を行わない。
var transSetting = sym.TransactionSetting(
  signer: carol1,
  generationHash: generationHashSeed, 
  networkType: sym.NetworkTypeEnum.testnet, 
  deadline: sym.Deadline.create(epochAdjustment),
  fee:sym.FeeMultiplier(100),
  cosignatoriesQ: cosigners.length);     // 手数料は100%。

// トランザクションの通知。
print('アグリゲートコンプリートトランザクションで送信');
var transactionSender = TransactionSender();

await transactionSender.sendAggregateComplete(transSetting, [multisigTx], cosigners);

とりあえず実行されました。

再度、9.2の確認を実行します。

takashiのminApprovalが2、minRemovalが1で変化はありません。

cosignatoryAddressesに3名が並んでいますが、この状態では冒頭のアドレスとは一致しないため、わかりづらいですね。。。

ということで、エンコード前アドレスも出力してきました。

アッパーにしてないのであれですが、carol1は9812…f485、carol4が987c…991e、carol5が9800…3257で親アドレスになっていることが確認できます。

感想編

現場で使えるヒントもこちらで。

多要素認証

ちゃんとやればセキュリティは安全に。ただ、変にやると漏れてしまうねっていうところでしょうか。

複数人で1アカウントの運用もできてしまうので便利ではありますが、一度ミスをした人がいれば全体にも波及する恐れがありますね。

MAGIシステムじゃないですが、複数人の承認がないと実行されないのは面白いですよね。
別に複数人でなくても、例えば金庫用のアカウントなんかがある場合は、金庫用のアカウントの親アカウントを２つ用意し、それぞれを普段使いのデスクトップPC、スマホと導入しておけば、片方だけでは送金とかされない安全性はありますよね。
……故障などで取り出せなくなることもあるため、秘密鍵の管理は別途、大事になるところだと思いますが。。。

アカウントの所有

親アカウントを所持していることで、子アカウントのアカウントも(それが発行したモザイクなども)所持しているということですね。親アカウントの構成を自由に組み替えられるため、誰かに子アカウントの譲渡もできる、という感じでしょうか。

秘密鍵は無効(というより、子アカウントでのトランザクション発行が無効なのかな？)とありました。
ふと思ったのは、子アカウントに向けて暗号化メッセージを送信した場合、メッセージの復号には子アカウントの秘密鍵が必要になるのでは？　と思いました。

これは言い換えると、子アカウントに対しては暗号化メッセージを送らないほうがよさそうな気もしますね。もちろん運用次第ですけど。
子アカウントを譲渡した際に子アカウントの秘密鍵の譲渡がされない場合、子アカウントへの暗号メッセージは譲渡された側が確認することができませんし、子アカウントの元の持ち主が見ることが可能かなと思います。そうだとしたらちょっと怖い部分かもしれないですね。

ワークフロー

あーそうですよね、ワークフロー。できそうな気もします。あんまりちょっとしっくり来ていませんが。。。複数階層のマルチシグアカウントで実験してないからかもしれません。

どこまで署名が集まったか？　っていうのは恒久的に確認できるんでしょうか。。。どこかで見れるのかも知れませんが、ちょっとまだ追えてないです。

その他

僕がもともとSymbolの機能で「ああ、こういうのあるのよねー」と思っていたのはネームスペース、モザイク、アグリゲートトランザクション、マルチシグのであったため、ここまでで一通りの？　「僕が思うSymbolの機能たち」というところまできました。長かった。

また次回。あと4章。ひとつきに2章やれればなんとか、12月には終えそうですね。

速習Symbolブロックチェーン6章、ネームスペース編です。

URLとしてはこちら。

テストネットの紹介はやめます。
(全然終わりそうもないので、進めるのを優先します)

それではやっていきます。

実践編

ネームスペースをレンタルし、アドレスやモザイクに名前を付けることができるということみたいです。

Symbolブロックチェーンではネームスペースをレンタルしてアドレスやモザイクに視認性の高い単語をリンクさせることができます。 ネームスペースは最大64文字、利用可能な文字は a, b, c, …, z, 0, 1, 2, …, 9, _ , – です。

Symbolerなら見たことあるかもしれません。

小文字しかできないのかな？

6.1 手数料の計算

ネームスペースのレンタルには手数料が必要なようです。ブロックチェーンに刻む=手数料が必要、そんな感じですね。参照は無料です。

こんな感じのコードを記述しました。

  /// レンタルフィーを取得する。
  /// [rentalDays]にレンタルする日数を指定する。(30日以上とする必要がある)
  /// ※ここでは、rentalDaysは365を指定した。
  Future<void> getRentalFees(int rentalDays) async {

    // 有効なネットワークホストを取得する。
    var availableHost = await _getNetworkHost();

    // レンタルフィーはNetworkRoutesから取得する様子。
    var networkRoute = NetworkRoutesHttp(availableHost.networkHost);

    // レンタルフィーはRootNamespace、SubNamespace、Mosaicで違うようだ。
    var rentalFees = (await networkRoute.getRentalFeesInformation());

    // レンタル日数を秒に戻し、30(Symbolのブロック生成速度は30sec)で割り、ブロック数を割り出す。
    var rentalBlock = rentalDays * 24 * 60 * 60 / 30;

    var rootRentalFee = rentalFees.effectiveRootNamespaceRentalFeePerBlock.value * rentalBlock;
    var childRentalFee = rentalFees.effectiveChildNamespaceRentalFee;

    print("rentalBlock: ${rentalBlock}");
    print("rootRentalFee: ${rootRentalFee}");
    print("childRentalFee: ${childRentalFee.value}");

  }

実行結果は以下。

ネームスペースレンタルフィー手数料は210240000と算出されます。

Symbolノードを利用しているため、手数料に使用するXYMは可分性が6であることから、1/1000000します。つまり、210.24XYMが手数料になります。速習Symbol通り。

また、ネームスペースは日付を指定した親(Root)ネームスペースと、紐づいた子(Child)ネームスペースが用意できるようです。

期間が指定できるのは親のようなので、親が生きている限り子も生きているということでいいのかな、と。

で、親がいる限りは子の追加は子(childRentalFee)のみで実行できるということでしょうか。10XYMかな？

6.2 レンタル

ルートネームスペース/サブネームスペースをレンタルするようです。

ルートネームスペースの子どもとして、サブネームスペース、サブのサブネームスペースぐらいの階層までは取得できるようです。

なお、ルート/サブのネームスペース取得には手数料がかかることがわかります。

また、ネームスペースの有効期限はルートネームスペースに依存しているとのことで、サブよりルートのネームスペースのレンタル料は高くなっています。

有効期限の更新についても、ルートネームスペースの期限さえ気にしていればよさそうですね。

さて、

• murakamiharuki(ルート)
• sekai-no-owari(サブ)
• wonder-land(サブサブ)

という形で取得してみたいと思います。
murakamiharuki.sekai-no-owari.wonder-landという完成形ですね。

また、レンタルする期間は1051200ブロックを考えています。

以下、ソースコード。

// aliceのアカウントを作成する。
var alice = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(alicePrivateKey), sym.NetworkTypeEnum.testnet);

print("[送信元] alice address: ${alice.address}");

// 大体、一年間分の期間。
var rentalDuration = sym.BlockDuration(1051200);

// ルートネームスペース。
var rootNamespaceId = sym.NamespaceId("murakamiharuki");

// サブネームスペース。
var subNamespaceId = sym.NamespaceId("murakamiharuki.sekai-no-owari");

// サブサブネームスペース。
var subsubNamespaceId = sym.NamespaceId('murakamiharuki.sekai-no-owari.wonder-land');

// トランザクション。
var transactions = [
  // ルートネームスペース登録トランザクション。
  sym.NamespaceRegistrationInfoV1.createRoot(alice.publicAccount, rentalDuration, rootNamespaceId, rootNamespaceId.fullName!),
  // サブネームスペース登録トランザクション。
  sym.NamespaceRegistrationInfoV1.createSub(alice.publicAccount, rootNamespaceId, subNamespaceId, subNamespaceId.name!),
  // サブサブネームスペース登録トランザクション。
  sym.NamespaceRegistrationInfoV1.createSub(alice.publicAccount, subNamespaceId, subsubNamespaceId, subsubNamespaceId.name!)
];

// Transaction設定を行う。
var transSetting = sym.TransactionSetting(
  signer: alice, 
  generationHash: "49D6E1CE276A85B70EAFE52349AACCA389302E7A9754BCF1221E79494FC665A4", 
  networkType: sym.NetworkTypeEnum.testnet, 
  deadline: sym.Deadline.create(1667250467),
  fee: sym.FeeMultiplier(100) );     // 手数料は100%。          


// トランザクションの通知。
var transactionSender = TransactionSender();

for (var element in transactions) {
  await transactionSender.sendTransaction(transSetting, element);
}

作りの問題で、alice.publicAccountが複数でてきていますね。
これは不要なので、そのうち直したいですが。。。

では実行してみます。

ルートネームスペース取得までの結果は以下。

サブネームスペースは以下。

サブサブネームスペースは以下。

一応ウォレットで確認すると、作成されていることが確認できます。

。。。たぶんこれでいいんだよね？　というところ。

有効期限の計算

先ほどの通り、有効期限はルートネームスペースに依存している、ということのようです。

ブロックチェーンのタクトとしては「時間」ではなく「ブロック高」ということなので、

1. ネームスペース情報を取得し、有効期限のブロック数を取得する。
2. 現在の最後のブロック数を取得する。
3. ブロックに関する情報を取得することで、ブロックが生成された時刻を取得する。
4. (ブロックが生成された時刻 + 現在から有効期限終了までのブロック数スパンを時間化)とすることで、予定時刻が出せるようです。

なお、ネームスペースをレンタルするトランザクション発行から、この有効期限の計算を行うまでいくらか時間経過しています。うーむ。

var networkHostInfo = await TransactionSender.getNetworkHost();

var namespaceHttp = sym.NamespaceRoutesHttp(networkHostInfo.networkHost);
var chainHttp = sym.ChainRoutesHttp(networkHostInfo.networkHost);
var blockHttp = sym.BlockRoutesHttp(networkHostInfo.networkHost);

var namespaceId = sym.NamespaceId("murakamiharuki");

// ネームスペース情報を取得する。
var nsInfo = await namespaceHttp.getInformation(namespaceId);

var lastHeight = (await chainHttp.getCurrentInformation()).height;

var lastBlock = await blockHttp.getInformation(lastHeight);

var remainHeight = nsInfo.namespace.endHeight - lastHeight;

print("namespace endHeight: ${lastHeight.value}");
print("lastBlock: ${lastBlock.block.height.value}");

print("remainHeight: ${remainHeight.value}");

var timestamp = lastBlock.block.timestamp.value + (remainHeight.value * 30000 + epochAdjustment * 1000);

var endDate = DateTime.fromMillisecondsSinceEpoch(timestamp.toInt(), isUtc: false);

print("endDate: $endDate");

取得した結果がこちら。

まぁこんなもんでしょうか。

念のため本日(20230701)のウォレットからの確認結果です。

まぁ、大体あってると思います。

6.3 リンク

ネームスペースは取得しただけでは活用法がない？　ため、特に意味はないかも？

ネームスペースはアドレスやモザイクと紐づくことで、それに命名できる感じなようです。便利ですね。

アカウントへのリンク

アカウントへというか、アカウントのアドレスみたいですね。

// aliceのアカウントを作成する。
var alice = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(alicePrivateKey), sym.NetworkTypeEnum.testnet);

print("[送信元] alice address: ${alice.address}");

// ネームスペース。
var namespaceId = sym.NamespaceId("murakamiharuki");

// アドレスエイリアストランザクション。
var tx = sym.AddressAliasInfoV1.create(alice.publicAccount, namespaceId, alice.address, sym.AliasActionEnum.link);

// Transaction設定を行う。
var transSetting = sym.TransactionSetting(
  signer: alice, 
  generationHash: "49D6E1CE276A85B70EAFE52349AACCA389302E7A9754BCF1221E79494FC665A4", 
  networkType: sym.NetworkTypeEnum.testnet, 
  deadline: sym.Deadline.create(epochAdjustment),
  fee: sym.FeeMultiplier(100) );     // 手数料は100%。          

// トランザクションの通知。
var transactionSender = TransactionSender();

// トランザクション送信。
await transactionSender.sendTransaction(transSetting, tx);

ウォレットで確認したところ、下記のようでした。

エイリアスタイプがaddressでエイリアスにアドレスが登録されていることが確認できました。

モザイクへリンク

そのまま続けてモザイクへリンクを行います。

// aliceのアカウントを作成する。
var alice = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(alicePrivateKey), sym.NetworkTypeEnum.testnet);

print("[送信元] alice address: ${alice.address}");

// モザイクid。以前の章で作成済み。
var mosaicId = sym.MosaicId("50E29F813AA1B901");

// ネームスペース。世界の終わり。
var namespaceId = sym.NamespaceId("murakamiharuki.sekai-no-owari");

// アドレスエイリアストランザクション。
var tx = sym.MosaicAliasInfoV1.create(alice.publicAccount, namespaceId, mosaicId, sym.AliasActionEnum.link);

// Transaction設定を行う。
var transSetting = sym.TransactionSetting(
  signer: alice, 
  generationHash: "49D6E1CE276A85B70EAFE52349AACCA389302E7A9754BCF1221E79494FC665A4", 
  networkType: sym.NetworkTypeEnum.testnet, 
  deadline: sym.Deadline.create(epochAdjustment),
  fee: sym.FeeMultiplier(100) );     // 手数料は100%。          

// トランザクションの通知。
var transactionSender = TransactionSender();

// トランザクション送信。
await transactionSender.sendTransaction(transSetting, tx);

実行結果は以下。

とりあえずトランザクションが承認されている様子。

ウォレットで確認したところ、以下となっていました。

エイリアスタイプがmosaicで、エイリアスにモザイクIDが設定されています。

ウォレットのモザイクページで確認したところ、モザイクにも名前が紐づいていることが確認できます。

6.4 未解決で使用

アカウント(アドレス)、モザイクIDにネームスペースをリンクすることで、わかりやすく名前を紐づけることができるようになりました。

この未解決で使用の項では、ネームスペース→アドレスやネームスペース→モザイクIDと変換しなくても、ネームスペース＝アドレス、ネームスペース=モザイクIDとして直接送信できるようですね。

ここいらでunresolved addressって名前が出てきたりするのですが、unresolved addressは未解決って意味らしいです。へー。

以下はコード。

print("bobがaliceに送信する");

var bob = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(bobPrivateKey), sym.NetworkTypeEnum.testnet
);

print("[送信元] bob address: ${bob.address}");

// 未解決アドレス(alice)
var unresolvedAddress = sym.NamespaceId("murakamiharuki").getUnresolvedAddress(sym.NetworkTypeEnum.testnet);

// 未解決モザイク(murakamiharuki.sekai-no-owari)
var unresolvedMosaicId = sym.NamespaceId("murakamiharuki.sekai-no-owari").getUnresolvedMosaicId();

// 転送モザイク。
var transMosaic = sym.Mosaic(amount: sym.Amount(100), id: unresolvedMosaicId);

// Transaction設定を行う。
var transSetting = sym.TransactionSetting(
  signer: bob, 
  generationHash: "49D6E1CE276A85B70EAFE52349AACCA389302E7A9754BCF1221E79494FC665A4", 
  networkType: sym.NetworkTypeEnum.testnet, 
  deadline: sym.Deadline.create(epochAdjustment),
  fee: sym.FeeMultiplier(100) );     // 手数料は100%。    

// 送り先に未解決アドレス、未解決モザイクを設定する。
var tx = sym.TransferInfoV1.create(bob.publicAccount, unresolvedAddress, [transMosaic] );

// トランザクションの通知。
var transactionSender = TransactionSender();

// トランザクション送信。
await transactionSender.sendTransaction(transSetting, tx);

速習Symbolでは未解決アドレス、未解決モザイクでやっていましたが、横着して一度にやることにしました。

送信するモザイクはsekai-no-owariに紐づいたモザイクIDです。

今回はbob → alice(未解決アドレス)と送信するため、あらかじめaliceからbobへ、sekai-no-owariをウォレットにて送信しておきました。

いざ実行です。

とりあえず承認されました。

ウォレットで確認します。

murakamiharukiあてに送られているのは確認できました。

sekai-no-owariモザイクはなんか表示がバグってますね(ウォレットが古い？)

数はしっかり減っていたため、explorerで見ると転送されていることが確認できました。

6.5 参照

ネームスペースのリンク情報を参照する方法についてです。

以下の感じです。

var namespaceId = sym.NamespaceId("murakamiharuki");
var namespaceId2 = sym.NamespaceId("murakamiharuki.sekai-no-owari");

var networkHostInfo = await TransactionSender.getNetworkHost();
var namespaceHttp = sym.NamespaceRoutesHttp(networkHostInfo.networkHost);

// ネームスペース情報を取得する。
var nsInfo = await namespaceHttp.getInformation(namespaceId);
var nsInfo2 = await namespaceHttp.getInformation(namespaceId2);

print("murakamiharuki info");
print(nsInfo.baseMap);

print("murakamiharuki.sekai-no-owari info");
print(nsInfo2.baseMap);

結果は以下。

aliasのtypeが2でアドレスエイリアス、addressに紐づいている対象アドレスでしょうか。

aliasのtypeが1でmosaicIdって形のようですね。

ネームスペース → 紐づき状態を確認できるって感じですね。

また、速習SymbolによるとregistrationTypeで親か子かもわかるようです。

逆引き

ネームスペース → アドレスと取得できるのであれば、逆にアドレス → ネームスペースと取得することができる、とのこと。

ネームスペースをアドレスに紐づける場合、「紐づき先のアドレスはネームスペース所有者以外でもよい」とのことなので、ネームスペース：アドレスは１：Nの関係であるらしいですね。

ここまで使用しているaliceのアドレスと、今回ネームスペースとリンクしたモザイクに付与されているネームスペースを取得します。

// aliceのアカウントを作成する。
var alice = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(alicePrivateKey), sym.NetworkTypeEnum.testnet);

// ネームスペースが紐づいているモザイクID。
var mosaicId = sym.MosaicId("50E29F813AA1B901");

print("[取得元] alice address: ${alice.address}");

var networkHostInfo = await TransactionSender.getNetworkHost();
var namespaceHttp = sym.NamespaceRoutesHttp(networkHostInfo.networkHost);

// アカウント名を取得。
var accountNames = await namespaceHttp.getReadableNamesFromAddresses([alice.address]);

// モザイク名を取得。
var mosaicNames = await namespaceHttp.getReadableNamesFromMosaics([mosaicId]);

print("account names");
print(accountNames.baseMap);

print("mosaic names");
print(mosaicNames.baseMap);

結果としては以下。

accountNamesも、mosaicNamesも、内容が配列になっているため、複数の情報を一度に取ることができることが確認できます。

レシートの参照

トランザクションに使用されたネームスペースを、ブロックチェーンがどうやって解決したかを確認するらしいです。

ネームスペースAは今、浜田くんと紐づいている。

しかし期限が切れた後、ネームスペースAを松本くんがレンタルして自分に紐づけた場合、同じネームスペースAであっても紐づけ先が変わっている。

そのため、現在の状態で過去の情報を引っ張ってきても、送り先が変わっている可能性がある、ということかな。

電話番号みたいですね。

以下のコードは、ブロック高が597274に対して、アドレス解決とモザイクIDの解決内容を取得するようにしました。

// aliceのアカウントを作成する。
var alice = await sym.Account.createFromPrivateKey(
  sym.PrivateKey(alicePrivateKey), sym.NetworkTypeEnum.testnet);

// ネームスペースが紐づいているモザイクID。
var mosaicId = sym.MosaicId("50E29F813AA1B901");

print("[取得元] alice address: ${alice.address}");

var networkHostInfo = await TransactionSender.getNetworkHost();
var receiptHttp = sym.ReceiptRoutesHttp(networkHostInfo.networkHost);

var criteria = sym.GetReceiptsAddressResolutionStatementsCriteria();

// ブロック高を597274を指定(bobがaliceにsekai-no-owariを送付したブロック)。
criteria.height = sym.Height(597274);

var receipt1 = await receiptHttp.getAddressResolutionStatements(criteria);
var receipt2 = await receiptHttp.getMosaicResolutionStatements(criteria);

print("receipt address");
print(receipt1.baseMap);
// わかりづらいのでエンコード済みアドレス化。
print(receipt1.data[0].statement.resolutionEntries[0].resolved.toAddress().value);

print("receipt mosaicId");
print(receipt2.baseMap);

結果は以下。アドレスも、モザイクIDも取得されていることがわかるため、これで当時の紐づき状態を知ることができるようです。

6.6 現場で使えるヒント

読みました。ドメインのような「個人を識別しやすくする」ということでしょうか。あとは譲渡について、というところ。

感想編

ざっくりといえば、

• Symbolにはネームスペースという概念がある。
• ネームスペースは3階層まで指定可能。(ネットワーク設定による？)
• ネームスペースはレンタル制で、レンタル期間はルートネームスペースの期限で定めている。
• ネームスペースにはアドレス、モザイクIDを紐づけることができる。
• 紐づけることで、アドレスやモザイクIDに任意の名前を付けることができる。
• ネームスペースについてはチェーン上で一意である。

という機能のようですね。

基本的にアドレス、モザイクID自体には「名前」といったものがないので、それを任意に付与する、というもののようです。

ネームスペースIDは文字列から生成され、かつ、一意であるため、使用する名前=IDのようです。

現場で使えるヒントからすると、ネームスペースのレンタルを途中でやめる、という選択肢はなさそう？
同様にネームスペースの譲渡ということもできない模様。

よって、譲渡する可能性のあるネームスペースであった場合、
マルチシグの子アカウントを作成し、子アカウントごとマルチシグで譲渡する。そういう風にするようです。

未解決状態でアドレス、モザイクIDとして扱えるのは面白いですが、レンタル期間の終了、または意図しないものとの紐づきに注意する必要もありそうですね。

ただ実際に使用する際にはレンタル期間が切れている可能性もありますし、タイポの可能性もある？　とかって考えると、ひと手間かかりますが、リンク状態を確認してから使用するほうが安心な気もしますね。

以上です。また次回。

速習Symbolブロックチェーン体験記「とろ速Symbol」の3章、アカウントについての感想編です。

こちらでは実装ではなく、「ああ、こういうことなのかな？」といった学んだと思う部分をまとめていこうと思います。まぁ、全然わかってないんだけど。

実施編はこちら。

さて。

アカウント生成・アカウントへの送信

アカウント構成はざっくり言えば下記のイメージ。

ある意味、アカウント生成とは秘密鍵(PrivateKey)を決めること。
秘密鍵(PrivateKey)から公開鍵(PublicKey)、生アドレス(RawAddress)、アドレス(Address)の導出が可能になる。

よって、バレてはまずいのは秘密鍵。
また、秘密鍵はネットワークに晒す必要もないため、誰かに教える必要はない。

上記の構成で公開アカウントで囲まれた内容がある。

これについては外部に公開可能な部分であり、SymbolノードのREST APIから直接取得できる部分でもある。

僕らが普段送信を行う対象はアドレスとなる。

また、アカウント生成時点ではネットワークが不要である。
つまり、ネットワークはアカウントが作成されたことを知らない。

つまり、秘密鍵が生成されたことをブロックチェーンは知らないため、秘密鍵から生成される公開鍵も不明であるし、アドレスも不明である。

アカウント(秘密鍵)が存在することを知らせるためには、作成したアカウントからトランザクションを発生させる必要がある。

トランザクション実行には署名が必要です。(これ、次回の話？)

署名が必要であるからには、秘密鍵が存在する。

よって、トランザクション実行により、対象のアカウントに対する公開鍵以降がチェーンに刻まれる。というお話。

なお、その場合、なぜかフォーセットから、(チェーンが認識していない)aliceアカウントに送金できるという部分がある。

おそらくこんな感じで、送信されている。

2. の秘密鍵の存在は不明～～はその通りで、よって、アドレスを間違えるとGOXの可能性がある。
(実際に導出済みのアドレスとは限らないため、本当に誰も所有していないところに飛ぶ可能性もあると思う)

そのため、アプリケーションから送金などを行う場合、通常であれば「公開鍵がブロックチェーンに登録されていること」を確認したほうが安全なのだろう。
(おそらく、あらゆる場面で)

アカウント情報の確認

先ほども書いたけれど、アカウントを作成しただけではSymbolブロックチェーンはアカウントの存在を認識していない。

また導出の順の通り、アドレスについては導出の最後になる。
そのため、アドレスから公開鍵は逆引きとなるため、不明な値(ゼロフィル)となる。

よってトランザクション実行時に公開鍵を使用するため、登録される。

うん、他には特にないですね。

現場で使えるヒント

暗号化と署名。

ここ、凄い困りました。全然暗号とかわかんないし。
AES-GCM形式っていうのはわかった。
※ざっくりいえば(aliceの秘密鍵＋bobの公開鍵) = (aliceの公開鍵＋bobの秘密鍵)となる鍵を作って、それで暗号化するということのようだった。

わからないのでFlutterのパッケージを組み合わせて試していたのですが、全然うまくいかなかったんですよ。これ、あれですね、わかったことではなくて愚痴ですね。

もう覚えてないのであれなんですが、ハッシュの計算？　かなんかが、よく使われているのとは別らしいですね。(内容はうろ覚えですが、よく提供されているのが128bitで、こちらでは256bitだったかな？)

それについて言及しているブログを目にしたため、「あ、これパッケージじゃだめなのかも」と認識しました。
(ブログではSymbolではなく、NEMについての言及でしたけれど)

結果として中身は全然わからないのですが、tweetnacl？　というソースを写経する感じに至りました。ほんまこいつ。。。。

そんなわけで、暗号化についてはこんな感じで理解しました。

これでbobはaliceのメッセージを受け取ることができるようです。

公開鍵の交換はローカルでもいいですが、トランザクションさえ発生させてしまえば公開鍵がチェーンから取得できるので、「トランザクションを発行したことがあるアカウント」であれば、秘密のメッセージを送りあうことができます。

また、他人から見た場合でも安全です。

また、「本当にaliceが送信したのか？」という疑わしい点を解消するため、署名の仕組みがあるとのことでした。

今回、速習Symbolではalice → bobへの送信したメッセージに対して、aliceが署名を行いました。

その署名内容を検証することでaliceが送ったということを証明できるようです。

なお、速習Symbolでは以下の感じです。

これ、本当はトランザクションの証明についての話でもあると思うんですが、たぶんそれは次の章で触れると思います。たぶん。

アカウントの保管

秘密鍵の暗号化をしよう！　という話でした。そうですね。

以上です。お疲れさまでした。

速習Symbolブロックチェーン体験記「とろ速Symbol」です。

「1. はじめに」「2.環境構築」についてはほぼ目を通すだけのため、スキップしました。

本ページでは「アカウント」をやっていきます。

感想編はこちら。

なお、今回はこちらのテストネットノードをお借りしました。

@ftakao2007

hoge.harvesting-sweet-potatoes.club(Symbol テストネット)

(敬称略)

もちろんメインネットのノードも運用されております。

間違っていたり、問題があったら教えてください。

本稿では「3. アカウント」の実施内容を記載します。

新規作成 – 秘密鍵と公開鍵の導出 – アドレスの導出

アカウントの新規作成を行います。

秘密鍵と公開鍵のキーペアを生成し、そこからアドレスの導出を行います。

また、アドレスの導出にはテストネット or メインネットの属性が必要なようです。

アカウント新規作成

まったく当てにならない僕の自作コードはこちら。

    // 使用するホスト情報を取得する。
    var availableHost = await _getNetworkHost();

    try {
      // 新アカウントを生成する。
      var newAccount = await _generateNewAccount(availableHost);

      return newAccount;

    } catch (e) {
      debugPrint(e.toString());
      debugPrint(StackTrace.current.toString());

      throw CreateNewAccountFailedException();
    }

※全体像を載せられるようなコードになっていないため、一部分だけです。

色々ありましたが、実行結果としてはこんな感じです。

秘密鍵の導出はさておいて(自分で用意していない部分でもあるので)、

導出された秘密鍵を使ってSymbolSDKから、アドレスを取得しようと思います。

そうすることで秘密鍵　→　公開鍵　→　生アドレス　→　アドレスの導出が同一であるということの検証とします。

※なお、raw addressと記載してますが、これをraw addressと呼んでいいかはわかりません。が、とりあえずこれで進めます。

なので比較のため、SymbolSDKでも同じことを実行します。

アドレスが同一の”TCY7YADZLU6G34GK7VPGI3EUK2PMS2SDS25QMIA”となっているため、秘密鍵からアドレスの生成までは同一である、ということとしました。

アカウント情報の確認

既に(もう少し先まで)実行した関係上、データがきれいではないのですが。

実行テストを行う上で、alice、bobの秘密鍵は固定で使用していくこととします。(期間が空いた際に毎度やり直すと大変なため)

基本的にaliceのアカウントは上記で行います。

既にトランザクションを実行している関係上、変な値ですがxymは保持されています。

こちらを取得します。

当てにならないコードはこちら。

_startProcessing();

                _accountWorker.getAccountAssetsFromAddress(Address("TAEKZ65QU3T4HK3JEEI2SOAHYNPYBUZ7BPC4YAA"))
                  .then((AccountMosaicProfile accountMosaicProfile) {
                    print("取得アカウント情報。");
                    print("address: ${accountMosaicProfile.account.address}");
                    print("public key: ${accountMosaicProfile.account.publicKey}");
                    
                    print("所持モザイク情報。");

                    var account = accountMosaicProfile.account;
                    var mosaicMap = accountMosaicProfile.mosaicInfos;

                    for (var mosaic in account.mosaics){

                      var mosaicDTO = mosaicMap[mosaic.id];
                      var mosaicAmount = "";
                      if (mosaicDTO != null && mosaicDTO.divisibility > 0){
                        var amountStr = mosaic.amount.toString();
                        var intVal = amountStr.substring(0, amountStr.length - mosaicDTO.divisibility);
                        var decVal = amountStr.substring(amountStr.length - mosaicDTO.divisibility);
                        mosaicAmount = "$intVal.$decVal";
                      }

                      print("id: ${mosaic.id} amount: $mosaicAmount");
                    }
                  })
                  .whenComplete(_finishProcessing);

実行結果はこちら。

所持モザイク情報が取得できていることが確認できますね。

現場で使えるヒント

暗号化と署名

AliceとBobのみがわかるように、内容を暗号化できるみたいです。

なのでやっていきます。

当てにならないコードはこちら。

  // aliceのアカウントを作成する。
  var alice = await _accountWorker
.createNewAccountFromPrivateKey("379891A667CBA1C4F9B8DFEBCEE2AE393E4D04D162B9ED3BAB6CA17178*****");

  // bobのアカウントを作成する。
  var bob = await _accountWorker
.createNewAccountFromPrivateKey("4A570201B9E491F0B1F4BDFE4C1AEED7D75582AAAA7771374FC88DC58C*****");

  var baseMessage = "super hogehoge";
  var message = PlainMessage.create(baseMessage);

  print("メッセージ[$message]を暗号化/復号化。");

  // メッセージの暗号化。
  var encryptedMessage = await alice.encryptMessage(message, bob.publicAccount);

  print("encrypted: ${encryptedMessage.payload}");

  // メッセージの復号化。
  // 念のため、payloadから暗号化メッセージクラスを別途インスタンス化し、復号化を行う。

  var newEncryptedMessage = await EncryptedMessage.create(encryptedMessage.payload, alice.publicAccount);
  var decryptedMessage = await bob.decryptMessage(newEncryptedMessage);

  print("decrypted: ${decryptedMessage.value}");

  print("署名と検証");

  // 復号化した内容にaliceが署名する。
  var aliceSignature = await alice.sign(decryptedMessage.toByte());

  print("aliceSignature: ${aliceSignature.value}");

  print("署名を行ったのがaliceなのかを検証する。");

  var isVerifiedAlice = await alice.publicAccount.verify(decryptedMessage, aliceSignature);
  var isVerifiedBob = await bob.publicAccount.verify(decryptedMessage, aliceSignature);

  print("alice: ${isVerifiedAlice ? "yes" : "no" }");
  print("bob: ${isVerifiedBob ? "yes" : "no"}");

“super hogehoge”をaliceがbobの公開アカウントに対して暗号化。

bobがaliceの公開アカウント情報に対して復号します。

公開アカウントってなに？　っていうと「公開鍵/生アドレス/アドレス」のセットです。

※使用するのは公開鍵なんですけど。

復号した内容への署名を行い、それを検証することで、署名したのがaliceである証明とします。

実行結果はこちら。

こんな感じです。

encryptedが暗号化後のメッセージ、decryptedが復号したメッセージ。

aliceSignatureがaliceの署名です。

検証結果から、aliceが署名したことをうかがえます。

ここでの作りは僕がコーディングしただけのため、実際にSDKと同じなの？　ということを確認する必要があります。

が、面倒でもあるため、SDKにて復号と署名の検証のみ行います。

ということで、復号は以下。

bobがaliceの公開情報を使用して復号した結果です。

同様に署名についても証明します。

aliceが署名していることを証明できました。

また自作のコードで暗号化 -> SDKにて復号(署名)も可能であることを確認しました。

アカウントの保管

アカウント項における最後。アカウントの保管についてです。

具体的には秘密鍵は大事な情報のため、ぱっと見ではわからないように暗号化して保管しようぜ！　って話です。

使用しているaliceの秘密鍵379891A667CBA1C4F9B8DFEBCEE2AE393E4D04D162B9ED3BAB6CA17178E*****を使用することとします。

ということでまずはSDKを使用して実行します。

こんな感じとなりました。

※QRコード表示はカットとします。

もちろん復号も可能です。

さて、これと同じようなものを実装しました。

※これ、厳密にはSDKに含まれているわけではない気がしますが。

そんなわけで当てにならないコードです。

  var alicePrivateKey = PrivateKey("379891A667CBA1C4F9B8DFEBCEE2AE393E4D04D162B9ED3BAB6CA17178E*****");

  print("秘密鍵の暗号化");

  // パスフレーズ付きで暗号化。
  // invest_in_kishidaはPW。
  var signerQR = qr.QRCodeGenerator.createExportAccount(alicePrivateKey, 
    NetworkTypeEnum.testnet, 
    symbolTestnetGenerationHash, "invest_in_kishida");

  var schema = signerQR.getSchema();

  var outputObject = await schema.toObject(signerQR);
  var printOutputObject = jsonEncode(outputObject);

  print("暗号結果。");
  print(printOutputObject);

  {
    print("復号する。");
    var decryptedQR = await qr.QRCodeGenerator.fromJson(printOutputObject, password: "invest_in_kishida");

    decryptedQR as qr.AccountQR;

    print("復号結果。");
    print(jsonEncode(decryptedQR.privateKey));
  }

  {
    print("速習Symbolより。Edgeを使用して作成した暗号化メッセージpayloadをdecryptする。");
    print("symbol-qr-libraryと等価であることを検証。");

    var fromBrowser = '''
      {"v":3,"type":2,"network_id":152,"chain_id":"49D6E1CE276A85B70EAFE52349AACCA389302E7A9754BCF1221E79494FC665A4","data":{"ciphertext":"aed4e1b553e02e5a38946db98ebf795bMOiGKwS3VtiQZnIvzBRQ21IQgyAM662tKUMJ3MiI3k/+YYrGC/JVbrvtkN1WfjmLOaBXYIg3dJw6FqdZ0mh80YiOl******....","salt":"d8b4f954c878fb6888cbff896ac1409eb861706d2fd933f4ede030c515148396"}}
    ''';

    var decryptedQR = await qr.QRCodeGenerator.fromJson(fromBrowser, password: "invest_in_kishida");

    decryptedQR as qr.AccountQR;

    print("復号結果。");
    print(jsonEncode(decryptedQR.privateKey));

    // 表示するQRコードの取得。
    _dispAccountQR = await decryptedQR.toQrImage(null);
  }

実行結果はこちら。

こんな感じとなりました。

秘密鍵の暗号化 -> 復号が可能であり、SDKで暗号化した秘密鍵の復号も可能であることから、おそらく、秘密鍵の暗号化、復号が等価である。かもしれない。というところになりました。

一応、QRを表示するのも用意したんですよ。

お見せできないんですけども。

そんなわけで第3章、アカウントについては以上です。

後半の感想編に続きます。