暗号通貨に関する事など

暗号通貨に関する覚書など。メモや日記。

※技術的なことに関して、間違っていたらコメントから指摘していただけると泣いて喜びます

【NEM-Catapult】 Transaction

※最終更新:2018.3.28

はじめに 


 今回はTransactionについてです。


Transactionの種類

 transaction は今これを書いている時点では10種類あります。ドキュメント記載順に...

  1. transfer transaction
  2. register namespace transaction
  3. mosaic definition transaction
  4. mosaic supply change transaction
  5. modify multisig account transaction
  6. aggregate transaction
  7. cosignature transaction
  8. lock funds transaction
  9. secret lock transaction
  10. secret proof transaction
 です。簡単に説明を続けます。


Transaction

 全てのトランザクションは前提となる" Transaction "の構造の上に乗っかっています。なので、全てのトランザクションは共通して下記枠内の情報を保持しています。

type      トランザクションの種類

version number バージョン

deadline    このトランザクション承認の締め切り

fee      手数料

signature    署名

signer     署名者の公開鍵

 以降、各トランザクションが持つフィールドはドキュメントに書いてあるのでそこを参照してください。



Transfer transaction

 Transfer (送信) 用。

 これだけだとわからないのですが、amountフィールドが無くなったかのな?(xemがmosaicと完全に同列の扱いになったから?)



Register namespace transaction

 register namespace (ネームスペース登録)用。 

 Durationフィールドを持ち、取得期間が指定できるようになったようです。



Mosaic definition transaction

 mosaic definition (モザイク定義)用。


 Mosaicpropertiesを見る限りだと、Levy機能なくなるのかな?
 修正
 下記リンクのmosaicDefinitionTransactionの使用例を見ると分かりますが "levyMutable: false" という記載があるとおり、Levy機能はNIS2でも実装されるようです。アーリアクセスとしては提供してませんよということのようです。(良かったね


また、ここにもDurationがあるので、namespaceに加えて、mosaic単体でも使用期間を指定できるようになっているようです。



Mosaic supply change transaction

 mosaic supply change (モザイク供給変化)用。



Modify multisig account transaction

 modify multisig account (マルチシグアカウント修正)用。



Aggregate transaction

 アグリゲートトランザクション機能提供用。
 新機能としては目玉機能の一つではないでしょうか。複数のトランザクションを同一ブロックに入れたいときに、このトランザクションを利用します。ちなみに、AggregateTransactionの中に含めるInnerTransactionとしてAggregateTransactionを指定することは出来ません(一層ということ)


 この機能を利用するときの注意点として書いてあるのが、AggregateTransactionを利用する前に必ず後に紹介するLockFundsTransactionを利用して10xem(最初の仕様)を固定しないといけません。また、署名は次に紹介するCosignatureTransactionで別に行われます。なので、アグリゲートトランザクションを利用するときは...

  1. LockFundsTransactionを送信・承認(10xemをロック)
  2. AggregateTransactionを送信 (中にInnerTxを含んでいる)
  3. 必要な分だけCosignatureTransactionで署名(送信)
  4. 署名が揃えばAggregateTransactionに入れられているInnerTxは認められ、送金が行われる
 もしLockFundsTransactionに定められた期限までにAggregateTransactionの署名が揃わなかった時、LockFundsTransactionで固定された10xemは有効期限切れの指定高さブロックを掘り当てたハーベスターのものになります。(これはスパム対策かなと思っています)

 AggregateTransactionと全てのCosignatureTransactionは一緒のブロックに入れられないといけないのかな?それとも別々で入れられるのかな?この辺がちょっとまだ曖昧です。(教えてください)


Cosignature transaction

 AggregateTransactionへのcosignature (連署名)用



Lock funds transaction

 Lock funds (資金ロック) 用。AggregateTransactionを利用する前、これを利用して10xem(現時点で)資金をロックしないといけません。


 このトランザクションがもつフィールドを見る限りだと、これはAggregateTransactionの前提トランザクションとしてしか利用できない感じかな?



Secret lock transaction

 シークレット(ハッシュ値)を解くまで資金をロックすることが出来るトランザクションです。シークレットが説かれると、このトランザクションで指定した相手にモザイクの送信が行われ、このトランザクションで指定した期限までにシークレットが解かれなければ、元の持ち主のもとにロックしたモザイクが返るという仕様のようです。


 フィールドを見てもらうと分かりますが、ハッシュ値とハッシュタイプ(アルゴリズム)を指定できるので、署名ではなくて単なる秘密のキーワードが答えの鍵になるようです。


 これ、なんか面白くないですか?



Secret proof transaction

 secret lock transaction に解答をする為に利用されるトランザクションです。


 以上各トランザクションの簡単な説明でした。



さいごに

 ここでは私が読んでそれについて日本語で書いてますが、NEMのドキュメントで使われてる英語ってそれほど難しくないです。ここまで読んでもらってこんなこと書くのアレですが、Google翻訳で読めるのでそっちで読んだほうが良いですよ。ドキュメントに書いてある内容以上のことを書いているつもりもないですし…

【NEM-Catapult】 Multi-Level Multisig Accounts(MLMA)

はじめに

 WhitePaperに続き、ついにCatapultのドキュメント来ましたね。



 ちなみに、中にも注意書きが書いていますが、このドキュメントは現時点ではMijin-testnet versionとして書かれています。


 で、読んで新しい概念だったりするものは気が向く限り文章にしようかということで書くことにしました。この記事に限らずですが、間違っていたら修正します。コメントなどで教えて頂けると助かります。


 今回は FNUDAMENTALS -> MultisigAccount の中にあるMulti-Level Multisig Account (MLMA)についてです。


Multi-Level Multisig Accounts (MLMA)の概要


 要するに「マルチシグアドレスの連署者としてマルチシグアドレスを登録できるよ」という話です。これによりマルチシグアドレスを利用して階層構造をアドレスで表現することが出来ます。また、MLMA accountはAND/ORのロジックをmulti-signature transactionsに追加するようです。


 連署者に選ばれたマルチシグアドレスは今まで同様操作権限を連署者に委託していて直接署名が出来ないので、そのマルチシグの連署者アカウントから署名することになります(文字にするとややこしいのでドキュメントページの一番下の図を見れば解ると思います)


 mijinの紹介資料のP29,30にあるような階層構造をマルチシグで表現できるようになったんですね。下記リンクからpdfが見れるのでそこを参照してみてください。


MLMA使ってみる

 追記予定


さいごに

 細かい話は使ってみてからまた・・・

【仮想通貨NEM】TransferTransaction実験1

はじめに

 NEMのFee計算がなんだか分かりにくいということで、徹底的に調べて記事にしようかと思って最近NEM-coreのソースコードを眺めてたりしています。すると、関係ないところで疑問に思ったことがありまして、今回はその実験と結果です。


 ちなみに、当然ですがテストネットで試してます。


疑問

 ソースコードを見る限りだとMosaicが添付されたTransferTransactionはAmount(送信xem量)フィールドが無視されるっぽい。実際、NanoWalletを利用してもモザイクの送信をしたい時に一緒にxemを送信するとなると "nem:xem" をわざわざ添付してあげないといけない仕様になっている。


 では、mosaicが添付されている + Amountフィールドに数値が入力されているTransferTransactionをブロードキャストするとどうなるのか。主に気になるのは以下の点。

  1. 手数料は?
  2. xemの送信量は?
  3. そもそもverificationを通過するの?

結果

 結果だけお伝えします


 Amountフィールドはモザイク送信時には別の意味になる


説明

 モザイクが添付されている場合、モザイクの送信量は以下の通りとなります。

トータルの送信量 = ( amount / 1,000,000 ) × ( quantity / 10^dividibility )

 ややこしいのでamountを1,000,000に固定すれば( amount / 1,000,000)は "1" になるので、それで良いと思います。送信量はquantityで調整できるので。


 なお、この時amountは1,000,000で割り切れる数字でないといけません。そうでなければ検証で弾かれます。


example

 上記説明の例を書いておきます。

[mosaic]

1. 名前 : alice

2. 総発行数 : 100

3. divisibility(可分性) : 2

4. 可分性を含めた発行数(2,3より) : 100.00


[送信]

amount : 2,000,000

quantity : 100

実際の転送量 : 2,000,000 / 1,000,000 * 100 / 10^2 = 2

[mosaic]

1. 名前 : alice

2. 総発行数 : 1000

3. divisibility(可分性) : 1

4. 可分性を含めた発行数(2,3より) : 1000.0


[送信]

amount : 4,000,000

quantity : 20

実際の転送量 : 4,000,000 / 1,000,000 * 20 / 10^1 = 8


今回送信したデータ

[MosaicInfo]
namespace : 1alice.1alice
mosaicname : 1alice
initial suply : 10,000
divisibility : 2
(つまり総発行数は10,000.00)


[TxData1]
01010000
02000098
21447005
20000000
2CE02903E133430372A5082DC544928CDD5EC8AED20ADEBB614BA096ABB2B6CF
3057050000000000
31527005
28000000
5441564E335036535A32483452524232495A54514D454855544A4552364B36504C55544959554E54
80841E0000000000 amount(2,000,000 == 2)
00000000
01000000
27000000
1B000000
0D000000
31616C6963652E31616C696365
06000000
31616C696365
6400000000000000 quantity(100)
(フィールド名は省略しています)


[txID]
a49efe9b1ddd1ecb907616491c017447d2efd440bb71d45d242b35f7786d7743


[送信量]
2,000,000(amount) / 1,000,000 × 100(quantity) / 10^2(divisibility) = 2
=> 1aliceモザイクを2.00送信できた


[TxData2]
01010000
02000098
90497005
20000000
2CE02903E133430372A5082DC544928CDD5EC8AED20ADEBB614BA096ABB2B6CF
3057050000000000
A0577005
28000000
5441564E335036535A32483452524232495A54514D454855544A4552364B36504C55544959554E54
20A1070000000000 amount(500,000 == 0.5)
00000000
01000000
27000000
1B000000
0D000000
31616C6963652E31616C696365
06000000
31616C696365
6400000000000000 quantity(100)


[APIcallの結果(JSON)]
{"innerTransactionHash"{},"code":148,"type":1,"message":"
FAILURE_MOSAIC_DIVISIBILITY_VIOLATED","transactionHash":{"data":"be83c04540dcccc1a0accb22114a0c59d1e1a6dfcca33639478f031c70b861f6"}}


※amountが1,000,000で割りきれない数字だとエラーが出るので送金できませんでした

さいごに

 最初無視しているのかと思いましたが、違ったようです。


 ここまでさらっとしてますが、これやるのにライブラリ使えばいいのに簡単なHTTPクライアントをJavaで作ったり(折角なので今後使いまわせるやつ作った)、MosaicInfoのデータが無いのでNEM-coreのコードを書き換えて自力入力できるようにしたりなんか色々やったので大変でした。


 コードが散らばってしまって多分来月には何がなんやらわからない状態になっていると思います。


 気になったらTestNetでどんどん試しましょうね。場合によってはバグバウンティ貰えるかもよ。


 手数料の記事はリファレンスを信用するならあれで解ると思いますし、わざわざ書かなくてもいいかな...とか思ってます。


 あと、今回"実験1"としているのは単に将来用です。2があるかどうかはわかりません。