PlasmaをFrameworkとして使う時のいくつかの前提

PlasmaをPlasma Frameworkとして見るとPlasma MVPやPlasma Cashよりも多くのことができます。何ができて何ができないのか?をセキュリティをもっとも犠牲にしてなく、かつ実用的に動きそうなPlasma Cashの実装や技術をベースに考えて見ます。結論から言うと「1週間後に私の確認なしで資金を解放して良いよ」とか「私の確認なしに、10ETHと交換して良いよ」と言うようなロック状態を実現することができないのかなと思います。

Plasmaのchallengeモデルにはいくつかの前提がある。というところを切り口にお話ししていきます。(以下、である調)

「オーナーの署名を求めない価値の解放の約束」は実現できないのではないか?

spent challengeの設計において、トランザクションのoutput(UTXO)がspentされていることは、spentされたトランザクションにUTXOのオーナーの署名があることで確認する。 challengeに使用するトランザクションが完全に正しいことを検証していない。ということは オーナーの署名を求めないトランザクションがアプリケーションに存在すると、challengeがworkしない。よって オーナーの署名を求めない価値の解放条件を持つUTXOは実現できない。

Generalized State Channelでできることはきっとできる

そのトランザクションが正しいか?の一部は状態遷移を検証することで検証可能。例えば「AliceとBobのマルチシグ」に対して、まるばつゲームを行い、買ったほうが全額もらうとする。最後の一手「まるばつゲームに買ったのでAliceが全額もらう」というトランザクションTx2を持って、直前の「Aliceがかつ一個手前のAliceのターン」を出力するトランザクションTx(n-1)にchallengeするには、Tx(n)が正しく無いといけない。Tx(n)が「無理やりAliceが勝つようにした」トランザクションであってはchallengeできてはいけない。この場合challengeの中の実装で状態遷移の正しさチェックを加えることで、challengeプロセスが正しく機能する。

価値の交換

次は「価値の交換」について考える。交換トランザクションは入力が複数ある。「AliceとBobが価値Aと価値Bを交換する」トランザクションをTx2とする。「直前のAliceの価値A」を出力するトランザクションをTx1とする。AliceがTx1でexitしようとした場合、Tx2が正しい場合にはBobがTx2でchallengeできることが望ましい。しかしTx2が正しいことを証明するには、Tx2の入力である、Aliceの価値AとBobの価値Bが正しく作られた入力であることを証明しなければいけない。仮にBobの価値Bが存在しないのに、Tx2がchallengeで利用できてしまうと、AliceはcoinAを失い、不正に作られてcoinBを手にすることになってしまう。またBobの価値Bの正しさを証明するには、exitプロセスと同様の証明が価値Bに対しても必要になってしまう。そこで実際には、このTx2に対してマークルルートを含めた確認署名(confirmation signature)を、coinBの履歴検証をした上で行うべきである。その場合価値の交換は可能である。

まとめ

上の交換の例でもAliceが自分の価値Aを「価値Bとの交換」という形でロック(オーダーブックっぽいやつ)し、自分の署名を必要なくすることはできない。そこで深く掘っていくと、結局自分の署名を求めない可能性のある形のロックが実現できない、にたどり着くのではないかと思った

「オーナーの署名を求めない価値の解放の約束」は実現できないのではないか?

具体的にいうと、「1週間後に私の確認なしで資金を解放して良いよ」とか「私の確認なしに、10ETHと交換して良いよ」ができないのでは無いか。

似たようなことを考えてる方ぜひ話しましょう!