連合による固定 - 今日からビットコイン以外も取り扱うブログに生まれ変わりましたが、いかがでしたでしょうか？

連合による固定（federated peg）を用いてMonacoinのプロトコルには全く手を入れないでMONAをMonacoin以外の副ブロック鎖の枠組みに対応しているブロック鎖に移動する方法（更に、移動したMONAを元のMonacoinのブロック鎖に戻す方法）について考えてみました。

先ず最初に結論を書くと、「原理的には可能だが、現実的には難しい」と思われます。

連合による固定では固定（peg：2つの異なるブロック鎖で（少なくとも一方的に）貨幣／資産を移動できるようにすること）を実現するために職員（functionary）と言われる者を利用することになります。

話を簡単にするためにMonacoinのブロック鎖上にあるMONAをCREACOINのブロック鎖に移動し、（移動後にCREACOINのブロック鎖上で何度か取引を行い）、最終的にCREACOINのブロック鎖から元のMonacoinのブロック鎖に戻す場合のみを考えることにします。CREACOINは副ブロック鎖の枠組みに対応しているものとします。
また、（本来は複数人が必要ですが）職員は1人のみであるとします。

この場合の連合による固定によるCREACOINのブロック鎖へのMONAの移動は次のように行われます。

0（準備）.職員は秘密鍵を生成し、秘密鍵から公開鍵を生成し、CREACOINのブロック鎖へのMONAの移動を希望する者（以下「希望者」と言う）に向けて公開鍵を公開する。
1.希望者は職員の公開鍵を取得する。
2.希望者は使い捨ての値（nonce）を無作為に生成する。
3.希望者はCREACOINのブロック鎖側のどの口座番号（address）（以下「移動口座番号」と言う）にMONAを移動させたいか決定する。
4.希望者は使い捨ての値と移動口座番号を結合したものを用いて職員の公開鍵から新しい別の公開鍵（以下「使い捨て公開鍵」と言う）を生成する。
5.希望者は使い捨て公開鍵のSha256Ripemd160要約値（＝使い捨て公開鍵に対応する口座番号）を計算する。
6.希望者はCREACOINのブロック鎖に移動したいMONAを使い捨て公開鍵に対応する口座番号に送付する。
7.希望者は職員にMONAの移動要求を申請する。この時に、使い捨ての値と移動口座番号と6で送付したMONAの簡易決済検証証明（simplified payment verification proof：SPV proof）を添付する。
8.職員は自身の公開鍵と希望者から受け取った使い捨ての値と移動口座番号から使い捨て公開鍵（4で生成されたものと同じになる筈）を生成する。
9.職員は使い捨て公開鍵のSha256Ripemd160要約値（＝使い捨て公開鍵に対応する口座番号）を計算する。
10.職員は使い捨て公開鍵に対応する口座番号にMONAが送付されているか確認する。送付されていない場合は希望者に「MONAが送付されていない」旨を通知し、業務を終了する。送付されている場合は業務を続行する。
11.職員は簡易決済検証証明を検証する。無効である場合は希望者に「簡易決済検証証明が無効である」旨を通知し、業務を終了する。有効である場合は業務を続行する。
12.職員は移動口座番号にMONAを移動する取引を作成し、CREACOINネットワークに流す（この取引には簡易決済検証証明が添付され有効かどうかが検証できる形になっている）。
13.職員が間違えない限り12の取引は有効で、CREACOINネットワークのノードによって有効であると承認され、最終的には採掘されたブロックの中に格納される。
14.12の取引がCREACOINのブロック鎖のブロックの中に格納され、ブロック鎖分岐がまず発生しないと言えるほどに十分な時間が経過したら、職員は希望者に「MONAの移動が完了した」旨を通知する。
15.この時点で希望者はCREACOINのネットワーク（ブロック鎖）の方でMONAを使用できるようになっている筈である。

CREACOINのネットワーク（ブロック鎖）の方で当該MONAの取引が何度か行われ、Monacoinのブロック鎖へMONAを戻す場合は次のような手順を実行します（上述の手順とほぼ同じですが一部違いがあります）。

16.Monacoinのブロック鎖へのMONAの移動を希望する者（以下「希望者」と言う）は職員の公開鍵を取得する。
17.希望者は使い捨ての値（nonce）を無作為に生成する。
18.希望者はMonacoinのブロック鎖側のどの口座番号（以下「移動口座番号」と言う）にMONAを移動させたいか決定する。
19.希望者は使い捨ての値と移動口座番号を結合したものを用いて職員の公開鍵から新しい別の公開鍵（以下「使い捨て公開鍵」と言う）を生成する。
20.希望者は使い捨て公開鍵のSha256Ripemd160要約値（＝使い捨て公開鍵に対応する口座番号）を計算する。
21.希望者はMonacoinのブロック鎖に移動したいMONAを使い捨て公開鍵に対応する口座番号に送付する。
22.希望者は職員にMONAの移動要求を申請する。この時に、使い捨ての値と移動口座番号を添付する。
23.職員は自身の公開鍵と希望者から受け取った使い捨ての値と移動口座番号から使い捨て公開鍵（19で生成されたものと同じになる筈）を生成する。
24.職員は使い捨て公開鍵のSha256Ripemd160要約値（＝使い捨て公開鍵に対応する口座番号）を計算する。
25.職員は使い捨て公開鍵に対応する口座番号にMONAが送付されているか確認する。送付されていない場合は希望者に「MONAが送付されていない」旨を通知し、業務を終了する。送付されている場合は業務を続行する。
26.職員は自身の秘密鍵と7で受け取った使い捨ての値と移動口座番号から8で生成した使い捨て公開鍵に対応する秘密鍵を生成する。
27.職員は移動口座番号に10で送付されていることを確認したMONAを移動する取引を26の秘密鍵を使って作成し、Monacoinネットワークに流す（26の秘密鍵を使って署名すれば有効な取引となる筈である）。
28.職員が間違えない限り27の取引は有効で、Monacoinネットワークのノードによって有効であると承認され、最終的には採掘されたブロックの中に格納される。
29.27の取引がMonacoinのブロック鎖のブロックの中に格納され、ブロック鎖分岐がまず発生しないと言えるほどに十分な時間が経過したら、職員は希望者に「MONAの移動が完了した」旨を通知する。
30.この時点で希望者はMonacoinのネットワーク（ブロック鎖）の方でMONAを使用できるようになっている筈である。

このように、連合による固定は原理的には可能です。

しかし、重要なのは、連合による固定の場合6の時点でMONAの実質的な所有権は職員に移転しているということです。MonacoinネットワークのノードはMONAがCREACOIN側に形式的に移動したことを認識しませんので、悪意のある職員は希望者から受け取ったMONAを勝手に別の口座に移してしまうことが可能です。そういう意味で、連合による固定では職員に対する信頼が必要となります。
これだけでも問題なのですが、更に問題があります。
それは、連合による固定の場合、職員が単一障害点（single point of failure：SPOF）となっているということです。職員に悪意がなくても、やむを得ず職務を放棄することはあり得ますし、職員が秘密鍵を紛失した場合はMONAをMonacoin側に戻せなくなってしまいます。
即ち、職員に対しては単に悪意を持っていないという信頼だけでなく、絶対に失敗しないというもっと広い意味での信頼が必要です。

Mt.Goxなどの顛末を見るに、現実的にはそのような信頼を確保するのは難しく、結局連合による固定は現実的には難しいと思われます（ただし、自分/自社の中だけで完結する取引を行うのに自分/自社自身が職員になって連合による固定を行うことは十分可能かと思います。これに関してはその内追記するかもしれません）。