Storing coin history service by 3rd party is secure?

#1

Plasmaでexclusion proofをcoin保持者が保持しておく必要があるのか？履歴所持をオペレーターに委託したり、3rd partyに委託してもセキュリティに影響がないのではないかという仮説。

送金に関して考える（confsig無し）

送信までに起こり得ること

以下が直前のトランザクション（Tx1）より前にある場合に、新たにトランザクション（Tx2）を発行すると、そのtransactionは無効になってしまう。

  • double spent
  • invalid transaction

送信者は、Tx2を発行する前に、Tx1までのexclusion proofを検証する必要がある。
Tx2発行前であれば、問題は送信者に閉じるので、coin保持中はオンラインになる度にオペレーターからexclusion proofを貰い、その都度確認するだけで良い。もし履歴を紛失されたり、渡してくれない場合は、直前のトランザクションでexitする。上記に加えてinvalid exitされた場合はchallengeしなければいけないので、もちろんinclusion proofは全て持つという前提である。

受取手

通常、送信者は受取手にTx2までの履歴を送らなければならない。
履歴が正しくなければ、受取手はcoinを受け取って対価を渡さない。

ここでオペレーターや3rd partyに履歴管理を委託しているとどうなるか？

受取手はTx2までの履歴を確認後に、coinの受け取り、その対価を渡したい。
送信者は正しくトランザクションを発行したが、Tx2までの履歴がオペレーターや3rd partyによって紛失されたり、withholdされた場合。送信者がTx1でexitし、Tx2でchallengeされ、受取手がTx2のexitを確定させることができる。

まとめ

上記が正しければ、トランザクション発行前に保持coinの履歴を検証することと、受け取り時に履歴検証をすれば、履歴を自分で保持する必要はない。履歴のサイズは受け取り時の検証スピードを遅くするので、履歴サイズの削減は、受け取りにかかる時間を削減することになる。

2 Likes
#2

追記
Plasma Cash startExit によるとInclusion Proofが2つあればLimbo Exitできるので基本的には Tx_{n} を発行したいときは (Tx_{n-2}, Tx_{n-1}) のInclusion Proofだけ持ってればLimbo Exitによるwithhold対策ができ、それ以外のNon Inclusion ProofやInclusion Proofはオペレーターに持たせる（送金時にオペレーターが検証を手伝うことで通信に乗せたりエッジに保管するProof量を減らす）ことができる。

Limbo Exitがそのまま履歴保管の委託サービス等のdata availability保証にも使えるってわけですね。

Tx_1 と Tx_2 の例でなく Tx_1...Tx_n のようにdepositからのTxの例で考えたとき、 Tx_1...Tx_{n-1} のどれでLimbo Exitしてもいいんでしょうか。 Tx_{n-1} でLimbo Exitしなければならないならそこまでの履歴は持っておく必要があるため少量の履歴削減効果しかなく、 Tx_1 つまりdepositTxでLimbo Exitするなら普段管理する履歴は不要ですが、 Tx_2 で challengeAfter(spendChallenge)され、 管理してなかった Tx_2 の履歴が共有され、芋づる式にstartExitの時間とガスが許す限り Tx_{n-1} まで履歴を管理せずして引っ張り出せるのは真だと思います。

この場合言えるのは、「exitの時間とガスを引き換えに少なくともオペレーターに履歴管理を強要できる」ということかなと。すると現状の履歴削減のためにstartExitを安くしていく方向性とは別に、startExitをなるべく安くしてガス代時間コストの和相当の報酬をオペレーターに支払うことでCryptoeconomicにオペレーターに履歴をもたせることを考えても面白いかもしれませんね。

0 Likes
#3

途中のTx_{n-10}とかでexitされることもあるので、Inclusion Proofは全て持っていないとダメですね。
今回のは、まだ私の疑問に近い形なのですが、基本的にはnon inclusion proofは、常時保管してる必要はないのではないか？そうすると実はボトルネックってストレージサイズでないものに移るのではないのか？というところですね。

0 Likes
#4

冷静に考えるとこの件では、3rd partyが送ってきたものを、ユーザがverifyするという形になると思うのですが、zkSNARKで検証コストを（proofサイズがどこまで減るかというのがわからないですが）削減したらどうでしょう？

ユーザはmerle rootのリストを持っていて、3rd partyがユーザにそのmerkle rootの所定の位置にzero hashが存在することのproofを送信します。通常はmerkle proofになりますが。zerohashを所定の回数hashした結果がmerle rootになることだけ証明する。、、なんか無理そうですね

0 Likes
#5

履歴検証を、セキュアに完全委託する方法についてのアイデアです。
こちらの場合は、通信も必要ありません。


追記: これだとchannelと同じようになってしまって、微妙な部分多いですね

1 Like