Plasma snapp における unwinding mechanism

---.icon

Roll back of the tip of unavailable chains

If the chain operator stops publishing new valid blocks for 3 days, then the plasma root chain contract would allow swapping the operators. Then anyone else can extend the plasma snapp chain provided that the new operator hands in valid snark for his new blocks.

オペレータが新しい正当なブロックの公開を 3 日間停止した場合、Plasma コントラクトでオペレータの交代が可能になる。新しいブロックに対応する正当な SNARK を提出すれば、誰でも Plasma snapp チェーンを伸ばすことが可能。

If no one can build on the tip of the plasma chain, then the last block of the plasma chain will be removed and we wait for people building on the second-highest block. We will continue this removal process of the plasma chain tip until it is extended again by another operator. If clients are storing all the data of the plasma chain, then they could always become the operator themselves in such a situation. Thus, if they do not agree with the reversal of a block of the chain tip, they need to become the operator. This is a fair mechanism, as everyone can stop the rollback of the history.

誰も Plasma チェーンの先端にブロックを繋げられない場合、先端のブロックは取り除かれ、2 番目に高いブロックに繋げる人を待つ。他のオペレータによって再びチェーンが伸ばされ始めるまで、この先端ブロックの除去処理を続ける。クライアントが Plasma チェーンの全データを保持している場合、いつでもオペレータになることができる。すなわち、先端ブロックの取り消しに賛同しない場合は、オペレータになる必要がある。全員が履歴のロールバックを止めることができるため、これは公平なメカニズムである。

Payment receivers should only acknowledge their payment as accepted, once they have the complete new state of the plasma chain. Then they could theoretically always prevent the rollback of their received transaction by becoming the plasma operator themselves.

支払いの受け手は、新しい完全な Plasma チェーンの state を保有していさえすれば、支払いが承認されたかを認識するだけでよい。彼らは、自身がオペレータになることで、理論的にはいつでも受領したトランザクションのロールバックを防ぐことができる。

Becoming a plasma operator is a heavy task, but on the other side, we could also incentivize this heavily by slashing the original operator and rewarding the new operator with these slashed funds: During the plasma chain creation, the operator has to make a deposit of x ether. If the plasma chain was stopped and the operator swapped, then the new operator would receive a fraction of this ether per submitted valid block. This ensures that the plasma chain is continued for quite sometime after the original operator was switched and everyone has the chance to leave the chain.

オペレータになることによる負担は非常に大きいが、これを強く動機付けすることもできる：Plasma チェーンの稼働開始時にオペレータが x ETH をデポジットしておき、そのオペレータが slash されたら、slash された資金を新しいオペレータに報酬として与える。Plasma チェーンが停止してオペレータが交代した場合、新しいオペレータは正しいブロックを提出するごとにこの ETH を受け取る。この仕組みによって、元のオペレータが解任された後も Plasma チェーンが継続することと、誰もがチェーンから離脱する機会があることが保証される。

But there is one hook, rolling back transactions of unavailable blocks might be fine, but unwinding withdrawals is not possible. However, there is a workaround: We require that

しかし、1 つ問題がある。unavailable なブロックのトランザクションをロールバックすることは問題ないが、withdrawal を unwind することは不可能である。が、回避策はある。我々は以下を要求する。

・Exit requests are bundled per block: Only if all withdrawal requests from a certain block-height are processed, then the plasma smart contract will allow the withdrawal of the actual funds.

・In order to have full security, users have to send an exit request for their funds at least 40k blocks after the data unavailability.

exit は、以下の中で最大となるブロック高（L とする）から 40k transfer ブロック（7 日）経過後に処理される

exit 要求の対象であるブロック高

exit 要求はブロックごとにまとめられる

特定のブロック高からの withdrawal 要求が全て処理された場合のみ、Plasma コントラクトは実際の資金の withdrawal を許可する

完全なセキュリティのため、ユーザーは、data unavailability が発生して少なくとも 40k ブロック経過後に exit 要求を送信しなければならない

ユーザーは、資金を引き出したい場合、Plasma コントラクトに対してブロック高 n を指定して要求を送る。n は、ユーザーの残高が引き出されるべき Plasma チェーンのブロック高。不幸な場合、これが最初の unavailable なブロックかもしれない。Plasma コントラクトはオペレータに対して、ブロック高 L + 40k + 1 の transfer ブロックを提出する前に、この exit を処理することを要求する。

Using this delayed mechanism, users funds are safe:

この遅延メカニズムを使用することで、ユーザーの資産は安全になる。

Imagine the block n is the first unavailable block.

1. If the operator keeps on building blocks but stops building new blocks before the block n+40k is finished, then all exits processed must be “old” accounts, which either were not touched since the data unavailability or the users are not aware of the data unavailability. Even when blocks are unrolled until n, we require the new chain with the new blocks to include the same exits, but without paying for the exits again. Thus no funds are lost.

2. If the operator keeps on building blocks and goes beyond the n+40k, then every user should have already registered their exit and the plasma contract would have made sure that it would have been withdrawn. The operator could then potentially revert his transaction without reverting the withdrawal, but since all users anyways have already withdrawn their funds, nothing would be left to steal.

ブロック n が最初の unavailable なブロックである場合を考えてみる。

1. オペレータがブロックを生成し続けていたが、n + 40k まで到達する前に新しいブロックの生成をやめてしまった場合、処理された全ての exit は「古い」アカウントに関するものなはず。data unavailability もしくは data unavailability によってユーザーに認識されなかったため、それらのアカウントは触れられていない。n 未満のブロックが公開されていれば、新しいブロックを伴う新しいチェーンに対して、同じ exit を含めることはできるが、その exit に対して再度支払いが行われることはない。よって、資金は失われない。

2. オペレータがブロックを生成し続け、n + 40k を超えた場合、全てのユーザーは既に exit の登録を終えているはずであり、Plasma コントラクトがそれらが引き出されることを保証する。オペレータが withdrawal を取り消すことなしにトランザクションを取り消す可能性もあるが、全てのユーザーは何らかの方法で既に資金を引き出しているので、盗むものは何も残っていない。

n が最初の unavailable なブロックなら、n - 1 までは available

n + 40k が登録されるまでに、n - 1 時点での残高の exit 要求を登録するはず

オペレータが n + 40k を登録するには n - 1 に対する exit 要求を処理する必要がある（Plasma コントラクトで規定）

n + 40k が登録された時点で n - 1 の（mass）exit は完了するので、問題なし

Note: In order to make this mechanism work, everyone needs to know when their transaction might have been included into the plasma chain. Especially, the scenario needs to be prevented where the operator produces unavailable blocks and includes in these blocks old transactions of somebody and thereby prevents this person to withdraw. Hence, every transaction submitted by a customer should be valid only for a specific block. This will be checked by the snark.

注：この仕組みを機能させるためには、全員が「自身のトランザクションが、いつ Plasma チェーンに取り込まれたのか」を知っている必要がある。特に、「オペレータが unavailable なブロックを生成し、それらのブロックに誰かの古いトランザクションを含め、このユーザーの withdrawal を妨げる」というシナリオは防ぐ必要がある。よって、ユーザーによって提出された全てのトランザクションは、特定のブロックでのみ有効であるべきである。これは SNARK によってチェックされる。

Note2: This specification has the nice property that we can use any hash function for the state Merkle tree within the snarks, as these hash functions do not need to be executed in the evm at all. This is a huge benefit. Only the deposits and exits need to be done with keccak, as here the evm will need to execute them as well.

注 2：この仕様は、SNARKs 内の state Merkle tree のためにどんなハッシュ関数を使うこともできるという素晴らしい特性を有している。なぜなら、これらのハッシュ関数は EVM などで実行される必要がないから。これは大きな利点である。deposit と exit の Merkle tree は EVM によって処理される必要があるため、keccak を使用する必要がある。