さてさて，「 適当技術解説-UTXOとは何か-1 」の続きの始まりです．
あ！いきなりここに来てしまった方は，前の記事を読んでから戻ってきて下さい．
また，より分かりやすくする為に少し書き足している部分もあるので，公開した段階で読まれた方は再読する事をお勧めいたします．
あれ，何の話をすると言っていましたっけ？？
確か，ビラビラ事UTXOの内部構造を解説していくという話でしたね．
技術的に難しそうな方向に飛んで行ってしまいそうな題材ですが，ここからもちゃんとイメージ優先で正確性は無視という方針をちゃんと継続をします．
詳細で正確な情報なんて何処にでも転がっていますから，一緒にガチドキュメントを読めるようになりましょう！
実はですねぇ．．前回記事でトランザクションに関する説明は避けるとか何とか書いてしまいましたが，ちょっと(大文)まずい事に，UTXOというのはトランザクション構造と深く結びついておりトランザクションなしではその真価を説明できない事に気がついてしまったのです．
だって，日本語訳(ほぼカタカナですがw)をすると「未使用の"トランザクション"アウトプット」なわけで．．．
にもかかわらず，新鮮お花畑野郎であるワイはトランザクションの話は避けるとか何とか言ってしまったわけです．
困りましたねぇ．．まぁワイも考えるのが面倒になったし正確性は犠牲にしてるという免罪符があるので，無理やりすっ飛ばしてしまいまうことにしました．
どうせ次のトランザクション解説の記事でしっかり分かる事ですし，イメージを掴む事が重要です．(適当ポジティブシンキングで行きます！適当技術解説ですから．)
いきなりですが，これが例のUTXOの内部構造です！
「Scrypt Pub Key」という謎用語が出てくる事を除けば，恐ろしくシンプルではないですか？
じゃあ，上から説明をしていきましょう！
金額は前回の記事にも書いた通りなので解説はいらないでしょうが，UTXOの額面の事ですね．
「Scrypt Pub Keyのサイズ」というのは，解説するまでも無くScrypt Pub Keyの大きさです．
で，最大の謎ワードは「Scrypt Pub Key」なのですが，よく図をみていただくと後ろに何かありませんか？
透過率50%ぐらいにされた南京錠が見えますよねぇ？
実はですねぇ，「Scrypt Pub Key」はこの南京錠の仕様書であり南京錠そのものなのですよ．
これを聞くと，『ええええぇええ？何で鍵の定義がこんなところに書いてあるんだよ．あんた散々南京錠でUTXOがロックされている図をみせてきたではないか！ビラビラとか何とか言って』と思う読者もいるかとおもいます．
でもねぇ，こういう事って情報処理界隈では良くある事なんですよ．オブジェクト指向言語やRDBMS(SQLのあれ)をさわった事がある人なら直ぐに分かるかとはおもいますが．．．ノンエンジニア向けの記事なので一応軽く触れておきます．
複数枚のビラビラ(UTXO)が一つの南京錠(アドレス)にぶら下がっている図を前の記事で見てもらいましたがコンピュータ内にそういう構造を作る場合，南京錠かビラビラの何方かにその情報を持たせる必要がある事はわかりますかね？
う〜ん
ちょっとここで，暗号通貨ネタから離れてみましょう．
上にも書いた通り，こういう構造は情報処理境遇ではよくある手法なのです．
まず下の図をみて下さい．
これは当店「コーヒーハウスハードボイルドオクトパス」の従業員管理システムの概念図です．
上段のネコ頭やウパ頭，お店のイラストの下の枠の中が実際にシステムに保存をされているデータを表しています．
当然これらはデジタルデータなのですが，紙のメモやノートと考えて頂いても差し支えはありません．
で，ネコ頭やウパ頭は自分のバイト先のお店を知っている反面，お店(側のデータ)は従業員の事なんて何にも知らないのです．
これは，従業員に特化した管理「システム」のごく一部の仕組みの話なので，「何も知らん」と書いてはいますが，勿論賃金体系等は別に管理をされていますよ！
当然メニューなども別に管理をしています！
細かい事は置いておいて，誰が我がコーヒーハウスで働いているかをお店側のデータに入れておく必要は必ずしもなく，働いている側に対応するデータとして保存をする方が都合が良い場合があるという事をぜひ感じていただきたいのです．
今は二人ですが，バイトの人数は変わるし変動もしますから，この方が簡単な気がしませんか？
元のUTXOの話に戻ると，UTXO(ビラビラ)が自分をロックしている南京錠(の設計図)を自分で保持しているのです．
上の例で言えば、お店の定義をバイト側のデータに保存しているような状況で違和感を覚えるでしょうが、正にお店は何にも知らない状況なんですよ。
勿論その南京錠は何らかの方法で定義されているデジタルデータなのですが，読者の中には「そりゃプログラミング言語で南京錠を作るって話だろ？」と先回りをして予想をしている方もいるかと思います．
まさにその通りで、(これをプログラミング言語と呼んでよいかは微妙ですが)ビットコインの場合はScriptという専用の言語で南京錠の設計図が書かれているのです．
Scriptの詳細に関してはいずれお話をしたいと思いますが，ビットコインに柔軟性を与えるという恩恵があるとだけここでは書いておきます．
例えば，安全性向上の為にマルチシグで保管したいのであれば，複数の鍵穴がある南京錠を定義すればよいのです．
勿論，ずっと複雑な物も当然定義可能です．
また，長くなってきたのとトランザクションの解説なしではこれ以上踏み込んだ解説はきびしそうですw
よってこの辺りで，この記事は切る事にします．
それでは！
