LoveChainのスマートコントラクトを見てみよう & 非中央集権なトークンのカタチ

Copyright Drecom Co., Ltd. All Rights Reserved. 1
のスマートコントラクトを
見てみよう
非中央集権的な
トークンのカタチ
&

前半

のスマートコントラクトを
見てみよう
blockchain.tokyo #12
2018/09/25

自己紹介
株式会社ドリコム
DRIP部
エンジニア
小川光典
@ogwmtnr

DRIP

LoveChain
2018年7月5日リリース
https://lovechain.ooo

LoveChainの仕組み
タロウハナコ
LoveChain
スマートコントラクトハナコ
に
プロポーズ
タロウ
に
プロポーズPartner
タロウ & ハナコ

タロウハナコ
LoveChain
スマートコントラクトメッセージ
追加
メッセージ
追加
Partner
メッセージ
url
view

タロウハナコ
LoveChain
スマートコントラクトお別れ
Partner
メッセージ
url
view

LoveChainコントラクト
mapping (address => address) private propose;
誰が誰に対してプロポーズ中なのか、を保持。
mapping (address => address) private partner;
誰と誰がパートナーなのか、を保持。
例えばタロウ（address: 0xA）とハナコ（address: 0xB）がパートナーだったら、
partner[0xA] = 0xB;
partner[0xB] = 0xA;
という状態になっている。
mapping (uint256 => string[]) private partnerMessages;
パートナーのメッセージが格納されている。

function proposeTo(address to) public
msg.sender から to に対してプロポーズ。
▼既に to から msg.sender に対してプロポーズ済だった場合、
partner[msg.sender] = to;
partner[to] = msg.sender;
▼まだ to からプロポーズされてない場合、
propose[msg.sender] = to;

function addMessage(string message) public
パートナーとの `partnerMessages` にメッセージを追加。
`partnerMessages` のキーは uint256 になっていて、ここには
「パートナー2人の `address` 」
を元にして作られたハッシュが入る。

function addMessage(string message) public {
address target = partner[msg.sender];
require(isPartner(msg.sender, target) == true);
uint index = partnerMessages[uint256(keccak256(craetePartnerBytes(msg.sender, target)))].push(message) - 1;
Message(msg.sender, target, message, index);
}

function getPartnerMessage(address a, address b, uint index) public view returns
(string)
パートナーのメッセージを取得する。
address さえ知っていれば誰でも叩ける。
パートナーでない address を指定した場合は revert となる。

function getPartnerMessage(address a, address b, uint index) public view returns (string) {
require(isPartner(a,b) == true);
uint256 key = uint256(keccak256(craetePartnerBytes(a,b)));
if (isHiddenMessages[key] == true) {
require((msg.sender == a) || (msg.sender == b));
}
uint count = partnerMessages[key].length;
require(index < count);
return partnerMessages[key][index];
}

function farewellTo(address to) public
パートナーとお別れする。
別れると先ほど紹介した `partnerMessageCount` や `getPartnerMessage` が revert となるため、
メッセージが見れなくなる。

LoveChain まとめ
• コントラクトは主に次の状態を持っている
– propose : 誰から誰にプロポーズ中か
– partner : 誰と誰がパートナーか
– partnerMessage : パートナーのメッセージ
• コントラクトは主に次のメソッドを使用している
– proposeTo
– addMessage
– partnerMessageCount / getPartnerMessage
– farawellTo
• パートナーのメッセージは2人の address を元に生成された
ハッシュをキーとする mapping object に保管される

LoveChainまとめ
公式ページフッターからコントラクトの ethscan ページへ行けます。
ソースコードも公開してます。
ココ！

LoveChainまとめ
公式ページフッターからコントラクトの ethscan ページへ行けます。
ソースコードも公開してます。

後半

blockchain.tokyo #12
2018/09/25
非中央集権的な
トークンのカタチ

自己紹介
株式会社ドリコム
DRIP部
エンジニア
小川光典
@ogwmtnr

ところで
みなさん

ERC721
トークン
持ってますか？

代替不可能
な
トークン

ERC721 と言えば
CryptoKitties

ERC721 と言えば
EtherTulips

ERC721 と言えば
CryptoCelebrities

ERC721 トークンのトレード
OpenSea

ERC721 トークンのトレード
RareBits

ERC721 トークンの価値
ERC721 トークンは、ユーザーの資産としてブロックチェー
ン上に半永久的に保持される。
ERC721 トークンの価値 ≒ サービス内での価値に紐づく

疑問
• (1) : サービスが終了したら全てのトークンは価値が無く
なってしまう？
• (2) : ユーザーが価値を手にする瞬間は売った瞬間、つま
りトークンを失う瞬間なので、ユーザーは「トークンが
資産価値を持つ」についてポジティブなイメージしずら
いのでは？
– 特に、高値のトークンはサービス内で価値があるので、サービ
ス利用を続行したいユーザーにとっては手放したくないので
は？

観測した取り組み1
HL-Report : Rekiconne Archive

レキシトコネクト内のキャラクターやアイテムの一部を
トークン化してユーザーに配布。

キティバース

仮想猫のデータを使って別の DApps が作れる

どちらも、トークンの参照は解放されているが、発行権は
各サービスが握っている。
任意のデータを持ったトークンを勝手に発行されないよう
に、すなわちトークンの品質を担保するためである。

↓
もしトークンの発行権も解放したら…

↓
もしトークンの発行権も解放したら…
どんな DApps でも発行でき、DApps 間で使いまわせるような
トークンが生まれて、ユーザーにとってトークンを作った
り所持したりするモチベーションが高まるのでは…？

作ろう！

まず ERC721 について
// イベント
event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);
event ApprovalForAll(addressindexed _owner, address indexed _operator, bool _approved);
// トークン所有権の移動
function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
// owner 以外でトークン transfer 可能なアドレスの設定
function approve(address _approved, uint256 _tokenId) external payable;
function setApprovalForAll(address_operator, bool _approved) external;
// オーナー情報
function balanceOf(address _owner) external view returns (uint256);
function isApprovedForAll(address_owner, address _operator) external view returns (bool);
// トークン情報
function ownerOf(uint256 _tokenId) external view returns (address);
function getApproved(uint256 _tokenId) external view returns (address);

// イベント
event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);
event ApprovalForAll(addressindexed _owner, address indexed _operator, bool _approved);
// トークン所有権の移動
function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
// owner 以外でトークン transfer 可能なアドレスの設定
function approve(address _approved, uint256 _tokenId) external payable;
function setApprovalForAll(address_operator, bool _approved) external;
// オーナー情報
function balanceOf(address _owner) external view returns (uint256);
function isApprovedForAll(address_owner, address _operator) external view returns (bool);
// トークン情報
function ownerOf(uint256 _tokenId) external view returns (address);
function getApproved(uint256 _tokenId) external view returns (address);

トークンの持つ固有な情報として定義されているのは
• owner
• approved
のみ。
それだけだと CryptoKitties における遺伝子のようなデータを持
たせられないので、DApps が定義可能な固有情報をトークン
に定義する。
「遺伝子」だと生物に寄りすぎているので、異なる名称を
考える。

ERC721 拡張
uint256 inscription : 銘刻
これを発行時に渡すと、不変なデータとしてトークンに刻
まれる。
function mint(address _to, uint256 _inscription) external

ERC721 拡張
しかし発行権を解放すると、任意の DApps で有利な inscription
を持つトークンが生成できてしまうので、トークンの品質
を担保できなくなるのでは？

ERC721 拡張
↓
………

ERC721 拡張

ERC721 拡張
！

ERC721 拡張
↓
トークンに発行元を記載する事で、そのトークンの品質に
対する信頼性を担保できるのでは？

ERC721 拡張
address creator
トークン発行時に msg.sender をトークン自身の creator として保
持させる。

ERC721 拡張使い方イメージ
DApps 独自
コントラクト
ERC721 拡張
コントラクト
発行を call
ERC721 拡張コントラクトの上に独自コ
ントラクトを乗せて使えば、独自コ
ントラクトのアドレスがトークンの
creator に刻まれる。
Inscription に入れるデータのロジックを
独自コントラクト等に記述すれば、
その発行元におけるトークンの品質
は担保されるはず。

ERC721 拡張
ERC721 トークンが
• DApps が定義可能な不変データ
• 自身の発行元
を持つ。
各 DApps は発行元と不変データを参照し、そのトークンの
振る舞いを決定できる。
例) ある Dapps では猫で、ある Dapps では有名人で、ある Dapps
では武器になって、ある Dapps では投票権になる。
トークンの発行/管理において、より非中央集権的な世界を
創り出せそうな可能性を感じる。

作りました

本日リリース！
https://6-pillars.ooo

DApps をまたいで利用可能なトークンを誰でも生成できる、
Ethereum 上で動作するスマートコントラクトです。
生成されたトークンには不変なデータが明記され、開発者
がそれを使いトークンの振る舞いを決定する事で、ある
DApps 上では価値がなかったものが、他の DApps 上では価値
が高いものとして扱われるなど、トークンの価値が絶対価
値から相対価値になります。

詳細はサイトにて。
https://6-pillars.ooo
github にてコードを公開してます。
npm ライブラリとして利用可能な状態になっています。
https://github.com/drip-oss/llllll

まとめ
• ERC721 トークンを使った既存サービスに思う疑問。
– 価値がサービスそのものに強く依存？
– トークンが価値になるタイミングがポジティブではない？
• 既にこの疑問に対する取り組みをしているサービスは存在するが、
トークンの品質を担保するため全てが解放されているわけではない。
• トークンに「銘文」と「発行元」を刻む事によりDApps で使いやす
い、かつ誰でも発行可能でどんな DApps も乗り越えて使える ERC721 拡
張トークンを定義し「||||||」としてリリースした。

drip drecom 🔍
フィードバックお待ちしてます

ご静聴
ありがとうございました！

LoveChainのスマートコントラクトを見てみよう & 非中央集権なトークンのカタチ

Recommandé

Recommandé

Contenu connexe

Similaire à LoveChainのスマートコントラクトを見てみよう & 非中央集権なトークンのカタチ

Similaire à LoveChainのスマートコントラクトを見てみよう & 非中央集権なトークンのカタチ (20)

Plus de Drecom Co., Ltd.

Plus de Drecom Co., Ltd. (20)

Dernier

Dernier (11)

LoveChainのスマートコントラクトを見てみよう & 非中央集権なトークンのカタチ