Smart Contracts on Plasma
一般的な課題
Why is EVM-on-Plasma hard?
Plasmaの基礎は「Plasmaチェーンのステートが正しい状態で引き出せる」こと
Plasmaチェーンのコンセンサスアルゴリズムが崩壊したとしてもこれが成立しなければならない
nrryuya.icon < 「正しい状態で引き出せる」ことを保証するために、正当ではない引き出しに対してチャレンジする仕組みが少なくとも必要o
※チャレンジの仕組みがあることに加え、Exitゲームの設計やData Unavailabilityへの対処方法なども必要
e.g. mass exit(Plasma MVP), More Viable Plasmaでのexit, limbo exit(Plasma Cash)etc.
(1)誰に引き出しの権限を与えるかが時に悩ましい
UTXO, アカウント、マルチシグならわかりやすい
CryptoKittiesのコントラクトは誰が引き出せる?
(2)誰でも変更できるステートは、誰でも引き出しをブロックできる
exit申請されたステートを、challenge periodの間に変更すれば、そのexitは不正になるため
(3)チャレンジ時に提出された(Plasmaチェーンの)状態遷移が正当か検証できなければならない
トークンのtransferなら、署名検証だけで良い
一般のコントラクトをPlasmaチェーンで利用するには、一般のコントラクトの状態遷移をオンチェーンで検証できなければならない
解決策: (E)VM inside the EVM: オンチェーンでオフチェーンの状態遷移の計算を行えるようにする
これがなかなかハード
その他
Plasma Leap
Ethereum Foundation Grant Wave2にて$50K獲得
More Viable Plasmaに、NST
SolEVM + TrueBit-like verification game
Spending Conditions
BitcoinのP2SH的な
EVM-Scriptで書かれる
SolEVM
部分的な"EVM inside the EVM"の実装
gas meteringなどはまだなさそう
Verification gameのためのSolEVMの制約
1つの計算ステップのgas costが(少なくとも)Block gas limitに収まらないといけない
1つの状態遷移を表すのに必要なデータがtransactionに収まらないといけない
EVM-Script
EVMの命令セットからSSTORE, SLOAD, CREATE, SELFDESTRUCTを除いたもの
Solidity(のサブセット)などEVMをターゲットにする言語からのコンパイラが作れる
code: SpendingCondition(JavaScript)
contract SpendingCondition {
address constant spenderAddr = 0xF3beAC30C498D9E26865F34fCAa57dBB935b0D74;
function fulfil(bytes32 _r, bytes32 _s, uint8 _v, // signature
address _tokenAddr, // inputs
address[] _receivers, uint256[] _amounts) public { // outputs
require(_receivers.length == _amounts.length);
// check signature
address signer = ecrecover(bytes32(this), _v, _r, _s);
require(signer == spenderAddr);
// do transfer
ERC20Basic token = ERC20Basic(_tokenAddr);
for (uint i = 0; i < _receivers.length; i++) {
token.transfer(_receiversi, _amountsi); }
}
}
TrueBit-like Verification game
SolverとVerifierがいる
Solverが提出した計算結果に対してVerifierはチャレンジできる
計算の各ステップ(1つのOPCODEの実行が1ステップとする)のステートをリーフとしたマークル木を使う
二分探索により、どの計算ステップで結果がズレているのかを探す
ステップごとにSolverとVerifierはマークルプルーフを提出する
Judge(オンチェーンのコントラクト)がそのステップを実行し、どちらのマークルハッシュが正しいのか検証する
Verification gameのインセンティブ設計
DDoSを防ぐためにチャレンジの際に担保を拠出する必要がある
しかし、必要な担保額を大きくするとユーザーがチャレンジしなくなる
Exiting Spending Conditions
code: RootChain(javaScript)
contract SpendingCondition {
address constant spenderAddr = 0xF3beAC30C498D9E26865F34fCAa57dBB935b0D74;
function exitProxy(
bytes32 _r, bytes32 _s, uint8 _v, // authorization to start exit
address _bridgeAddr, // address of Plasma bridge
bytes32[] _proof, uint _oindex // tx-data, proof and output index
) public {
address signer = ecrecover(bytes32(this), _v, _r, _s);
require(signer == spenderAddr);
PlasmaInterface bridge = PlasmaInterface(_bridgeAddr);
bridge.startExit(_proof, _oindex);
}
function fulfil(...);
}
contract PlasmaBridge is PlasmaInterface {
using TxLib for TxLib.Outpoint;
using TxLib for TxLib.Output;
using Reflectable for address;
event ExitQueueMock(bytes32 txHash);
function startExit(bytes32[] _proof, uint _oindex) {
bytes32 txHash;
bytes memory txData;
(, txHash, txData) = TxLib.validateProof(32, _proof);
// parse tx and use data
TxLib.Output memory out = TxLib.parseTx(txData).outs_oindex; // check that caller is owner
if (msg.sender != out.owner) {
// or caller code hashes to owner
require(bytes20(out.owner) == ripemd160(msg.sender.bytecode()));
}
emit ExitQueueMock(txHash);
}
}
Non-fungible Storage Token (NST)
NFTを、ステートを保持できるように拡張したもの
code: NST(JavaScript)
contract StorageToken is ERC721Token {
mapping(uint256 => bytes32) public data;
function read(uint256 _tokenId) public view returns (bytes32) {
}
function verify(
uint256 _tokenId, // the token holding the storage root
bytes _key, // key used to do lookup in storage trie
bytes _value, // value expected to be returned
uint _branchMask, // position of value in trie
bytes32[] _siblings // proof of inclusion
) public view returns (bool) {
require(exists(_tokenId));
return tree.verifyProof(data_tokenId, _key, _value, _branchMask, _siblings); }
function write(uint256 _tokenId, bytes32 _newRoot) public {
require(msg.sender == ownerOf(_tokenId));
}
}
NSTに関しては、More Viabile Plasmaと同様のdeposit/trandfer/exitのライフサイクルが可能
相違点は、NFTのためamountの代わりにTokenIDがそのトークンに付与され、storage rootのフィールドが付与される
ExitにおいてPriority queueはない、チャレンジ期間はある
Spending ConditionからのNSTのread/write
NSTをinputにし、NSTをoutputする
readの際はoutputもread-onlyで、writeの際はstate(とstorage root)が書き換えられたものがoutputされる
Resources
Plasma EVM 2.0
by Onther Inc.
韓国発のスタートアップ
2種類のブロック
Request Block: enter/exit request
nonRequestBlock: その他のtransaction
TrueBit-like verification game & SolEVM
Block withholding
Onther approaches block withholding attacks by enforcing the submission of block data by the operator to reveal all transactions
userRequestBlock for Data unavailability
userRequestBlockは、それを提出したユーザー(もしくは他のユーザー)のexit requestを反映するtransactionのみを含む
Resources
Matic Network
TrueBit-like verification game
precompiledのEVM実行関数を使う想定
https://whitepaper.matic.network/matics.png
Checkpoints LayerはPoSで選ばれる
Matic ChainのBlock ProducerはCheckpoints Layerのstakerにより(ルートチェーンでの)投票により選ばれる
Checkpointing
checkpointingのproposerは、前回のcheckpointからのブロックを検証し、それらのブロックハッシュからマークルツリーを構成する
checkpointには2/3の投票が必要、メインチェーンに提出されてから一定期間チャレンジ可能
Resources
Other Projects
ethresear.chによく登場するkladkogex氏がCTO
詳細不明(?)
Plasma Chamber
by Cryptoeconomics Lab
状態機械を静的解析できる言語(現在はPrologに似たものとなっている)からスマートコントラクトの状態機械を生成し、Plasmaコントラクトと子チェーン双方に同じ状態機械を備えることで、子チェーンでの状態遷移の正しさを検証するコストを安くすることがコアとなる発想です。EVMをPlasma上で動かすことを志向しない決断となります。
詳細が気になる
Plasmabits
TrueBit-like verification game
Vitalikにより提案(EIP)されたEVM inside EVM用のOPCODEを使う想定 チャレンジが成功するとチェーン停止する等が書いてある
Kelvinが色々指摘しているがその通りという感じ
実装などはない