1. Iconic Projectとは何か
これは、物理的Symbol決済において、アカウントを物理媒体に保管し、決済に用いるパッケージの開発プロジェクトである。
第一に、人に使ってもらうなら自分で作ってもらおうでなく、そのパッケージそのものを提供すべきである。Web3においてはなんでもオープンソース何でも自己開発となりがちだが、あえて言おう。
それは無理だ。
今回の記事はSymbolのあんちょこというより、プロジェクトの墓標みたいなものなので、またひょっこり蘇ったらよろしくね。
2.第一次Iconic Project（2024/11~2024/6）
どうやったらワンタッチでトランザクションができるか、簡単に考えつくのがNFCの活用だろう。
ちょっとアイテムをAmazonで買ってトライすること2ヶ月くらい、完成したのがこちら
第一次Iconic その１
第一次Iconic その２
第一次Iconic カード
<リンクはX>
死因
1. 裸の秘密鍵を晒さざるを得ない
当然のようにNFCカードだけではプログラムを動かせない以上、決済アプリで署名せざるを得ない。すなわち自分の秘密鍵を他人の端末にさらすことになる。これではセキュリティもへったくれもない。
2.時期が悪かった
他の人とSymbol決済に関してネタが被った。
3.開発費用の高騰
NFCカードは（第二次Iconic Projectに用いたjavacardに比べたら）まだ安い。これ以上の開発費の高騰、デバイス費用の高騰がなされては、クラファンをやっても買い手がつかない
3.第二次Iconic Project(2025/7~2025/11 休眠中)
そうはいっても個人事業主、やらねば金にはならない。こうして240ユーロ払って問屋で仕入れたJavacardを使って開発を始めた。
第二次Iconic その１
一応展示会には 「はりぼてだが」 サンプルを持って行った。
展示会 写真
<リンクはX>
死因
1.計算能力がなさすぎる
一般的に皆さんが使っているようなクレジットカードはjavacardと呼ばれているように、javaで動いている。しかし、これの計算能力は群を抜いて制約されている。
Symbolの署名形式Ed25519は、long(16進数16桁)に収まるような足し算や引き算、掛け算を行い、処理をしていく。当然この際には整数型はlongであることが望ましいし誤差がない。たまにintで収まるならintでもよい。
しかし、javacardはshort(16進数4桁)の整数型までしか使えない。4桁しか使えないということは、掛け算を記録できる範囲は、「2桁*2桁」までである。そうなるとどうなるか
long:003278E5C69BDA41
という数字は
short[]:{0032,78E5,C69B,DA41}
という形で管理運用しなければならない。マイナスの値が出た日には運用はめちゃくちゃである。
2.パッケージ化に問題がある
皆さんがパソコンで使っているICカードリーダーライターをUSB-Cポートに変換ポート経由で挿してもうまくいかないみたいなのはあるだろう。要するに汎用の通信運用（CCID）とその機器の開発企業が専用で出しているプラグインを用いた通信運用（CCID）があるのだが、汎用のCCIDを運用するFlutterのプラグインはパソコンでしか使えない。このデバイスをiPadのレジ端末で使うならこの機器を買ってくださいねではどうもやりづらい。
3.実力不足
今回はあまりにもわからなかったので、ChatGPTとの二人三脚でコードの翻訳、実装を行った。だがChatGPTのコーディング力は、自分がコーディングを想像できないなら適切な指示を出せない。解決は自分が考えつかなければ進まない。
4.第三次Iconic Project？
じゃあ、マシン作ってみるか...？
5.将来
Javacardによる物理ウォレットは、今は無理だが時間で解決は一応可能だ。なんと現在のjavacard3.0.5からjavacard3.1になったら汎用のプラグインでEd25519が使えるようである。EVMの署名形式であるECDSAよりは比較的汎用的な暗号化アルゴリズムなので、Symbol決済の物理カード化はEVMよりもチャンスはある。また、一応チップメーカー（NXP）と機密保持契約さえ結べれば現状のJCOP4.5相当のjavacardでもEd25519署名は可能である。
それだけ需要があるんだったらなぁ
6.謝辞
個人事業主でしかない私にJavacardを売っていただいたMoTechnoのHanno Sponholzさんには感謝してもしきれない。開発の沼へ進むなら、ここで買ってテストをしないか...
MoTechno