This article presents a Plasma network, a design for more decentralized plasma nodes payment network. This construction mitigates the problems of fragmentation, history, and enables instant finality.

Plasma Network is many plasmas which are connected by predicates. It is designed on the predicate interface. It requires some basic predicates.

  • Payment channel
  • Payment channel network
  • Swap between different plasmas
  • Payment channel between different plasmas

Users move their assets to another plasma chain

Another important thing is, users can move their assets to another chain instantly. Previous plasma contract issue exit-NFT and the user can deposit this exit-NFT to next plasma contract. This exit-NFT has information about assets value. When…


This article describes the construction like payment channel on Plasma using great predicate stuff from Plasma Group. This has instant finality and enables micro-payment on Plasma. And also the fragmentation of Plasma cashflow is an unsolved open problem which has no implementation. Coin fragmentation makes micro-payment difficult and makes unacceptable exit cost. Also, the finality of Plasma is basically longer than layer 1. This construction is the challenge for these. (These might be flaws)

Channel on Plasma with instant finality

Plasma predicate enables us to generalized channel on Plasma. Of course, We can develop payment channel on Plasma using predicate. (As it to say, it seems…


I’d like to describe multi transfers in Plasma Cash based on my experiences with the Plasma implementation. I’m a developer and researcher in CryptoeconomicsLab. Inc. And we are developing Plasma Chamber, it is Plasma Cashflow variant and implemented it in Typescript and Vyper. And also I am grateful to ethResearch and Plasma Group for great documents and discussions.

Use cases

I list use cases of multi transfers. We can also send a segment instead of a coin, a segment are a set of coins.

  1. Alice sends coin 1 and coin 2 to Bob.
  2. Alice sends coin 1 to Bob and coin 2…


映画館のチケットシステムをブロックチェーンで実装するとどうなるでしょう?私なら、チケット購入から席決めまでをオンチェーンで実装し、オンチェーンの情報を元に、Walletをかざすと自動で開閉するゲートを映画館に設置すると思います。ここでトラストなのは開閉するゲートです。オンチェーンでは席を持っているのに、ゲートが悪戯して開かない可能性はあります。それに対してチケットを買ってから席を決めるまでのシステムはトラストレスに動作します。

このようにブロックチェーン上にスマートコントラクトを作成し、それを利用したアプリを作るときに、価値の作成、変換、譲渡はオンチェーンで実行し、それを利用する部分はブロックチェーン外(オフチェーン)で実行すると、システム全体の分権性が崩れにくくなります。またオンチェーンの処理はコストが高く、アプリケーションが求める速度は出ません。そこでブロックチェーン外で価値の譲渡(送金)を実現したものが、State ChannelやPlasmaなどのL2技術です。

ゲームで例えるならば、アイテムの利用(所持の証明により)のみがゲーム内で中央集権的に取り扱っても問題ないと思われます。つまり交換や合成、burnはオンチェーンで行い、何を所持しているかだけがゲーム内で扱えます。このようにアプリケーションレイヤーでの価値の扱いは薄く、しかしそれを利用して面白いアプリケーションを作ることはできると思います。これに徐々に実装が出始めたPlasmaを利用することで、譲渡や交換もブロックチェーン外で高速にできるようになっていくでしょう。

Plasmaが送金だけでなく、面白いアプリケーションやゲームが作られるきっかけになることを楽しみにしています。


「Aが本質的である」とは、Aがその文脈において無視できない事柄である、ということである。
本質的という言葉は日常生活では通用しない。文脈が全てである。もし私がブロックチェーンの安全性について議論したいのであれば、その安全性について本質的な話はできるだろう。と言っても本質的な議論は、大胆に邪魔な物事を取り除くことから始まる。数学はとても良い例である。買い物中の計算も、何時に家を出れば学校に間に合うかも、単純な計算で理解できる。手に持った大根が古いかどうかとか、バスが遅れる確率は一旦忘れるだろう。それが彼らにとって本質的なのである。強烈な目的意識は本質を導き出す。

我々は物事を整理し、邪魔なものを排除し、残ったものを体系立てることで、初めて本質的に考えることができるのである。人間の脳はそれほどに、複雑なことを考えるのには向いていない。もし私に無限の時間があれば、本質的に考えることをやめるのかもしれない。しかし人の一生は限られている、そして我々は本質的でないことを文章にして後世に残すすべを知らない。何を隠そうこの文章も「本質的」というただこの一語を、頭から引っ張り出した時につられて出てくるグラフ状の概念を文章にして繋げているに過ぎない。つまり私は混沌を文章にする術は知らない。

私たちは邪魔なものを排除することで、漸近的に進むしかないのだ。本質的に考えるとは自分の脳が大したことはないと認めた上での行為なのだ。「Aが本質的である」とは、「Aはその人の目的にとっての大事な仮説に必要な要素である」ということである。我々は共通の目的を持った時に、何が無視できるかを、議論しなければならないのだ。


I explain about the idea of Plasma generator.

As in this article why-evm-on-plasma-hard, most Plasmas are based on UTXO or NFT. For the reason that is to save security with few data in root chain. If we wanna more complex programming, we can wrap “Value” by some state like unlock script. (If you are interested in complex programming by “unlock script”, please search TxVM.) But how we can introduce unlock script into Plasma UTXO?

Problems of generalized Plasma

The first problem of that is how to verify unlock script. In the context of Plasma, we have to verify a state transition(this transition means UTXOs…


When we use plasma as a framework we can do a lot of things than to own assets and send any assets. When we verify “challengeExit”, we have to check that state transition is correct or not. A large-scale mechanism like EVM inside EVM is not necessarily required. If the variation of transactions is a few, it can be hard coding on RootChain contract.

What is a suitable paradigm for Plasma? I thought it after reading this article. It will be similar to unlock script like TxVM, but it’s not enough. Ownership is important but UTXO’s ownership is not…


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と交換して良いよ」ができないのでは無いか。

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


Plasmaが本当に難しいので、難しさの根源を探すために少しメタに考えて見たい。と思い書きました。

はじめに

why-evm-on-plasma-hardに書かれているように、ほとんどのPlasmaはUTXOかNFTを扱います。その理由はルートチェーンの少ないデータで、子チェーンのセキュリティを守るためです。Plasmaでは子チェーンのトランザクションはマークル木として集約しマークルルートをルートチェーンに提出します。これはスケーラビリティのためです。私たちはあるトランザクションがサブミットされているか否かを検証することができるようになります。逆にいえば存在確認しかできなく、その正しさは検証できません。

MVPについて

そのためPlasmaMVPでは、startExitとchallengeExitで使用されたTXOの指摘期間があります。また私たちは、常に悪意のあるオペレーターを頭に入れておかねばなりません。オペレーターはいつでも、不正なトランザクションをサブミットしたり、正しいトランザクションをサブミットしないことが出来ます。他のユーザは不正なマークルルートがサブミットされた場合、exitしなければいけません。exit gameで詳しく説明されています。現実的に、このexitは非常に難しいです。ユーザーは完全なデータを持っていなければ、オペレーターの不正を検知できませんし、challengeすることもできません。このためValidatorという存在が必要になります。

Cashについて

Plasma Cashでは全てのデポジットされた価値をNFT(coin)として扱うことで、このexitに関する問題を解決しています。Plasma Cashでは自分所有するcoinに関する履歴データ(トランザクションとマークルプルーフ)を保持するだけで良いです。またMVPと同じようにexitには1週間のchallenge期間があります。なのでユーザは1週間に一度だけオンラインにならなければいけません。Plasma Cashにおける、challengeの仕組みは強力です。不正なexitをされた場合、所有者は1週間に一度オンラインになることでそれに気づけます。Plasma CashにおけるchallengeはSpent, Double Spent, Invalid Historyの3種類あり、ユーザは自身の所有する履歴データだけで完全なchallengeを行うことが出来ます。RootChainでのChallenge方法はkarl.teck がわかりやすいです。また子チェーン側でもDouble Spent,やInvalid Historyを持つcoinを送受信しないように、クライアントでは受け取る前にそのcoinの履歴を検証してから、coinとその履歴を受け取ります。この履歴検証の際に、invalid historyについてはTransactionの正しさとつながりをdeposit blockまで見ていけば良いですが、double spentは、全てのブロックのnon-inclusion proofが必要です。なのでPlasma Cashでも履歴量は課題になっており、そのためにチェックポイントRSA accumulatorが提案されています。

Plasmaの一般化がしたい

私は、これらのPlasmaを考える上で、若干の定義の一般化ができるのではないかと思いました。以下のように一般化して見ます。

  • このPlasmaにおいて正しいトランザクションとは何か?
  • ある時点でのstateは何か?
  • 誰がchallenge可能なのか?

「正しいトランザクション」はマークルツリーに含まれており、正しい署名を持ち、入力と出力が正しい遷移(PlasmaMVPやCashに複雑な遷移はないですが)を行なっているかどうかです。

ある時点でのstateは何か?これは言い換えると、ある時点でstateがexit可能で、その定義が何か?ということです。これはchallengeのプロセスによって定義されると思います。MVPにおいては、トランザクションの集合の中で、Spentされていないものの出力がその時点でのstateになります。あるexitに対して、それを入力とする「正しいトランザクション」を提出することでchallengeが可能です。Plasma Cashでは、これにさらに、depositブロックから正しいトランザクションでつながっていること、とdouble spentされていないという条件がつきます。

最後に「誰がchallenge可能なのか」は、とても重要なポイントではないかと思います。 MVPにおいてはvalidatorなど、子チェーンのフルノードを運用している人は、必ずchallenge可能です。一般ユーザがchallenge可能なパターンもありますが、これはオペレーターでなく一般ユーザが起こせる不正に対してのみです。Plasma Cashでは、全てのcoinにオーナーが存在します。つまり「ある時点でのstate」に必ず一人のオーナーが存在するのです。そのためオペレーターによる不正なexitが発生した場合に「誰がchallenge可能なのか」の答えは常に、coinのオーナーとなります。このようにPlasmaの安全性の根幹になるのがこの3つ目の「誰がchallenge可能なのか」のデザインだと思います。

まとめ

このように少しだけ一般化して考えると、Plasmaにはまだまだ可能性があるのが(難しさもたくさんあるのが)見て取れるのではないでしょうか?


Thanks to sg and nakajo for daily discussion.

Intoroduction

As in this article why-evm-on-plasma-hard, most Plasmas are based on UTXO or NFT. For the reason that is to save security with few data in root chain. In Plasma, transactions in child chain was stored as merkle root on Root Chain. It's for scalability. We can verify only wether a transaction was submitted or not. So MVP has startExit and challengeExit to challenge spent TXO. We always have to think malicious plasma operator. Operator can submit invalid transaction. Other users have to exit such a merkle root include invalid transaction. …

Shuhei Hiya

CryotoeconomicsLab, BoostIO, Domain Specific Modeling.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store