Tech

TCP/IPを置き換える? BitPay の Foxtrot について

  • このエントリーをはてなブックマークに追加

BitPayのCEO Stephen Pairが、将来TCP/IPを置き換えるかも知れないと言ったFoxtroitについての情報まとめ

僕の初めのリアクション「んなわきゃねー!」ですが、あまりにクレイジー過ぎるので、調べ中です。

現状、英語でも非常に情報が限られているので、詳細はわかりません。
が、初期状態のGitHubでのコードはあります。

現状の情報まとめ

  • 現在、初期段階
  • TCP/IPを置き換える可能性がある、というのは将来の話
  • 初期状態のコードがGitHubにある
  • ルータにIPと同時にFoxtrotをサポートできる、とCEOが発言
  • 帯域にBitcoinで課金できるようにする予定
  • アドレスは、IPアドレスでなくBitcoin的アドレス
  • EC暗号ベースの非中央的ルーティング・ネットワーク
  • ピアのリンクを暗号化
  • エンド間のコネクションも暗号化
  • Layer 2でも動く様に設計
  • 元々、CopayやInsightなノードを非同期にsyncしたい等のバックエンドの問題がモチベーションらしい

事前知識

  • ネットワーク(レイヤー、TCP/IP)、ルーティングの知識
  • Bitpay: ビットコインのペイメントシステムを提供する会社
  • Bitcore: bitcoin関連のオープン・ソースライブラリ by Bitpay
  • Copay: オープン・ソースのウォレット (by Bitpay)
  • Insight: オープン・ソースなブロックチェーン閲覧サイト bitcoindのフロントエンドとして動く(Node.js by Bitpay)

ソースコード@GitHub

https://github.com/bitpay/foxtrot

コードを読んだ感じ

僕がコードを軽く読んだ感じ

  • npm install foxtrot でインストール
  • 現状のバージョン 0.0.1 (2014-11-04時点)
  • Node.js製
    • なんで?と一瞬思うが、コンセプト状態からか、bitcoreを使っているからか。
  • bitcoreをincludeしている
    • bitcoreは、Bitpayのオープン・ソースなビットコインライブラリ
  • サンプルチャットのコードでは、ビットコイン的なアドレスにconnectしている
  • 現状TCPを使っている

プレゼン・ビデオ

Overview

  • github.com/bitpay/foxtrot
  • Decentralized routing network based in EC crypto
  • Endpoints are location independent public keys
  • Routing decisions based on observing peer behavior
  • Peer links encrypted
  • Connections encrypted end to end
  • Designed to run on layer 2
  • Plans to incorporate bitcoin for bandwidth billing
  • Nodejs implementation is protocol compatible with the “net” module
  • it barely works

以下の画像より引用
Foxtrotのスライド画像

Motivations

  • Needed to make Copay work asynchronously
  • WebRTC has limited browser support and lacks routing
  • Made copay use Insight for async operation
  • Problem: Copay users needed to be on the same Insight node
  • Need to enable communications between Insight nodes
  • Evaluated several other projects (tor, i2p, cjdns)

Creating a Server

  • 秘密鍵を入れる
var foxtrot = require('foxtrot');
var server = foxtrot.createServer({key: <key>});
server.on('connect', function(client)) {
    client.write('hello');
    client.on('data', function(data)) {
        console.log('data received:', data);
    });
});
var foxtrot = require('foxtrot');
var socket = foxtrot.connect({address: <addr>}, function() {
    console.log('connected');
    socket.on('data', function(data) {
        sonsole.log('received:', data);
    });
});
socket.on('error', ...);
socket.on('close', ...);

Peering

  • Form a trust network of connected peers
  • Bootstrap with prolific peering
  • Evolve to deliberate peering with trusted nodes
  • Peers use EC encryption
    • key exchange is nearly vebatim TLS handshake
    • (minus PKI and legacy algo support)
  • Similar to bitcoin peering
  • DNS Seeding, ZeroConf, Gossip (not yet implemented)

Connections

  • Aconnection request is: pubkey, nonce, sig
  • Connection ID is 20 byte hash of connection request
  • Requests propagete like bitcoin INV messages
  • Target signs a CONNECTACK and returns it to peer(s) from which it was received
  • Intermediate nodes form connections that deliver traffic between peer nodes
  • Nodes can innovate and improve routing performance independently of the protocol
  • A foxtrot connection canbe used for peer links

Routing Economics

  • Nodes charge money for delivering data over a connection
  • Change a little more than the next node to earn a profit
  • Routing decisions can be based on performance and cost
    • Maintain list of backup peers and fall back on failure
    • Deliver data over multiple links for added reliability
    • Maintain latency stats for each peer
    • Dynamically adjust pricing based on congestion (and increase reliability when there is spare bandwidth)
    • Lots of possibilities!

Connection Economics

  • Not feasible to flood connection requests to every device on Earth
  • But routers need to establish connections to earn money
  • Plan to use rate limiting as a short term fix until payment channels are incorporated
  • Small size of network and rate limiting will allow exhaustive search to work initially
  • Need solutions that allow you to narrow search space
    • Localized pools of nodes where exhaustive search is used
    • Stealth Addresses!

Stealth Addresses

  • Have a private key as well as a “scan key”
  • Scan key can be advertised with peers
  • Advertisements inform peers which links are likely to succesfully yield a connection
  • Advertisements can carry additional information relating to metrics (hops to destination, etc)
  • Makes connection establishment more cost effective at the expense of privacy

Applications

  • Multi-sig payment proposals
  • Payment channel negotiation
  • Escrow payment coordination
  • CoinShuffle
  • Alternative to TCP/IP
    • Start small and at the edges (wireless mesh nets)
    • Add router support directl on ethernet
    • ISP adoption once economics become clear
    • Dramatically improve ISP peering situation
    • Lessons from IPv6

To Do List

  • Use stealth addresses
  • Add TCP like delivery guarantees
  • Move to UDP for peer links
  • incorporate payment channels
  • Multicast
  • Service Discovery
  • Peer reconnect
  • Gossip protocol for peer discovery
  • Robustification

BitPay attempts MaidSafe – maidsafe.org | forum

Demo

  • chatのデモ
  • /foxtrot/example/chat
  • [サーバ] chatd 公開鍵を指定してコネクションを待つ
  • [クライアント] ./chat -n stephen -s <公開鍵>

情報ソース

  • このエントリーをはてなブックマークに追加