Plasma XT における checkpointing（発展）

---.icon

民主的な checkpointing

This makes me wonder why it should even be a requirement that Plasma XT checkpoints can only be operator-initiated. It makes plenty of sense for the operator to initiate checkpoints (because they have all the information about the state), but users (or anyone) could also conceivably initiate them, by doing the same thing—putting up a bond, and revealing a state commitment and a cryptoeconomic aggregate signature.

danrobinson：なぜ「オペレータだけが checkpoint を打つことができる」という要件が必要なのか疑問である。もちろんオペレータが checkpoint を打つのは道理にかなっているが（なぜなら、オペレータは状態に関する全ての情報を持っているから）、ユーザー（もしくは他の誰でも）が checkpoint を打ってもよいはず。これは、オペレータと同じことをすれば可能である。すなわち、担保を提出し、state commitment と cryptoeconomic aggregate signature を公開すればよい。

If that works, then operators can’t even prevent users from checkpointing their state (although, since they can prevent users from transacting, this isn’t a particularly significant win).

danrobinson：これが機能した場合、オペレータはユーザーが checkpoint を打つことを妨げることはできない（が、オペレータはユーザーのトランザクションを妨げることはできるため、これで全てが解決するわけではない）。

This might be a good reason to look at alternative ways of expressing the bitmaps in cryptoeconomic aggregate sigs. The only requirement is that you somehow identify all the coins that assent to the checkpoint. This can be done via bitmaps (if there are many adjacent coins involved in the checkpoint), but if participating coins are much sparser, a list of indices might be more efficient; indeed if they’re much denser, a list of the unincluded coins could be more efficient, or some kind of runlength encoding. It’s a pretty straightforward compression problem. (These alternative forms could be useful for operator-initiated checkpoints as well, although those are likely to be dense and random enough for bitmaps to be the most efficient representation).

danrobinson：これは、ビットマップを cryptoeconomic aggregate signature で表現するという方法の代替案を検討する十分な理由だと思う。唯一の要件は、checkpoint に同意した全てのコインをどうにかして識別できるということである。（多くの隣接したコインが checkpoint に含まれている場合）これはビットマップによって実現できるが、参加するコインが非常にまばらである場合、インデックスのリストはより効率良く集約できる。コインが非常に密であれば、含まれていないコインをより効率良く集約できるし、ある種の連長圧縮を適用することもできる。これは、かなり単純な圧縮問題である（これらの代替案は、オペレータによって checkpoint が打たれる場合でも有用であるが、ビットマップが最も効率の良い表現であるくらいコインが十分に密もしくはまばらである必要がある）。

This is a really good observation. Anyone could aggregate checkpoints, as long as they put up the required bond!

kfichter：素晴らしい見解だ。必要な分の担保を提出すれば、誰でも checkpoint を集約できる！

The nice thing about this as that the EVM doesn’t even have to “understand” what the bitmaps represent. Someone could publish a bitmap along with the string “every coin ending with 2 or 3”, and it would (theoretically) work. Of course we’d rather have some semantics that the Plasma Cash client can understand, but it shows what options we have.

kfichter：これの良いところは、ビットマップが表していることを EVM が「理解する」必要さえないところである。誰かが「2 もしくは 3 で終わる全てのコイン」という文字列と一緒にビットマップを公開することもでき、それは（理論的には）機能する。もちろん、Plasma Cash クライアントが理解できるようなセマンティクスを採用した方がよいと思うが、それは我々が採用できる選択肢の 1 つではある。

I think it eventually has to—you need to prove that the recipient of the checkpointing was on notice, so in the event of a challenge, the EVM needs to be able to evaluate whether the published representation of the set being checkpointed included a particular coin.

danrobinson：最終的には、checkpoint を受信する側にきちんと情報が伝わっていることを証明する必要があると思う。つまり、challenge が発生した際、EVM は公開された checkpoint の表現が特定のコインを含んでいるのか判断できる必要がある。

(Another reason evaluating these needs to be computationally simple is of course that every coinholder needs to interpret every checkpoint, at least sufficiently to know that their coins are not included in it.)

danrobinson：（判断が単純な計算でこれらを行える必要があるもう 1 つの理由は、もちろん、全てのコイン保有者が全ての checkpoint を解釈でき、少なくとも自身のコインがそれに含まれていないことを知ることができる必要があるから）

Makes sense, recipients must be able to know whether their coins are being checkpointed or not.

kfichter：ごもっとも。受信者はコインが checkpoint を打たれているかどうかを知ることができなければならない。

Actually, you could probably use this for a mass move from one Plasma chain to another that doesn’t require the cooperation of the first chain operator. So you could maintain the liveness of your Plasma Cash coins even if the operator goes rogue, at the on-chain cost of only around 1 bit per coin. So efficient mass checkpointing, mass exit, and moving could all be enabled by basically the same mechanism.

---.icon

checkpointing の委任

I think there is a slight change in assumptions. With Plasma MVP, the user can delegate the task of watching the chain and initiating withdrawals to someone else, so the user does not actually have to be online regularly. The delegate could grief the user by initiating unnecessary withdrawals, or could fail to do their job, but could not steal the user’s coins.

tasd：仮定が若干変わっていると思う。Plasma MVP では、ユーザーはチェーンの監視や引き出し開始を他の誰かに委任することができるので、実際、ユーザーは常時オンラインである必要はない。委任によって発生する不必要な引き出しや諸々のミスはユーザーを苛ませることはあるだろうが、ユーザーのコインが盗まれることはない。

In Plasma XT, it seems like a user could not delegate the checkpointing task while they are offline to an untrusted entity, because they would have to provide their private key to that entity for the purpose of signing off on checkpoints.

tasd：Plasma XT では、ユーザーがオフラインな間の checkpoiting を信頼できない団体に委任できないように見える。なぜなら、checkpoint において承認を行うためにはその団体に秘密鍵を提供する必要があるから。

Do you see a solution that would enable checkpoints to be made while the user is offline, or would they just have to allow the coin history to grow and then make a new checkpoint when they do eventually come online?

tasd：ユーザーがオフラインな間の checkpointing を可能にする策はある？もしくは、ユーザーはコインの履歴が増大することを許容し、再びオンラインになったときに新しい checkpoint をつくるだけでよい？

Although I think it’s probably fine for a first implementation if users have to be online, it would definitely be very useful for users to be able to outsource this. I haven’t thought about it a lot - one solution off the top of my head would be for users to make an on-chain transaction that somehow specifies a third party that can sign off on the checkpoint instead. This would basically look like a 2of2 multisig with a special key (for the third party) that can sign off alone. The third party could then be sure that they haven’t signed off and challenge whenever they see a false positive.

kfichter：ユーザーがオンラインである必要があっても最初の実装としては大丈夫だと思うが、それらをアウトソーシングできることは間違いなくユーザーにとって非常に有用だろう。自分はそれについて深く考えたことはないが、頭に浮かんだ 1 つの解決策は、ユーザーがどうにかして代わりに checkpoint において承認を行えるサードパーティを指定するオンチェーンなトランザクションをつくることだろう。これは、基本的には、単独で承認が可能な（そのサードパーティ用の）特別な鍵を用いた 2 of 2 マルチシグのようなもの。サードパーティは、ユーザーがまだ承認していないことを確信できるので、偽陽性を見つけたらいつでも challenge することができる。

Of course, this means that the third party could temporarily grief the user by refusing to sign the signature. Maybe this isn’t the worst thing if users can easily submit another transaction changing their third party provider.

kfichter：もちろん、これは、サードパーティが署名を拒否することによってユーザーを一時的に苛ませる可能性があることを意味する。ユーザーが委任先のサードパーティを変更する別のトランザクションを簡単に送信することができる場合、おそらくこれは最悪なことではない。

If the user is able to unilaterally change their checkpointer on the Plasma chain, I don’t think the checkpointer can safely challenge a checkpoint, since the user could have maliciously changed their checkpointer (assuming as we always do that the operator is working against them and making data unavailable). So you need to give the checkpointer the ability to veto (though you could still retain sole authority to withdraw the coin).

danrobinson：ユーザーが Plasma チェーン上で checkpointer を一方的に変更できる場合、checkpointer が安全に checkpoint に challenge できるとは思わない。なぜなら、ユーザーは悪意を持って checkpointer を変更することができるから（いつも通り、オペレータは彼らの足を引っ張るためにデータを unavailable にしていると仮定している）。よって、checkpointer に拒否権を与える必要がある（が、コインを引き出す権限だけは残しておくことはできる）。

Also, note that what you’re describing is a solution for outsourcing challenging of checkpoints, rather than outsourcing of checkpointing. I agree that the former is more important (because checkpointing is optional and if you have some time you could always do it before you plan to spend the coin, in order to reduce the proof you have to transfer). I’m not really sure the latter is possible, because for them to sign off on an unavailable checkpoint would be an unattributable fault.

danrobinson：また、あなたが記述しているのは checkpoint への challenge のアウトソーシングのための策であって、checkpointing のアウトソーシングではない。前者がより重要であるということには同意する（なぜなら、checkpointing は任意であり、余裕があれば、譲渡時に必要な proof を削減するためにコインを使用する前に常にそれを行うことができるから）。後者が可能かどうかはわからない。なぜなら、unavailable な checkpoint で承認を行ってしまうというサードパーティに責任のない問題が起こりうるから。