Skip to content

SIXIS

Symbol blockchain and more.

Menu
  • とろ速Symbol
  • 運用中ノードについて。
  • ノード設定
Menu

3. アカウント[感想編]

Posted on 2023年3月5日2023年3月5日 by 和泉

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

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

実施編はこちら。

さて。

Table of Contents

Toggle
  • アカウント生成・アカウントへの送信
  • アカウント情報の確認
  • 現場で使えるヒント
    • 暗号化と署名。
    • アカウントの保管

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

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

ある意味、アカウント生成とは秘密鍵(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では以下の感じです。

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

アカウントの保管

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

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

Continue Reading

Next Post:
3. アカウント[実施編]
Previous Post:
4. トランザクション

和泉/Izumi

活動内容や備忘録などを記していきます。
暗号資産のSymbol, NEMなど。

Recent posts.

  • 13. 検証
  • 12. オフライン署名
  • 11. 制限
  • 10. 監視
  • dHealthノードの構築および、引っ越しについて。

Categories.

  • dHealth
  • dHealth
  • Linux
  • とろ速Symbol
  • ノードイベント
  • ノード設定
  • 備忘録
  • 未分類
  • 運用中ノード

Archives.

  • 2023年12月
  • 2023年11月
  • 2023年10月
  • 2023年9月
  • 2023年7月
  • 2023年6月
  • 2023年5月
  • 2023年3月
  • 2022年8月
  • 2022年7月
Tweets by lynx2lion
©2026 SIXIS | Built using WordPress and Responsive Blogily theme by Superb