Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ICOコンサルティング事業から得たトークンと全体アーキテクチャ設計方針の知見 @ blockchain.tokyo #2

29d8c9f22e421a3044572dd66812c22d?s=47 Tomohiro Nakamura
November 14, 2017
Technology
7
23k

ICOコンサルティング事業から得たトークンと全体アーキテクチャ設計方針の知見 @ blockchain.tokyo #2

29d8c9f22e421a3044572dd66812c22d?s=128

Tomohiro Nakamura

November 14, 2017
Tweet

More Decks by Tomohiro Nakamura

See All by Tomohiro Nakamura
29d8c9f22e421a3044572dd66812c22d?s=48 tomohiron
2
1.7k
29d8c9f22e421a3044572dd66812c22d?s=48 tomohiron
2
1k

Other Decks in Technology

See All in Technology
0e20ab5db11ca70d818a4f10bfea9c9c?s=48 ymas0315
0
180
93c80c388fe9d8f9df7d030549a0ff0b?s=48 chaspy
1
160
3009eedce0d0f7ae45987a7bd8f57b85?s=48 nkjzm
1
850
9e7a653ed313b3da4b263a772bfc5026?s=48 clustervr
0
210
4649f3418cb4e7b951ca28e65003c7ac?s=48 sumi
0
530
79c9f45e8a3cd4bfa9d7292adb3a6dc0?s=48 kraj
0
5.4k
9e7a653ed313b3da4b263a772bfc5026?s=48 clustervr
0
190
A61fc58218907d6778a6cbf0fe7611da?s=48 redhatopenshift
0
310
A64ac825509279a770c13c6fc517f11a?s=48 kawaguti
0
120
19fc8f6113c5c3d86e6176362ff29479?s=48 kanaugust
PRO
0
100
53850955f15249a1a9dc49df6113e400?s=48 line_developers
PRO
0
2.2k
D683c1df0b6584c3f1e279ef6c8c04f9?s=48 layerx
1
920

Featured

See All Featured
F57e2136eb9895eb95ff5dc8a1c02677?s=48 zakiwarfel
88
3.3k
E14f55d3f939977cecbf51b64ff6f861?s=48 keithpitt
401
20k
168ccec72eee0530b818d44f3fedaacf?s=48 shlominoach
176
7.4k
C1daf20e5c49ff910745198ef9869ac2?s=48 hatefulcrawdad
257
17k
D47656e20ff5e42f125fc5ea0fd636c6?s=48 tmm1
61
8.4k
E13c31390e0369fcd5972292ce0e7b92?s=48 jnunemaker
PRO
40
4.6k
6bb82b13cda86d3b821fa44100335ddf?s=48 thoeni
4
550
053e75a5b48b44d6dd0612795dfb326d?s=48 notwaldorf
13
1.6k
A60068bce2e73de3a37ca9d2dbe36092?s=48 bryan
30
3.3k
1519587b1a0febb658c36c94f6272b0d?s=48 roundedbygravity
241
21k
1f74b13f1e5c6c69cb5d7fbaabb1e2cb?s=48 sferik
609
54k
Be9caeb9d4ef9944d151af909063ed6e?s=48 samlambert
237
9.9k

Transcript

  1. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE CTO Tomohiro Nakamura ( @HAIL ) ICOコンサルティング事業から得た トークンと全体アーキテクチャ設計⽅針の知⾒ 2017/11/14（Tue）

  2. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE ⾃紹介 AnyPay株式会社 CTO Tomohiro Nakamura ( @HAIL ) 2010年

    早稲⽥⼤学⼤学院情報理⼯学専攻 2010年 Goldman Sachs 2012年 Electronic Arts (ex. Playfish) 2014年 Wekids Inc. 創業 2016年 AnyPay株式会社 CTOとして⼊社 好き: Kotlin, Android, GCP paymo招待コード: PNKYFNP ࣗݾ঺հ

  3. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE εϚʔτϑΥϯܾࡁαʔϏεΛఏڙ ΘΓ͔ΜΞϓϦzQBZNPz ܾࡁαʔϏεzQBZNP CJ[z ఏڙதͷαʔϏεʹ͍ͭͯ ఏڙதͷαʔϏεʹ͍ͭͯ

  4. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE *$0ίϯαϧςΟϯάࣄۀʹ͍ͭͯ ৽نࣄۀ 'JO5FDIࣄۀͷల։ɺۀք΁ͷ౤ࢿ࣮੷΍ࠃ಺֎ͷؔ࿈اۀͱͷϦϨʔγϣϯΛ׆͔ͯ͠ɺ Ծ૝௨՟ʹΑΔࢿۚௐୡɺ*$0ίϯαϧςΟϯάࣄۀΛల։ɻ λʔήοτ ڧΈ ελʔτΞοϓɾະ্৔தখاۀஶ໊ਓͳͲ ࢿۚௐୡधཁ͕ΑΓߴ͍اۀΛ༏ઌɻ Ұൠফඅऀ΁ߴ஌໊౓΍޿͍ϑΝϯ૚

    *$0ʹೃછΈͷ͋Δاۀ΍Ұൠ౤ࢿՈ΍ ػؔ౤ࢿՈͷרࠐΈૂ͍༏ઌ౓Λݕ౼ ɾԾ૝௨՟ۚ༥ۀք΁ͷਂ͍ཧղ ɾ౤ࢿՈऔҾॴɺۀ຿ఏܞઌͳͲωοτϫʔΫ ɾઓུίϯαϧςΟϯάͷέΠύϏϦςΟ ɾߴ͍ٕज़ྗ $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE

  5. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE ICOコンサルティング事業について 事前準備 事前設計 実装 ICO実施 ⽬的・意義の 定義 調達額・ 計画検討

    既存株主への 説明・説得 スキーム決定 コイン機能・サー ビスとの融合決定 コイン実装 サ イ ト オ プ ン プ レ セ ル ク ラ ウ ド セ ル 社 内 側 の 動 き 社 外 協 議 取引所との協議 弁護⼠確認・協議 ﾌﾟﾛﾓｰｼｮﾝ・ 投資家との ｺﾐｭﾆｹｰｼｮﾝ ｷｬﾝﾍﾟｰﾝ 設計 ｵﾍﾟﾚｰｼｮﾝ 設計 ホワイト ペーパー 作成 サイト 作成 セ カ ン ダ リ マ ケ ッ ト 開 設 1カ⽉〜 1〜2カ⽉ 2〜3カ⽉ ：法務・会計 ：技術・開発 ：ビジネス・マーケ

  6. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE どうしたら ICOに投資してくれるだろう？

  7. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE 1. 値上がりが期待できる 2. 付加価値がついている

  8. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE 付加価値のかたち ICO実施企業の 提供サービス内にて 通貨として利⽤、もしくは 特別割引などの優待を 受ける事が可能 コインが株式のような 役割を担い、 保有者に対して

    企業経営・プロジェクトの 収益の⼀部が還元される サービス型 株式型

  9. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE 実際に設計してみよう

  10. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE その前に前提を・・・ Ethereumブロックチェーンに乗っかる ICOの多くはEthereumベース Solidityを使った開発やParityなどを使ったデプロイや管理などエコシステムが できあがりすぎていて圧倒的に楽なため 送受信されるコントラクトはERC20インタフェースに乗っかる Ethereumベースのコントラクトが基本的に実装するべき関数の定義たち、 と考えておけば良い ウォレットや取引所サービスたちは、基本的に各トークンがERC20準拠である

    ことを前提にしている

  11. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE ERC20 contract ERC20 { // 合計流通量を返す function totalSupply() constant

    returns (uint totalSupply); // _owner の持っている量を返す function balanceOf(address _owner) constant returns (uint balance); // _to に _value 分送る(ウォレットアプリがよく叩く関数) function transfer(address _to, uint _value) returns (bool success); // _from から _to に _value 分代理で送る function transferFrom(address _from, address _to, uint _value) returns (bool success); // _spender に _value 分代理で送ることを許可する function approve(address _spender, uint _value) returns (bool success); // _owner は _spender にどれだけの量を代理で送ることを許可しているか返す function allowance(address _owner, address _spender) constant returns (uint remaining); }

  12. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE 典型的な(シンプルな)セールの流れ CONFIDENTIAL : copyright © by 2017 AnyPay inc.

    all rights reserved 1. セールの実施前に参加予定者に事前登録してもらい連絡⼿段を確保 (Email, Slack, Telegram, etc…) 2. セールの実施前に、参加予定者にETHを取引所アカウントではなく、⾃ 分で秘密鍵を管理しているアカウントに移動しておくよう伝達 3. セール開始直前に、参加予定者にETH振込先を伝達 4. ETHを振り込んでくれたアドレスに、ERC20準拠であるICOトークンを 送り返す 5. 終了⽇時または最⼤調達⾦額に達したら締め切り

  13. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE 〜ケーススタディ〜 想定クライアントはアジアのあるライドシェアサービス 当然ながら、ICOをきっかけにサービスの拡⼤を考えている 以下のフェーズに分けてICOをしたいと考えている

  14. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE ケーススタディ ‒ Phase 1 ① このICOで得た資⾦で、サービスに使う⾞両を購⼊する ② このトークンを持っていることにより、購⼊された⾞両によって得られた利益のうち⼀ 部が分配される(株式型)。利益の分配はEthereumベースで毎⽉決まったタイミングで

    ⾏われる ③ トークンセールの参加にはKYC(本⼈確認) が要求される。また、許可されていないアド レスにtransferすることは許可しない ④ Phase 1のセールは2回⾏われる。それぞれ期間と上限額を事前に決定する。1回⽬は 2ヶ⽉後ぐらいを予定している。2回⽬は未定 ⑤ KYCは2度のPhase 1セールで共有される ⑥ 後々発⾏されるPhase 2のトークンに割引価格で変換できる ⑦ または、⾞両が償却されるまでトークンを持ち続けた場合、再売却価格の分配を受ける こともできる Phase 1

  15. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE ケーススタディ ‒ Phase 2 ① Phase 2のトークンは、このICO予定の会社以外にも、世界中のシェアリング サービスで利⽤可能なサービス型トークンとなっていく計画を持っている ②

    サービスのユーザは、このトークンを⽀払に利⽤することができる ③ シェアする側のユーザは、対価としてこのトークンを受取る ④ Phase 1とは違い、こちらのトークンは取引所への上場を予定している Phase 2

  16. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE さあ設計してみよう！ オブジェクト指向でいうところのクラス図を書こう！ (Ethereumのコントラクト開発は、 正直オブジェクト指向にちょっと寄った JavaScript開発ぐらいの気持ち)

  17. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE 要点1 ユーザに伝達したアドレス上の コントラクトを上書きすることは無理

  18. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE 要点2 数ヶ⽉以上後先のサービスのことなど 普通確定しない(仕様は誰も知らない) (通貨が仮想になりDBがブロックチェーン になったぐらいでこの宇宙の決まりが 変わるわけない)

  19. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE この2点からの導き • 柔軟に作ろう • ユーザが触れるコントラクトでごちゃごちゃやるのはやめよう • 迷惑かけずに実装を変更できるようにしよう • 先のことはわからないが可能性が⾼いことのPoCはなるべくしよう

    • こんな当たり前のことをするのが⾯倒な時点でつらぽよなので、す べてをEthereum上でやるかどうかは疑問視してかかろう (時間次第ですがここで1分ぐらい待ちます)

  20. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE 解答例

  21. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE 登場⼈物 1. Coin Vendor(投資家がETHを振り込むアドレスのコントラクト) 2. Coin(投資家が⼿に⼊れるトークンの実装。ERC20) 3. Coin Implementation(ロジックを書くコントラクト)

    4. Storage(データを持つコントラクト) 5. Shared Storage(複数トークン間でシェアするデータを持つコント ラクト)

  22. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE Coin Vendor • Phase 1のコインをまとめ て”Private Coin” と便宜上呼ぶ •

    ユーザがこのコントラクトに ETHを送るとpayableな無名関 数()が呼ばれる • セールの期間やこれまでに販売 した(発⾏した)量、最⼤販売量、 販売単位などが定義されている • コインの実装コントラクトへの 参照を持つ • transferFundsはたまったETH を引き出す関数

  23. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE Coin Vendor要所 function () public payable { vend(msg.sender, msg.value,

    now); } function vend(address receiver, uint value, uint timestamp) internal returns (bool) { uint amount = value / tokenUnitPrice; // ETH (単位は wei) を購入数に変換する require(amount >= minimumPurchaseUnit); // 最小販売トークン数を超えているか require(timestamp >= salesBegin && timestamp < salesEnd); // 販売期間の確認 require(safeAdd(amount, cumulativeSalesAmount) <= salesAmount); // 在庫の確認 cumulativeSalesAmount = safeAdd(cumulativeSalesAmount, amount); impl.mint(receiver, amount); // 発行する(実装はimplに委譲されている) return true; }

  24. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE Coin Implementation • 実際のロジックを持つ • データは持たない • ⾮管理者から関数が叩かれ ることは想定していないの

    で殆どの関数が auth 修飾 ⼦つき

  25. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE Coin Implementation要所 function transfer(address sender, address to, uint amount)

    auth public returns (bool) { require(coinStorage.coinBalanceOf(sender) >= amount); // 残高を超えて送金してないか require(amount > 0); // 1円以上送ろうとしているか // オーナーまたは許可された (KYC 通過済み) アドレスかを確認 require(sharedStorage.isOwnerAddress(to) || sharedStorage.isApprovedAddress(to)); // 送金元の残高を減らし、送金先の残高を増やす coinStorage.setCoinBalance(sender, safeSub(coinStorage.coinBalanceOf(sender), amount)); coinStorage.setCoinBalance(to, safeAdd(coinStorage.coinBalanceOf(to), amount)); // 送金先がコントラクトで、isPrivateTokenAcceptable が true を返すコントラクトではreceiveToken() if (isContract(to)) { PrivateCoinAcceptableContract receiver = PrivateCoinAcceptableContract(to); if (receiver.isPrivateTokenAcceptable()) { require(receiver.receiveToken(sender, amount)); } } return true; } ここがPhase 2のPoC部分 (Phase 1トークンはPhase 2トーク ンに割引価格で交換できる)

  26. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE Coin • 取引されるトークンのコン トラクト • ERC20準拠 • Eventを呼ぶ •

    実装はimplに委譲

  27. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE Coin要所 function transfer(address to, uint amount) public returns (bool)

    { if (impl.transfer(msg.sender, to, amount)) { Transfer(msg.sender, to, amount); return true; } else { return false; } } Eventを呼ぶ 基本的にimplに委譲

  28. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE Coin Storage Phase 1の2つのトークンそれぞれ別々に持つデータのコントラクト

  29. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE Shared Coin Storage KYC済みアドレスのリストなど、 Phase 1の2つのトークンで共有するデータのコントラクト

  30. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE もう⼀度登場⼈物 1. Coin Vendor(投資家がETHを振り込むアドレスのコントラクト) 2. Coin(投資家が⼿に⼊れるトークンの実装。ERC20) 3. Coin Implementation(ロジックを書くコントラクト)

    4. Storage(データを持つコントラクト) 5. Shared Storage(複数トークン間でシェアするデータを持つコント ラクト)

  31. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE リリース⽅法 1. 全てのコントラクトをせっせとデプロイする 2. setImpl(address) auth public: bool などを実⾏して付け替えを⾏う

    3. KYC済みユーザの追加は impl.addApprovedAddress(address) データのコントラクト書き換えの場合は マイグレーションも頑張らないといけませんよね…… 正直Ethereumすごい。すごいけど

  32. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE Phase 2をすべて この調⼦で実装していこうと思ったら まだつらい気がしている…… (GAS⼿数料も⾺⿅にならない笑)

  33. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE ⼿段のために⽬的を⾒失わない ⼀番⼤事なことは • ◦ トークンの価値が上がり投資家もユーザもハッピー • ◦ サービスが使いやすくてユーザもハッピー •

    ◦ メンテが楽で開発者もハッピー • × 全部ブロックチェーンでやるとかっこいい ストレージが増える(RDB, NoSQL, ブロックチェーンetc)ごとに、 当然ながらメンテは⼤変。 Ethereumとプライベートな独⾃ブロックチェーンの併⽤も⼤変。 かっこよさとハッピー、両⽴したい、どうしよう…… えっ、もっと詳しく話を聞きたいって？

  34. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE ここでお知らせです AnyPayではICOコンサルティング を提供しております AnyPayでは優秀なエンジニアと コンサルタントを募集しております

  35. $0/'*%&/5*"-DPQZSJHIU˜CZ"OZ1BZJODBMMSJHIUTSFTFSWFE 決済でもブロックチェーンでも、 興味ある⼈はWantedly で応募待ってます！ https://www.wantedly.com/projects/167898