Imataka, CTO of Umi Labs
Sui Networkのイントロダクション
Blockchain Onboarding Week Summer🏄♂️
Presented and Translated by Umi Protocol
Credit to: �Shayan Sanjideh�Developer Relations Engineer, Sui Foundation
Credit to: �Evan Cheng�Co-founder and CEO, Mysten Labs
Web3
Web 3
昨今のWebの問題点
ユーザーの創作物は中央集権的な団体によって流通がなされ、
収益化に利用されている
IG, TikTok, YouTube:
プラットフォームがマネタイズをコントロールし、創作者はその一部を受け取る
Facebook, Twitter:
ソーシャルグラフはプラットフォーム内にロックされている
Fortnite, World of Warcraft:
ユーザーの保有するアセットは、ゲームの外では何の価値を持たない
Web3 の 本質
Web3 は以下の間の関係性の変化�- プロダクト�- プラットフォーム�- ユーザー�特にアセットへのアクセスと�所有権をめぐるものである
コンテンツプラットフォーム:
プラットフォームはユーザーの消費行動を促し、マネタイズの分け前を得る
ソーシャルネットワーク:
ソーシャルグラフ がプラットフォーム外でも利用可能
ゲーム:
ユーザーのアセットは、ゲームの外でも価値をもち、ユーティリティを持つこともある
Web3 はこれからどうなっていくのか？
技術は影を潜め、体験こそが重要に
テクノロジー
所有権
消費者同士、参加者同士の直接的な関係
直接的な関係
プラットフォームやコミュニティにおける所有権
ブロックチェーン
Blockchain
複製されたステートマシン
ステートマシンのレプリカ（"バリデータ"）は、�・状態 0�・トランザクションの順序("コンセンサス")�・関数 f(State, Transaction) -> Stateについて合意しなければならない
トランザクション 1
トランザクション2
状態 0
状態 1
f
f
…
ブロックチェーン
プログラマブルな�アセットのための�インフラ
=
アセットのための、プログマブルでオープンな認証されたデータベース
複製されたステートマシン – �デジタル資産の認証レポジトリ
分散されたトラスト (バリデータ) +
経済的なアラインメント (トークン)�*経済的な利得・ 価値尺度を揃える
プログラマビリティ – �スマートコントラクトは中央集権的な�仲介業者を置き換える
ブロックチェーンは�その約束を果たしているか？
今日のブロックチェーンの3つのコア機能:
アセットの作成と所有権の記録管理
プログラムによるアセットの操作
制限のないトランザクション処理
アセットと�所有権
プログラマビリティと
トランザクション処理
Assets & Ownerships
Programmability and �Transaction Processing
tokenX (account => balance)
tokenX smart contract
AliceAccount => 1
purchase: tokenX[AliceAccount] = 1
AliceAccount
BobAccount
Purchase
�EVM アプローチのアセット(トークン)
tokenX (account => balance)
AliceAccount => 1
Transfer
tokenX smart contract
AliceAccount
BobAccount
�EVM アプローチのアセット(トークン)
tokenX (account => balance)
AliceAccount => 1
transfer: tokenX[AliceAccount] = 0
tokenX[BobAccount] = 1
tokenX smart contract
AliceAccount
BobAccount
Transfer
�EVM アプローチのアセット(トークン)
tokenX (account => balance)
AliceAccount => 0
BobAccount => 1
transfer: tokenX[AliceAccount] = 0
tokenX[BobAccount] = 1
Alice と Bob は実際には何も所有していない
- コントラクトの介在なしには、自分のアセットに対してのアクセスをコントロールできない
- 自分のアセットを貸したり、預けたり、他のコントラクトに使わせたりすることができない
tokenX smart contract
AliceAccount
BobAccount
Transfer
�EVM アプローチのアセット(トークン)
- 所有者情報はマッピングである (tokenId -> ownerAddress)
- メタデータ (name, symbol, tokenURI) はコントラクトアカウントに保存される
- アセットはJSON blobとして記述され、オフチェーンに保存される
{
"name": "Thor's hammer",
"description": "Mjölnir, the legendary hammer of the Norse god of thunder.",
"image": "https://game.example/item-id-8u5h2m.png",
"strength": 20
}
https://docs.openzeppelin.com/contracts/2.x/erc721
NFT(ERC-721) - Example
一般的なブロックチェーンの�データモデルの問題点
アセットがスマートコントラクト内に閉じ込められる(trapped)
アセットの移動はリソースの競合を引き起こす
NFT = URLのラッパー
コンポーザビリティ
スマートコントラクトの境界を越えたアセットの共有は難しく、エラーが発生しやすい
NFTアセットが互いにどのように相互作用するかをプログラマブルに定義する方法がない
❌プロトコルのコンポーザビリティ�- コントラクトがアセットを相互に利用する
❌アセットのコンポーザビリティ�- アセットを組み合わせて新しいアセットを生み出す
プログラマビリティ
Programmability
すべてはアセットに関すること
アセット、所有権、アクセス制御ルールはスマートコントラクトの基本的な構成要素ですが、それらを説明するための語彙がない！
1. 新しいアセットタイプを定義する
2. アセットを読み書きし、転送する
3. アクセス制御ポリシーをチェックする
- Solidityでは、アセットがファーストクラスの概念としてさえ存在しない
- コントラクト2で使用されるアセットタイプをコントラクト1で使用することは不可能
ERC-721のような "標準 "は 最小公倍数。�基本的な静的アセット以外を記述するにはあまりにも窮屈
プログラミング
モデル
Solidityは次の典型的なことすらできない！
アセットを関数の引数として渡す、関数の返り値とする
データ構造にアセットを格納する
関数に対して一時的アセットの借用を渡す
アセットを作成したそのコントラクトの�外にそのアセット持ち出す�
トランザクション
処理
Transaction Processing
古典的なバリデータのアーキテクチャ
問題点
💎
完了!
Mempool / 初期チェック
コンセンサス/ シーケンシング
逐次実行
DB更新 +�高整合性データ構造
p2pフラッド& 手数料に基づく選択
すべてのトランザクションをブロック内で並べる
各トランザクションを実行する（グローバルロック）
DB、インデックス、暗号（マークル木）を更新する
オーバーレイフラッドは遅く、かつ大幅な冗長性がある
BFTコンセンサス：秒単位の遅延、伝統的には低スループット
シングルコアで全ての計算を実行
ストア、ブロックの追加遅延
バリデータが行うこと
新しいブロックチェーン
アーキテクチャ
- 完全なアセット - セントリック
- 型付きオブジェクトとしてのアセット
- コンポーザブルなアセット
完全なアセット-セントリック
各アセットは型付きオブジェクトとして表現される
グローバル・ストレージは Map<ObjectID, Object>
すべてのオブジェクトはステーブルかつグローバルに一意のIDを持つ: 「すべてがNFT」
すべてのトランザクションの入力と出力は�オブジェクトで表現される
トランザクションの依存関係は明示的で、�静的に把握可能
Tx
IDA,2
IDB,3
IDA,3
IDc,0
型付きオブジェクトとしてのアセット
開発者はオブジェクトタイプを定義することで、あらゆるアセットをモデル化できる
オブジェクトは複数のコントラクトをまたいで一貫したセマンティクスを持つ
アセットデータはオンチェーンで保存可能
アセットのプロパティの変更が可能
コンポーザブルなアセット�
装備
オブジェクトは他のオブジェクトを所有できる
変更し、組み合わせ、階層構造を作ることが可能
tokenX smart contract
AliceAccount
BobAccount
Purchase
�Suiが採用しているアセット (トークン)
tokenX smart contract
AliceAccount
BobAccount
Purchase
Purchase: create tokenX ->
T
transfer tokenX
T
(
)
�Suiが採用しているアセット (トークン)
tokenX smart contract
AliceAccount
BobAccount
T
Alice は実際にアセットを所有している
�Suiが採用しているアセット (トークン)
tokenX smart contract
AliceAccount
transfer tokenX
BobAccount
T
(
)
Alice は実際にアセットを所有している
Alice は Bob に直接譲渡できる
�Suiが採用しているアセット (トークン)
tokenX smart contract
BobAccount
AliceAccount
T
Alice は実際にアセットを所有している
Alice は Bob に直接譲渡できる
�Suiが採用しているアセット (トークン)
Move
アセットと所有権は �線形型でエンコードする
「あなたが私にコインをくれたら、
私はあなたに車検証をお渡しますよ」
fun buy(c: Coin): CarTitle
「あなたが権利書を見せて手数料を払えば、�私は登録証をお渡ししますよ」
fun register(c: &CarTitle, fee: Coin): CarRegistration{…}
*線形型
型システムが防ぐ �アセットバリューの不正使用
デジタル資産が物理的な資産と同じように振る舞うことを保証する
複製
Duplication
fun f(c: Coin) {
let x = copy c; //error
let y = &c;
let copied = *y; //error
}
二重支払い
Double-spending
fun h(c: Coin) {
pay(move c);
pay(move c); //error
}
破壊
Destruction
fun g(c: Coin) {
c = …; //error
return //error—must move c!
}
PROTECTION
AGAINST
でも、 �それは早いの?
❓
開発者にとって必要なこと
コストの予測可能性
❌ グローバルな手数料市場
- 関連性のないオンチェーンアクティビティがグローバルにコストを押し上げる
サービスの可用性
❌ 固定された低料金
- スパムに対する抑止力が低い
キャパシティの弾力性
ただのスケーラビリティではなく
短期:�急増に対応するため、オンデマンドで�容量を増やす能力
長期: �需要の増加に伴い、時間とともに�キャパシティが増加
オブジェクトセントリック
データモデルによるスケーリング
トランザクションはその対象オブジェクトに基づいてグループ化される
各グループは別々のワーカーによって独立して処理することができる
バリデータはワーカーを追加することでキャパシティを水平にスケールできる
バリデータは需要の急増に対応するためにより多くのワーカーを“起動”できる
Coin�Balance
DEX
NFT�Mint
1
2
3
4
5
6
7
9
8
既存のブロックチェーン(Ethereum):�シングルレーンアプローチ
👯♀️
🚘
👯♀️
👯♀️
🚘
👯♀️
🚘
👯♀️
🚘
👯♀️
初期チェック
順序付け
実行
ブック
キーピング
Sui:�マルチレーンアプローチ
初期チェック
順序付け
実行
❌
ブックキーピングはクリティカルパスから外れて実行
🚘
🚘
🚘
🚘
🚘
🚘
🚘
🚘
❌ 順序付け�は不要
Suiバリデータアーキテクチャ
一貫性のあるブロードキャスト
トランザクション
ローカルWAL
*Write-Ahead Logging
コンセンサス
tx履歴 チェックポイント
状態 チェックポイント
Execution
Execution
実行
Execution
Execution
実行
No!
実行は並列化される
確定した証明�ただし完全なコンセンサスなし
確定した証明�完全なコンセンサス
auditのための履歴 / アーカイブ / 同期
+1 net Delay
どのようなトランザクションは �コンセンサスを回避できるか？
全ての入力: 所有オブジェクト,
同一アドレスに所有されている
=>
必要なのは信頼できるブロードキャストだけ �(オーナーが指定したシーケンスを確認)
IDx,25
IDY,5
IDx,26
IDY,6
Tx
Ty
入力: 所有オブジェクト(同一アドレス)と共有オブジェクトの混合
=>
同一の共有オブジェクトに関する他の
トランザクションとの関係でコンセンサスが必要
(シーケンスを共同して作成)
IDx,?
IDY,?
IDx,?+1
IDY,?+1
Tx
Ty
オーナーがシーケンスを決定できる
システムがシーケンスを決定しなければならない
他のIDxに関連したシーケンス
オブジェクトのバージョン => 並列実行
Core 1
所有オブジェクトのトランザクションは�常に並列実行可能。入力されたオブジェクトの
ID/バージョンさえ知っていればよい
IDx,25
IDY,5
IDx,26
IDY,6
Tx
Ty
共有オブジェクトもまたそれぞれに対して
並列で実行可能�(ただし各共有オブジェクトに対して逐次実行)
IDx,?
IDY,?
IDx,?+1
IDY,?+1
Tx
Ty
他のIDxとのシーケンス
Core 1
Core 4
Core 3
今日のまとめ
まとめ
既存のブロックチェーンは
アセットインフラが貧弱。
データモデルに原因がある
データモデルは
・所有権管理
・アクセス制御
・スマートコントラクトの表現力
・スケーラビリティ
に影響する
Suiはオブジェクトセントリックなデータモデルによって、
トランザクションパイプラインの並列化しスケーラビリティを獲得すると同時に、
無数のユーザビリティとプログラマビリティの制限を解決する。
Thank you, welcome to Sui!
MoveとSuiMoveの違いは？
Move
・Account-centric
・各アセットはアカウント配下に型付きリソースとして格納される
・グローバル・ストレージは Map<(address, ResourceType)>
・採用チェーン: Diem, Aptos, 0L, Starcoin, Movement Labs
Sui-Move
・Object-centric
・各アセットは型付きオブジェクトとして格納される
・グローバル・ストレージは Map<ObjectID, Object>
・採用チェーン: Sui
Original Move vs Sui-Move
Move
・各アセットは型付きオブジェクトとして表現される
・グローバル・ストレージは Map<ObjectID, Object>
Sui-Move
・各アセットは型付きオブジェクトとして表現される
・グローバル・ストレージは Map<ObjectID, Object>