XRPL DeFi Hackathon Input Session

Transcript

1. XRP Ledger Input Session
2. 自己紹介 Q / tequ 2017年からクリプトの世界へ アカウントの残高追跡アプリや NFTマーケットプレイスなどを作成 @_tequ_ 2
3. Agenda • XRP Ledgerとは • コンセンサスの仕組み • データ保有 • 手数料と準備金 • アカウントの管理 • XRPレジャーの機能 3
4. XRP Ledgerとは 4
5. XRP Ledgerとは XRP XRP Ledgerの開始時に1000億単位発行されたネ イティブトークン 手数料や準備金、ブリッジ通貨など 手数料や準備金の額はバリデータによるオンレ ジャーのガバナンス投票により決定。 スパム対策となり、かつユーザの負担が小さくなる 額へ調整される。 XRP Ledger（XRPL） 2011年から2012年にかけてBitcoinの初期コントリ ビュータを含む3人の開発者によって開発された分 散型のL1ブロックチェーン Bitcoin/Ethereumとは異なる独自のコンセンサスア ルゴリズム →PoW・PoSに対してPoA(Proof of Association) と呼ばれることも。 プロトコルネイティブなDEXやNFT →最小限のコントラクトリスク 5
6. コンセンサスの仕組み How Consensus Works
7. コンセンサス • XRP Ledger Consensus Protocol / Proof of Association ◦ 連合コンセンサスとも • PoWやPoSなどの計算力や資金力によるパワーの競争の仕組みではない ◦ トランザクションを選択するリーダーの選出は行わない ◦ 上位いくつかのマイナー /バリデータが共謀することで 悪意あるトランザクションがネットワークに取り込まれるリスクがない • 各ノードは共謀しないと信頼する(=コンセンサスを取りたい)バリデータのリストを自由に設定 ◦ 選択するバリデータは誰かに強制されているものではない。 ◦ 多数のバリデータと大きく異なる選択をした場合はネットワークをフォローできなくなる恐れ • バリデータ間の合意と妥協の中でレジャーに含めるトランザクションの決定・バリデーション 7
8. バリデータによる投票 8 トランザクション手数料 Amendment 準備金 投票はトランザクションとして処理 バリデータのみが作成可能な特殊なトランザクション 通常のトランザクションと同じように 80%超からの提案が必要
9. Amendment • XRPLのトランザクション処理方法の変更 • レジャー番号ベースではなく、 合意ベースでの変更 • Featureフラグ ◦ 各バリデータの投票 (80%超)により有効化 ◦ レジャー情報にフラグ保持 9 サーバプログラムのアップデート ≠ 機能の有効化 開発者の望む機能とネットワーク参 加者が望む機能が一致するとは限 らない
10. データ保有の思想
11. データ保有 ユーザが望まないオブジェクトを保有させることはできない ◦ ユーザが資産を盗まれるリスクの軽減 ◦ ユーザが保有を希望するなら ▪ 明示的な表明（TrustSet) ▪ ユーザ自身によるオブジェクトの取得 (OfferCreate, NFTokenCreateOfferなど) 11
12. 手数料と準備金 Fee and Reserves
13. 手数料と準備金 トランザクション手数料 ◦ トランザクションを送信するためのコスト ▪ → ネットワークコスト ◦ 非常に安い(0.001円程度) ◦ ネットワークが高負荷の場合に、必要となる手数料は高 騰 準備金 ◦ レジャーオブジェクトを保有するためのコスト ▪ → ストレージコスト ◦ オブジェクトを保有しなくなったら返還される 13 ユーザの実質負担コストを最小化 ストレージ利用中だけ負担 処理実行コスト
14. 手数料と準備金 • 基本準備金 (Base Reserve) ◦ アカウントを有効化するために必要な準備金 ▪ アカウントが有効化 = AccountRootオブジェクトが存在 ◦ 1アカウントあたり 10XRP ◦ アカウントの削除を行うことで準備金の一部を取り戻すことが可能 • 所有者準備金 (Owner Reserve) ◦ １つのレジャーオブジェクトを保有するために必要な準備金 ◦ 1オブジェクト当たり 2XRP ◦ オブジェクトを削除することで準備金を取り戻すことが可能 • 準備金の額はバリデータによるオンレジャーの ガバナンス投票によって決定 14
15. アカウントの管理 Account Management
16. アカウントの管理 アドレスはEVM系のような公開鍵形式ではなく、公開鍵から算出した形式を利用 `rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh` • マルチシグ ◦ 最大32アカウント ◦ 複数人でアカウントの操作が可能 • レギュラーキー ◦ 他アドレスのキーでトランザクションへの署名 ◦ マスターキーの流出リスクを減らす • マスターキーの無効化 ◦ プロトコルでマルチシグを必須とする運用が可能 16
17. Payment Smart Payment features
18. Payment • ネイティブアセット送金 • トークン送金 • クロスカレンシー送金 • スワップ 18
19. Paymentトランザクションのフィールド • 通貨額(Amount) ◦ ネイティブトークン (XRP) ▪ 文字列で指定 ▪ 最大100,000,000,000,000,000 ◦ 発行トークン ▪ オブジェクト型 • 発行者アドレス: issuer • 通貨コード: currency • 金額: value 19
20. Paymentトランザクションのフィールド • Amount ◦ 宛先に届ける通貨額 • SendMax ◦ 送金元が支払う最大の通貨額 • DeliverMin ◦ 宛先に届ける最低の通貨額 ◦ Partial Payment時のみ • DeliverMax ◦ Partial Payment時のAmount (APIレスポンスでのみ ) ◦ トランザクションでは指定不可 20
21. Tokenization Advanced token management features
22. トークンの管理 • 保有者制限機能: Authorized TrustLine ◦ トークンが保有可能なアカウントを発行者が認可 ◦ 認可トラストライン • 凍結機能: Freeze ◦ 第三者間のトレード、送付を禁止する • 回収機能: Clawback • 入金制限機能: DepositAuth ◦ Paymentトランザクションによる入金を認可制とする ▪ Checkなどでの入金は可能 22 規制要件準拠のため
23. DEX Built-in decentralized finance
24. DEX • CLOB • AMM 通貨ペアが1つであることによるグローバルな流動性 CLOBとAMMの流動性の統合 AutoBridging/PathFindingによる流動性の向上 24
25. DEX • 世界初のDEX ◦ 2012年のXRPL稼働当初から存在 • 無制限のペアとオンチェーンの注文情報 ◦ 注文情報はすべてチェーン上に公開情報として存在 ◦ 過去の約定情報も historicalデータから取得可能 • AutoBridgingによる最良レートの自動採用 ◦ USD->EURのトレードでUSD/EURだけでなくUSD/XRP,XRP/EURの流動性も自動的に利用 25
26. DEX/CLOB • DEX注文時(OfferCreate)のAutoBridging • 暗黙的にXRPをブリッジ通貨とするパスも利用 26 JPY USD DEX JPY/XRP DEX XRP/USD DEX JPY/USD 自動で利用される XRP
27. DEX 27 JPY USD DEX JPY/XRP DEX XRP/USD EUR ETH DEX ETH/XRP DEX XRP/EUR XRP • プロトコルネイティブでXRPをブリッジ通貨とする仕組み
28. DEX • クロスカレンシー送金(Payment)時のPathFinding • WebsocketAPIで継続的に最良パスを検索可能 28 JPY USD DEX JPY/XRP DEX XRP/USD DEX JPY/USD DEX JPY/BTC DEX BTC/EUR DEX EUR/USD 明示的に指定
29. DEX 29
30. AMM • CLOBの流動性との統合 ◦ 外部のアグリゲータ不要でのネイティブ統合 • 無制限のプール・プール毎のガバナンストークン (=LPToken) ◦ プールの取引手数料投票や連続オークションへの入札 • 連続オークション ◦ 取引手数料割引の権利を競い、 低ボラティリティでも裁定機会 を与える ◦ トレーダー...ボラティリティがプールの取引手数料未満でも裁定機会を得ることができる ◦ 流動性提供者…オークションから収益を得ることができる • MEVなし ◦ トランザクションは正規化された順序で実行され、複数のバリデータとの合意が必要 ◦ 1バリデータがレジャーに含めるトランザクションを決定したり、その順番を決めることは不可能 30
31. Hooks Small, efficient piece of code
32. Hooks • ネイティブなスマートコントラクト機能 ◦ アカウントにスマコンを付与 • XRPLのトランザクション送受信の前後へロジックを組み込む ◦ 支払いを行う前に・・・ ◦ 支払いを受け取った時に・・・ ◦ NFTを購入した時に・・・ ◦ Hook実行用トランザクションを実行した時に・・・ • State操作 • Hookロジック内からトランザクションを送信 ◦ 支払いを受けた時に NFTを転送 ◦ NFTを売却した時にトークンを売却 • パラメータやメモなどでHookにデータを渡す 32
33. Hooks 33 コントラクト アカウント Hookあり アカウント 秘密鍵なし 秘密鍵あり プロトコルで 秘密鍵無効化可能 Hookの追加・更新・削除などより高い自由度
34. Hooks • ユースケース ◦ 支払いの分配 ◦ ブラックリストによる支払いの拒否 ◦ DeFi etc… • WASMによるコーディング ◦ C, AssemblyScript, Rustなど • 安全なスマートトランザクタとの連携が可能かつ EVMで可能なことのほとんどが可能 • Hookの更新が可能 ◦ 更新不可能(コントラクトアカウント化 )とすることも可 34
35. Hooks 35 最大20のチェーンが可能
36. Xahau Network 36 XRP Ledgerのコードフォーク Xahau <> XRPLでコードの移植は容易 (有効化は別の話 ) スマートコントラクト機能Hooksを搭載 XRPLメインネットに対する実験的なプロダクション環境の意味も持つ Evernode - Hooksを利用したXahau上のL2ネットワーク AppChainとして機能する超柔軟な dAppsを構築可能 JS/Pythonを含むほぼ全ての言語で構築可能
37. ドキュメント XRPL Developer Document xrpl.org Xahau Developer Document
 docs.xahau.network Evernode evernode.org 37
38. 学習ポータル XRPL Learning Portal learn.xrpl.org 38
39. コミュニティ XRPL Japanディスコード discord.com/invite/xrpljapan 開発者またはリサーチャー権限を選択し、 開発者チャンネルに参加しましょう 39