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.
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).
m0t0k1ch1.icon わいも kfichter に This is a really good observation. 言われてみたいわあ
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.
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.
(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.)
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.
danrobinson：実際、ある Plasma チェーンから別の Plasma チェーンへの mass move のためにこれを利用することができるかもしれない。これができれば、最初のチェーンのオペレータの協力は不要である。よって、オペレータが悪事を働いている場合でさえも、1 コインあたり 1 bit 程度のみのオンチェーンコストで Plasma Cash コインの活性を維持できる。効率の良い mass checkpointing・mass exit・mass moving は、基本的には全て同じ仕組みで可能である。
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.
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.
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?
I would agree that there is a change of assumptions w.r.t Plasma MVP. I don’t believe that this changes any assumptions w.r.t Plasma Cash, particularly because of the discussion here: Watchtowers may not work in Plasma (Cash).
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.
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.
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).
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.