Go to the profile of erukiti
erukiti
JS(TS)メタプログラマ

blockchain.tokyo#5 に行ってきたまとめ

blockchain.tokyo #5に参加してきました。とても面白い内容だったので、自分なりにまとめてみました。間違いとかツッコミとか質問とかあれば、よろしくお願いします！

マイニングプールの収益配分と攻撃方法

マイニングプールの収益配分と攻撃手法

マイニングプールの仕組み、ブロックチェーンの仕組みを悪用してマイニングの収益性を不当に上げる手段の数々でした。どれも考えた人頭いいなーとしか思えなかった。

前提

  • Bitcoinだと特にそうだけど、マイニングプールを使わないとマイニングに参加する意味が無い
  • そのプールでコインを発見するまでをラウンドと呼ぶ
  • プールマイナー達の貢献度は、ディフィカルティを下げたnonceをプールに報告する数 (shareと呼ぶ)で示す

Pool Hopping

初期の素朴なプールマイニングでは、ラウンドの最初から最後までのshareの比率だけで報酬分配していたが、幾つものマイニングプールにラウンドの最初のほうだけshareを投げつける攻撃方法。

ラウンドは短いパターンがある。つまりたまたまハッシュパワーによる期待値よりも早くブロックを作れるケース。これに遭遇すると少ない労力で報酬を得られる。複数マイニングプールのラウンド初期だけつまみぐいしていれば、このラッキーなパターンに遭遇する確率が上がる。

ラウンドが長いパターンはラウンド内のshareを皆で高めている状態なので、その時点でのマイニングは、得られる報酬額が相対的に少ないので長いラウンドには参加しない。

最初から最後まで1つのプールのラウンドに参加し続けた場合の報酬よりも、つまみぐいした方が報酬が上がる可能性が高まるというもの

対策 Score

ラウンド後半のshareによる貢献度の比率を上げる対策方法。

ラウンドの後半に参加するモチベーションにはなる。

ただ、つまみぐいによりラッキーな事例に遭遇する可能性を上げるというのには対策にならないのと、プールマイナーの移動によるハッシュレート増減によってもホッピングする動機はまだ残る。Scoreでは定数を使った計算式なので、ディフィカルティ変動(ラウンドはblockとは言ってみれば非同期なのでディフィカルティは変動する)に対応できない

対策 PPLNS

ラウンド終了(つまりマイニング成功)の時点でshare提出してない、つまり参加してないヤツは貢献してないと見なすやり方。ある意味シンプルでわかりやすいわりにHopping耐性は十分ある。

対策 PPS

shareごとに報酬を支払う。Hopping耐性としては完璧だしマイナーにとっては安定収入万歳なんだけど、プール側としてはかなりリスキー。マイニング成功すればいいけど、失敗しまくる、ラウンドが長くなるとマイニング成功で得られるコインよりも支払ったコインの方が上回ってしまう。

強いプールなら、期待値的には割に合うかもしれない。あと手数料を上げて対処する。

Sabotage attack

shareは報告しても、マイニング成功時にblockを送信しない。PPSだと収益を得つつ攻撃ができる。それ以外の方式だとこの攻撃方法は単独だとただの嫌がらせにしかならない。

Lie in wait attack

まず複数プールでマイニングする。自分でどこかのブロックが見つかったら、ブロック送信をいったん保留して、他のプールの演算を留めて対象のプールに集中してshareを出しまくる。十分な数のshareを出したらブロックを送信する。

つまみぐいの一種と言えるか

Block withholding attack

自分がメインに使うプールを決める。そこでメインの演算をする。それ以外のプールに対してはSabotage attackをして妨害することで、自分のメインプールの収益性が相対的に上がる。

面白い考え方だけど、まぁ複数プールでBlockを自力で見つけられること前提なので、強いヤツにしかできない。

前提ふたたび

51%攻撃というのがある。ハッシュパワーが世界の半分より上ならブロックの生成を自分の都合のいいようにねじ曲げることができる

Selfish Mining

ここからは、プール運営側の攻撃方法。

プール内のブロック発見をいったん保留して、他のプールに無駄なマイニングさせて収益性を悪化(ラウンドが長引くようにする)させた上で、適度なタイミングでブロック発見を確定させる。

これは収益性の高いプールにマイナーが移動したがる習性を利用したもので、他のマイニングプールを邪魔すれば、自分のプールのハッシュパワーが上がるというもの。50%以下のハッシュパワーしか持ってないプールでも、このやり方でマイナーを誘導して無理矢理51%以上という状況を作り出す

具体的には、1つのBlockを採掘した状態で保留状態にして、そのまま次のブロックをマイニングする。他のプールがBlock報告をしたら即座に被せる。

もし次のブロックのマイニングにも成功してたら、主導権を奪いつつ相手のプールのハッシュパワーが無効化される。

次のブロックのマイニングに成功してなくても、その時点で既に相手よりも次のブロックの演算は進んでる状態ではあるので、少しは有利なはず。運良く移動するマイナーが自分のところに乗っかってくれれば、次のブロックの発見確率は上がる。

ハッシュパワーがある程度以上あれば確率論的に有利になる。移動してくるマイナーが0であっても33%ハッシュパワーがあれば得になる。

Sybil attack

他のプールの送信妨害をするフルノードを立てる。自分のプールの送信成功だけを伝搬する。

Selfish Miningの成功確率を上げる事ができる。

Selfish Mining / Sybil attack の実際

マイニングプールとしての手法なので、それやると、少なくともブロック発見したプールマイナーにとってはバレバレになる。本当に有効なら他のプールも採用してしまうので、意味が無い。

などなど、実際には問題があるから成立しない。Sybil attackも対策方法ある。

前提

difficulty調整が2014ブロックごとに決まるのと、difficultyの合計値でチェーンが選ばれるのと、タイムスタンプは偽造できる

Difficulty Raising Attack

difficulty調整用の2014ブロックを非公開状態で採掘しておいて、タイムスタンプを1秒刻みということに偽造。すると次のdifficultyは、「2014秒でいけちゃったから、難易度めっちゃ上げちゃる！！！」って事になってしまって、自分のその2014ブロックの次のブロックの採掘によって、メインチェーンを乗っ取れる。

現時点でのdifficultyで必要とされるハッシュパワーを上回るハッシュパワーを持ってないと成立しないから、まぁ成立させるのはかなり大変だし、こんな超絶に目立つことやったら、当然対処されちゃうよね…。

まとめ

基本的にどれもパワーあるの前提なので、実際には難しい。と言っても他にも色々考える悪い人はいるので、もしかしたら……。

「ほええええええ、そんなこと考えるヤツがおるのか、なるほど！！！！！」って感じの驚きに満ちたセッションでした。楽しかった。

Sidechain, NiPoPoW

Sidechain, NIPoPoW // Speaker Deck

にぽぽう。めっちゃ難しかった。すみません。まだかみ砕けてないので、後日調べて別途書いてみます。なんか1/5位理解したようなしてないような感じです。

詳解 BTC支払い

詳解 BTC Payment // Speaker Deck

Bitcoin決済を実際に行ってみたら色々泥臭い大変なことになったというセッションでした。

バンドルカード

VANDLE CARDというアプリの開発者の方の発表。

  • アプリで、VISAのオンライン決済が可能
  • 物理カードも発行すれば実店舗でのVISAの決済が可能
  • プリペイド方式で、コンビニ・クレカ・Bitcoinなどでチャージが可能

前提

  • Bitcoinのトランザクションは、scriptの自由度もあるし送信先も複数指定できたりするしで、表現の自由度が高い。
  • トランザクションは、どれかのブロックに取り込まれて、ブロックがチェーンで伸びるのがconfirmation(承認)
  • この時、ブロックが伸びきらずに破棄される可能性があるし、confirmationが完了するまでに時間がかかりまくる可能性もある

payment vs settlement

はてブでバズってたので読んだ人も多いと思うけど、Satoshiが注意深く設定した世界の境界線 — Shin’ichiro Matsuo — Mediumでは、サトシ・ナカモトはBitcoin P2P e-cash paperという最初にメーリングリストに投稿したペーパーでは、特別なノードなしで、P2Pネットワークを使ったe-cashのpaymentが出来るシステムを考えたよーとしか言ってなかったことが指摘されている。

  • payment(支払い)は、e-cashを誰にいくら送るかを指定するだけのもの
  • settelement(決済)は、実際に移動を完了させるもの

BTCによるチャージをどう実現するか？

  • 自社で既に別の形で持っている場合は自社のDB書き換えだけで終了する (例: BitlfyerのBic cameraでの決済とか)
  • 拡張公開鍵(xpub)対応APIサービスを利用する
  • bips/bip-0032 いわゆるHDウォレット対応APIのサービスを利用する
  • 自前でウォレット構築

決済でよくおこる問題 (送金間違い)

ユーザーが、1000円(0.0009BTCとする)チャージしたいとする。この時Vandleには1000円チャージするよーと言ったら、そのタイミングでのBTCを特定の口座に送金するようにユーザーに指示を出す。この時、アドレスを間違えたり、金額を間違える可能性がある。0.0009BTCのつもりが、間違って0.00009BTCを送金してしまうこともあるかもしれないからだ。

これに関してはまだ対処方法があって、bips/bip-0021で定義されたBitcoin URI schemeとそのQRコードで対処は可能。URIの中にアドレスと金額を指定できる。

決済でよくおこる問題 (入金確認)

アドレスに入金されたBTCは果たしてどのチャージ要求へのBTCなのか。正しい(と瞬時に判断できるような)金額、タイミングではっきりしていればいいが、そうじゃない場合は少し困る可能性がある。トランザクションの都合上、わかりづらい入金パターンになる可能性もある。confirmationが覆される可能性もゼロではない。

bips/bip-0070では入金指示と確認用のフローについて手順が定義されている。これに対応すれば問題は発生しづらくなる。

相場変動問題

BTCを日本円換算しなければならないサービス固有の事情とは言える。あるタイミングでpaymentしたけど、そのほんのすぐ後にBTCが暴騰、あるいは暴落する可能性もある。

まとめ

  • 返金しようとするとさらにクソダルイよね…
  • Bitcoinのブロックはconfirmationが取り消しになる可能性が決して0にはならない仕組みなのが面倒
  • Paymentを組み立てて実際にsettlementにするのはクソダルい。特に異常系。
  • スマフォとか前提にするならBIP21のURIスキームで捗る
  • BIP-70良さそう
  • Lightning Networkが本格的に稼働すれば捗るかも

ということで、リアルワールドの円に対応するサービスやるのは、かなり修羅の道だなーとは思った。元々決済システム自体とても面倒なものだけど、そこにさらにBitcoin的な事情が絡んでくるから余計大変そうだなーと思った。

仮想通貨で5000兆円欲しい！

仮想通貨で5000兆円欲しい！

面白いセッション枠だった。ネタ的に僕のLTと少し近い部分はあった…。

5000兆円トークン

  • 15000兆円トークン(1token)
  • 50005000兆円トークン(5000token)

「ごせんちょーえん」というトークンをEthのDappsで実現する

「ごせんごせんちょうえんとーくん」が不意打ちすぎて面白かった

ちょっとしたリアクション代わりに5000兆円を投げ合う

  • Ethで5000兆円を買うことができる
  • 5000兆円を投げ合える
  • 価値を持たせない
  • 5000兆円でEth買えるようにしない
  • 希少性で価値が生まれないようにする

iida-hayato/gosenchouen

問題

作ってみたけど、あまり使ってくれなかったとのこと。Ethereum自体の普及やらアドレスの周知やら…。

アプリ作ったり、SNSアカウントとの紐付けが課題。

まとめ

面白ネタをシンプルにやってきたなーというか。ある意味僕がやりたかった事に近い。

Dappsを支えるオラクル

オラクルと言ってもDBじゃなくて、神託機械的なもの。

用途としては、二日後晴れたらいくら支払うみたいなスマートコントラクトを実装したりするのかな？

オラクルというデータキャリア

ブロックチェーンに外の世界観のデータを取り入れるにはコンセンサスが問題になる。この時ブロックチェーンに外の世界のデータを取り入れるデータキャリアがオラクル。

  • 認証機関のように「そいつを信頼する」前提の集権型オラクル
  • 合意アルゴリズムでなんとかする分散型オラクル

ただ、後者は現実的な設計がムズカシイらしくほとんど前者らしい。

基本的にはオラクルを実現するサービスを利用する、みたいな形になる。

Reality Keys

Yes/Noで答えられる質問にのみ対応したサービス。Yes/Noをそれぞれ示す二つの公開鍵ペアを作り、両方の公開鍵がまず公開される。
真偽が確定した段階で、真ならYesの秘密鍵、偽ならNoの秘密鍵が公開される。

Oraclize

Dappsに外部データfetchを組み込むもの。これの運営会社がちゃんと正しい内容をfetchしてブロックチェーンに与えてくれることを信頼する仕組みではある。

ほか

ChainLink, Gnosis とかいうのがあるらしい。
現時点では使いやすさでOraclizeがよく使われるらしいが、特定の組織を信頼しちゃわない分散型とかが今後発展すると面白そうではある。

DAGで表現するお気持ちネットワーク

DAGで表現するお気持ちネットワーク / Okimochi // Speaker Deck

というのをLTしてきました。ちなみにこのプレゼンの元になったOkimochiを2018/02/13に考えた時のやつ — HackMDも公開しています。

以下、Tx = トランザクションです。

前提: クリエイターはフィードバックが死ぬほど欲しい

小説家の人から「感想死ぬほど欲しい。感想もらえたらめっちゃうれしい」とよく聞く。技術同人誌の執筆でも全く同じで、感想をくれる、評価してくれる人はとても尊い。

ただ、微妙な評価とか、評価してるようにみせてディスってくるコメントとかはあまり見たくない。

前提: そもそもインターネッツは炎上に弱すぎる

  • カジュアルに生じる炎上
  • 暴言を投げるコストが低すぎる
  • 1対多数という数の暴力が発生しやすい

攻撃側が有利すぎるのがインターネッツ

ポジティブな評価を集める場を作りたい

みんなが個別にネガティブと戦って各個撃破されるくらいなら、ポジティブな感想を元に次の面白い何か作っていく方が絶対楽しいはず。

クリエイティブ、発表、評価、そういった事をしてコミュニティを盛り上げる人を貢献者とする。

そこでお気持ちをDAGで表現

DAGは有向非巡回グラフで、向きが決まってて循環が発生しないグラフ構造。

ポジティブな感想「お気持ち」はn段階の評価(例えば5段階)とコメントとタグと対象を添えてTx(トランザクション)にする。この時、電子コインと違ってお気持ちは無限に発行しても問題が生じない(重複したお気持ちは後で消せるし、お気持ちの乱発はスコアリングでペナルティを与えられる)ので、一本の鎖である必要がない。

ここでは1以上の親TxへのHashを含めたDAG構造をTxDAGと呼ぶ。

TxDAGからスコアを算出する

評価の高い人からの評価は高い価値があるべきなはずなので、PageRankめいた計算をすればTxDAGによって評価をスコアという形で算出できるはず。

ただ、この時スコアは全体共通のものではなく、タグごとに紐付く。JavaScriptのスコアが高い人が他のスコアが高いとは限らない。

他のTx

ルール上ネガティブなコメント、違法行為(著作権違反なものを貼り付ける)などを禁止しているが、それを人の手でModerationする。(もちろん自動検知ができるようになったら自動検知も取り入れられるだろう)。ModerationのModerationもあり得る。

クリエイター・コンテンツの世界なので、新しいコンテンツを発表したという新作情報のTxや、どこかにあるコンテンツを自分のものであると(電子署名などで)証明するサインTx、あるいは既に発行したトランザクションを取り消すRevokeなどのTxが想定できる。

トークン

ここまでのアイデアでお気持ちを投げ合う事で誰かを評価できるようになった。もちろん評価だけでも価値はある。例えばTxDAGを読めるクライアントなら、自分の欲しい情報だけ取り出してくれるフィードとか作成できる。ある意味低コストなキュレーションになる。

ただ、ここから少し拡張を考えたい。それはスコアに応じてトークンを発行するというもの。スコアからトークンを発行する計算式も決まってるので、TxDAGを追いかければ当然トークンもきっちり問題なく生成される。ただ、TxDAGはコンセンサスを取るのに問題が生じない仕組みだが、トークンをやりとりする時にはコンセンサスについてちゃんと設計する必要がある。

たとえば、PoIでいうようなImportantなノードで合意形成をする (Important Peer)という方式とかはありかなと思う。

暗号通貨を寄贈する

ぶっちゃけ「お気持ちを金で買う」というパワめいた言葉を言いたかっただけかもしれません！

誰か奇特な人が何らかの暗号通貨をお気持ちネットワークに寄贈するという形を取る。この時例えばJavaScriptに1BTCを寄贈する。寄贈した人はパトロンとして名誉スコアを得ることができる。それでいて、JavaScriptスコアを持ってる人(JavaScriptに何らか貢献している人たち)は、比率に応じて、寄贈されたBTCを分配してもらえる権利を持つ。トークンは実際にはその分配の権利であり、トークンをバーンした時に実際に暗号通貨を受け取る。

応用例

たぶん分散ハッシュテーブルとか分散DB的なものは必要になるだろうからそういうの実装した上で、ついでにデータblobを保持するようにすれば、配信プラットフォームや分散ストレージになるよなーとか。違法行為に対応するためIPの記録を初めとした対策はしないといけないけど、熱心なファンだけが読めるDRMとかそういうのも設計可能だろうと思う。

質疑応答

Q. Monacoinでいいんじゃね？

まぁMonacoinとかBitZenyをクリエイターに送るみたいな文化はあるけど、僕自身がPoWって無駄が多いなーというのが一つの理由です。

質疑応答の時には言わなかった(忘れてた)理由としては、Monacoinとかめんどすぎるというのもあります。Monacoinを送るまでのハードル、受け取ってそれを何かに使う・換金するまでのハードル、両方とも高すぎると思っています。感想とかカジュアルに投げつつ、でも暴言にならないように注意する位のさじ加減を実現できる仕組みにしたいのです。

個人的にPoWのWorkが意味のある計算ならいいけど、そうじゃないならちょっとなー派です。Workの例として、スコアを元にしたタグのクラスタリングとか、よりよいサジェストとかを計算するなんてのもありかなーとは思いますが、低コストで確実に検証する手段があれば、そういう貢献の形も面白いとは思っています。

そこらへんがあったので、Blockchainで使われてるようなコンセンサスの必要のない仕組みにしたくて、お気持ちという減らず、重複に簡単に対処できて、乱発とかにもスコアリング計算式で対処できる設計にしたところ、DAGで簡単に実現できそうだなーというところです。

不正に対しては仕組みとして対処できるようにプロトコルを工夫したいとは思っています。

あと、ブロックチェーンを自前で設計・実装してみたかったのもあります。(僕が考えた最強のブロックチェーン)

Q. Okimochiって、CAMP Fireさんが既にやってるやつあるよね？

忘れてました！！！！！！以前たしかに記事を読んだ覚えがあるので、無意識のうちにパクってたかもしれません！！！！！発想としては、似た部分ありますし

ということで、後ほど別の名前を考えます。「お気持ち」並にニュートラルでローマ字での字面の良い日本語を探したいところではあります。

まとめ

自分の発表ということで長々記事書いちゃいました。

そして今日(2/18)は僕の誕生日なので、暗号通貨とか振り込んでくれるとうれしいです！！！！！！

BTC: 1BRCrrHj46RgtszSp83pUdAMF5TpuZgghm
Monacoin: MUgG6ZC1DqiRSYgKW7vr8FtVL7eYHagdoL
Bitzeny: Zm82eeF7XrqY2pj9AdBBTKryWT6GUZNHgy