# nem / symbol Advent Calendar 2025 記事レビューするぞ

## カレンダー

- [nem / symbol Advent Calendar 2025](https://qiita.com/advent-calendar/2025/nem)

## Day1

[KeyStoneの目指す世界 \#Blockchain \- Qiita](https://qiita.com/inatatsu_csg/items/b59881eeed4f4a70c9cd)

署名アプリとしてはSSSが界隈では有名ですが、それのアプリ版みたいなもので、機能的にはアドレスのビューアなんかも備えていて、ウォレットに近いものといっていいかも。
ベータテスト中ということで参加させてもらって、触ってみています。

仕様に即した実装を行ったWebサイトをリストに登録すると、アプリ側で署名をして、署名済みトランザクションを返却するという動作をするため、Webサイト側で秘密鍵やトランザクションへの署名操作をしなくてよかったり、その責任を回避できるというもの、ということでいいと思います。

例えばWebサービスを運営している側として、サービスとして必要な形式のトランザクションをユーザーに求めたい場合に、秘密鍵についての責任を持ちたくはないでしょうし、持つべきではないとも考えられるので、KeyStoneやSSSを始め、Webサイトとウォレットの連携というのはもっと浸透させて、WebサービスへSymbolネットワークを組み込む型みたいなものを作り込んでいきたいですね。

トランザクションへの署名というのは、暗号通貨界隈ではずっと課題があると思っていて、知る限りでは理想的かつ現実的なソリューションはまだないよなぁと思ってます。

近いのは…やっぱりハードウェアウォレットかなぁ。
とにかく、技術的に安全な場所で、入力としてトランザクションを受け取り、署名だけを行って、署名済みのデータを返す、という仕組みを誰でも簡単に低コストでできるようになって欲しいですね。

最近はBitcoin向けでSeedsignerってのが有名っぽいですが、これはRaspberry Piと小さなディスプレイの組み合わせで自作できるハードウェアウォレットですね。

https://github.com/SeedSigner/seedsigner

カメラからトランザクションを入力し、ディスプレイで署名結果を返す、エアギャップな方法でやりとりをするので、現時点で考えられる方法として一番安全なんじゃないかと思います。

Trezerのように、買えば使えるという製品は結局その販売元がどれだけ信用できるか、という問題がつきまといます。
OSSソフトウェアを自分でインストールするのであれば、第三者もソースやバイナリを検証できますし、その面については、若干神経質かもしれませんが、ある程度は安心といえると思います。

これのSymbol版は欲しいですよね。
ハードウェアは日本国内だとちょっと揃いづらいらしいですが、一般的に売っているものですし、ソフトウェアさえ作れれば出来ちゃう気がします。

KeyStoneからちょっと話がそれてしまいましたが、Webサービスやサイトが要求するトランザクションの解決の手段として新しいものが出てきたのは期待が高いですね。

## Day2

[symbol\-qr\-libraryをNode\.js v22&ARM Macに対応させた話 \#Symbol \- Qiita](https://qiita.com/_oe/items/95ba9472dde615aa3e48)

自分はあまり詳しくは知らないけど、SDK v3が公開されたころから、結構なコミッタやメンテナがSymbolを離れちゃったみたいで、この辺の周辺ツールは軒並みメンテが滞ったままになってるんですよね。
しかも今となっては、対応ランタイムも古いし、暗号通貨として一番気を使って欲しいセキュリティにも不安を抱えちゃってるので、野放しにはなっててほしくはないですね。

この記事では、ランタイムでの苦労から、古いネイティブ拡張を廃して、PureJSで実現してくれたおかげで、フロントエンドでも使えるものに仕上がったのと、ESM対応でモダンなスタックを実現できたということで、素晴らしい実績だとおもいます。

## Day3

[【未解決】ARM環境でSymbolノードの同期中に「Too many open files」エラーで停止する \#oci \- Qiita](https://qiita.com/_oe/items/157fa2a0fa96082664f0)

Symbolもメインネットがローンチされて数年立ちますし、ブロックデータの問題も話題に上がったことがありますが、故に同期がうまく行かないということも発生しつつあるようですね。
まぁ割と初期にもあったような気はしますけど、データアーカイブからの復帰など、ノウハウも溜まってきたので、あまり苦労することは無くなってきたみたいではあります。

そんななか遭遇した問題のようですが、結論から言うとDockerに問題があるらしいですね。
バージョンを戻したら解決したとの情報もあります。

まぁその意味でもDockerに依存しているという状態でもありますね。
Dockerも便利ではありますが、もしノード専用で動かすサーバなら、直接インストールして動かすというのもありな気はします。

ただ、そのノウハウはあんまり共有されてなく、挑戦している記事もあった気はしますが、どうだったかな…。
もちろんそれはそれでまた色々とトラブルがありそうな気もしますが、セキュリティ的にも、なるべくシンプルな構成にできるなら、その方が望ましいですよね。

## Day4

[Everyday Symbol　リニューアルサイト作ったよ \#Blockchain \- Qiita](https://qiita.com/Radio-Radio/items/8a31ce011460f8ba44a3)

EverydaySymbolというSymbol決済を導入してくれているお店のサイトを元の運営者が都合上で止めるところを引き継いで継続するという話でした。

私自身は正直なところ今はなきnembarで数回やったくらいで全然していないので肩身は狭いんですが、こうして導入している人たちがいることにはとても感謝しかないですね。

単なる決済手段に加えて、チェーン情報を活用したアイディアへと展開していけたら、よいユースケースとなり、広まっていく可能性は十分あるんじゃないかと思います。

## Day5

[Typespecでnem / SymbolのAPI定義を構築している \#WebAPI \- Qiita](https://qiita.com/husqva_luna/items/f1e3cef0e346ab080323)

こちらはSymbol REST APIの再定義の話ですね。
確かにコアデブからOpenAPI定義があるんですが、5,000行くらいあって開くとエディタが重くなるんですよね。
まぁ、そもそもあんまり見ることが多いわけじゃないんですけど、たまにバグっぽいのを修正したいなと思っても、そういうところでちょっと気持ちが萎えるというか。
私事として、別件でyamlを扱った際にも、ちょっと取り回しが難しかったり、分割しても管理しにくかったりで、一枚で収まる程度なら全然いいんですけどね。
Typespecはその辺Typescriptっぽくかけるみたいなので、型定義も持ち込めて安全に編集できて良い感じですね。
JsonschemaやProtocolBufferの定義にも対応しているようですし、応用の幅がありそうな言語ですね。
まだプレビュー版ですが、クライアントソースの生成もできるようなので、TypespecからJSなりJavaなりPythonなりのクライアントコードが出せるようです。
これについてはOpenAPIでいったん吐かせて、それをZODとかOrvalとかクライアントコードを生成するライブラリは他にもあるので、それを使えばいいって話かもしれませんが。

## Day6

[【NEM】スプレッドシートで既得バランスの獲得予測をする \#NIS1 \- Qiita](https://qiita.com/_oe/items/1dfd98367d7e516f01d9)

こちらはnemの話になりますが、委任ハーベストが可能になるまでの日数を仕様に基づいてわかりやすく表現するということで、
まぁ自分は言ってしまうとあんまり意識したことがなくて、ええい、どうせ安いんだから10万xemくらい買ったらぁと思ってホールドしてたので、
あんまり気にしたことが無かったですｗ

今後どうなるかわかりませんが、いまは…xemは0.2円とかなのでワンチャン期待して、10万xemくらい買っといたらいいんじゃないですかね。
自分が初めて買ったときよりよっぽど安いので。
そしたら、ぜひこの記事のシートの実装を使って計算してみて日数を出してみてはいかがでしょうか。

## Day7

[【NEM】XEM送金後の既得バランスを計算する \#NIS1 \- Qiita](https://qiita.com/_oe/items/b066ed2339774b856ebe)

引き続いて既得バランスの話です。
ちゃんと仕様を把握して計算ロジックに落とし込んでいるのはこちらも素晴らしいですね。
自分はハーベストするウォレットと送受信するウォレットはわけて扱っていたので、気にしたことがありませんでした。

まぁ頻繁にやり取りをしたほうがインポータンスが上がるんだったかで、ハーベストしやすくなるから、
既得バランスを管理しながら資産移動をしていると、効果的な運用が可能かもしれませんね。

## Day8

[【NEM】既得バランス1万XEMをキープしたまま送金できる額を計算する \#NIS1 \- Qiita](https://qiita.com/_oe/items/8ed8371ab3fc60764360)

続いて、委任ハーベスト条件を切らずに送信するための管理方法の指南ですね。
もうnemの仕様は忘れかけてますが、確か条件を割ってしまうと、再委任するためにまたトランザクションを
出さないといけないので、単純に手数料分だけロスするし、割っている間は当然ハーベストできないので、重要ですね。

## Day9

[【NEM】ハーベスティングが無効になったことを通知しよう \#NIS1 \- Qiita](https://qiita.com/_oe/items/1f881ebb3751971563e3)

もうちょっとnemのハーベスト仕様を忘れてしまったので、記事の内容をお借りしますが、
たしか、委任しているサーバ側の都合で委任が外れてしまうことがあった気がしますね。

こればかりは自分から気が付いて、再委任しないと行けないので、それをGASをつかって
監視＆通知しようという話ですね。

まぁSymbolでは復帰できるようになったものの、手順をしくじると外れちゃうみたいなので、
ちょっと自分はノード運営はエアプなので、そうらしいくらいにしかわかんないんですけど、
そこらへんはづーさんの活躍でだいぶ安定しているので、感謝しかありませんね。

最近は結構ノードを辞めちゃう人がちょくちょくでていて、まぁ価格を考えたら厳しいよねというのはそうなんですが、
個人的にはハーベスト報酬を得て、それをノードの運用費に当てるというのは、どうしても
売り圧にしかならなくて、それを打ち返すくらいに実需が伴わないといけないと思うので、
まぁどこかでバランスが取れるようになり、かつみんなが納得できる状況になってほしいなぁと思いますね。

## Day10

[Iconic Projectはなぜ一度滅びまた蘇りまた眠りについたのか \#Java \- Qiita](https://qiita.com/choconaak/items/010aface045a69914abf)

choconaak

NFCカードによる決済に挑戦したという記事ですね。
こちらも、いかに署名を安全にかつ気軽にできる環境を作り出そうという試みだと思います。
結果として、実現しきれなかったということですが、その挑戦と結果には十分価値があったと思います。

そういった制約が大きいハードウェアを扱う経験はないので、あまりちゃんとした意見は言えないのですが、
追記にある、ETH用のkeycardというのは気になりますね。
単なる決済だけでなく、Symbolのトランザクションをフックとしたサービスがカードを差し込んだりタッチすることで承認される、
という世界観は実現してほしいことの一つではあります。

まぁ全然知らないんですけど、stXEM,stXYMが出回り始めたら、これで扱えたりもするもんなんですかね。
だとすれば、ETHの力を借りられるという意味では何か大きなことが起こるような気がしなくもないですね

## Day11

[ExpoGo\+Symbol\-SDK \#reactnative \- Qiita](https://qiita.com/ccHarvestasya/items/2fbf267c819af69da2fe)

ccHarvestasya

この手のフロントエンドでSDKを使うためのハックやテクニックはv2のころからちょこちょこやってきたりはしましたが、
いかんせんめんどくさいし、バッドノウハウの塊感があって、あまりやりたくないんですよね…。

JS周りのビルドツールも気を抜くとトレンドがあっという間に変わるので、また手探りで設定を探さなきゃだし…。
V3のREADMEには一応webpackだったかな、サンプルコードはありますが、いまはもうviteですし、
またなんか違うのが流行るとか流行らないとか…

署名ロジックのためにNodeJS側のビルドインやライブラリに依存しているため、それをフロントエンドエンド用の
機能で置き換える、というハックをねじ込むわけですが、
なんかこう、あんまり変なことせずに、簡単にできるような状態に持ってって欲しいところですね。

## Day12

[【Symbol】初めてのブロックチェーン開発でも作れる！Webウォレットの仕組みをコンポーネントごとに徹底解説 \#JavaScript \- Qiita](https://qiita.com/mikun/items/b04c240b927e7f45e44a)

mikun

SSSを使ったウォレットアプリの作り方についての記事ですね。
KeyStoneで話題にしたように、署名ロジックを扱うということは、秘密鍵やニーモニックなどを扱う責任が発生するということです。
これらは当然に厳重かつ安全に保管されなければなりませんが、そのためにはそれなりの知識も持ち合わせていないといけません。

そこで署名ロジックはSSSに移譲することで、その辺りを作り込まなくてもいい、その意味で気楽にウォレットを作れるよ、という話です。
サービスごとにオリジナルのウォレットを提供するということも、ハードル低くできるかもしれません。
さっそくKeyStoneでの実装サンプルもあるので、ぜひ参考にしてみてください。

## Day13

[ノリと勢いでNodeWatchを入れてみた \#NEM \- Qiita](https://qiita.com/ccHarvestasya/items/e74928435d88f97d0f08)

ccHarvestasya

最近ノード築城はすっかりやっていないのであまり現状を知らないのですが、どうもshoestringを動かすためには、特定の監視サーバへのアクセスが必要みたいです。
みたいなんですが、そのサーバがたまに落ちてたりするせいで、shoestringが動作しない状態にハマってしまうということです。

そのAPIを提供するNodeWatchはソースが公開されてはいるものの、あんまりちゃんとしたガイドはなかったので、
てさぐりで動かすことに成功したとのことです。

こういうところもなー、もうちょっとどうにか、ちゃんとしたガイドをかいておいてくれよなー…という気もしつつ、
みんな愛があるからこそ、解決しちゃうんだよな、って気もします。

## Day14

[Symbol meets n8n: Blockchain apps with no code \#NEM \- Qiita](https://qiita.com/zero4862/items/fddd2963a16047ce8330)

@zero4862

ビジュアルで流れが見やすいのはいいですね。
以前にはnode-redというビジュアルプログラミングツールを使った実装もありました。
https://flows.nodered.org/node/node-red-contrib-blockchain/
n8nは初めて知りましたが、これも同じようなツールなのかな。

記事にもあるように、まぁだいたいのコードの型って決まっているので、テンプレ化して使い回すのはみんなやってると思います。
なんならサンプルコードをコピペしたっていいくらいですし。

実験的にブレッドボード的な使い方で、一連の処理を組んでみてプロトタイピング以前の検証が素早くできそうです。

個人的には後半の、教育目的で流れを説明するために有用である、ということは気になりました。
確かにコードと動作だけ見せられても、理解してもらうのは難しいかもしれませんし。
そういう用途ではビジュアルプログラミングって強いですよね。

## Day15

M5Stackで作る地震速報モニター #M5stack - Qiita https://qiita.com/ishidad2/items/f07e4bee4dbe08b3c151

トランザクションのメッセージペイロードに記録された地震情報をM5Stackというマイコンボードを使ってビジュアル化する記事ですね。
諸々の実装が手のひらサイズに収まっていて、モニタまでついているので、比較的簡単にインターネットと組み合わせた
DIYモジュールを作成できるらしいですね。あんまり知らないのでこれくらいで。

アドレスやトランザクションをwebsocketで監視しているとのことですが、
どうしてもコネクションを貼り続けないといけないので、
やっぱりアドレスに届くトランザクションのプッシュ側の通知は欲しくなりますよね。

理屈で言えば、ノードのサーバにWebプッシュやWebフックなんかを組み込むことはできると思いますし、
その通知サービスの購読料でxymを払わせるとか、モザイクの所持とかフラグでとか、色々できそうな感じがしてきます。

## Day16

Using an AI Agent as a Smart Contract on Symbol

Symbolチェーンには地震の情報が即座に記録されているので、それを検知して寄付としてトランザクションを発信できないか、という試みの記事でした。
Symbolにはいわゆるスマコンという、ロジックをデプロイし、ブロックチェーン上（厳密にはロジックの結果を反映するかをノード間で合意をとる）で動かすという機能はないわけですが、それをAIエージェントで代替しようというアイディアです。

記事にもある通り、

> 本記事で紹介した仕組みは、**完全でもトラストレスでもありません**。
> しかし、AI・IoT・Symbol を組み合わせることで、社会的に意味のある仕組みを作れる可能性を示しています。

個人的にはこれこそがSymbolとしての役割だと思っていて、既存の動作する仕組みと組み合わせるには必要十分なプロトコルであり、それらがブロックチェーンの美味しいところだけを使えるからいいと思っています。

確かに、サーバレスな仕組みがノード上で勝手に動いてくれたらなぁ…と思うことは結構あるにしても、スマコンが欲しいとまでは思わないというか。
いわゆるスマコンのことについてあまり知らないので、そう思ってるだけの節はありますが…。

それはそれとして、AIとのやり取りというのは切り開いていきたいところではありますね。
例えば自然言語で説明したとおりのトランザクションをAIが構築し、それに対する署名をユーザーに求めてくる、みたいなMCPサーバなのか、エージェントなのか、そういうものとか。
流石に秘密鍵を預けるのはまだ危険だと思うので、こういうところでもKeyStoneだったりエアギャップに署名できるハードウェアなんかは役に立ってくるんじゃないかなと思ってます。

## Day17

[symbol\-sdk v3\.3\.0逆引きリファレンス \-\- アカウント/アドレス/ニーモニック編 \#Symbol \- Qiita](https://qiita.com/yanchi4425/items/f154ab02634442ba9e6b)

SDKの使い方についてですね。
この辺のアカウント、公開鍵オブジェクト、アドレスオブジェクトの相互変換や導出は結構使います。
微妙に面倒だな、と思っているのはAPIレスポンスが16進数形式だから一旦変換するとか、そういうときはよくありますね。
まぁ、素の値をオブジェクトでラップしてしまえば色々なメソッドが使えて便利なので、変換の仕方は把握しておくと便利です。

## Day18

symbol-sdk v3.3.0逆引きリファレンス -- トランザクション編 #Symbol - Qiita https://qiita.com/yanchi4425/items/92aa60d4cb4deaed597e

続いてこちらはトランザクション編。
この辺も頻出なスニペットですね。この辺りの基本がわかればもう８割は使いこなしたも同然でしょう。

メッセージの部分についてはちょっと気をつけないといけないんですよね。
最初の1バイトがフラグになっているので、これ次第でSDK側での解釈が変わってきてしまいます。
SDKを使わずに値を扱うのであれば、直接文字列をぶち込んでしまってもいいんですけどね。

v2,v3で互換性を保つためのテクニックも時には必要になるかもしれません。

そしてアグリゲートトランザクションも、通常のトランザクションをラップすることが主たる機能なので、
他のトランザクションも個別にクセはよく理解しないとですが、
基本トランザクションとの組み合わせ方さえ把握していれば、9割は使いこなしたも同然ですね。

## Day19

symbol-bootstrapによるノードのアプデ不具合を九州勢で未然に防いだ話 #Symbol - Qiita https://qiita.com/_oe/items/5fe3fcb554038cd7bb3d

今年９月でハードフォークを伴うために、ノードの更新が必要だったとのことで、
ノードの設定を簡単に管理できるようにするツールを使うのが安心安全なんですが、
ちょうどこのあたりではまだ、古いsymbol-bootstrapから新しいshoestringというものへの以降の過渡期の間みたいなタイミングで、
まだまだsymbol-bootstrapだよりって状況だったと思います。

ただ、公式にはsymbol-bootstrapはもうメンテされていないから、どうしたもんかと。
もうこんなの普通にコアデブがボコられたり見放されてもいいレベルなのにみんな愛がありすぎますね。

原因はcrypto-jsという依存していたライブラリに破壊的変更があったためとのことですが、
セマンティックバージョニングも当てにならんよね、って感じで、
実際、もうセマンティックバージョニングやめようみたいな話題もどっかであった気がします。

また、悪意あるコードを埋め込まれたバージョンを意図せずインストールしてしまったりするから、
バージョンは固定したほうがいいとか、pnpmにはそれを防止する機能みたいなのがあるとかないとか。

暗号通貨界隈に限らず、昨今は妙なコードが仕込まれるということをよく聞きますので、
仕事でも趣味でもOSSでも、油断が許されない状況になっていて気を引き締めていかないとですね。

## Day20

Symbolでゲームを作ってみた話
https://thesymbolsyndicate.notion.site/building-a-game-for-symbol-jp

> 実験1：XYM Doom

> 学んだこと
> コインを即座に使う必要がなければ、プレイヤーは「すぐに残高に反映されなくても気にしない」

こういうのをブロックチェーン寄りで考えてしまうと、そんなのは意味がない、中央集権的とか言われそうですけど、これもありだと思ってて、
最終的にちゃんと結果をトランザクションに乗せてくれればそれでいいんじゃないかと。
それがうまく動かなかったなら、バグなのか仕様なのか、ちゃんと対応すればいいことであって。
先進的なブロックチェーンな思想からはちょっと前時代的かもですけど、でも今はそれで世の中は動いているわけで。

> コインはまとめて処理（バッチ処理）しないと、トランザクションを乱発し、手数料が無駄に増える

それもそうですね。運営側でも利用者側でも、チェーンのストレージについてもですが、まとめられるならその方がコストは小さく済みますね。
それでいうとトマティーナは、あれは確か、一発を１トランザクションで投げてるんでしたっけ、すごくトランザクションが出てた気がしますが。
FPS風でしかも被弾でそれをやるっていうのは、なかなかおもしろいですけどね。
ゲームの性質次第では、都度トランザクションが飛んでもいいでしょうし

実験2：XYM Quake

ついこの間、Meta quest 3Sが40,000円くらいだったので飛びついて、遊んでて、
バーチャル鬼ごっこに参加したもののVR酔で全然遊べなかったりしたんですけど、
こういうワールドがVRCやClusterにできて、集えたらいいですよね。

記事を読む限りだと、ブロックチェーンいる？って構想には見えるものの、個人的にはこれで良いと思っていて、
ゲームなら、ゲームとしてちゃんと作り込むほうが、シンプルに楽しいと思うし、変にブロックチェーンの仕様に囚われなくていいと思います。
あくまでも、外部に状態を持たせてそれを活用するような、DLC的な、仕組みで、無くても動くけど使うと楽しいみたいな。
もちろんブロックチェーンを前提としたものでもいいんですけど。

ブラウザで動作するカジュアルゲームはそれを公開するプラットフォームも結構あるので、そこの規約次第ですが、アドレスのモザイクを活用して、
ゲームの遊びが広がる、みたいな仕組みとかも出来そうですし、
それのプレイ配信を見た視聴者がその機能を試したさにブロックチェーンに興味をもって…みたいな流れも出来たらいいですよね

## Day21

Knights of MonadomみたいなのをSymbolで作っていきたい #ブロックチェーン - Qiita https://qiita.com/nizveyl/items/98203e0faf1ef5a98ee1

はい、久しぶりに色々書きました。
やっぱモノを出したいからどうにか一応動くものは出しました。
ちょっとでいいから遊んでみて欲しいです。
あんまりできることはないけどね…。

最近モナダムを色々遊びつつどういうものなのか着想を得たりしてたんで、こういう形になりましたが、
本当に言いたいのは長ったらしい後半のポエムの話で、
要するにもっとみんなモザイクを動かしていくような動機を提供していこうよ、
それがSymbol経済圏に参加することそのものじゃないかという
問題提起というか、電波文書がそれです。

結局どんなにどんぐりを溜め込んだって、現金を溜め込んだって、それを欲しい別のなにかと交換できなきゃ意味ないわけで。
結局当たり前のことでしたが、書き散らしているうちに気が付きました。
逆にいったら書く必要もなかったことかもしれませんが、
なんかブロックチェーンだのトークンだのということに囚われていると
逆にそのことを忘れてしまってないかということに気が付かされた気がします。

## Day22

速習Symbol JavaScript版 Symbol-SDK-V3 versionを書籍化した際の、v3.3.0対応による変更点 #Blockchain - Qiita https://qiita.com/h_gocchi/items/5ec0b616e50b577c1ee3

速習Symbolのお話ですね。
申し訳ないんですが、だいたいのことはコミュニティの記事やソースコードの型情報や実際の実装を読んでやってしまうため、手に取ったことがありません。

評判はいいようですし、原典はxembook氏がv2時代に書いたものをベースにしているとのことで、十分信頼に値すると思います。

V3はV2から大きく刷新され、それ相応の破壊的変更ではありましたが、
構成を見る限りスリム化し、かつより現代的な実装に仕上がったように感じます。

まぁ個人的にはnemとsymbolは切り分けたパッケージにして、更にシンプルになったらいいな、とか思うところはありますが、まぁ何らかの思想や構想があるんだろうと思います。

本書はJS版ということで、たしかPython版も出してたかな？SDKとしてはその２言語がコアデブからはリリースされているわけですが。

スリム化したSDKはより抽象的なインターフェース定義だけに昇華して、データ仕様とか、補足の情報をまとめてAIに喰わせたら、言語ごとのコードが出てきそうな気がしますね。
それが各言語でお作法に則ったものかどうかは…また別問題がありそうですが。

でもそういうことがわりと現実的にできそうなくらいバイブコーディングもこの１年で実用的になりましたし、来年はどうなってしまうんだってくらいなので、そういった方法で各言語のSDKを作り出すことも出来そうですね。

## Day23

アグリゲートQR #Symbol - Qiita https://qiita.com/kicnft/items/7bc48b9dfc265541b5df

アグリゲートトランザクションのペイロードを直接相手へ渡して、署名をもらうことで連署を完成させるためのツール、ということでいいかな。
アグリゲートトランザクションのうちで、アグリゲートボンドトランザクションは、
ブロックチェーンネットワーク経由で相手のアカウントへ直接署名を求められますが、
10xymのデポジットが必要だったり、タイムアウトするとデポジットがハーベスト報酬として流れてしまうということがあります。
まぁこの辺は、相手が署名する動機が十分ある取り引きであれば、そういったことはないとは思いますが、
仕組みとしてはそういう感じになってます。

アグリゲートコンプリートトランザクションは署名データが手元にあれば、それを組み込んで、トランザクションを成立させることができるので、
トランザクションをQRコード形式で共有するツールってことですかね。

見た感じ、ツールの機能としてはトランザクションのペイロードをQRコードの形である程度のサイズで分割・結合するだけの機能のようなので、
SNS上でという例示もあるので、データを共有するに限られたデータ量でしか連絡できないケースで使うものですかね。

もし、誰かから署名を貰おうと思ったら、QRでもテキストでもとにかく相手がそれに署名して、署名データを取り出せるそういった
アプリが必要だと思うので、QR連続リーダーに署名機能があるか、もしくはウォレットアプリにこの機能が乗っているか、
って状況で成立するのかなと思って。
で、署名データをDMでもメールでも何らかの形で渡して、署名を組み込んで、成立したらアナウンス、って流れになるのかな。

あえてアグリゲートコンプリートトランザクションを何らかの形で晒して、関係者がそれに署名して送り返して、ってことが
仮にパブリックな場で行われたとしても対象となるアカウントでなければ署名は作れないし、署名自体は改ざんできないし、
結果は公開チェーンだから誰でも見れるので、あえてこういう事をすることでできる演出や仕組みのアイディアがあると
面白そうですね。

## Day24

メタデータキーを連番管理する #Ethereum - Qiita https://qiita.com/inatatsu_csg/items/de0408b20e07d52571f1

皆さんご存知のように、アカウントとモザイクには、メタデータという任意のラベル名とそれに対する文字列を設定する機能があるわけなんですが、
ちょっとプログラミング的な話になりますけど、例えば、`abc`というラベルをつけようとした際に、
実際にその`abc`のままチェーンに記録されるのではなく、SDKを用いる場合はそのSDKのアルゴリズムによって作られる数値で記録されるんですね。
例えば、これは正しくないんですが、`abc`というラベルなら`123456`みたいな。
なので、文字列のラベルで値を管理する場合はこうなるんですが、最初から数値で管理するって手もあるよねという話です。

今まで盲目的にSDKのサンプルに従っていましたが、確かにそのとおりで、そういう表現も可能でしたね。盲点でした。
もちろんそれが適切にワークするケースや逆に良くない結果を及ぼすこともあるでしょうから、結局は使いようという話ですが、
選択肢の一つとして把握しておくと役に立ちそうです。

## Day25

2025年のSYMBOL界隈を映像で振り返る😎🌻🎥｜花畑
https://note.com/hanabata_ke/n/n54515366fb26

今年も一通り年内のまとめありがとうございます。
下火どころか灯火レベルのブロックチェーン界隈、限界集落Symbol村ですが、なんやかんや結構いろんなことがありましたよね。
こうして続いている事自体がありがたいことだし、歩みは遅くとも堅実に積み上げていることは確かだと思います。

stXEM/stXYMが発表され、これはETHの能力を借りる形でnem/Symbolを拡張できる、ということだとも考えていて、
なおさらSymbol村のコンテンツをやっていき、魅力を高め、外部からの流入を盛り上げることが求められるチャンスでもあると思います。

来年は自分からも何かコンテンツ提供をしていきたいと思っていますし、
色んな人が入ってきてくれることを期待したいですね。

------

# パート２

## Day1

[Symbol上で誰もが検証できるERC1155相当を実現するアプリケーションレベルプロトコル \#Ethereum \- Qiita](https://qiita.com/bootarouapp/items/300a15cfd819180819b7)

## Day2

「KeyStone」をTypeScript/Reactで快適に使う型定義＆サンプル #Symbol - Qiita https://qiita.com/ccHarvestasya/items/23097ff2d33935502f7e

SymBreakは早速KeyStoneでのログインも対応させてもらいましたが、その際ちょうどこの記事が公開されていたので、せっかくだから取り込ませてもらいました。

`@ts-ignore`で誤魔化してたところがスッキリ解決しました。
ありがとうございます。

------