9/30/2017

エドワード・スノーデン: Zcashが最も面白いビットコインの代替手段

Coindeskより

注目の告発者エドワード・スノーデンは、プライバシー指向の暗号通貨Zcashをビットコインの最も興味深い代替手段と呼び、支持する事を表明している。

科学技術者Mason Bordaはツイートに応じる形で次のように書いている。「Zcashはプロでアカデミックな暗号学者によって設計、構築された(私が知る)唯一のaltcoinである。」スノーデンは「全く同感」と答えた。

彼は続けた

「Zcashのプライバシ技術は、最も面白いビットコインの代替手段になる。ビットコインは素晴らしいが、民間でないなら、安全では無い。」

スノーデンは有名なプライバシー擁護者であり、2013年にNSAの機密文書を大量に漏洩した事で最もよく知られている。競合する民間の通貨であるMonero(モネロ)に関する彼の考えを尋ねると、スノーデンはそれは素人の暗号だと言い、技術の内部にトレーサビリティ(追跡の可能性)の問題があると指摘した。

スノーデンは、このような設計ミスは仲間の告発者を危険に晒す可能性があると言い、「間違いが起こると、私のような人に大きな影響を与える」と述べている。

その意見は、競合する通貨間の既存の競争を生んでいる。その結果、Twitterの反応の洪水となり、Moneroの開発者Richard Spagniがプロジェクトの技術を強く擁護したのに対し、litecoinの作成者Charlie Leeは「Zcashでは無く Moneroを持っている。」と述べた。

ZcashとMoneroはどちらもユーザのプライバシを守るために作られているが、異なるツールを使用してほぼ間違いなく同じ結果を達成しているように見える。

Zcashはzk-SNARKsと呼ばれる暗号操作に基づいているが、Moneroはリング署名とステルスアドレスで情報を難読化して動作している。

発表: CoinDeskはDigital Currency Groupの子会社であり、Zcashの開発をサポートする営利企業であるZcash Companyの株式を所有している。

Hacker News

QVCのホストとゲストが番組中、月は惑星か星かで大激論

BoingBoingより。もちろん、月は惑星でも星でも無く、地球の衛星だ。

「いいえ、私はちっとも好きではない。私はその意味が分からない。」

Bo Gardiner:

アイザック・ミズラヒの言い訳が何なのか分からないけど、彼が自分の愚かさでこの愚かな女性のストレートな調子を飾らせるのを愛さなくちゃ。熱心なキリスト教徒であるショーン・キリンジャーについて、おそらく彼女は日曜学校の創世記から科学を理解したんでしょうね。0:39のモデルの反応をチェックして! 私は彼女が天体物理学の博士課程を卒業していると想像するのが面白くて好き。
Be02f0f0 9db6 11e4 9d65 93be206defae rs 560x360 150115110428 1024 issac mizrahi

Rachel MaddowYahoo! News

9/29/2017

Goでブロックチェーンを作る (第3回: 永続性とCLI)

Ivan Kuznetsovさんのブログより。

概要

これまでのところ、プルーフ・オブ・ワークのシステムを持つブロックチェーンを構築し、マイニングが可能になった。我々の実装は、完全に機能的にブロックチェーンに近付いているが、まだいくつかの重要な機能が欠けている。今日は、データベースにブロックチェーンを格納し始めることとし、その後、ブロックチェーンを操作するための簡単なコマンドライン・インタフェース(CLI)を作成する。本質的に、ブロックチェーンは分散データベースである。我々は、今のところ分散部分をあえて省き、データベース部分に焦点を当てている。

データベースの選択

現在、我々の実装にはデータベースはない。代わりに、プログラムを実行してメモリに格納するたびにブロックを作成する。ブロックチェーンを再利用する事はできず、他の人と共有する事が出来ないため、ディスクに格納する必要がある。

どのようなデータベースが必要だろうか? 実際には、どれか一つだ。オリジナルのビットコインの論文では、特定のデータベースの使用について何も触れていないため、使用するDBは開発者次第である。ビットコイン・コアは、現在ビットコインのリファレンス実装であるサトシ・ナカモトによって発表されたもので、LevelDBを使用している(2012年にクライアントのみを紹介された)。そして我々は使用するのは...

BoltDB

なぜなら、

  1. シンプルで最小主義である。
  2. Goで実装されている。
  3. サーバを動作させる必要がない。
  4. 我々が望むデータ構造を作る事ができる。

Github上のBoltDBのREADMEより

Boltは、Howard ChuのLMDBプロジェクトに触発されて作られたGo言語のキー/バリュー・ストアである。このプロジェクトの目標は、PostgresやMySQLなどのデータベースサーバを必要としないプロジェクトのためのシンプル、高速、信頼性のあるデータベースを提供する事である。

Boltはこのような機能性の低レベル部分として使用される事を意図され、シンプルさが重要である。APIは小さく、値の取得と値の設定にのみ焦点を当てる。それだけである。

我々のニーズに完璧だと思われる! 検討してみよう。

BoltDBはキー/バリュー・ストレージで、つまりSQL RDBMS(MySQL、PostgreSQLなど)のようなテーブルは無く、行も列も無い。代わりに、データはキーと値のペア(Go言語のマップのように)として保存される。キーと値のペアは、同様のペアをグループ化するためのバケットに格納されている(これはRDBMSのテーブルに似ている)。従って、値を取得するには、バケットとキーを知る必要がある。

BoltDBの重要な点の一つは、データ型がない事である。キーと値はバイト配列である。Goの構造体(特にブロック)を格納するので、それらをシリアル化する必要がある。つまり、Go構造体をバイト配列に変換し、バイト配列からそれを戻すメカニズムを実装する必要がある。これには、encoding/gobを使用するが、JSON、XML、プロトコル・バッファなども使用できる。encoding/gobの方がシンプルで、標準のGoライブラリの一部であるため使用する。

データベース構造体

永続性ロジックの実装を開始する前に、まずDBにデータを格納する方法を決定する必要がある。そして、これについて、ビットコイン・コアが行う方法を参照してみよう。

簡単に言えば、ビットコイン・コアはデータ格納に2つのバケットを使用する。

  1. blocksは、チェーン内の全てのブロックを記述するメタデータを格納する。
  2. chainstateは、全ての未使用のトランザクション出力やメタデータであるチェーンの状態を格納する。

また、ブロックはディスク上に別々のファイルとして格納される。これは、パフォーマンス目的で実行される。単一のブロックを読み取る時、それらの全てまたは一部のメモリにロードする必要は無い。我々はこれを実装しない。

blocksで、key -> valueのペアは、

  1. 'b' + 32バイトのブロックハッシュ -> ブロック・インデックス・レコード
  2. 'f' + 4バイトのファイル番号 -> ファイル情報レコード
  3. 'l' -> 4バイトのファイル番号: 最後のブロックのファイル番号に使われる
  4. 'R' -> 1バイト真偽値: 再インデックスのプロセス中かどうか
  5. 'F' + 1バイトのフラグ名長さ + フラグ名文字列 -> 1バイト真偽値: いくつかのフラグはオンあるいはオフである
  6. 't' + 32バイトのトランザクションハッシュ -> トランザクション・インデックス・レコード

chainstateで、key -> valueのペアは、

  1. 'c' + 32バイトのトランザクションハッシュ -> そのトランザクションの未使用トランザクション出力レコード
  2. 'B' -> 32バイトのブロックハッシュ: データベースが未使用トランザクション出力を表すまでのブロックハッシュ

(詳しい説明はここにある。)

トランザクションはまだ無いので、blocksバケットのみを持つ。また、上記のように、ブロックを別々のファイルに格納する事なく、DB全体を一つのファイルとして格納する。従って、ファイル番号には何も必要はない。そのため、これらは使用するkey -> valueのペアである。

  1. 32バイトのブロックハッシュ -> ブロック構造体(シリアル化)
  2. 'l' -> チェーンの最後のブロックのハッシュ

永続的メカニズムの実装を開始するのに知っておくべき事はこれだけである。

シリアル化

前述のように、BoltDBの値は、[]byte型のみとなり、DB内にBlock構造体を格納しなければならない。構造体をシリアル化するにはencoding/gobを使用する。

BlockSerializeメソッドを実装しようみよう(簡略のため、エラー処理は省いている)。

func (b *Block) Serialize() []byte {
    var result bytes.Buffer
    encoder := gob.NewEncoder(&result)

    err := encoder.Encode(b)

    return result.Bytes()
}

部品は複雑では無い。最初、シリアル化されたデータを格納するバッファを宣言し、その次にgobエンコーダを初期化して、ブロックをエンコードする。結果はバイト配列として返却される。

次に、バイト配列を入力として受け取り、Blockを返す非シリアル化関数が必要である。これはメソッドではなく、独立した関数である。

func DeserializeBlock(d []byte) *Block {
    var block Block

    decoder := gob.NewDecoder(bytes.NewReader(d))
    err := decoder.Decode(&block)

    return &block
}

シリアル化についてはこれだけである!

永続性

NewBlockchain関数から始めよう。現在、Blockchainの新しいインスタンスを作成し、そこに起源ブロックを追加する。我々がやりたい事は次の事である。

  1. DBファイルを開く。
  2. そこにブロックチェーンが格納されているかチェックする。
  3. ブロックチェーンが存在すれば、
    1. 新しいBlockchainインスタンスを作成する。
    2. Blockchainインスタンスの先端をDBに格納されている最後のブロックハッシュに設定する。
  4. ブロックチェーンが存在しなければ、
    1. 起源ブロックを作成する。
    2. DB内に格納する。
    3. 最後のブロックハッシュとして起源ブロックのハッシュを保存する。
    4. 起源ブロックを指す先端を持つ新しいBlockchainインスタンスを作成する。

コードでは、このようになる。

func NewBlockchain() *Blockchain {
    var tip []byte
    db, err := bolt.Open(dbFile, 0600, nil)

    err = db.Update(func(tx *bolt.Tx) error {
        b := tx.Bucket([]byte(blocksBucket))

        if b == nil {
            genesis := NewGenesisBlock()
            b, err := tx.CreateBucket([]byte(blocksBucket))
            err = b.Put(genesis.Hash, genesis.Serialize())
            err = b.Put([]byte("l"), genesis.Hash)
            tip = genesis.Hash
        } else {
            tip = b.Get([]byte("l"))
        }

        return nil
    })

    bc := Blockchain{tip, db}

    return &bc
}

これを一つ一つ点検しよう。

db, err := bolt.Open(dbFile, 0600, nil)

これはBoltDBファイルを開くための標準的な方法である。そのようなファイルが存在しない場合、エラーを返さない事に注意する。

err = db.Update(func(tx *bolt.Tx) error {
...
})

BoltDBでは、データベース内の操作はトランザクション内で実行される。トランザクションには、読み取り専用と読み取りと書き込みの2種類がある。ここでは、DB内に起源ブロックを置く事を期待しているため、読み書きトランザクション(db.Update(...))を開く。

b := tx.Bucket([]byte(blocksBucket))

if b == nil {
    genesis := NewGenesisBlock()
    b, err := tx.CreateBucket([]byte(blocksBucket))
    err = b.Put(genesis.Hash, genesis.Serialize())
    err = b.Put([]byte("l"), genesis.Hash)
    tip = genesis.Hash
} else {
    tip = b.Get([]byte("l"))
}

これは関数の中心部である。ここでは、ブロックを格納しているバケットを取得する。存在する場合、そこからlキーを読み取る。存在しない場合、起源ブロックを生成し、バケットを作成し、ブロックをその中に保存し、チェーンの最後のブロックハッシュを格納するlキーを更新する。

また、Blockchainを作成する新しい方法に注意して欲しい。

bc := Blockchain{tip, db}

我々は、もはやそれに全てのブロックを保存するのではなく、チェーンの先端だけが保存される。また、プログラムを実行している限り、一度それをオープンしたら開いたままにしておきたいので、DBコネクションを保存する。従って、Blockchain構造体は次のようになる。

type Blockchain struct {
    tip []byte
    db  *bolt.DB
}

次に更新したいのは、AddBlockメソッドである。ブロックをチェーンに追加することは配列に要素を追加するほど簡単では無い。これからDB内にブロックを格納する。

func (bc *Blockchain) AddBlock(data string) {
    var lastHash []byte

    err := bc.db.View(func(tx *bolt.Tx) error {
        b := tx.Bucket([]byte(blocksBucket))
        lastHash = b.Get([]byte("l"))

        return nil
    })

    newBlock := NewBlock(data, lastHash)

    err = bc.db.Update(func(tx *bolt.Tx) error {
        b := tx.Bucket([]byte(blocksBucket))
        err := b.Put(newBlock.Hash, newBlock.Serialize())
        err = b.Put([]byte("l"), newBlock.Hash)
        bc.tip = newBlock.Hash

        return nil
    })
}

これを一つ一つ点検しよう。

err := bc.db.View(func(tx *bolt.Tx) error {
    b := tx.Bucket([]byte(blocksBucket))
    lastHash = b.Get([]byte("l"))

    return nil
})

これはBoltDBトランザクションの他の(読み取り専用)型である。ここでは、DBから最後のブロックハッシュを取得して、新しいブロックハッシュをマイニングする。

newBlock := NewBlock(data, lastHash)
b := tx.Bucket([]byte(blocksBucket))
err := b.Put(newBlock.Hash, newBlock.Serialize())
err = b.Put([]byte("l"), newBlock.Hash)
bc.tip = newBlock.Hash

新しいブロックをマイニングした後、シリアル化された表現をDBに保存し、lキーを更新する。これで新しいブロックのハッシュが保存される。

完了! それほど難しくはなかったかな?

ブロックチェーンを検査する

全ての新しいブロックはデータベースに保存されるため、ブロックチェーンを再度開いて新しいブロックを追加する事ができる。しかし、これを実装した後、我々は素晴らしい機能を失った。我々はこれ以上配列にブロックを格納しないため、もはやブロックチェーンのブロックを出力できない。この欠陥を修正しよう!

BoltDBは、バケット内の全てのキーを反復処理できるが、キーはバイト単位でソートされた順序で格納され、ブロックチェーン内でブロックを順番に出力する。また、全てのブロックをメモリにロードしたくないので(ブロックチェーンDBは巨大かもしれない!...あるいはそうなると仮定してみよう)、我々はそれらを一つずつ読み取る。この目的のために、ブロックチェーンのイテレータが必要である。

type BlockchainIterator struct {
    currentHash []byte
    db          *bolt.DB
}

イテレータは、ブロックチェーン内のブロックを反復処理するたびに作成され、現在のイテレーションのブロックハッシュとDBへのコネクションを格納する。後者のため、イテレータはブロックチェーンに論理的にアタッチされており(DBコネクションを格納するBlockchainのインスタンスである)、従って、Blockchainメソッドに作成される。

func (bc *Blockchain) Iterator() *BlockchainIterator {
    bci := &BlockchainIterator{bc.tip, bc.db}

    return bci
}

イテレータはブロックチェーンの先端を最初に指しているので、ブロックは新しいものから古いものまで最上部から最下部に取得される事に注意してほしい。実際に、先を選択する事は、ブロックチェーンの投票を意味する。ブロックチェーンは複数のブランチを持つ事ができ、メインブロックと見なされるブロックチェーンの中で一番長い。先を取得したら(ブロックチェーン内の任意のブロックにできる)、ブロックチェーン全体を再構築し、その長さとそれを構築するのに必要な仕事を見つける事ができる。この事実は、先がブロックチェーンの一種の識別子である事も意味する。

BlockchainIteratorは、ブロックチェーンから次のブロックを返却するというただ一つの事を行う。

func (i *BlockchainIterator) Next() *Block {
    var block *Block

    err := i.db.View(func(tx *bolt.Tx) error {
        b := tx.Bucket([]byte(blocksBucket))
        encodedBlock := b.Get(i.currentHash)
        block = DeserializeBlock(encodedBlock)

        return nil
    })

    i.currentHash = block.PrevBlockHash

    return block
}

DB部分についてはこれだけである!

CLI

これまでの実装は、プログラムとのやりとりを行うためのインタフェースは提供されていなかった。メイン関数のNewBlockchainbc.AddBlockを実行していただけである。これを改善する時だ! 我々はこれらのコマンドを持ちたい。

blockchain_go addblock "Pay 0.031337 for a coffee"
blockchain_go printchain

操作に関連する全てのコマンドラインは、CLI構造体によって処理される。

type CLI struct {
    bc *Blockchain
}

その入り口は、Run関数である。

func (cli *CLI) Run() {
    cli.validateArgs()

    addBlockCmd := flag.NewFlagSet("addblock", flag.ExitOnError)
    printChainCmd := flag.NewFlagSet("printchain", flag.ExitOnError)

    addBlockData := addBlockCmd.String("data", "", "Block data")

    switch os.Args[1] {
    case "addblock":
        err := addBlockCmd.Parse(os.Args[2:])
    case "printchain":
        err := printChainCmd.Parse(os.Args[2:])
    default:
        cli.printUsage()
        os.Exit(1)
    }

    if addBlockCmd.Parsed() {
        if *addBlockData == "" {
            addBlockCmd.Usage()
            os.Exit(1)
        }
        cli.addBlock(*addBlockData)
    }

    if printChainCmd.Parsed() {
        cli.printChain()
    }
}

コマンドライン引数を解析するため、標準フラグパッケージを使用している。

addBlockCmd := flag.NewFlagSet("addblock", flag.ExitOnError)
printChainCmd := flag.NewFlagSet("printchain", flag.ExitOnError)
addBlockData := addBlockCmd.String("data", "", "Block data")

まず、2つのサブコマンドaddblockprintchainを作成し、次に前者のために-dataフラグを追加する。printchainはフラグを持たない。

switch os.Args[1] {
case "addblock":
    err := addBlockCmd.Parse(os.Args[2:])
case "printchain":
    err := printChainCmd.Parse(os.Args[2:])
default:
    cli.printUsage()
    os.Exit(1)
}

次に、ユーザによって提供されるコマンドをチェックし、関連するflagサブコマンドを解析する。

if addBlockCmd.Parsed() {
    if *addBlockData == "" {
        addBlockCmd.Usage()
        os.Exit(1)
    }
    cli.addBlock(*addBlockData)
}

if printChainCmd.Parsed() {
    cli.printChain()
}

次に、どのサブコマンドが解析され、関連する関数を実行するかをチェックする。

func (cli *CLI) addBlock(data string) {
    cli.bc.AddBlock(data)
    fmt.Println("Success!")
}

func (cli *CLI) printChain() {
    bci := cli.bc.Iterator()

    for {
        block := bci.Next()

        fmt.Printf("Prev. hash: %x\n", block.PrevBlockHash)
        fmt.Printf("Data: %s\n", block.Data)
        fmt.Printf("Hash: %x\n", block.Hash)
        pow := NewProofOfWork(block)
        fmt.Printf("PoW: %s\n", strconv.FormatBool(pow.Validate()))
        fmt.Println()

        if len(block.PrevBlockHash) == 0 {
            break
        }
    }
}

この要素は以前のものとほとんど同じである。唯一の違いは、BlockchainIteratorを使用してブロックチェーン内のブロックを反復処理する事である。

また、それに応じてmain関数を変更する事を忘れないようにしよう!

func main() {
    bc := NewBlockchain()
    defer bc.db.Close()

    cli := CLI{bc}
    cli.Run()
}

提供されるコマンドライン引数に関係なく、新しいBlockchainが作成される事に注意してほしい。

以上! 全てが期待通りに動作する事を確認しよう。

$ blockchain_go printchain
No existing blockchain found. Creating a new one...
Mining the block containing "Genesis Block"
000000edc4a82659cebf087adee1ea353bd57fcd59927662cd5ff1c4f618109b

Prev. hash:
Data: Genesis Block
Hash: 000000edc4a82659cebf087adee1ea353bd57fcd59927662cd5ff1c4f618109b
PoW: true

$ blockchain_go addblock -data "Send 1 BTC to Ivan"
Mining the block containing "Send 1 BTC to Ivan"
000000d7b0c76e1001cdc1fc866b95a481d23f3027d86901eaeb77ae6d002b13

Success!

$ blockchain_go addblock -data "Pay 0.31337 BTC for a coffee"
Mining the block containing "Pay 0.31337 BTC for a coffee"
000000aa0748da7367dec6b9de5027f4fae0963df89ff39d8f20fd7299307148

Success!

$ blockchain_go printchain
Prev. hash: 000000d7b0c76e1001cdc1fc866b95a481d23f3027d86901eaeb77ae6d002b13
Data: Pay 0.31337 BTC for a coffee
Hash: 000000aa0748da7367dec6b9de5027f4fae0963df89ff39d8f20fd7299307148
PoW: true

Prev. hash: 000000edc4a82659cebf087adee1ea353bd57fcd59927662cd5ff1c4f618109b
Data: Send 1 BTC to Ivan
Hash: 000000d7b0c76e1001cdc1fc866b95a481d23f3027d86901eaeb77ae6d002b13
PoW: true

Prev. hash:
Data: Genesis Block
Hash: 000000edc4a82659cebf087adee1ea353bd57fcd59927662cd5ff1c4f618109b
PoW: true

(ビールを開ける音)

結論

次回は、アドレス、ウォレット、(おそらく)トランザクションを実装する予定である。だから、チャンネルはそのままに。


リンク:

  1. 完全なソースコード
  2. ビットコイン・コア・データ・ストレージ
  3. boltdb
  4. encoding/gob
  5. flag

9/28/2017

BGPsecがRFC化

いよいよ、BGPsecがRFC化された。果たして...

RFC# Title タイトル
RFC 8205 BGPsec Protocol Specification BGPsecプロトコル仕様
RFC 8206 BGPsec Considerations for Autonomous System (AS) Migration 自律システムの移行のためのBGPsecの検討
RFC 8207 BGPsec Operational Considerations BGPsecの運用の検討
RFC 8208 BGPsec Algorithms, Key Formats, and Signature Formats BGPsecのアルゴリズム、鍵形式、署名形式
RFC 8209 A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests BGPsecルータ証明書、証明書失効リスト、証明書要求のプロファイル
RFC 8210 The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1 ルータ・プロトコルへのリソース公開鍵基盤バージョン1
RFC 8211 Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) 認証局あるいはリソース公開鍵基盤のリポジトリ監督者による有害行動

RFC 8205より。

1. 序論

このドキュメントは、Border Gateway Protocol (BGP) [RFC4271]の経路広告のためのパス・セキュリティを提供するためのメカニズムBGPsecを説明する。つまり、有効なBGPsec UPDATEメッセージを受信するBGPスピーカは、広告された経路が次の属性を持つ事を暗号的に保証する。UPDATEメッセージ内のASリストのパス上の全ての自律システム(AS)は、パス内の後続ASへの経路の広告を明確に認可される。

このドキュメントは、オプションの(非通過型)BGPパス属性であるBGPsec PATHを規定する。BGPsec準拠のBGPスピーカ(いか、BGPsecスピーカと呼ぶ)が、この属性を含むBGP UPDATEメッセージを生成、伝播、検証して上記の保証を得る方法についても説明する。

BGPsecは、BGPオリジン検証[RFC6483] [RFC6811]を補完するために使用される事が意図されている。オリジン検証と共に使用される時、BGPに対する多種多様な経路ハイジャック攻撃を防ぐ事ができる。

BGPsecは、AS番号およびIPアドレス資源の割り当てを証明するリソース公開鍵インフラストラクチャ(RPKI)証明書に依存している(RPKIの詳細については、RFC 6480 [RFC6480]およびその中で参照されているドキュメントを参照してほしい)。BGPsec_PATHを含むBGP UPDATEメッセージを外部(eBGP)ピアに送信したいBGPsecスピーカは、BGPsecスピーカのAS番号に対応するRPKI経路証明書[RFC8209]に関連付けられた秘密鍵を所有する必要がある。しかし、BGPsecスピーカは、BGPsec_PATH属性を含む受信したUPDATEメッセージを検証するために、そのような証明書を必要としないことに注意してほしい(5.2節参照)。

Hacker News

Goでブロックチェーンを作る (第2回: プルーフ・オブ・ワーク)

Ivan Kuznetsovさんのブログより。

概要

前回の記事では、我々はブロックチェーン・データベースのエッセンスである非常にシンプルなデータ構造を作成した。そして、それらの間でチェーンのような関係を持つブロックを追加することができた。各ブロックは前のブロックにリンクされている。悲しいかな、我々のブロックチェーンの実装は一つの重大な欠陥がある。ブロックをチェーンに追加するのは簡単でチープである。ブロックチェーンとビットコインの肝心な部分の一つは、新しいブロックを追加することが難しいことである。今日は、この欠陥を修正することとする。

プルーフ・オブ・ワーク

ブロックチェーンの重要なアイデアは、ブロックチェーンにデータを置くためにはいくつかのハードワーク(骨の折れる仕事)をしなければならない。ブロックチェーンを安全かつ一貫性のあるものにするのためのハードワークである。また、このハードワークに報酬が支払われる(これが人々がマイニングによってコインを得る方法である)。

このメカニズムは現実にある仕事と非常に似ている。報酬を得て生活を維持するためには、一生懸命働かなければならない。ブロックチェーンでは、ネットワークの一部の参加者(マイナー: 鉱夫)がネットワークを維持し、新しいブロックを追加して仕事に報酬を与える。仕事の結果、ブロックがブロックチェーンに安全に組み込まれ、ブロックチェーン・データベース全体の安定性が維持される。注目されるのは、仕事を終えた人がこれを証明するという事である。

この辺りのハードワークを行って証明する仕組みは、プルーフ・オブ・ワークと呼ばれている。高性能のコンピュータでさえ、高速に処理することはできない。更に、この仕事の難しさは、新しいブロックを1時間に約6ブロックに保つために時々増やされる。ビットコインでは、このような作業の目標は、ブロックのハッシュを見付ける事で、いくつかの要件を満たしている。証明の役割を果たすのがこのハッシュである。従って、証明を見つける事が実仕事である。

最後の点に注意してほしい。プルーフ・オブ・ワークのアルゴリズムは要件を満たさなければならない。仕事を行うのは難しいが、証明を検証するのは簡単である。証明は、他の誰かに渡されるので、検証するのに時間が掛かるべきではない。

ハッシュ化

この段落では、ハッシュ化を議論する。この概念に精通している人は、この部分をスキップできる。

ハッシュ化は、指定されたデータのハッシュを取得する一連の行為である。ハッシュ化は、計算されたデータの一意表現である。ハッシュ関数は任意のサイズのデータを取り、固定サイズのハッシュ値を生成する関数である。ハッシュ化の機能は次のとおりである。

  1. 元のデータはハッシュ値から復元できない。従って、ハッシュは暗号ではない。
  2. 特定のデータにはハッシュは一つしかなく、ハッシュは一意である。
  3. 入力データの1バイトを変更すると、完全に異なるハッシュ値になる。
Hashing example

ハッシュ関数は、データの一貫性をチェックするために広く使われている。一部のソフトウェア・プロバイダは、ソフトウェアパッケージに加えてチェックサムを発行する。ファイルをダウンロードした後に、それをハッシュ関数に入力し、生成されたハッシュ値をソフトウェア開発者が提供したものと比較する事ができる。

ブロックチェーンでは、ブロックの一貫性を保証するためにハッシュ化が使用される。ハッシュアルゴリズムの入力データには前のブロックのハッシュが含まれているため、チェーン内のブロックを変更することは不可能である(または、少なくともかなり難しい)。ハッシュとその後の全てのブロックのハッシュを再計算しなければならない。

Hashcash

ビットコインは、最初にメールのスパムを避けるために開発されたプルーフ・オブ・ワークのアルゴリズムであるHashcashを使っている。それは以下のステップに分けられる。

  1. 公に知られているデータを入手する(メールの場合、受信者のメールアドレスである。ビットコインの場合、ブロックヘッダである)。
  2. カウンタを追加する。カウンタは0で始まる。
  3. data + counter の組み合わせのハッシュを得る。
  4. ハッシュが特定の要件を満たしている事を確認する。
    1. そうであれば、完了である。
    2. そうでなければ、カウンタを増やして、手順3と4を繰り返す。

従って、これはブルートフォース・アルゴリズムである。つまり、カウンタを増やしたり、新しいハッシュを計算し、チェックし、カウンタを増やし、ハッシュを計算する...。これが計算上の費用が掛かる理由である。

さて、ハッシュが満たすべき要件を見ていこう。オリジナルのHashcashの実装では、要件はハッシュの最初の20ビットはゼロでなければならないように思える。ビットコインでは、計算力が時と共に増加し、ネットワークに参加するマイナーが増えても、意図的にブロックは10分毎に生成されなければならないため、要件は時々調整される。

このアルゴリズムを実証するため、前の例(私はドーナツが好きです)のデータを取り出し、3ゼロバイトで始まるハッシュを見付ける。

Hashcash example

ca07caはカウンタの16進数で、10進数の13240266である。

実装

OK、我々は理論を終えたところで、コードを書いてみよう! まず、マイニングの難易度を定義しよう。

const targetBits = 24

ビットコインでは、"目標ビット"はブロックが採掘された時の難しさを格納するブロックヘッダである。今のところ、我々は目標調整アルゴリズムを実装しないので、グローバル定数として難易度を定義できる。

24は任意の数値で、我々の目標はメモリ内で256ビット未満を取得する目標を持つ事である。そして、差が大きくなるほど適切なハッシュ値を見付けるのが難しくなるため、差が十分に大きくても構わないが、あまり大きくは無い。

type ProofOfWork struct {
    block  *Block
    target *big.Int
}

func NewProofOfWork(b *Block) *ProofOfWork {
    target := big.NewInt(1)
    target.Lsh(target, uint(256-targetBits))

    pow := &ProofOfWork{b, target}

    return pow
}

ここでは、ブロックへのポインタとターゲットへのポインタを保持するProofOfWork構造体を作成する。"ターゲット"は、前項で説明した要件の別の名前である。ターゲットとハッシュを比較する方法があるため、大きな整数を使用する。ハッシュを大きな整数に変換し、それがターゲットより小さいことを確認する。

NewProofOfWork関数では、big.Intを1の値で初期化し、256 - targetBitsビットを左にシフトする。256はSHA-256ハッシュの長さで、SHA-256ハッシュアルゴリズムを使用する。targetの16進表現は次の通りである。

0x10000000000000000000000000000000000000000000000000000000000

そして、メモリ内を29倍と占有する。前の例のハッシュと視覚的な比較は次の通りである。

0fac49161af82ed938add1d8725835cc123a1a87b1b196488360e58d4bfb51e3
0000010000000000000000000000000000000000000000000000000000000000
0000008b0f41ec78bab747864db66bcb9fb89920ee75f43fdaaeb5544f7f76ca

最初のハッシュ("私はドーナツが好きだ"で計算される)は、ターゲットよりも大きい、従って有効なプルーフ・オブ・ワークではない。2番目のハッシュ("私はdonutsca07caが好きだ"で計算される)はターゲットよりも小さいので有効な証明である。

ターゲットは範囲の上限と考える事ができる。つまり、数値(ハッシュ)は境界よりも低い場合は有効で、逆もまた同様である。協会を小さくすると有効な数値が小さくなり、従って有効な数を見付けるために必要な仕事がより困難になる。

さあ、ハッシュにデータが必要である。それを準備しよう。

func (pow *ProofOfWork) prepareData(nonce int) []byte {
    data := bytes.Join(
        [][]byte{
            pow.block.PrevBlockHash,
            pow.block.Data,
            IntToHex(pow.block.Timestamp),
            IntToHex(int64(targetBits)),
            IntToHex(int64(nonce)),
        },
        []byte{},
    )

    return data
}

この部分は簡単である。ブロックフィールドをターゲットとノンスと結合する。nonceは上記のHashcashの説明のカウンタである。これは暗号化の用語である。

OK、すべての準備が完了したら、PoWアルゴリズムのコアを実装してみよう。

func (pow *ProofOfWork) Run() (int, []byte) {
    var hashInt big.Int
    var hash [32]byte
    nonce := 0

    fmt.Printf("Mining the block containing \"%s\"\n", pow.block.Data)
    for nonce < maxNonce {
        data := pow.prepareData(nonce)
        hash = sha256.Sum256(data)
        fmt.Printf("\r%x", hash)
        hashInt.SetBytes(hash[:])

        if hashInt.Cmp(pow.target) == -1 {
            break
        } else {
            nonce++
        }
    }
    fmt.Print("\n\n")

    return nonce, hash[:]
}

まず、変数を初期化する。hashIntはハッシュの整数表現である。ノンスはカウンタである。次に、無限ループを実行する。これはnextNonceで制限され、math.MaxInt64と等しくなる。これはnonceのオーバーフローを回避するために行われる。我々のPoWの実装の難しさは、カウンタ溢れには単純過ぎるが、念のためにこのチェックを行う方が良い。

ループの中は、

  1. データを準備する。
  2. SHA-256でハッシュ化する。
  3. ハッシュ値を多倍長整数に変換する。
  4. 整数値をターゲットと比較する。

これまでに説明したように簡単である。今度は、BlockSetHashメソッドを削除し、NewBlock関数を変更できる。

func NewBlock(data string, prevBlockHash []byte) *Block {
    block := &Block{time.Now().Unix(), []byte(data), prevBlockHash, []byte{}, 0}
    pow := NewProofOfWork(block)
    nonce, hash := pow.Run()

    block.Hash = hash[:]
    block.Nonce = nonce

    return block
}

nonceBlockプロパティとして保存されている事が分かる。証明を検証するためにnonceが必要なので、これは必須である。Block構造体は次のようになる。

type Block struct {
    Timestamp     int64
    Data          []byte
    PrevBlockHash []byte
    Hash          []byte
    Nonce         int
}

いいぞ! 全てがうまくいくかどうかを確認するプログラムを実行してみよう。

Mining the block containing "Genesis Block"
00000041662c5fc2883535dc19ba8a33ac993b535da9899e593ff98e1eda56a1

Mining the block containing "Send 1 BTC to Ivan"
00000077a856e697c69833d9effb6bdad54c730a98d674f73c0b30020cc82804

Mining the block containing "Send 2 more BTC to Ivan"
000000b33185e927c9a989cc7d5aaaed739c56dad9fd9361dea558b9bfaf5fbe

Prev. hash:
Data: Genesis Block
Hash: 00000041662c5fc2883535dc19ba8a33ac993b535da9899e593ff98e1eda56a1

Prev. hash: 00000041662c5fc2883535dc19ba8a33ac993b535da9899e593ff98e1eda56a1
Data: Send 1 BTC to Ivan
Hash: 00000077a856e697c69833d9effb6bdad54c730a98d674f73c0b30020cc82804

Prev. hash: 00000077a856e697c69833d9effb6bdad54c730a98d674f73c0b30020cc82804
Data: Send 2 more BTC to Ivan
Hash: 000000b33185e927c9a989cc7d5aaaed739c56dad9fd9361dea558b9bfaf5fbe

わーい! 全てのハッシュは3ゼロバイトで始まり、これらのハッシュを取得するまでに時間が掛かる。

すべき事がもう一つの事が残っている。プルーフ・オブ・ワークを検証できるようにしてみよう。

func (pow *ProofOfWork) Validate() bool {
    var hashInt big.Int

    data := pow.prepareData(pow.block.Nonce)
    hash := sha256.Sum256(data)
    hashInt.SetBytes(hash[:])

    isValid := hashInt.Cmp(pow.target) == -1

    return isValid
}

そして、これは我々が保存されたノンスを必要とする。

全てがOKであるという事をもう一度確認してみよう。

func main() {
    ...

    for _, block := range bc.blocks {
        ...
        pow := NewProofOfWork(block)
        fmt.Printf("PoW: %s\n", strconv.FormatBool(pow.Validate()))
        fmt.Println()
    }
}

出力:

...

Prev. hash:
Data: Genesis Block
Hash: 00000093253acb814afb942e652a84a8f245069a67b5eaa709df8ac612075038
PoW: true

Prev. hash: 00000093253acb814afb942e652a84a8f245069a67b5eaa709df8ac612075038
Data: Send 1 BTC to Ivan
Hash: 0000003eeb3743ee42020e4a15262fd110a72823d804ce8e49643b5fd9d1062b
PoW: true

Prev. hash: 0000003eeb3743ee42020e4a15262fd110a72823d804ce8e49643b5fd9d1062b
Data: Send 2 more BTC to Ivan
Hash: 000000e42afddf57a3daa11b43b2e0923f23e894f96d1f24bfd9b8d2d494c57a
PoW: true

結論

我々のブロックチェーンは、実際のアーキテクチャに一歩近づいている。ブロックを追加するには、ハードワークが必要なため、マイニングが可能である。しかし、ブロックチェーン・データベースは永続的ではなく、ウォレット、アドレス、トランザクションもなく、コンセンサスメカニズムも存在しない。これらの事は全て将来の記事で実装する。今の所、ハッピー・マイニング!


リンク:

  1. 完全なソースコード
  2. ブロックチェーン・ハッシュ・アルゴリズム
  3. プルーフ・オブ・ワーク
  4. Hashcash

ジャレッド・クシュナー氏は過去8年間、女性として投票していた

BoingBoingより

トランプは不正投票が蔓延している事について不満を言った時、それは確認しないと分からない。なんと、彼の義理の息子であるジャレッド・クシュナー氏は過去8年間、女性として投票している。どうして? 知るもんか!

しかし、性の混同は単純にクシュナー氏のフォームの取り違えの可能性もある。Wiredによると、彼はボックスに正しく記入することが習慣的にできない。そして、今の所、彼はトランプの上級顧問である。いいぞ。

Kushner2

正確には、クシュナー氏が思いがけず何度もフォームをしくじるのは、多くの議論の対象となっているだけでなく、上院情報委員会の前の彼自身の宣誓書も同様である。しかし、どうやら習慣的にボックスに正しく記入できないにも関わらず、米政府全体を全面見直しを行う目的を持つ男からそう言われると迷惑である。

「クシュナー氏は必要最低限な書類仕事を記入する事さえできないのに、彼がどういうわけか中東に平和をもたらすだろうと考える人がいるのは不思議である。」リベラル野党の研究拠点でジャレッドの投票不手際を最初に確認したグループAmerican BridgeのスポークスマンのBrad Bainumは言う。「大統領の義理の息子なら誰でも情報開示の誤りを繰り返し、機密情報にアクセスする権限のフォームをしくじった後も、ホワイトハウスの仕事ができるのか?」

もちろん、女性としての投票が意図的ではなかった場合、それはクシュナー氏のケースだと思われるが、不正投票とは見なされない。それは単にずさんでうっかりである。

9/27/2017

Goでブロックチェーンを作る (第1回: 基本プロトタイプ)

Ivan Kuznetsovさんのブログより。

概要

ブロックチェーンは21世紀の最も革新的技術の一つで、今もなお成長しており、潜在的にはまだ完全に実現されていない。本質的に、ブロックチェーンは単なるレコードの分散データベースである。しかし、それを優れたものにしている点は、パブリックデータベースであり、プライベート・データベースではないことである。つまり、利用する全員がその完全または部分的にコピーを持っている。新しいレコードは、データベースの他の保持者の同意がある場合にのみ追加できる。また、ブロックチェーンは暗号化とスマート・コントラクトを可能にしている。

この一連の記事では、シンプルなブロックチェーンの実装に基づいて、簡易化された暗号通貨を構築してみたい。

ブロック

ブロックチェーンのブロック部分から始めよう。ブロックチェンでは、重要な情報を格納するのがブロックである。例えば、ビットコインのブロックはトランザクション(取引き)を格納し、暗号通貨の最重要点である。この他に、ブロックにはバージョン、現在のタイムスタンプ、前のブロックのハッシュなどの技術情報を含んでいる。

この記事では、我々はブロックチェーンやビットコインの仕様で説明されているようにブロックを実装するつもりはなく、重要な情報のみを含む単純化されたバージョンを仕様する。以下に示す:

type Block struct {
    Timestamp     int64
    Data          []byte
    PrevBlockHash []byte
    Hash          []byte
}

Timestampは現在のタイムスタンプ(ブロック作成時の)、Dataはブロック内の実際の重要な情報、PrevBlockHashは前のブロックのハッシュ、Hashはこのブロックのハッシュである。ビットコインの仕様では、Timestamp、PrevBlockHash、Hashはブロックヘッダで、個別のデータ構造を形成し、トランザクション(ここでのData)は別のデータ構造である。ここでは単純化のためにミックスしている。

では、ハッシュはどのように計算するのか? ハッシュを計算する方法は、ブロックチェーンの非常に重要な機能で、ブロックチェーンを安全にする機能である。肝心なのは、ハッシュ計算はコンピュータ的には難しいオペレーションであり、高速なコンピュータでも時間が掛かることである(ビットコインを採掘するために強力なGPUを購入するのはそのためである)。これは意図的なアーキテクチャデザインであり、新しいブロックを追加するのを難しくし、追加後の変更を防ぐことができる。この仕組みについては、今後の記事の中で説明する。

ここでは、ブロックフィールドを取得するだけで、それらを連結し、連結された組み合わせに対してSHA-256のハッシュ計算を行う。SetHashメソッドでこれを行う:

func (b *Block) SetHash() {
    timestamp := []byte(strconv.FormatInt(b.Timestamp, 10))
    headers := bytes.Join([][]byte{b.PrevBlockHash, b.Data, timestamp}, \
[]byte{})
    hash := sha256.Sum256(headers)

    b.Hash = hash[:]
}

次に、Go言語の慣習に続いて、ブロックの作成を簡単にする関数を実装する:

func NewBlock(data string, prevBlockHash []byte) *Block {
    block := &Block{time.Now().Unix(), []byte(data), prevBlockHash, \
[]byte{}}
    block.SetHash()
    return block
}
そして、ブロックにとってはこれで終わりである!

ブロックチェーン

さて、ブロックチェーンを実装してみよう。要するに、ブロックチェーンは特定の構造を持つデータベースというだけである。順序付けされた後方連結リスト(back-linked list)である。つまり、ブロックは挿入順に格納され、各ブロックは前のブロックにリンクされている。この構造により、チェーン内の最新のブロックを迅速に取得し、そのハッシュによってブロックを(効率的に)取得することができる。

Go言語で、この構造は配列とマップを使って実装することができる。配列は順序付きハッシュを保持し(配列はGoでは順序付けされている)、マップはハッシュ→ブロックのペアを保持する(マップは順序なし)。しかし、我々のブロックチェーンプロトタイプでは、今はハッシュでブロックを取得する必要はないので、配列を使用する。

type Blockchain struct {
    blocks []*Block
}

これが我々の最初のブロックチェーンである! 私はこんなに簡単だとは思っていなかった😉

さて、それにブロックを追加してみよう。

func (bc *Blockchain) AddBlock(data string) {
    prevBlock := bc.blocks[len(bc.blocks)-1]
    newBlock := NewBlock(data, prevBlock.Hash)
    bc.blocks = append(bc.blocks, newBlock)
}

それで終わり! あるいは違う?...

新しいブロックを追加するのに既存のブロックが必要だが、ブロックチェーンにブロックは存在しない! 従って、どのブロックチェーンでも、少なくとも一つのブロックが存在しなければならず、そのようなブロック(チェーン内の最初のブロック)は、起源ブロック(genesis block)と呼ばれる。そのようなブロックを作成する方法を実装してみよう。

func NewGenesisBlock() *Block {
    return NewBlock("Genesis Block", []byte{})
}

ここで、起源ブロックを持つブロックチェーンを作成する関数を実装できる。

func NewBlockchain() *Blockchain {
    return &Blockchain{[]*Block{NewGenesisBlock()}}
}

ブロックチェーンが正しく動作数rことを確認してみよう。

func main() {
    bc := NewBlockchain()

    bc.AddBlock("Send 1 BTC to Ivan")
    bc.AddBlock("Send 2 more BTC to Ivan")

    for _, block := range bc.blocks {
        fmt.Printf("Prev. hash: %x\n", block.PrevBlockHash)
        fmt.Printf("Data: %s\n", block.Data)
        fmt.Printf("Hash: %x\n", block.Hash)
        fmt.Println()
    }
}

出力は、

Prev. hash:
Data: Genesis Block
Hash: aff955a50dc6cd2abfe81b8849eab15f99ed1dc333d38487024223b5fe0f1168

Prev. hash: aff955a50dc6cd2abfe81b8849eab15f99ed1dc333d38487024223b5fe0f1168
Data: Send 1 BTC to Ivan
Hash: d75ce22a840abb9b4e8fc3b60767c4ba3f46a0432d3ea15b71aef9fde6a314e1

Prev. hash: d75ce22a840abb9b4e8fc3b60767c4ba3f46a0432d3ea15b71aef9fde6a314e1
Data: Send 2 more BTC to Ivan
Hash: 561237522bb7fcfbccbc6fe0e98bbbde7427ffe01c6fb223f7562288ca2295d1

以上!

結論

我々は非常に単純なブロックチェーン・プロトタイプを作成した。ブロックの配列だけで、各ブロックは前のブロックとの接続を持っている。実際のブロックチェーンは遥かに複雑である。我々のブロックチェーンでは、新しいブロックを追加するのは簡単で高速だが、実際のブロックチェーンでは新しいブロックを追加するにはいくつかの作業が必要である。一つは、ブロックを追加する許可を得るのに、何らかの重い計算を実行する必要がある(このメカニズムは、プルーフ・オブ・ワークと呼ばれる)。また、ブロックチェーンは、単一の意識決定者を持たない分散データベースである。従って、新しいブロックは、ネットワークの他の参加者によって確認され、承認されなければならない(このメカニズムはコンセンサスと呼ばれる)。我々のブロックチェーンにはまだトランザクションが存在しない!

今後の記事で、これらの機能それぞれを取り扱っていく。


リンク:

  1. 完全なソースコード: https://github.com/Jeiwan/blockchain_go/tree/part_1
  2. ブロック・ハッシュ・アルゴリズム: https://en.bitcoin.it/wiki/Block_hashing_algorithm

セレブが自分への悪口を読み上げる「Celebrities Read Mean Tweets」

geektyrantより。口汚いツイートを書き込まれても気にしない、気にしない。セレブが自分について書かれた意地悪なツイートをカメラの前で読むと言う企画がある。第11弾が公開された。

人は、Twitter上で残酷になる事ができる、特にセレブに向けては。私は、"Celebrities Read Mean Tweets"がこの意味の質を少し軽くしたと思っているが、11回目のツイートはこれまでと同じくらい残酷だ! 下記をチェックして、これらのランダムツイートが本当に利口だと思うかどうか教えて欲しい...あるいは、ジミー・キンメルのスタッフが幽霊アカウントを作成し、その一コマでセレブに関するジョークを伝えている。
Emma Watson seems like the type of girl who I would be friends with for like 3 days and then get really sick of but not tell her.

エマ・ワトソンって友達になっても3日くらいで嫌になっちゃいそう。でも、彼女に言わないでね。

9/26/2017

macOS High Sierraのキーチェーンに脆弱性

ars technicaより。Appleのレスは予想通り。早く修正して欲しい。

High Sierraとそれ以前のバージョンのmacOSには、不正なアプリケーションがMacのキーチェーンに格納されている平文のパスワードを盗むことができる脆弱性があると、セキュリティ研究者が月曜日に語った。大いに期待されていたアップデートがリリースされたのと同じ日である。

Macのキーチェーンは、パスワードと暗号鍵を保存するデジタル金庫である。Appleのエンジニアは、インストールされたアプリケーションがユーザによるマスターパスワードの入力無く、コンテンツにアクセスできないように設計している。しかし、キーチェーンの弱点は、悪意のあるアプリケーションがパスワードを必要とせずに保管されている全ての平文パスワードを盗む事ができるようになる。現在、セキュリティ会社のSynackで働いている元国家安全保障局のハッカーであるPatrick Wardle氏はビデオデモをここに投稿した。

ビデオは、High Sierraを実行するMacの仮想マシンがアプリケーションをインストールするのを示している。アプリケーションがインストールされると、ビデオはNetcatネットワークユーティリティを実行しているリモートサーバ上で攻撃者を表示する。攻撃者は"exfil keychain"ボタンをクリックすると、アプリは秘密裏にキーチェーンに保存されている全てのパスワードをこっそり取り出し、それらをサーバにアップロードする。窃盗行為は、不正アプリケーションの最初のインストール以外ユーザとのやり取りは必要とせず、アプリやmacOSのいずれも警告を表示せずに、許可も求めない。

Appleの代表は次の声明文をメールした。

macOSはデフォルトで安全に設計されており、GatekeeperがこのPoC (実演)に示されているような署名の無いアプリのインストールをユーザに警告し、明示的に承認の無いアプリを起動する事を阻んでいる。ユーザは、Mac App Storeのような信頼できるソースからのみソフトウェアをダウンロードし、macOSが提示するセキュリティ・ダイアログに注意を払う事を奨励する。

レイ・カーツワイル、テクノロジーが人間の仕事を無くさない理由を説明

Slashdotより

未来学者のレイ・カーツワイル(Googleのエンジニアリング担当ディレクタ)は、Fortuneとの新しいインタビューで興味深い議論をした:

我々は既に人類の歴史の中で何度も全ての仕事を排除してきた。今日、1900年頃の仕事が存在しているだろうか? 私が1900年の先進的な未来学者であれば、「あなたたちの38%が農業に従事し、25%が工場で働いている。それは人口の3分の2である。私は2015年までに、農業が2%に、工場が9%になると予測する。」と言うだろう。そして、誰もが「大変だ。我々は仕事を失うことになるだろう。」と言う。私は「我々が排除した全ての仕事について心配しなくていい。我々はスキルラダーの上に更に仕事を作るだろう。」と言う。そして、人々は、「どんな新しい仕事?」言う。そして、私は「私には分からない。我々はまだそれらを発明していない。」と言うだろう。

それは事実であり続け、あなたは自動車やトラックを運転する人々を考えるため、困難な政治的問題を引き起こし、それらの仕事がなくなるとかなり確信を持つことができる。そして、それらはまだ存在しない業種や構想にあるため、新しい仕事を説明できない。

また、カーツワイルはソーシャルネットワークと経済動向の凄まじい力のために、政府の力と影響が減少していると主張している...。

「多くの人々は事態がますます悪化していると考えている。これは実際には、進化的適応でもある。あなたの生存本能が悪いニュースに敏感である事は非常に重要である。葉っぱの中の小さな音は捕食者かも知れないので、それに注意を払う方が良い。」

睡眠時間が短いと、寿命も短くなる

Slashdotより

匿名の読者がレポートを共有する:
"致命的な睡眠不足の蔓延"は、多くの潜在的に致死的な病気を引き起こしていると、その分野の専門家が述べている。カリフォルニア大学バークレイ校のヒューマン・スリープ・サイエンス・センター長のMatthew Walker教授は、ガーディアンとのインタビューで、「睡眠不足が我々の生物学のあらゆる側面に影響を与え、現代社会に広まった」と語った。しかし、この問題は政治家や雇用主によって真剣に受け止められておらず、良い夜の睡眠を得る願望を怠惰の兆候としてしばしば非難する、と彼は言った。電灯、テレビ、コンピュータ画面、長い通勤、仕事と個人の時間の間の境界線のぼやけ、など現代生活の様々な側面が夜の7時間未満と定義される睡眠不足の一因となっている。しかし、これはガン、糖尿病、心臓疾患、脳卒中、アルツハイマー病、肥満、他の健康問題に共通する精神的健康の低下に関連している。要するに、睡眠不足が我々を殺している。

9/25/2017

High Sierraは自動的に毎週EFIファームウェアをチェックする

Electric Lightより

High Sierraへのアップグレードは新しい重要なセキュリティ機能がもたらされる。あなたのMacは自動的にEFIファームウェアをチェックする。一連のツイートで新しいツールを担当している3人のエンジニアの1人であるXeno Kovahがこれがどのように動くかの概要を説明する。

/usr/libexec/firmwarecheckers/eficheckにある新しいユーティリティeficheckは、1週間に1度自動的に実行される。それは、Appleのデータベースと比較してMacのファームウェアが適合しているかをチェックする。パスした場合は何も用事されないが、不一致がある場合は、次のダイアログでAppleにレポートを送信するよう求められる。

Eficheck

Hackintoshではなく、本物のMacを実行しているなら、Kovahはレポートを送るのに同意するよう求める。これにより、eficheckはEFIファームウェアからバイナリデータを送信し、NVRAMに保存されているデータを除いてプライバシーを保護する。Appleはデータを分析してマルウェアやその他の何かによって変更されているかどうかを判断する事ができる。

もちろん、大多数のユーザはそのダイアログを見ることは決して見るべきでは無い。もし、見た場合、あなたの決定は記憶される。Appleにデータを送信することに同意した場合、eficheckは1週間後に再び実行され、自動的に最初の選択に従う。

eficheckは既知の良いデータの小さなローカル・ライブラリに依存し、App Storeペインでセキュリティアップデートが有効になっている場合、自動的かつ黙ってアップデートされる。

これは、Xeno Kovah、Nikolaj Schlej、Corey Kallenbergによって開発され、この種のファームウェアの完全性の大規模なプライバシー保護チェックの最初の試みと考えられている。うまくいけば、High Sierraにアップグレードされた全てのMacにセキュリティの大幅に改善をもたらすだろう。

(上記スクリーンショットは、Xeno Kovahのツイートから得た情報そのままである。Xeon、あなたの仕事とこの知恵に感謝する。)

Hacker News

ストールマン vs. カノニカルCEO: MicrosoftはLinuxをたまらなく好きなのか?

Slashdotより

TechRepublicは、カノニカルの創業者でCEOのマーク・シャトルワースとリチャード・ストールマンのLinuxへのMicrosoftの新しい熱意に関して異なる回答を得た。ストールマンは、Linux向けのWindowsサブシステム(WSL)を作るというMicrosoftの決定は、ユーザが自由に実行、コピー、配布、学習、変更、改善するソフトウェアを絶滅させるための試みになると考えている。
「確かにそのように見えます。しかし、フリー・ソフトウェアを使用して進歩させる理由が実用的な利便性に限定されないため、私たちを絶滅させるのはそれほど簡単ではありません。」彼は言った。我々は自由を求めている。自由にコンピュータを使用する方法として、Windowsはやるべき事をやらない...。ストールマンは、WSLがWindowsのようなプロプライエタリなソフトウェアの支配を強固にさせ、フリーソフトウェアの使用を弱体化させるのを助けるだけだと強く主張している。「それはフリーソフトウェアの原因を少しも進展させるもではありません。」彼は言う...。「フリーソフトウェア運動の目的は、Windowsなどの自由を拒否するプロプライエタリなプログラムやシステムからユーザを解放する事なのです。WindowsやmacOS、iOS、ChromeOS、Androidなどの非フリーソフトウェアをより便利にする事は、自由を求める運動の後退です...。」

シャトルワースにとって、WindowsのGNU/Linuxの採用は、オープンソース・ソフトウェア全体にとって差し引きでプラスである。「Microsoftはおもちゃを盗んでいるという訳ではなく、全ての人に望み得る最高の体験を提供するためにMicrosoftと共有する方がいい。」彼は言う。「WSLは、Windows環境に精通しているユーザにより幅広い選択肢と柔軟性を提供し、その一方でオープンソース・プラットフォームの潜在的なユーザ基盤を開いています...。」今日のシャトルワースは、文字通りGNU/LinuxのためにMicosoftの新たな熱意を利用している。そして、同社は1990年代とは異なる気質、オープンソース・ソフトウェアと同じくらいMicrosoftに恩恵をもたらす新鮮な見通しを持っていると言う。「Microsoftは、複数の面でオープンで競争の激しいプラットフォームをよりバランスの取れた視点を持つ変わった企業です。」彼は言う。「AzureやHyper-V上のUbuntuのようなオープンプラットフォームに対応するために、膨大な作業を行い、この作業はそうした考えから行われています。」

この記事は、Microsoftは単一のGNU/Linuxディストリビューションを使って可能なものを拡張するためにWSL基盤に取り組んでいるように思えると指摘する。例えば、ユーザに様々なGNU/LinuxディストリビューションのコマンドとWindowsのコマンドを連鎖させる。

9/24/2017

Rotten Tomatoesは映画業界をダメにしたか? ノー、低俗映画には

Philly.comより

あなたが映画のスタジオを運営する資格があるかどうかを確認するために簡単なクイズを出そう。

質問: どうしようもない映画『ザ・マミー/呪われた砂漠の王女』(主演はトム・クルーズ)は、映画レビュー集約サイトRotten Tomatoesでどうしようもない16パーセントの評価を受ける。そして、ボックスオフィスで元気がなかった。

この失敗は次の結果によるもの:

A: 皮肉的に着想され、不完全に実行されたまずいアイデア
B: Rotten Tomatoes

あなたがBと答えたら、スタジオの幹部になることができる。少なくとも最近のニューヨークタイムズの記事から判断すると、スタジオのボスがゾッとするような(20年で最悪の)ボックスオフィスの数ヶ月を批判のせいにしている。ウェブサイト上では、数百人の批評家のレビュー、数百の引用、そして評判の高いトマトメータで少なくとも60%肯定的レビューを獲得するのに失敗する映画に対して、"rotten(腐っている)"格付けを割り当てている。

サイトは急速に成長しており、5月にユニークビジター数は1400万人近くに達し、前年より35%増加している。その親会社Fandangoは、チケット購入インタフェースにトマトメータを取り付けている。こうした事が、Rotten Tomatoesを映画を観る価値があるかどうかに関して早く掴みたい人のための頼りになる消費者向けサービスにしている。

タイムズによると、スタジオの経営幹部は人気が高まるにつれて過度の商業的影響を与える事を恐れている。しかし、彼らは記録上から明らかにこれを強くは信じていないようだ。

記事はウェブサイトは映画ビジネスの破壊を加速していると言うブレット・ラトナー監督の陳腐でしばしば繰り返される言葉を引用する。(偶然にも、彼はRotten Tomatoesで18パーセントの格付けを持つ『ラッシュアワー3』を監督したが、1億4千万ドルを稼ぎ、見たところ彼の理論が誤りだと証明している。) ラトナーの意見は、スタジオの幹部によって日々同調されていると言う記事の主張にも関わらず、サイトにさらに正当性を与える事を恐れて公然と同意する人はいないだろう。

私は別の理由があると思っている。

あなたが『マミー』(私はそれに2つ星を与えた)、『キング・アーサー』(2つ星、Rotten Tomatoesで28パーセント)、『CHiPs』 (2つ星半、RTで15パーセント)、『ベイウォッチ』(2つ星半、RTで18パーセント)、『トランスフォーマー/最後の騎士王』(2つ星、RTで15パーセント)にゴーサインを与えた人物であるなら、レビューを集めるだけのウェブサイトであなたの酷い映画の失敗をイカサマと責めているように見えるだろう。

そして、明らかにしよう。それは映画にとって酷い夏だった

そして、サイトは実際にそれ以上の事をしている。Rotten Tomatoesのキュレータは各レビューを読んで、各映画を賛成、拒否を割り当て、Rotten Tomatoesの用語で新鮮、腐っているに変換される。多くの批評家はこのような白黒の言葉を使わない。これらのキュレータは実際にはかなり潔癖である。彼らは意見を支持または明確にするために中立の評論家とコンタクトを取る。『Ingrid Goes West』(私は新鮮と言った)と『ラフ・ナイト』(私は腐っているにした)で新鮮あるいは腐っているの格付けを確認するために、彼らは2度私に連絡してきたため、私はこれが本当だと分かった。

映画のような潜在的に複雑な実体が緑のsplatや赤いトマトになぞらえられる方法について、何かオーウェル式で還元主義的なものがあるのだろうか? はい。しかし、しばしば何かそれについて適切なものがある。映画を製作して大量の商品のように販売する場合(『マミー』は文字通り、シリーズ化/神話の宇宙の始まりと着想された)、彼らはそれのようにYelpする事ができる。(より適切な質問は、なぜ腐ったトマトのアイコンが緑なのか? それは未熟なトマトではないのか?)

あなたが望めば、かなり洗練された方法でRotten Tomatoesを使う事ができる。トマトメータから始めるが、映画の幅広い論評を得るために個々のレビューにクリックできる。あなたは自分が好む評論家に相談するために自分の供給口をカスタマイズできる。

あるいは、別のサイトに行く事ができる。消費者は、映画を選んだのと同じようにアグリゲータの選択を行う。一つは、Rotten Tomatoesよりも洗練され、目に肥えたものを目指しているMetacriticである。その方法の一環として、Metacriticは、より小さな、より味付けされた、そしてより権威のある基盤から始めて、実際に批評家を審査する。このグループ内で、最も価値のあるものと見なされる批評家の重みが増える。(これはMetacriticの秘密のソースで、材料は開示されていない。)

ほとんどのファンはRotten Tomatoesの乱暴な民主主義を好むが、その便利なモバイルインタフェースと素晴らしい検索エンジンの最適化(Rotten Tomatoesは映画に関するほとんどの検索で登場する)、本格的な映画ファンのためにRotten TomatoesやMetacriticのアルゴリズムを研究している映画関係者統計専門家は、Metacriticを推奨している(ガウス分布が素晴らしいと、ある統計専門家が言う)。

そして、アナリストはIMDBとFandangoで見つける事ができるユーザ投票を好んでいる。Fandangoのユーザ調査を調べた数学者は、Fandangoがあまりに多くの映画を好むと結論付けている。私は、ユーザの世論投票もおそらくゲームのようなものだと気付いた。スコアは映画が実際に公開されるまで高く、その後は落ちる(しばしば急激に)。疑わしい人は、スタジオが映画を幸先の良いスタートを与えるためにユーザの票の水増しを行っていると結論づけるだろう。

ところで、それは決してうまくいかない。

映画ビジネスと映画の文化には一定のものが残っているためである。それは、長年に渡って映画をどのように販売するかは古風な口コミである。マーケティングは、公開週末で劇場の観客を獲得する事ができる。そして、Rotten Tomatoesはそれらの批評家を集める事ができる。

しかし、最近のRotten Tomatoの格付けのおおまかな見通しでさえ、サイトの格付けと実際の興行収入との間の密接な関係を示している。うまくいった映画には腐った格付けが割り当てられており(『ヒットマンズ・ボディガード』、『The Emoji Movie』)、貧弱な映画には圧倒的に肯定的な評価を付けている(『ローガン・ラッキー』)。

映画が公開され、人が他の人に話すと(ソーシャルメディアによって加速される)、客数が入る/維持する。

それは素晴らしい映画の素晴らしいニュースである。

そして、『マミー』には悪いニュースである。

Hacker News

9/23/2017

Appleの最新製品の寄せ集めのレビューと消極的な反応

Slashdotより。最近の機種は、積極的に買い換えるほどのインパクトは無い。

Mark Gurmanがブルームバーグで伝えている:
ブランドの強みにも関わらず、Appleはたまに評価があまり芳しく無い製品を発売する。オリジナルのApple TVやApple Watchを覚えているだろうか? しかし、Appleがホリデーシーズンに向け、新しいガジェット群を発表した時、批評家がこんなに無愛想になったことは滅多にない。「私は、昨年発売されたiPhone 7から、iPhone 8またはiPhone 8 Plusにアップグレードする説得力ある理由を一つも思い付かない。」The VergeのNilay Patelは書いた。悩みのもう一つの潜在的兆候は、iPhone 8モデルは予約で売り切れなかったことで、Appleの携帯にとってもう一つの珍しいことだ。[...] ウォール・ストリート・ジャーナルのJoanna Sternは、新しいApple Watch Series 3モデルを評価し、次のように書いている。「AT&T接続モデルでは、セルラー接続が切断され、通話が頻繁に不安定になり、Siriが接続に失敗することがあった。T-Mobileで繋がっていた携帯に関して、私は接続がいくつか落ちる経験をした。」The VergeのLauren Goodeは、同じように深刻な接続の問題に気付いた。「このデバイスはLTEに切り替わるのではなく、ランダムなWi-Fi信号のシングルバーを拾って放さないように見える。」[...] Apple TV 4Kを評価したThe VergeのPatelは、このデバイスの価格は高く、YouTubeなどの主要アプリで4Kのサポートが無く、ドルビーアトモスのオーディオ規格がサポートされていないことに気付いた。
ロイターは金曜にレポートした:
例年、新しい製品が発売された時は何百人もの人が街のメインストリートであるジョージ・ストリートに行列を作ってシドニーのAppleストアに集まる。しかし、ロイターの目撃によると、金曜日のストアが開店する前には、30人ほどの人が集まっていたと言う。Appleストアの外に並んでいる人の数は、多くの人がオンラインで購入することで何年にも渡って減少してきたが、最新のiPhoneの弱い出足は、部分的に芳しくない評価のためとされている。
フィナンシャル・タイムズで、Tim Bradshawはレポートする:
Above AvalonのAppleのアナリストNeil Cybartは、「フラグシップ携帯電話を手に入れるというだけの理由では、私は需要は昨年から下がると思う。」と言った。「iPhone発売の一部は、まだ現れていない。」この週末の初期売上高は、iPhone 6が2014年に最初に発売されてから、いつの時点でも低下する可能性があると、Cybart氏は付け加えた。昨年のモデルと比較してiPhone 8の価格を引き上げるというAppleの決定やモバイルキャリアによるあまり積極的ではない発売奨励も、需要に影響を与える可能性がある。

9/22/2017

HBOがウォッチメンのパイロット版を正式発注

Slashfilmより

今週初め、『Lost』と『LEFTOVERS/残された世界』の共同制作者デイモン・リンデロフは、アラン・ムーアとデイブ・ギボンズによる1980年代の名高いDCコミック『ウォッチメン』のテレビシリーズの作品『Day One』を発表するInstagramの写真に掲載した*TV Lineは、HBOが正式にパイロットとドラマの予備脚本を発注したと報じているが、ウォッチメンのリンデロフ主導バージョンは実際にどのようなものになるだろうか? それを理解してみよう。

* 原作コミックに登場するナイトオウル1世/ホリス・メイソンの引退を記念する像

9/21/2017

数式は2100年にグローバルな大量絶滅を予測

Slashdotより

Kate LunauがMotherboardに書いている:

Science Advancesの新しい論文は、人類が地球上のすべての植物や動物の大多数が存在する海洋に一定量の炭素を加えると、地球の古代の過去からの大量絶滅時代が引き起こされる可能性があることが分かった。論文はその量は310ギガトンだと裏付けている。筆頭著者のMITのDaniel Rothmanによると、気候変動に関する政府間パネルの予測に基づいて、我々は2100年までに順調にその数値に達しようとしている。その後、我々は未知の分野に入っている。[...] 以前の大量絶滅が数千年または何百万年もの間に起こったが、我々が現時点での変動期は、せいぜい数世紀に渡るもので、比較することが難しい。多くの専門家は地球が既に6番目の大量絶滅を体験中であると言うが、依然として科学的疑問は残り、MITの地球大気惑星科学部門で地球物理学教授であるRothmanは私に次のように言った。我々の惑星は彼がこの論文で同定した閾値に達すると、より早い時期にすべてのものを増幅する変化を促進するだろう、彼は説明した。繰り返し述べるが、これらの同じ変化は、これまでの地球上のすべての大量絶滅に関連している。

MIT NewsHacker News

意識はあなたが考えるよりも深い

Slashdotより

匿名の読者がBernardo Kastrupによって書かれたScientific Americanの記事を共有する:

数年前に関心を集めた幼児の意識の神経科学に関する記事では、「いつ赤ちゃんは意識を持つのか?」もちろん、前提は、赤ちゃんが意識を生むわけではなく、むしろ意識を発達させるという事だった。しかし、新生児のように感じる事は何も無いと考えるのは難しい。新生児は、自らの体、環境、両親の存在などを明らかに経験しているように見える。無分別ではあるが、現在志向である。それが常に赤ちゃんのような気がするなら、赤ちゃんは意識していない事になる。むしろ、彼らは最初から意識がある。問題はやや驚くべき事に、"意識"という言葉がしばしば経験の質以上のものを伴い、意味を含んでいるかのように文献の中で使われている事である。例えば、DijksterhuisやNordgrenは、「気付きは、無意識思考と意識的思考の区別の鍵であることを認識することが非常に重要であると主張している。意識的思考は気付きを伴う思考である。」これは、思考が気付きを逃れた場合、意識不明になることを意味する。

実際、Jonathan Schoolerは意識とメタ意識のプロセスを明確に区別している。両者のタイプが経験の質を伴うのに対して、メタ意識のプロセスは彼が再表象と呼ぶものを伴う。経験の内容を明示的に評価する事に、定期的に気付きが向けられる。結果として生じるメタ意識は、意識の明示的な再表象を伴い、自分の心の状態を解釈し、記述し、そうでなければ特徴付ける。

Hacker News

次期ターミネーター・シリーズにリンダ・ハミルトンがサラ・コナーとして戻って来る

geektyrantより。ターミネーター2の続編ということは、相当にCG(モーフィング)が使われるんだろうなぁ。

私たちに新しい三部作の映画を提供するため、ターミネーター・シリーズに戻って来るジェームズ・キャメロンに本当のところとても興奮している。デッドプールの監督、ティム・ミラーは、キャメロンと共に映画を製作している。アーノルド・シュワルツェネッガーはシリーズに戻る予定で、そして今、キャメロンからリンダ・ハミルトンも戻って来る事を知った! 彼女は、サラ・コナー役を再演するだろう。すごくクールだ!

THRによれば、キャメロンはシリーズを祝うプライベート・イベントで発表した。

「いついかなる場所でも、彼女は性差を超えたアクション・スターだったことに意義があり、熟練した戦士である彼女が戻って来る事に大きな声明を出したい。そこには、50歳、60歳でも悪人を殺す男はいるが、女性にはそういう例はない。」

その後、キャメロンとミラーは、キャメロンの「ターミネーター2」への文字通りの続編として、シリーズの次の映画を扱っていることを明らかにした。新しい若い女性のキャラクターがシリーズに参加すると説明されているが、ターミネーターとサラ・コナーが物語の中心になる。キャメロンは語る:

「僕たちは新しい物語の新しい中心的存在になる18かそこらの女性を探し始めている。まだ時間は掛かるだろう。未来から来たキャラクターと現在のキャラクターが登場する予定だ。登場するのは、ほとんど新しいキャラクターだけど、アーノルドとリンダのキャラクターはこれまで通りだよ。」

私は、ターミネーター・シリーズのこの次の章について知れば知るほど興奮している。

キャメロンは2019年に使用権を取得しているが、現在ミラーとキャメロンはデヴィッド・ゴイヤー(ダーク・ナイト)、チャールズ・エグリー(ダーク・エンジェル)、ターミネーターのスピンオフ・シリーズ「サラ・コナー・クロニクルズ」を作ったジョシュ・フリードマンを含む作家チームと共に制作中である。

私はキャメロンと彼のチームがこの次のシリーズの映画にリンダ・ハミルトンのサラ・コナーを入れることを考えていることに喜んでいる。彼女の背中や活躍が見られるのは素晴らしい事だ。今... エドワード・ファーロングをジョン・コナー役の再演に戻すだろうか? おそらく無い。

あなたはハミルトンがターミネーター・シリーズに戻って来ることをどう思うか?

SlashfilmEngadgetars technica

更新: シュワルツェネッガーが次期ターミネーターについてファンに紹介している(geektyrant)。「リンダ・ハミルトンは現在トレーニングを受けている。」、「ターミネーター6は、ターミネーター6とは呼ばれない。」、「Genisysは無視されるだろう。」、「ロバート。パトリック(T-1000)は関与しない。」、撮影は3月に開始され、話はキャメロン自身が作ったもの。この映画は3部作になる。

更新(2017.09.28): キャメロン曰く、シュワルツェネッガーは年齢そのままで演じるとのこと(geektyrant)。

9/20/2017

AppleのFace ID

シュナイアーのブログより。シュナイアーはFace IDに対して慎重だ。

これは、Face IDについて、Appleのソフトウェアエンジニアリング担当SVPとの優れたインタビューである。

正直、私はどう考えたらいいか分からない。Appleは写真データベースを収集してはいないと確信しているが、偽造の顔でハッキングできないと楽観的にはなれない。私は警察が人に電話を向け、自動的にアンロックするという現実は嫌だ。

私は、警察に逮捕されたり、泥棒があなたのデバイスを引き渡すよう求められる微妙な状況下で素早くFace IDを無効化する確実な方法についてフェデレギに質問した。

「古いiPhoneでは、シーケンスは電源ボタンを5回クリックするようになっているが、iPhone 8やiPhone Xのような新しいiPhoneでは、両サイドのボタンを掴んで少し押したままにするとFaceIDを無効になる。」フェデレギは言う。「だから、あなたは泥棒があなたの電話お手渡すよう求めた場合には、ポケットに手を突っ込んで、Face IDを無効にできる。Touch IDを無効にするには、iPhone 8で同じことができるだろう。」

そのスクイーズは、音量ボタンと電源ボタンのいずれかにすることができる。これは、私見では、あまり目立たないので、5クリックよりも優れたソリューションである。これを行うと、デフォルトでパスコードに戻る。

さらに:

ここでいくつかの追加の詳細に注目する価値がある:

  • 48時間以内にFace IDを使用しなかった場合、または再起動したばかりの場合は、パスコードを要求する。

  • Face IDに5回失敗した場合、デフォルトでパスコードに戻る。(フェデレギは、パスコードが要求された時、これがデモのステージで起こった事を確認した。演壇の上の電話を設定する人を読むことを試みた。)

  • 開発者は、Face IDの配列から生のセンサーデータにアクセスする事は出来ない。代わりに、ステージに表示されるSnapのフェイスフィルタのようなアプリケーションで利用できる深度マップが与えられる。これは、ARKitアプリケーションでも利用できる。

  • パスコードを使用して電話をロック解除していない場合、または6.5日以内にFace IDが4時間以内にロックを解除していない場合は、パスコード要求される。

また、スリープ/スリープ解除ボタンが押される度に、またはスリープ状態になる度にロックするようiPhoneが準備できていることを確認する。これはTouch IDと同様である。

フェデレギはまた、AppleがiPhone Xのリリース前後で、Face IDのセキュリティのホワイトペーパをリリースする予定だと述べている。もし、あなたが研究者またはセキュリティの虫で、期待しているのであれば、システムのセキュリティについて詳しく説明する。

ここに偽造の顔で欺くことに関しての詳細がある。

顔認識は、長い間、打ち負かすのが簡単である事で有名だった。例えば、2009年には、セキュリティ研究者は、カメラの前にラップトップの所有者の写真がプリントされたものを見せるだけで、様々なラップトップの顔に基づくログインシステムを欺くことができる事を示した。2015年、ポピュラーサイエンスの作家Dan Morenは、自分自身が瞬きしているビデオを使用するだけで、Alibabaの顔認識システムを打ち負かした。

しかし、Face IDのハッキングはそれほど単純ではない。新しいiPhoneは赤外線システムを使用し、Appleは目に見えない光の点3万個のグリッドで投影するTrueDepthを呼び出す。赤外線カメラは、ユーザが顔の3D形状をマッピングするために頭を回転させると、グリッドの歪みを捉える。これは、現在俳優の顔を捉えてアニメーションやデジタルに強化された文字にそれらをモーフィングさせるために使用されているトリックである。

より難しいだろうが、それが行われるだろう事は疑いの余地はない。

さらなる推論

私はまだそれを有効にするつもりはない。

更新(2017.9.28): AppleはFace IDのセキュリティに関するホワイトペーパを公開した(9to5macHackerNews)。

EFFが、EMEの決定を受けてW3Cを脱退

CircleIDより

電子フロンティア財団(EFF)は、World Wide Webコンソーシアム(W3C)への公開書簡で、暗号化メディア拡張(EME)を標準として発行する団体に応えて、火曜日にWorld Wide Web Consortium (W3C)から脱退すると発表した。書簡より。「2013年に、EFFはW3Cがウェブブラウザのエコシステム内でDRMに一級の役割を果たすことを目的としたAPI"暗号メディア拡張"の標準化プロジェクトを実施したことに失望した。そうする事により、団体は特許プール、スタッフ・サポート、道義的権限の利用を、ブラウザがユーザからリモート団体への主要な側面を制御する権限を譲る事ができるように設計されなければならないという考えに基づいて提案した。... 我々はその選択を後悔すると信じている。本日、W3Cは何十億という人々が使用しているブラウザに対して、法的に容認できない攻撃面を後世に残した。ビデオを再利用する障害を持つ人々を訴えたり、脅迫したりする権限をメディア企業に与える。彼らは、時代の公の記録を保存するために争っているアーキビストに対して反対している。W3Cのプロセスは、確立された秩序を揺るがすことによって、富を作り企業によって悪用されている。そして今、EMEのおかげで、彼らは、誰にも同じ革新的な圧力を課すことを確実に行うことができるだろう。

BoingBoingSlashdot

9/19/2017

当初、High SierraでAPFSはフラッシュドライブのみ適用される

Darling Fireballより。Fusion Driveやハードディスクに対するAPFSのサポートはいつになるのか?

Juli CloverがMacRumorsにレポートする:

Fusion Driveを搭載したiMacは、最初のmacOS High Sierraベータでのベータテストプロセス中はAPFSに変換されたが、それ以降のベータ版でサポートが削除され、再実装されていない。

ソフトウェアのゴールデン・マスタ版のリリースで、AppleはAPFSがFusion Driveで利用可能ではない事を確認し、APFSから標準のHFS+フォーマットに変換するための手順を提供している

私は、全てフラッシュドライブのMacBook ProやiMacを持っているが、急いでAPFSに切り替えるつもりはない。また、High Sierraにアップデートする時、更新できるドライブはAPFSに自動的にアップグレードされるため、私はHigh Sierraにアップデートするのを急いでいない。誤解しないで欲しい、私はAPFSを楽しみにしている。これは、私が10.13.1を待つだろう何かを感じるだけだ。

Slashdot

8時間労働制、平均的な労働者が生産的なのは数時間だけ

INCの記事より。労働時間が8時間と決められたのは産業革命時代の事で、本当に生産的な労働時間を考慮しているわけではない。

8時間労働制の勤務時間は、人間が集中できる最適時間に基づいていない。実際、ほとんどの人が今やっている仕事とはほとんど関係がない。その起源は、情報化時代ではなく産業革命時代にある。

18世紀後半、工場は24時間365日稼働する必要があったため、10-16時間労働が普通だった。そのような長い日々が残酷で持続不可能であることが明らかになった時、ウェールズの活動家ロバート・オーウェンのような活動家たちは、より短い労働時間を主張した。1817年、彼のスローガンは、「8時間の労働、8時間の気晴らし、8時間の休息」となった。

しかし、この8時間の動きは、1914年にフォード・モーターが一日の時間を8時間に短縮しながら同時に賃金を倍増させて驚かせた時まで、ほぼ1世紀近く標準にはならなかった。結果は? 生産性が向上した。

従って、一部の人にとっては信じ難いかもしれないが、平均的な労働時間をより人間的にする方法として、8時間の労働時間が最初に制定された。

今や、労働時間は別の破壊の機が熟している。研究者は、8時間労働制で平均的な労働者は2時間53分しか生産性がないことを示唆している。

その通り、あなたはおそらく一日約3時間しか生産的がないのだ。

労働統計局によると、平均的なアメリカ人は毎日8.8時間働いている。しかし、約2000人のフルタイムのオフィスで働く人の調査によると、ほとんど人は仕事中のほとんど時間に働いていないことが明らかになった。

最も一般的な非生産的な活動をリストアップすると:

  1. ニュースウェブサイトの閲覧 - 1時間5分
  2. ソーシャルメディアのチェック - 44分
  3. 同僚との仕事と関係ないことの話し合い - 40分
  4. 新しい職の検索 - 26分
  5. 喫煙時間 - 23分
  6. 配偶者/友人との電話 - 18分
  7. ホットドリンクを作る - 17分
  8. インスタントメッセージを書く - 14分
  9. スナックを食べる - 8分
  10. オフィスで食事 - 7分

これは、フリーランサーや自宅で仕事をする人にとっては特に良いニュースである。あなたがオフィスに行かなくても十分にやっていないと簡単に感じてしまう。けれども、この研究は、あなたが1日3時間だけ生産的であるなら、オフィス内の誰かと8時間も同じ量の生産をしていることを示唆している。

私たちは本当にこの情報を受け入れるかどうかを考えてみてほしい。たとえ、私たちが3時間まで就業時間を削減しなかったとしても、6時間に削減すればどうなるだろうか? 基準が11am-5pmの労働時間だったらどうなるだろうか?

人はもっと休養をとり、集中しやすくなり、より生産的になるだろう。

唯一の疑問は、どの会社が再び勤務時間を本当に破壊させる先頭に立つだろうか?

Hacker News

9/18/2017

Linux財団の代表がオープンソース・サミットのプレゼンでmacOSを使う

Slashdotより。Linuxデスクトップを推奨している本人がねーと言う話。

Slashdotの読者mschafferが伝える:

Linux財団のエグゼクティブ ディレクターJim Zemlinは、2017年は本格的にLinuxデスクトップの年だ!と宣言しているにも関わらず、MacOSを使っているようだ。これはいくつかのYouTubeチャネル、Switched to LinuxThe Lunduke Showで目撃された。ついにはIt's FOSSでも報道された。

実際、デスクトップ用のLinuxの年であれば、Zemlinのような人は単純にスライドのプレゼンテーションを行うことはできない筈だ。実際に、Linuxディストリビューションを仕事に使うのはもちろんだ。

記事によると、Googleのセキュリティ開発者は、"過去4年間で2度、Jim ZemlinはAppleのmacOSを使っているのを確認した。"クラウド/コンテナ技術に対する財団の卓越した努力がデスクトップ上のLinuxを軽視していると述べている。

皮肉なことに、Zemlinは3月、クラウドカンファレンスで、"オープンソースの共通のイノベーションを取り入れない"組織は"失敗するだろう"と語った。

Hacker News

オンライン広告は価値がない?

Slashdotより

turkeydanceがZeroHedgeのネタを共有する:

カテゴリー1の嵐雲は、伝統的に何十年もの間シリコンバレーから生まれる最も儲かる、おそらく唯一採算の取れる部門の一つ、オンライン広告が集めている。2ヶ月前に、望んだ投資利益が得られていないと考えたP&Gは、デジタル広告費を削減したと発表してから間も無く、驚くべき発見をしたと"アドテック(adtech)"に威嚇射撃をした。「我々は成長率の低下は見られなかった。」CFOのJon Moellerは述べた。「私たちが削減した支出はほとんど効果がなかったと言うことは、何を意味しているのだろう...。」

ゴールドマン・サックスが主催した木曜日のGlobal Retailing Conferenceで、レストレーション・ハードウェアの楽しい興味深いCEOゲイリー・フリードマンは、同社のオンライン・マーケティング戦略とオンライン広告支出の大まかな状況について、次のような印象的な逸話を暴露した。フリードマンが明らかにした事は、簡単に言えば次のようなことだ。「私たちのビジネスの98%は、22のワードによってもたらされる事は知っている。だから、待てよ、私たちは3200のワードを買い、ビジネスの98%は22のワードによってもたらされている。22のワードは何だ? そして彼らは言った。それは、レストレーション・ハードウェアというワードとそれを間違って綴る21の方法である。いいかな?」

簡潔に言うと、膨大なオンライン広告費の大部分は無駄で、そこに無いクリックを追い掛けているだけだ...。あとどのくらいで、悪名高いAmazonの収入と利益のために貧窮しているほぼ全ての小売業者やその他のオンライン広告のパワーユーザは、包絡分析に同じように戻して、RHのように彼らは収益のわずか2%に見合うだけの価値を得るのだろうか?

9/17/2017

Dropboxバックボーンネットワークの進化

DropboxがAWSから独自インフラに移行し、その顛末をブログに掲載している1,2,3,4。今回のバックボーン・ネットワークの進化について書かれた内容は、日本の企業がこの手の話をほとんど公にすることはないので、非常に興味深い。

01 slide11
Dropboxのグローバル・バックボーン・ネットワーク技術

前回の投稿で、世界中のユーザのパフォーマンスを向上させるために導入したグローバル・エッジ・ネットワークの概要を示した。私たちは、Magic Pocketの恩恵を実現させるための戦略の一環として、2年間でこのエッジ・ネットワークを構築した。

エッジ・ネットワークと同時に、北米のデータセンターを互いに接続するだけでなう、世界中のエッジノードに接続するグローバルなバックボーン・ネットワークを立ち上げた。このブログでは、最初にどのように私たちがこのバックボーン・ネットワークの構築に取り掛かったかを精査し、それが私たちとユーザのためにもたらしたメリットについて検討する。

Dropboxのバックボーン・ネットワーク

過去3年間、私たちのネットワークはユーザの増大についていくために大幅に進化している。私たちはMagic Pocketに移行する前に、全てのストレージとインフラのニーズに対応するクラウド・テクノロジーを早期に採用していたが、成長を続ける顧客基盤に対応しながら、数百ペタバイトの顧客データを独自のデータセンターに移行する複合効果は、大幅に素早くネットワークを拡大する必要があった。

02 4phmn8akd7ewbds
バックボーン・ネットワークの進化

2015: 新しいテクノロジーの計画と実装の年

2015年初頭には、10倍規模への対応、高い信頼性(99.999%)の提供、ユーザのパフォーマンス向上のためにネットワーク拡張構想を開始した。当社の内部予想では、ユーザの採用が増加し続ける中、ネットワーク・トラフィックの指数関数的な増加が指摘されている。私たちはネットワーク規模を拡大する計画があるので、Quality Of Service (QoS)、Multi-Protocol Label Switch (MPLS)、IPv6のようなテクノロジを導入する検討を開始し、将来の成長をサポートするためのアーキテクチャをオーバーホールした。

ルーティング・アーキテクチャ:
当時、私たちのルーティング・アーキテクチャは、主にInterior Gateway Protocol (IGP)としてOpen Shortest Path First (OSPF)で、Interior Border Gateway Protocol (iBGP)デザインにはルート・リフレクタ(RR)を利用していた。10倍規模と新しいテクノロジ導入の計画があったため、IGPとBGPデザインの両方のルーティング・アーキテクチャを再評価した。

IGPマイグレーション:
OSPFを継続する上で最大の課題の一つは、IPv6を本格展開する際の複雑さだった。元々はIPv4のみをサポートするOSPFv2を使っていた。私たちがアップグレードを計画していたIPv6にはOSPFv3が必要である。OSPFv3の複数アドレスファミリー機能は、全てのベンダーが完全にサポートしておらず、この時点では広く導入されていなかった。これは、v4とv6のサポートのために二つのOSPFを実行する必要があることを意味し、運用上より複雑だった。

私たちは、OSIレイヤ2で動作するプロトコルに依存しないアーキテクチャであるIS-ISに置き換えることを検討し始め、v4やv6を含む全てのアドレスタイプを簡単にサポートできるようになった。更に、IS-ISはLink State Packetsの情報を運ぶためにType Length Value (TLV)を利用する。TLVは、IS-ISを容易に拡張し、異なる種類の情報を運び、将来新しいプロトコルをサポートすることを可能にする。2015年Q2には、バックボーン全体をOSPFからIS-ISにうまく移行できた。

iBGPデザイン:
私たちの初期のiBGPデザインは、単一階層ルート・リフレクタ(RR)モデルに基づいていた。しかし、iBGP RRには限られたパス・ダイバシティを提供すると言う事実などの独特の制限がある。クライアントからの経路を学習した後、RRはピアに1つのベストパスを広告する。これにより、RRピアは全てのプレフィックスに対して1つのパスのみが表示され、いくつかの等しいコストのネクストホップに分散されるのではなく、そのプレフィックスの全てのトラフィックが1つのネクストホップに送信される可能性がある。

その結果、ネットワーク全体でトラフィックの負荷バランスが不均一になる。複数のパスを広告する機能を提供するAdd-Pathを使用して、この問題を軽減しようとした。Add-Pathはその当時、ルーティングベンダが開発している新しい機能だったため、テストした時に複数のバグが発生した。その時点で、私たちは新しいiBGPデザインを考え出し、ルートリフレクタから離れることに決めた。我々は次のようないくつかのデザイン上の選択肢について議論した:

  1. 全てのルータに跨るフルメッシュiBGPデザイン。このシナリオでは、全てのルータが相互にフルメッシュiBGPを持つ。このデザインは、フルメッシュのiBGPと同様に、全てのルータが相互に全ての経路を学習するため、RRで発生するパスダイバシティの欠陥を解決する。これはルータの数が少ない小規模のネットワークではうまくいくが、ネットワークが成長するにつれて、学習されたルータと経路の数が大幅に増加することが分かった。コントール・プレーンで数百万の経路がメモリの問題を引き起こす可能性がある。これはCPUと/またはRIB/FIBメモリに影響を与え、重大な運用上の影響を引き起こす可能性がある。

  2. リージョン内はフルメッシュiBGP、リージョン横断のルートリフレクタ。第2のアプローチは、バックボーン・ネットワークを小さなリージョンに分割し、リージョン内のルータ間はフルメッシュiBGPを持ち、RRがリージョン間の経路を広告するようにする。これにより、フルメッシュiBGPのルータ数は遥かに少なくなるため、経路スケーリングの問題が解決される。しかし、上述したように、RRの限界はこのデザインでも依然として存在し続けるだろう。

私たちは最終的に2つのハイブリッド型アプローチ、リージョン横断の選択的経路を広告するフルメッシュBGPに決定した。現在、全てのルータでフルメッシュiBGPを使用できるが、バックボーン・ネットワークをルーティング・ポリシーの異なる小規模なグループに分けることもできる。トランジット・プロバイダの経路はトラフィックの大半を占めるため、トランジット・プロバイダからの経路を発信元地域に限定した。その他のピアリング経路と内部トラフィックは、全ての地域に広告される。このアプローチは、RRの限界を排除し、フルメッシュiBGPによる経路スケーリングの問題も解決する。

03 skxl9xexnuxhap4
私たちの米国ネットワークのスナップショットがリージョン別に分かれている。更に、ヨーロッパとAPACをそれぞれの地域として扱い、合計を5にさせる

MPLS-TE
2015年初め、MPLS-TEの導入を開始した。顧客の期待に応えるために、私たちのネットワークは障害を処理し、需要の急増に迅速に対応する必要がある。帯域幅の容量と需要の動的変化に適応する課題を処理するため、RSVPでMPLSを実装した。

MPLS RSVP-TEはマニュアルでの介在なしにトラフィックの急激なスパイクに対応して調整するメカニズムを持っている。利用可能な帯域幅が十分にあれば、MPLSはこれらのポイント間にラベルスイッチパス(LSP)を確立することで、送信元と宛先間のネットワーク上の最短パスにたどるだろう。私たちは優先度の異なる複数のLSPを導入した。ユーザトラフィックは常に高い優先度のLSPを利用するのに対し、内部トラフィックは低い優先度のLSPを利用する。

トラフィック需要が増加するにつれて(または、ネットワーク容量が障害のためにダウンした場合)、RSVP-TEはLSPをその要求を処理するのに十分な帯域幅を持つより高いメトリック値の代替パスに移動する。優先度の異なる複数のLSPを導入するため、RSVP-TEはユーザトラフィックを最短経路のままにしておいて、まず以下の図に示すように重要度の低い内部トラフィックを長いパスに移動することから始める。これにより、ネットワークに冗長性を持たせ、ネットワーク資源を効率的に利用して、必要なサービスレベルを確保し、過剰設備を避けることができる。

02 mpls topo
この図は、帯域幅の供給量に応じて、Dropboxバックボーン・ネットワークでLSPが従うパスを示している

Quality of Service
Quality of service (QoS)は、重要なアプリケーションのための高性能なパフォーマンスを保証するための業界標準の一連の規格とメカニズムである。Dropboxのネットワークには、レイテンシに敏感なユーザトラフィックと大量のバットトラフィックが混在している。これには、データ移行やサーバプロビジョニングによるトラフィックが含まれている。2015年には、様々なトラフィックタイプを識別子、それに応じてエンドツーエンドで対応するQuality of Service (QoS)プログラムを開始した。QoSは、ネットワーク帯域幅、レイテンシ、ジッタ、パケット損失を管理するために必要な技術を提供し、輻輳の間に重要なアプリケーションに対してネットワーク資源を保証する。

このプログラムを構築するため、Dropbox内の様々なアプリケーション所有者と協力して、サービスの優先順位に基づいてホストマシン上でサービスをマークした。全てのDropboxトラフィックを4つのカテゴリに分類し、以下に示すようにそれぞれのキューを割り当てた。

  1. Network_Control: 全てのルーティング・プロトコルのhelloあるいはkeepaliveメッセージがこのキューに格納される。これらのパケットが失われると、適切なネットワーク運用が危険に晒されるため、これらのメッセージが最優先される。

  2. Premium: エンドユーザにサービスを提供する全てのトラフィック。プレミアムキュー内のパケットは、Dropboxユーザにとって重要であると見なされ、高い優先順位で処理される。

  3. Default: ユーザに影響を与えないが、内部サービスが相互に通信するための重要なトラフィック。

  4. Best_Effort: 重要ではないトラフィック。これらのパケットは通常、混雑したネットワーク条件下で最初に落とされ、しばらく経ってから再送される。

私たちは一日中、全てのトラフィックタイプをサポートするのに十分な帯域幅がある事を確認するが、意図的ではなく予期しないネットワーク障害から重大サービスを保護したいと考えている。QoSは、プレミアム(ユーザ)トラフィックが他の優先度の低いトラフィックよりも優先させることで可能にしている。

2016: 10倍規模をサポートする履行年

2016年はネットワークを再構築し、将来のスケーラビリティをサポートするための新しいハードウェアを導入した年だった。

ルータのタイプ
Dropboxのバックボーン・ネットワークは3つの異なる役割を持つルータで構成されている。

  1. データセンタールータ(DR)は、データセンターをバックボーン・ネットワークに接続する主要な機能を持つ

  2. 長距離回線の終端ポイントとして機能し、データセンターを持つリージョンのDRの集約デバイスとしてのバックボーン・ルータ(BB)

  3. ピアリングルータ(PR)はDropboxを外部BGPピアに接続してインターネットの接続を提供する主要機能を備えている

Dropboxネットワークは、Dropboxとオープン・インターネットとの間に流れるユーザトラフィックとDropboxデータセンター間を流れるデータセンタートラフィックという2種類のトラフィックがある。古いアーキテクチャでは、一つのネットワーク層があり、両方のトラフィックタイプが同じアーキテクチャを使用しており、同じ一連のデバイスを通過していた。

古いアーキテクチャ

05 sxyh6b3ucp999th
古いバックボーン・アーキテクチャ

最初、3つの役割全てに同じハードウェアデバイスを使用していた。しかし、私たちが大幅に拡大を始めた時、既存のデザインと使用していたプラットフォームが限界に達した。私たちは水平に成長する事で同じ道を歩み続けていたかも知れないが、それは高価で運用上複雑だった。代わりに私たちのアーキテクチャを再検討することを決断した。その結果、新しい2層アーキテクチャに進化した。

2層アーキテクチャ
新しいアーキテクチャでは、各タイプのトラフィックを個別に処理する2つのネットワーク領域を作成した。また、DCと呼ばれる新しい一連のルータを導入して、データセンタを接続した。新しいデータセンタ(DC)層は、それらの間にフルメッシュMPLS (RSVP) LSPを持ち、マルチテラビットの容量を容易に拡張できる高密度の一連のバックボーンルータ上に構築されている。新しいDC層は、データセンターのトラフィックを運ぶが、古いDR層は主にDropboxからインターネットにユーザトラフィックを転送するために利用される。各層は独自のBGP及びMPLS LSPメッシュを備えているが、同じ物理トランスポートネットワークを共有する同じ一連のバックボーン(BB)ルータに接続する。

私たちは、ユーザトラフィックの約2倍のデータセンタートラフィックがあり、両方のトラフィックプロフィールは異なる特性を持つ。データセンターのトラフィックは、相互に通信する内部サービス、またはあるデータセンターから別のデータセンターへのコピーデータで構成される。ユーザトラフィックは常にDRからPoP (point of presence)に運ばれ、プレミアムトラフィックとして扱われる。Dropboxの内部トラフィックを独自の層に外すと、2つのタイプのトラフィックは明確に分離され、各トラフィックタイプに特有のトラフィックプロフィールとネットワークトポロジを構築するのに役立つ。

06 a55shyt19p9f3t8
新しいバックボーン・アーキテクチャ

オプティカル:
驚異的な成長をサポートし、一貫したサービス内容合意を維持するために、私たちはデータセンターをPoPに接続するダークファイバに投資した。ダークファイバを借りて、独自のオプティカルシステムを稼働させることで、オプティカル・トランスポート・ベンダの帯域幅や専用回線容量を購入する場合に比べ、容量を大幅に増やすことができる。これを踏襲するため、私たちは利用可能な最新の途方も無いエッジ・オプティカル・ギアを導入し、迅速かつ簡単に拡大が可能になった。

2017: 将来成長の準備

100Gへの移行
2016年には、数十テラビットのスループット能力をサポートするための規模と密度を備えた最先端のテクノロジーを備えた次世代のバックボーン(BB)ルータの選定を開始した。様々なベンダーの製品を約8ヶ月間しようし、最終的に私たちの要件を満たす最新のテクノロジー製品を利用することを決断した。Dropboxは、商用インフラにこのプラットフォームを初めて選択し導入する一社となった。

バックボーンでの私たちの初期導入は10G回線で行われた。私たちのネットワーク上のトラフィックが増加するにつれて、10Gリンクをさらに追加して容量を増やし、最終的にこれらの10Gリンクを1つのリンクアグリゲーションバンドル(LAG)に結合した。2016年初めには、それぞれ10本以上の10Gリンクを持つ複数のLAGバンドルがあり、回線のプロビジョニング、管理、トラブルシューティングを行う際に複雑さが増してきた。私たちは、10Gの複数回線を100Gに置き換えることで、アーキテクチャを簡素化することに決めた。

私たちのネットワークに新しいBBルータが導入されたことで、複数の10G LAGバンドルから100GにWANリンクを移行することができた。2017年6月までに、私たちは大西洋横断リンクを含む米国とEUのWANリンクを全て100Gに移行した。これにより累積WAN容量は約300%まで増加した。

IPv6
2016年Q4に、私たちはネットワーク全体でIPv6を導入し始めた。私たちの設計目標の一つは、ルーティングとフォワーディングの両方でIPv4とIPv6の間を同等にすることだった。この導入の一環として、v4とv6の両方に対して一貫性のあるルーティングを行うために、マルチトポロジでIS-ISシングルトポロジを選択した。v6トラフィックのフォワーディングには、v4トラフィックをトンネリングするのに使用したものと同じ一連のMPLS TE LSPを使用する予定である。RFC 3906で定義されているようなIGPショートカットを使用することでこれを行うことができる。IGPショートカットの実装では、v6とv4の両方のトラフィックがバックボーン全体で同じMPLS-LSPを使用していた。2017年Q1の終わりまでに、データセンター、バックボーン、エッジでv6を本格展開を完了した。

まとめ

Dropboxは数百ギガビットのトラフィックを管理し、私たちは急速なペースで成長している。それを維持するために、Dropboxネットワークエンジニアリングチームが採用している信念(mantras)の一つは、常に”規模に合わせて構築する(build for scale)”ことである。スケールアップは、ネットワーク容量、ノード、またはデバイスを追加することでは無い。代わりに、私たちはアーキテクチャを定期的に更新しており、今日の規模の10倍規模でネットワークを成長させ、運用する方法を常に考えている。

この考え方は、私たちが常に2〜3年前に計画していることを意味し、私たちは現在稼働しているものの10倍の容量での運用をサポートするツール、自動化、及び監視を全て備えている。同じ原則が、データセンター、バックボーン、またはエッジのいずれであっても、ネットワーク全体に適用される。


  1. https://blogs.dropbox.com/tech/2016/03/magic-pocket-infrastructure/
  2. https://blogs.dropbox.com/tech/2016/05/inside-the-magic-pocket/
  3. https://blogs.dropbox.com/tech/2016/07/pocket-watch/
  4. https://blogs.dropbox.com/tech/2017/06/evolution-of-dropboxs-edge-network/

Hacker News

ウェブサイトのセキュリティポリシーを記述するSecurity.txtの標準案

Slashdotより。これはいい。

匿名の読者が伝える:

ウェブ開発者とセキュリティ研究者であるEd Foudilは、ウェブマスターがドメインルート上でホストでき、サイトのセキュリティ・ポリシーを記述できるsecurity.txtの標準化を求める草案をIETF(Internet Engineering Task Force)に提出した。このファイルは、ウェブサイトが通信し、ウェブと検索エンジンのクローラのためのポリシーを定義するために使用する標準で、robots.txtに似ている。

例えば、セキュリティ研究者がウェブサイトにセキュリティ上の脆弱性を発見した場合、そのサイトのsecurity.txtファイルにアクセスして、会社に連絡して問題を安全に報告する方法についての情報が入手できる。現在のsecurity.txt IETFドラフトによると、ウェブサイトの所有者は次のようなsecurity.txtファイルを作成できる:

#This is a comment
Contact: security@example.com
Contact: +1-201-555-0123
Contact: https://example.com/security
Encryption: https://example.com/pgp-key.tx...
Acknowledgement: https://example.com/acknowledg...
Disclosure: Full

9/15/2017

Apple Watch、セルラー版とGPS版の違いは?

Darling Fireballより。ジョン・グルーバの言う通りなら、MVNOの人もセルラー版を買える(値段の差以上にセルラー版の方がスペックが高い)。

私がたくさん受けた一つの質問は、セルラー対応のWatchでセルラーオプションをアクティベートする必要があるかどうかです。その答えはノーです。それはちょうどiPadのようなものです。あなたはセルラーモデルを購入し、必要な時までアクティベートしないことを選択できます。

UpdateとOpenメッセージを使って経路リークの検出とフィルタリング

BGPのピアリングの関係を推測して経路リークを検出する機能のインターネットドラフト

[draft-ietf-idr-bgp-open-policy]は、BGP OPENケーパビリティとValley-freeピアリング関係1を強制する経路マーキング結果を定義する。このドキュメントでは、経路リークを自動的に検出するため、特定のマーキングを伝搬させるeOTC通過型BGP属性を定義する。目的は、遠方のASがValley-freeピアリングの違反を判断できるようにすることである。

1. 概要

このドキュメントの目的で、BGP経路リークは、BGP経路がトランジット・プロバイダあるいはピアから学習した経路が別のプロバイダのあるいはピアに広報された時に発生する。[RFC7908]を参照。これらは通常、BGP経路フィルタリングが誤って設定されたか、存在しないか、2つのBGPスピーカ間で調整不足のために発生する。

[I-D.ietf-idr-route-leak-detection-mitigation]は、運用者が維持するマーキングに依存する経路リークのマーキングと検知の手法を説明する。残念ながら、ほとんどの場合で経路のリークは間違ってマークするよう誤って設定される可能性もあるだろう。

経路リークを検出するため、インポートフィルタとしてピアのカスタマコーン2内の既知のプレフィックスに依存するホワイトリスト・フィルタリングを使うことが推奨されている。残念ながら、多数の中間トランジット・オペレータは、コミュニティタグ付け無しに、学習経路のソースに注意を払うこと無しに、エクスポートフィルタはACLに過ぎない一つのプレフィックス・リストを使う。そのため、プロバイダあるいはピアから顧客の経路を学習しても、他のプロバイダやピアを含む全ての方向に広報してしまう。この誤って設定が限られた数のプレフィックスに影響を与える。しかし、そのような経路リークは明らかに上位の上流プロバイダによって設定されているカスタマコーンのインポートフィルタをバイパスするだろう。

このドキュメントは、BGPの役割([I-D.ietf-idr-bgp-open-policy])に従って設定された新しいBGPパス属性を介して経路リークを検出するための自動フィルタを作成する方法を規定している。iOTCは経路リーク防止の強力な弁ダコードベースの執行を提供するが、誤って設定された古いBGPの実装の結果として経路リークはまだ存在する可能性がある。経路リークはMITM攻撃やDoSのような悪意を持ったアクティビティの結果でも起こる。この提案の目的は、誤ってあるいは目的があって遠隔ASがValley-freeピアリング規則の違反を判断できるようにすることである。

2. BGP External Only To Customer属性

External Only To Customer (eOTC)属性は、タイプコード<TBD1>の新しいオプション通過型BGPパス属性である。この属性は4バイトで、経路に属性を追加したASのAS番号を含んでいる。

eOTC属性を設定する2つのルールがある:

  1. eOTCが設定されず、送信者の役割がプロバイダあるいはピアなら、eOTC属性は送信者のAS番号に等しい値が追加されなければならない(MUST)

  2. eOTCが設定され、受信者の役割がプロバイダまたはピアである場合、その値はネイバーのAS番号ではないので、到着経路は経路リークで、低いLocal Preferenceを設定しなければならない(MUST)、あるいは経路を落とすかも知れない(MAY)

これらの2つのルールは、ASパス内の遠方のグループによって作成された経路リーク検出のためのメカニズムを提供する。

3. BGPsecとの互換性

BGPsec[I-D.ietf-sidr-bgpsec-protocol]対応ルータの場合、FlagsフィールドにeOTC属性が存在することを示すビットが追加される。eOTCの値は、追加されたSecure_Path SegmentのASフィールドに自動的に格納される。

経路がBGPsec対応ルータから非BGPsecルータに変換される場合、AS_PATH再構成に加えて、eOTC属性に対して、再構成を実行されなければならない(MUST)。Secure_Path Segmentの一つにフラグビットが設定されている場合、eOTC属性は最初に表示されるセグメントのAS番号を追加する必要がある(SHOULD)。


  1. Lixin GaoはAS間のルーティングポリシーを分類するために、Valley-free規則を使う方法を提案した(論文)。Valley-freeはトラフィックの方向によって、provider-customer、peer-peer関係を推測するもので、文字どおり谷の無い経路以外は超えることができず、谷を含めた以下の4つの条件がある経路を通ることが出来ないと言うものである。それぞれASパス内に、
    1. 2個以上のpeer-peer関係のリンクがある
    2. provider-customer関係の後にcustomer-provider関係が存在する
    3. provider-customer関係の後にpeer-peer関係が存在する
    4. peer-peer関係の後にcustomer-provider関係が存在する
    と言う条件に当てはまるルーティングがないものとすると、provider-customer、peer-peerの関係が推測できる
  2. ASネットワークの情報を収集しているCAIDAでは、ASの規模を示す指標として、カスタマコーン(Customer Cone)を用いてASランクと呼ばれるランク付けをしている。カスタマコーンとは、あるASから到達可能な顧客ASの最大数を言う

広告業界団体が、新しいSafariのトラッキング防止機能を非難

Slashdotより。監視資本主義者の言い分。

最大の広告組織は、Appleが新しいバージョンのSafariにクッキーブロッキング技術を統合する計画を、インターネットの現在の経済モデルを妨害(sabotage)すると言う。Marty SwantがAdWeekにレポートする:
Interactive Advertising Bureau (IAB)、アメリカ広告連盟、全米広告主協会、4A社など6つの業界団体は、ユーザのクッキーの設定をAppleがコントロールする標準セットに置き換えるというインターネット・ブラウザのバージョンをリリースするAppleの計画に深く憂慮していると述べている。"Intelligent Tracking Prevention (知的トラッキング防止機能)"と呼ばれるこの機能は、広告理ターゲッティングの24時間制限を設けて、広告主とウェブサイトがインターネット上のユーザを追跡する方法を制限している。今日の午後に公表される予定の公開質問状で、グループは新規格を"不透明で恣意的"であると表現し、この変更がウェブサイト全体に渡る基準に大きく依存する"現代インターネットのインフラ"に影響を及ぼす可能性があると警告した。グループは、この機能は広告をより"一般的でタイムリーさと有用性の低い"ものにすることで、ユーザ体験に損害を与えると言う。

TechCrunch(JP)

AppleがFace IDの認証失敗を説明

Slashdotより。デモの前にクレイグではないスタッフが何度も認証したために、iPhoneは設計通りパスコード認証を要求したというわけだそうだ。簡単に言うと、デモの準備ミスという事。

Appleは火曜日のiPhone Xの発表会で、新しい顔認識機能がステージ上のデモでiPhoneのロック解除ができなかった理由を説明している(1時間35分58秒の印を参照)。レポートより:
Appleは、Face IDの誤作動はスタッフが公開に先立ちデバイスを移動させることで引き起こされたロックアウトメカニズムのせいにした。Appleのソフトウェアチーフは、意図的に用意されていたバックアップ装置に移り、問題を解決した。しかし、障害は広く報告されてしまった。「事前にステージデモのためにデバイスを操作していた人物で、Face IDが自分の顔を認証しようとしていることを認識していなかった。」YahooのDavid Pogueによると、匿名の同社の代表が引用されている。「何度も失敗した後、彼らはクレイグ[フェデレギ]では無かったため、iPhoneはパスコードを要求するように設計されたことをしただけだ。」

Daring Fireball

更新: Face IDは一見すると便利なように見えるが、他の顔認証も含め、強力な顔認証のデータが他の組織に悪用されたらと考えると怖い(WIRED)。生体認証は替えが効かない。

更新2: クレイグはFace IDのデータはデバイスに留まると言う。

Netflixで最も視聴されたスタートレックのエピソード

Business Insiderより

Netflixは190カ国で1億人以上の加入者からのデータを調べ、スタートレックのどのエピソードが最も人気があるのかを調査した。

Netflixには6つ全てのスタートレック・シリーズがあるが、最も視聴されたエピソードは「ボイジャー(VOY)」と「新スタートレック(TNG)」の2つのシリーズのエピソードだけだった。

(略)

  1. 道は星雲の彼方へ (ボイジャー, 7x24)
  2. 浮遊機械都市ボーグ: 前編 (新スタートレック, 3x26)
  3. 浮遊機械都市ボーグ: 後編 (新スタートレック, 4x1)
  4. 生命体8472: 前編 (ボイジャー, 3x26)
  5. 生命体8472: 後編 (ボイジャー, 4x1)
  6. ケスとの別れ (ボイジャー, 4x2)
  7. ボーグ暗黒フロンティア計画 (ボイジャー, 5x15)
  8. 無限の大宇宙 (新スタートレック, 2x16)
  9. ブラックホールからの脱出 (ボイジャー, 1x3)
  10. 空白の一日 (新スタートレック, 4x14)

BoingBoing

9/14/2017

米財務長官は新婚旅行に1時間2万5千ドルの政府専用機を要求した

BoingBoingより

スティーヴン・マヌーチン財務長官と妻のルイーズ・リントンは、今夏初めにスコットランド、フランス、イタリアへの新婚旅行に彼らを乗せるため、1時間25,000ドルの政府専用機を要求した。

夫婦は、この要求が財務省関係者のさらなる検討の結果、不要と判断されたと分かって悲しんだ。私は彼らの旅行を台無しにしていなことを本当に願う。

先月、白人の救世主コンプレックスとマリー・アントワネットとレオナ・ヘルムズリーの最悪の部分を兼ね備えた性格を持つ女優のリントンは夫の5億ドルの財産を持たない人を物笑いの種にして批判された後、彼女はInstagramのアカウントを非公開にした。

599b9d001900002500dd4b99

Equifaxのデータ侵害に関して

シュナイアーのブログより。

先週の木曜日、Equifaxは人口の44%にあたる1億4300万人の米国の顧客に影響を与えるデータ侵害を報告した。非常に深刻なデータ侵害である。ハッカーはフルネーム、社会保障番号、生年月日、住所、運転免許書番号を利用し、まさに情報犯罪者は銀行、クレジットカード会社、保険会社、詐欺に脆弱な他のビジネスに対して、なりすまし犯罪に利用できる。

多くのサイトでは、起こった事に対して自分の身を守る手引きが掲載されている。しかし、このような事が起こらないようにしたいのであれば、あなたの唯一の解決策は政府の規制である(現時点では可能性は低い)。

市場はこれを解決できない。市場は買い手が売り手達の間で選択し、売り手が買い手を得るために競争をする事で動いている。あなたは気付いている思うが一応念のために言うと、あなたはEquifaxの顧客では無い。あなたは商品である。

これは、あなたの個人情報が貴重であり、Equifaxがそれを販売する事で事業を成り立たせているために起こった事だ。同社は信用調査機関では無い。データブローカである。私たち全員に関する情報を収集し、全てを分析し、次にそれらの洞察をして販売している。

その顧客とは情報を購入したい人や組織である。お金を貸したい銀行、アパートを貸すかどうかを決める家主、あなたが有益な顧客かどうかを判断しようとしている企業、政府を含めてあなたに何かを売りたがっている全ての人である。

Equifaxだけでは無い。彼らは最大の一つかも知れないが、2500〜4000の他のデータブローカーがあなたに関する情報を収集、保管、販売をしている。そして、そのほとんどがあなたは聞いた事がなく、ビジネス関係のない企業である。

監視資本主義はインターネットを悪化させており、時には全員があなたをスパイしているように思われる。訪問したほぼ全ての商用ウェブサイトで、あなたは密かに追跡されている。Facebookは人類が作り出した最大の監視組織である。あなたのデータを収集することがそのビジネスモデルである。私は、Facebookのアカウントを持っていないが、Facebookはいまだ私と私の交友関係に驚くほどの完全な記録を保管している。私が参加すること決めた場合に備えて。

私はGmailに私のメールを保存させたくないので、Gmailのアカウントを持っていない。しかし、私の推測では、私と連絡をとる非常に多くの人がアカウントを持っているため、私の電子メールの約半分を何だかんだ持っていると思われる。私はGmailでnewperson@company.comがホストされているかどうか分知る手段が無いため、gmail.comのアドレスに書き込まないことを選択することによって回避することはできない。

そして、私たちを追跡する多くの企業は、私たちの認識と同意なしに秘密裏にそれを行なっている。そして、私たちはオプトアウトする事ができない。時にはそれはEquifaxのような会社であり、私たちには決して答えない。時にはそれはFacebookのような会社であり、実質的にはその規模が大きいため独占的である。そして時には、携帯電話会社である。それらの全てが私たちを追跡する事をは決めて、消費者のプライバシーを提供することによって競争しない。確かに、電子メールアカウントや携帯電話を持たないように教えることはできるが、21世紀のアメリカに住むほとんどの人にとっては現実的な選択肢ではない。

データを収集して販売する企業は、市場シェアを維持するためにデータを安全に保つ必要はない。彼らは商品である私たちに答える必要はないのだ。彼らはセキュリティ上のお金を節約し、データ損失後のたまの悪い報道を乗り切ればいいことを知っている。そう、私たちは犯罪者がデータを入手した時、または私たちの個人情報が一般に公開された時に苦しむ立場にいるが、最終的にはEquifaxは気にするべきだろうか?

はい、今週は同社にとってひどい評判で傷がついた。間も無く、別の企業が大量のデータ侵害を起こし、Equifaxの問題を覚えている企業はほとんどないだろう。昨年、Yahooが2013年に10億ユーザと2014年に更に5億人の個人情報を晒したことを認めたことを覚えている人はいるだろうか?

この市場の失敗は、データセキュリティに固有のものではない。政府が介入するまで、あらゆる産業で安全性とセキュリティを改善することはほとんどない。政府、食品、医薬品、自動車、飛行機、レストラン、職場条件、難燃性のパジャマを考えて見て欲しい。

このような市場の失敗は、政府の介入によってのみ解決する事ができる。私たちのデータを保存する企業のセキュリティ実践を規制し、規制に従わなかった企業に罰則を科す事で、政府はセキュリティが安価な代替手段になるほど、セキュリティのコストを上げる事ができる。彼らは、個人データが晒されている事を損害として引き合いに出して、うまく訴訟を起こす能力を個人に与えることによって、同じことを行う事ができる。

何としてでも、Equifaxのデータ侵害の結果としての個人情報の盗難から自身の身を守るために推奨される手順を実行してほしい。しかし、これらの手順はマージンに対してのみ有効であり、ほとんどのデータセキュリティはあなたの管理を離れている事を認識して欲しい。おそらく、連邦取引委員会が関与するだろうが、不公正かつ欺瞞的な取引き慣行の証拠がなければ何もできない。多分、集団訴訟が起きるだろうが、あなたが被った多くのデータ侵害と特定の損害との間の線引きは難しいため、裁判所はあなたに味方しそうに無い。

あなたは、Equifaxがあなたのデータをどんなにいい加減に扱ったか気に入らなくても、Equifaxを非難しても無駄である。政府を非難して欲しい。

このエッセイはCNN.comに既に掲載された

追記: この侵害の早い時間に、私はラジオのインタビューを受けたが、私はこの事の影響を過小評価していた。私は侵害の完全な範囲を知らなかったし、終わるとも知れづ続く侵害の中でまさに別のものだと考えた。私は、なぜ報道機関がこれを話題にするのだろうかと思っていたが、どのラジオ番組が私にインタビューしたのか覚えていない。私は、それがオンエアされない事を希望している。

9/13/2017

唯一の安全なメールはテキストのみのメール

Slashdotより

ダートマス大学のコンピュータサイエンスの准教授Sergey Bratus氏とポスドク研究アソシエートAnna Shubina氏が伝える:
現実の問題は、今日のウェブベースの電子メールシステムは、ますますオンライン体験を敏感でインタラクティブなものにクリックで関与するために要求や誘惑で満たされている電子地雷原である。Gmail、Yahooのメールなどのサービスだけではない。Outlookのようなデスクトップコンピュータのメールプログラムも同じ安全ではない方法でメッセージを表示する。端的に言えば、安全な電子メールは、プレーンテキストの電子メールである。埋め込まれたリンクや画像が無く、到着時と全く同じ内容のメッセージしか表示されない。ウェブメールは、広告主にとって便利であるが(画像や素敵なフォントを使って見栄えの良いメールを書くことができる)、ウェブページ(または電子メール)は簡単に一つの事を表示できるが、他の事も行うことができるので、それは不必要で重大な危険を伴う。電子メールを元のプレーンテキストに戻すことは急進的に思えるかも知れないが、根本的に優れたセキュリティを提供する。連邦政府のトップのサイバーセキュリティ専門家でさえ、ウェブセキュリティについて真剣な人物、組織、政府はプレーンテキストの電子メールに戻るべきだ(PDF)という驚くべき重要な結論に達した。

9/12/2017

iPhone用ハードウェア・プライバシー・モニター

シュナイアーのブログより。

アンドリュー・バニー・ファンとエドワード・スノーデンは、iPhoneに接続して携帯電話のオペレーティングシステムがセキュリティ侵害された場合でも、悪意のある監視活動をモニターするハードウェア・デバイスを設計している。彼らはそれをイントロスペクション・エンジンと呼んでおり、ユースモデルは政府の監視に関して懸念を持つジャーナリストである。

我々のイントロスペクション・エンジンは、以下の目標を念頭に置いて設計されている:

  1. 完全にオープンソースであり、ユーザが検査可能(あなたは私たちを信用する必要はない)

  2. イントロスペクション操作は、電話のCPUから完全に分離された実行領域で実行される(状態を公正に判断するための判断が損なわれているものに依存しない)

  3. イントロスペクション・システムの適切な操作はフィールド検査ができる("evil maid"攻撃やハードウェア障害に対する保護)

  4. 誤検出を引き起こすのが難しい(ポジティブが多すぎると、ユーザはセキュリティ警告を無視または無効にする)

  5. 署名入りのファームウェアの更新であっても、誤検出を誘発するのが難しい("システム鞭打を信頼しない" -- システムベンダの全面的協力を受けている国家レベルの敵は、イントロスペクション・エンジンを偽装するか、バイパスする、署名されたファームウェアの更新を作成できないはずだ)

  6. 可能な限り、インストロスペクション・システムはパッシブで、携帯電話のオペレーティング・システムで検出するのが難しい筈だ(イントロスペクション・エンジンのシグネチャに基づいてユーザのブラックリスト/ターゲッティングを防止する)

  7. 解釈や操作に特別な知識を必要としないシンプルで直感的なユーザインタフェース(検出漏れにつながるユーザエラーを回避する; "ジャーナリストは安全であるために暗号技術者になる必要はない)

  8. ワークフローへの影響を最小限に抑えて、最終的なソリューションを日常的に使用できるようにする必要がある(個人セキュリティと効果的なジャーナリストとの間の選択を現場記者に強いることを避ける)

これは素晴らしい仕事のように見え、彼らは動くプロトタイプを持っている。

もちろん、これは携帯電話で起こる全ての正当な監視(場所の追跡、話した相手の記録など)を止めるものではない。

BoingBoingの投稿

Hacker News

9/11/2017

ビットコインの学術的歴史

acmqueueにビットコインの学術的歴史という記事が掲載されている。

暗号通貨の概念は、研究文献の中の忘れられたアイデアから構築された。

Arvind Narayanan、Jeremy Clark

あなたが報道でビットコインに関する記事を読み、暗号分野の学術研究にある程度精通しているなら、次のような印象を受けるかも知れない。David Chaum10,12から始まった電子マネーに関する数十年に渡る研究は、中央集権型のシステムをコントロールする銀行ライクなサーバを必要とし、銀行も加入を望まなかったため、商業的な成功をもたらさなかった。やがて、銀行を必要としない分散型暗号通貨の根本的に異なる提案であるビットコインが登場し、電子マネーは成功した。その発明者である謎のサトシ・ナカモトはアカデミック・アウトサイダーで、ビットコインはこれまでの学術的提案と全く似ていない。

この記事は、ビットコインの技術要素のほとんどが1980年代と1990年代の学術的文献(図1参照)に由来していることを示すことで、その見方に異議を唱えている。これはナカモトの業績を軽んじることでは無く、彼が巨人の肩に乗っていた事を指摘する事である。確かに、ビットコインのアイデアの起源を辿る事で、ナカモトの真の洞察の飛躍、基本的な要素を組み立てた明確で複雑な方法に焦点を絞る事ができる。これは、ビットコインが発明されるのに長く掛かった理由を説明するのにも役立つ。ビットコインの仕組みをよく知る読者は、この史実の説明からより深い理解を得られるかも知れない。(序論のために、Arvind Narayananらによるビットコインと暗号通貨の技術36を参照) ビットコインの思想史は、学会、専門外の研究者、専門職従事者の間の関係性を実証するケーススタディとして役立ち、これらのグループが互いにどのように恩恵を受けられるのかについての教訓を提供する。

Narayanan1

台帳

安全な台帳があれば、デジタル決済システムにそれを活用するプロセスは単純である。例えば、アリスがPayPalでボブに100ドル送金したら、PayPalはアリスの口座から100ドルを引き落とし、100ドルをボブの口座に振り込む。銀行間で共有される単一の台帳がない事は物事を複雑にするが、これが概ね伝統的な銀行業務で起こる事である。

台帳のこの考え方が、ビットコインを理解する出発点である。システム内で発生する全てのトランザクション(取引き)を記録する場所であり、オープンであり、全てのシステムの関係者に信頼されている。ビットコインは、この支払い記録システムを通貨に転換する。一方、銀行業務では、勘定残高は銀行から要求される現金を表すが、ビットコインの単位は何を表すのだろうか? 今のところ、取引されているものは本質的に価値があると仮定する。

関係者がお互いに信用できないインターネットのような環境の中で使うための台帳をどのように作る事ができるか? データ構造の選択という簡単なところから始めよう。いくつかの求められる特性がある。台帳は変更不可能、さもなければ正確で追加のみであるべきだ。新しいトランザクションは追加できるが、削除、変更、あるいは既存のトランザクションを再オーダーできないようにすべきである。いつでも、台帳の状態の簡潔な暗号ダイジェストを取得できる方法を持つべきある。ダイジェストは台帳全体の保管を避ける事ができる短い文字列で、台帳が改ざんされた場合、結果ダイジェストが変わり、改ざんが検知される事が分かっている。これらの特性の理由は、一つのマシンに格納された通常のデータ構造とは異なり、台帳は相互に信頼できない関係者によって共同で管理されているグローバルなデータ構造である。これは、多くの関係者がローカル台帳を管理する分散型デジタル台帳7,13,21へのもう一つのアプローチとは対照的で、競合を解決するためにこの一連の台帳を照会するユーザ次第である。

連結されたタイムスタンプ

ビットコインの台帳のデータ構造は、1990年から1997年の間にStuart HaberとScott Stornettaによって書かれた一連の論文(彼らの1991年の論文にはもう一人の共著者Dave Bayerがいた)から最小限の変更で借用されている5,22,23。ナカモトがビットコインのホワイトペーパーでそう述べていたため34、私たちはこれを知っている。HaberとStornettaの仕事は、ドキュメントタイムスタンプの問題を解決した。彼らはデジタル公証人サービスを構築することを目指していた。特許、ビジネス契約書、その他の文書にとって、ある時点までに文書が作成されたことを立証したい場合がある。文書の概念は非常に一般的で、どんな種類のデータでも可能である。なお、彼らは金融取引を潜在的な応用として言及しているが、フォーカスしていたわけではなかった。

HaberとStornettaの提案の簡略化されたバージョンでは、文書は絶えず作成され、ブロードキャストされる。各文書の作成者は作成時間を表明し、文書、タイムスタンプ、前にブロードキャストした文書に署名する。以前の文書は、前に使われていた物に署名していたので、文書はやがて後方へのポインタを持った長いチェーンを形成する。外部のユーザは作成者が署名したためタイムスタンプ付きのメッセージを変更できないし、作成者もまた後続のメッセージのチェーン全体を変更せずにメッセージを変更できない。従って、あなたは信頼できるソース(例えば、別のユーザまたは特別なタイムスタンプサービス)によってチェーン内の一つのアイテムを与えられたら、そのポイントまでのチェーン全体がロックされ、不変となり、一時的にまとめられる。更に、作成時間が誤った文書をシステムが拒絶したと仮定するなら、文書は少なくともそれらが主張するのと同じくらい古いと合理的に保証される。いずれにしても、ビットコインはHaberとStornettaの仕事からデータ構造だけを借用し、この記事の後半で説明するプルーフ・オブ・ワークのスキームを追加してセキュリティ特性を再設計した。

彼らの補足論文で、HaberとStornettaはこのデータ構造をより効果的かつ効率的にするためのアイデアを紹介した(その一部は、最初の論文で示唆されていた)。まず、署名の代わりにハッシュを使用して文書間のリンクを作成できる。ハッシュは計算が簡単で高速である。このようなリンクはハッシュポインタと呼ばれる。第二に、文書を個別にスレッド化する代わりに、多数の文書がほぼ同時に作成されると非効率かも知れない、それらはバッチあるいはブロックにグループ化できる。各ブロックの文書は基本的には同じタイムスタンプを持つ。第三に、各ブロック内で、マークル木と呼ばれるハッシュポインタのバイナリツリーと結び付ける事ができる。つまりは、Josh BenalohとMichael de Mareは、HaberとStornettaの最初の論文の後すぐの1991年にこれらの3つのアイデアを独自に導入した6

マークル木

ビットコインは基本的にHaberとStornettaの1991と1997年の論文のデータ構造を使っており、図2(ナカモトはおそらくBenalohとde Mareの仕事に気付いていなかった)の単純化した形式で見られる。もちろんビットコインでは、トランザクションは文書の代わりになる。各ブロックのマークル木の中で、リーフノードはトランザクションで、各内部ノードは基本的に2つのポイントで成り立っている。このデータ構造は2つの重要な特性を持つ。第一に、最後のブロックのハッシュはダイジェストとしての働きをする。トランザクション(リーフノード)の如何なる変更も、ブロックのルートと全ての配下のブロックのルートまで伝わる変更を必要とする。従って、最新のハッシュが分かっていれば、信頼できないソースから台帳の残りをダウンロードして、変更されていないかを検証できる。同様の議論がもう一つの重要なデータ構造の特性を確立する。すなわち、特定のトランザクションが台帳に含まれていることを効率的に立証できる。このユーザはそのトランザクションのブロック(これはマークル木の先端である)の中の少数のノードだけをあなたに送る必要がある。同様に後続のブロックごとに少量の情報を送信する必要がある。トランザクションが含まれている事を効率的に立証できる能力は、パフォーマンスとスケーラビリティにとって非常に望ましい。

Narayanan2

ところで、マークル木は1980年の論文の中でアイデアを提案した非対称暗号のパイオニア、ラルフ・マークルに由来する33。彼が意図した利用法は、デジタル証明書の公開登録簿のダイジェストを生成する事だった。例えば、ウェブサイトで証明書が提示された場合、その証明書がグローバルな登録簿内に載っていることを示す短い証明を提示できる。あなたが登録簿内に証明書のマークル木のルートハッシュを知ってさえいれば、証明を効率的に検証できる。このアイデアは古くからの暗号標準だが、その力は最近になって認められてきた。最近導入されましたCertificate Transparencyシステムの中核にもある30。2015年の論文で、エンドツーエンドの暗号メールのための公開鍵のディレクトリにそのアイデアを適用するCONIKSが提案されている32。グローバル状態の一部の効率的な検証は、新しい暗号通貨Ethereumの台帳が提供する重要な機能の一つである。 ビットコインは、HaberとStornettaのデータ構造の最もよく知られた実世界のインスタンス化かも知れないが、これが初めてではない。少なくとも二つの企業、90年代半ばに始まったSurety、2007年に始まったGuardtimeが文書のタイムスタンプ・サービスを提供している。興味深い意外な展開がこれらのサービスにあるのは、Bayer、Haber、Stornettaが指摘するアイデアであり5、広告を除外した新聞に定期的にマークル木を発表したことである。図3はGuardtimeによって発表されたマークル木を示している。

Narayanan3

ビザンチン将軍問題

もちろん、中央権限のないインターネット通貨の要件はより厳しいものがある。分散台帳には必然的に分岐がある。つまり、ブロックAが最新のブロックと考えるノードもあれば、ブロックBと考える他のノードがある。これは、台帳の操作を妨害しようとしている敵対者や、ネットワークの待ち時間のために起こることがある。その結果、異なるノードがお互いのブロックを認識していないために時にはほぼ同時にブロックが生成される。Mike Justが1998年に示したように、連結されたタイムスタンプだけでは分岐を解決するには十分ではない26

異なる研究分野、耐障害性(フォールトトレラント)分散コンピューティングはこの問題を研究している。ここでは、状態の複製を含む様々な名前で通っている。この問題の解決策は、一連のノードが同じ順序で同じ状態遷移を適用することで、通常は正確な順序は問題ではない、全てのノードは一貫性がある。電子マネーでは、複製される状態は一連の残高であり、トランザクションは状態遷移である。チューリング賞を受賞したLeslie Lamportが1989年に提案したPaxosを含む初期の解決策は28,29、通信チャンネルが信頼できない場合や、少数のノードが永久にオフラインになるとか、再起動して障害メッセージを送ってオフラインになるような実際の障害を示す場合に状態の複製を考える。豊富な文献は、より不利な設定や効率の妥協が行われた。

関連した研究では、ネットワークの信頼性が非常に高い(メッセージは制限時間のある遅延で配信される)が、プロトコルからのずれを処理するため、”障害(fault)”の定義が拡張された。このようなビザンチン障害は、自然に発生する障害だけでなく、悪意を持って作られた挙動も含まれる。彼らは最初、1982年にRobert Shostak、Marshall Peaseと共著したLamportによる論文でも研究された27。その後、1999年にMiguel CastroとBarbara Liskovの画期的な論文が、ビザンチン障害と信頼できないネットワークの両方に対応したPBFT (実用的なビザンチン耐障害性)を発表した8。連結されたタイムスタンプと比較して、耐障害性に関する文献は膨大であり、Paxos、PBFT、その他の将来性があるプロトコルの数百のバリエーションと最適化が含まれている。

ナカモトのオリジナルのホワイトペーパで、彼はこの文献を引用しておらず、その言葉も使っていない。彼は、合意のメカニズムとして彼のプロトコルを参照し、攻撃者の形で、ネットワークに参加・離脱するノードの両方の障害を考慮して、いくつかの概念を利用している。これは連結されたタイムスタンプ(および、次に考察するプルーフ・オブ・ワーク)における文献への明白な信頼とは対照的である。ビットコインとビザンチン将軍問題(解決するにはBFTの思考実験が必要)との関係に関してメーリング・リストの議論で聞かれると、ナカモトはプルーフ・オブ・ワークのチェーンがこの問題を解決すると断言していた35

その後、他の学者が分散システムの観点からナカモト合意を研究してきた。これはまだ進行中の作業である。一部の人はビットコインの特性は非常に弱いと指摘するが43、他の人たちはBFTの観点でビットコインの整合性特性を公正に評価していないと主張する40。別のアプローチは、よく研究された特性の変形を定義し、ビットコインがそれらを満たすことを証明することである19。最近、これらの定義は、メッセージ配信に関するより現実的な仮定の下で保持するより標準的な一貫性の定義を提供するために大幅に向上された37。しかし、この仕事のすべては一部の参加者間の公正な行動(例えば、プロトコル準拠)についての仮定を作るのに対し、ナカモトは公正な行動にインセンティブがあるため盲目的に仮定する必要はないと示唆している。インセンティブの役割を説明するナカモト合意の豊富な分析は、耐障害システムの過去のモデルに簡単に適合しない。

プルーフ・オブ・ワーク

ほぼすべての耐障害システムはシステム内のノードの厳密な多数決または圧倒的多数(例えば、過半数または2分の3)が、公正で信頼できると仮定する。オープンなピア・ツー・ピア・ネットワークでは、ノードの登録はなく、自由に参加したり離脱することができる。従って、敵対者はシステムの合意保証を乗り越えるためには、十分なシビルあるいはソックパペット(自作自演)ノードを作成できる。シビル攻撃は、2002年にJohn Douceurによって形式化され14、彼はそれを軽減するためにプルーフ・オブ・ワークと呼ばれる暗号構造に目を向けた。

起源

プルーフ・オブ・ワークを理解するために、その起源を調べてみよう。今日プルーフ・オブ・ワークと呼ばれる最初の提案は、1992年にCynthia DworkとMoni Naorによって作成された15。彼らの目標はスパムを防ぐことだった。ここで留意すべきは、スパム、シビル攻撃、サービス拒否攻撃は全て類似した問題であり、敵対者は正規のユーザと比較してネットワークの影響を増幅する。プルーフ・オブ・ワークは、3つ全てに対する防御として適用できる。DworkとNaorの設計では、電子メールの受信者は、送信者が適度な量の計算作業を実行したという証拠を伴う電子メールのみを処理することになる。故に、仕事の証明となる。おそらく証明を計算することは、通常のコンピュータでは数秒掛かる。従って、普通のユーザにとっては問題をもたらさないが、100万通のメールを送信したいスパマーは、同等のハードウェアを使用しても数週間必要だろう。

ここで留意すべきことは、プルーフ・オブ・ワークのインスタンス(パズルとも呼ばれる)は、電子メールだけでなく送信者にも固有のものでなければならない事だ。そしないと、スパマーは同じ受信者(あるいは複数の受信者に同じメッセージ)に複数のメッセージを送ることができ、1人の受信者に対して1つのメッセージのコストが発生する。2番目の重要な特性は、受信者に最小限の計算負担を課すべきであるという事で、パズル解決は計算がどれほど難しいかに関わらず、検証はわずかにすべきである。更に、DworkとNaorは、権力者が仕事をしなくてもパズルを解決できるよう中央権威に知られている秘密であるトラップドアを受けた機能を考慮した。トラップドアの可能性のあるアプリケーションの一つは、コストを負担することなくメーリングリストへの投稿を承認する権限である。DworkとNaorの提案は、その特質を満たす3つの候補パズルから成り立っており、それは我々が報いる全く新しい研究分野が幕を開けた。

Hashcash

Hashcashという非常によく似たアイデアが、1997年にサイファーパンク・グループの一員だったポスドクの研究者Adam Backによって独自に発明された。サイファーパンクは、政府と中央機関の権力に反対する活動家達で、暗号を通じて社会的、政治的変化を求めた。Backは実際に自分の立場を明らかにしていた。彼は、ソフトウェアとしてHashcashを最初にリリースし2、5年後の2002年にインターネット・ドラフト(標準化文書)と論文を公表した4

Hashcashは、DworkとNaorのアイデアよりもはるかに簡単である。トラップドアや中央権限がなく、デジタル署名の代わりにハッシュ関数のみを利用する。これは単純な原理に基づいている。ハッシュ関数は実用目的ではランダム関数として動作する。つまり、特定の出力に対してハッシュする入力を見付ける唯一の方法は、目的の出力が得られるまで様々な入力を試すしかない。更に、任意の一連の出力をハッシュする入力を見付ける唯一の方法は、再度異なる入力を一つずつハッシュを試す事である。そのため、バイナリハッシュ値が10個のゼロで始まる入力を見付けることに挑戦する場合、多くの入力を試さなければならず、各出力に10個のゼロで始まるのは1/210の確率であることが分かる。210個の入力、つまり約1000個のハッシュ計算を試す必要がある。

名前が示唆するように、Hashcashでは現金の形としてプルーフ・オブ・ワークを見なしていた。彼のウェブページでは、David ChaumのDigiCashに代わり、銀行からユーザに追跡できない電子マネーを発行するシステムだった3。彼はテクニカル設計をより現金に近く見えるようにするため妥協した。後で、BackはビットコインがHashcashの単純な拡張であったことを示唆するコメントをした。しかし、Hashcashは二重支払いに対する保護が無いため、単純に現金にはならない。Hashcashトークンは、ピア間で交換することはできない。

その間、研究はサービス拒否攻撃の防止25、ウェブ解析の完全性の保証17、オンラインでのパスワードの推測など38、スパム以外にプルーフ・オブ・ワークのアプリケーションを多く発見した。ちなみに、プルーフ・オブ・ワークという用語は、Markus JakobssonとAri Juelsの1999年の論文の中で作られ、この論文の中には、その時点までの素晴らしい研究の調査も含まれている24。これらの研究者はHashcashを認識していないように見えるが、Eran Gabberらや18、JuelsとBrainardの論文で紹介されたハッシュベースのプルーフ・オブ・ワークに独立して収斂し始めたことは注目に値する25。(この段落のあらゆる場所で使用される用語の多くは、問題の論文が公表されるまで標準用語にはならなかった。)

プルーフ・オブ・ワークと電子マネー: 落とし穴(Catch-22)

スパム対策として、オリジナルのアプリケーションではプルーフ・オブ・ワークが成功しなかったことが分かるだろう。考えられる原因の一つは、様々なデバイスのパズル解決速度の劇的な違いである。これは、スパム送信者がカスタムハードウェアにわずかな投資を行い、迷惑メールの速度を1桁高めることができることを意味する。経済学では、生産コストの非対称性への自然な対応は交換(トレード)である。つまり、プルーフ・オブ・ワークのソリューションの市場である。しかし、これは機能している電子マネーを必要とするため、落とし穴(catch-22)を提起する。確かに、そのような通貨の欠如は、そもそもプルーフ・オブ・ワークのモチベーションの主要部分である。この問題の解決法の一つは、Hashcashが試みるように、現金になるようなパズルの解決策を宣言することである。

パズルの解決策を現金として扱うためのより首尾一貫したアプローチは、ビットコインに先行する2つの小論文に見られ、それぞれb-money13やbit gold42と呼ばれるアイデアを説明している。これらの提案は(プルーフ・オブ・ワークを通じて)通貨の作成を認めるタイムスタンプサービスを提供し、資金が作られると、彼らは移転を有効にする。しかし、サーバやノード間で台帳の不一致が発生した場合、それを解決する明確な方法がない。仮に過半数の決定を著者の両方の書いたものに潜在しているように見えるとするが、シビル問題のために、ネットワークへの侵入をコントロールするゲートキーパがない、あるいはシビル・レジスタンスが自身でプルーフ・オブ・ワークを達成されない限り、これらのメカニズムは全く安全ではない。

全てを理解する

ビットコインの設計を含むこれらすべての先行技術を理解する事は、ナカモトのイノベーションの真の天才さの評価につながる。初め、ビットコインでは、パズル解決策がそれ自体で現金を構成しない。代わりに、単に台帳を安全にするために使われる。プルーフ・オブ・ワークを解決する事は、マイナー(採掘者)と呼ばれる特殊な存在によって実行される(ナカモトは特殊化したマイニング(採掘)がどのようになるかを全く過小評価していたが)。

マイナーは常に次のパズルの解決策を見付けるために互いに競争している。各マイナーはパズルのわずかに異なる変形を解決するので、成功のチャンスはマイナーがコントロールするグローバルなマイニング力にわずかに比例する。パズルを解決するマイナーは、連結されたタイムスタンプに基づいて、トランザクションの次のバッチまたはブロックを台帳に貢献するようになる。台帳を保守するサービスと引き換えに、ブロックに交換したマイナーは新たに発行された通貨単位で見返りがある。高い可能性で、マイナーは無効なトランザクションあるいはブロックに貢献した場合、それは次のブロックを提供する他のマイナーの大多数によって拒絶され、不良ブロックのブロック報酬も無効になるだろう。このようにして、金銭的インセンティブのために、マイナーは互いのプロトコルの遵守を保証する。

ビットコインは、価値を持つパズル解決策自体を避けるため、現金でのプルーフ・オブ・ワークのスキームに悩まされている二重支払い問題をきちんと回避する。実際には、パズル解決策は経済的価値からはるかに分離させている。ブロックを生成するのに必要な作業量は浮動パラメータ(グローバルなマイニング出力に比例する)であり、更にブロック毎に発行されるビットコインの数も固定されていない。ブロック報酬(どのように新しいビットコインが作り出す)は、4年毎に半減するよう設定されている(2017年には、報酬は12.5ビットコイン/ブロックで、50ビットコイン/ブロックからダウンしている)。ビットコインには、追加の報酬金スキーム、すなわちトランザクションをそのブロックに含めるサービスのためのマイナーに支払うトランザクションの送信者が組み込まれている。マーケットがトランザクション手数料とマイナーの報酬を決定する想定されている。

ナカモトの天賦の才は、ビットコインの個々の要素のいずれかでなく、むしろシステムに生命を吹き込むために組み合わせる複雑な方法だった。タイムスタンプとビザンチン合意の研究者は、ノードにモチベーションを与えるというアイデアを思い付かなかった。また、2005年までに、身元をなくすためにプルーフ・オブ・ワークを使用する事もなかった。逆に、hashcash、b-money、bit goldの作者は、二重支払いを防ぐ合意アルゴリズムのアイデアを組み入れなかった。ビットコインでは、安全な台帳が二重支払いを防止し、通貨が価値を持つことを保証するために必要である。マイナーに報酬を与えるには貴重な通貨が必要である。同様に、帳簿を安全にするためにはマイニング力の強さが必要である。これが無ければ、敵対者はグローバルなマイニング力の50%以上を集めて、ネットワークの残りの部分より高速にブロックを生成し、倍速トランザクションで、効果的に取引履歴を書き換えてシステムを制圧できる。従って、ビットコインは自力で立ち上がり、これら3つの要素の間に循環依存がある。ナカモトの挑戦は設計だけでなく、ピザの価格が10,000ビットコインで、ネットワークのマイニング力が今日の1兆分の1に満たなかった頃は、ユーザとマイナーの初期のコミュニティが未知のものに一緒に飛び込むことを納得させる事だった。

アイデンティティとしての公開鍵

この記事は、安全な台帳が電子マネーを簡単に作成することを理解することから始まっている。この主張をもう一度見直してみよう。アリスがボブに支払いを望む時、彼女は全てのビットコインノードにトランザクションをブロードキャストする。トランザクションは単なる文字列である。つまり、アリスがボブに何らかの価値の支払いを符号化した取引明細書である。最終的には、この署名された取引明細書がマイナーによって台帳に組み込まれる事で、トランザクションが実際に行われる。ここで注意する事は、ボブの参加を必要としない事である。しかし、トランザクションにないものに焦点を当てよう。明らかに、アリスとボブの身元が欠けている。代わりに、トランザクションにはそれぞれの公開鍵のみが含まれている。これはビットコインの重要なコンセプトである。公開鍵は、システム内の唯一の身元である。トランザクションは、アドレスと呼ばれる公開鍵との間で価値を転送する。

身元を”要求する”ためには、あなたは対応する秘密鍵を知らなければならない。中央の権限や登録簿を持たずに、新しい鍵ペアを生成する事で、いつでも新しい身元を作成できる。ユーザ名を取得したり、特定の名前を選択した事を他の人に知らせる必要はない。これは、分散されたID管理のコンセプトである。ビットコインは、アリスがボブに彼女の仮名(システムに外付けである)が何であるかを規定しない。

今日の他の支払いシステムとは根本的に異なるが、これらのアイデアはかなり古く、電子マネーの父であるDavid Chaumにまで遡る。実際に、Chaumは匿名ネットワークにも独創性に富んだ貢献をしており、このコンテキストで彼はこのアイデアを発明した。「追跡できない電子メール、返信アドレスとデジタル仮名」9という彼の1981年の論文の中で、彼は「デジタル仮名は、対応する公開鍵の匿名保持者によって行われた署名を検証するために使用される公開鍵である。」と述べている。

今では、メッセージの受信者を公開鍵でしか知ることができないという明らかな問題が存在する。メッセージを正しいコンピュータにルーティングする方法はない。これはChaumの提案では巨大な非効率性に繋がり、匿名のレベルに対してトレードオフとされるが、排除する事はできない。ビットコインは、中央集権型の支払いシステムと比較して同様に非常に非効率的である。すべてのトランザクションを含む台帳は、システム内のすべてのノードによって維持される。ビットコインは、セキュリティ上の理由から、この非効率性を招き、従って匿名性(すなわち、公開鍵を身元とする)を無料で実現する。Chaumは、1985年の論文11でこれらのアイデアをさらに引き継ぐ、広く普及している仮名に基づくプライバシ保護Eコマースのビジョンと、電子マネーの背後にある重要な技術的アイデアである”ブラインド署名”を提示した。

身元としての公開鍵というアイデアは、先に議論したビットコインへの2つ先駆けた小論文b-moneyとbit goldにも見られる。しかし、Chaumの基礎で築いた仕事の多くは、Chaum自身の後のecashに関する仕事と同様に、このアイデアから離れた。サイファーパンクは、プライバシー保護の通信と商取引に熱心な関心を示し、彼らはnymsと呼ばれる仮名を採用した。しかし、彼らにはnymsは単なる暗号の身元(すなわち公開鍵)ではなく、むしろ通常は公開鍵に連結された電子メールアドレスだった。同様に、匿名の通信に関する多くの将来の研究の基礎となったIan Goldbergの論文は、Chaumのアイデアを認識しているが、nymsは人間にとって記憶に残るニックネームであり、それらに結び付けられた証明書が必要である事を示唆している20。従って、ビットコインはChaumのアイデアの最も成功したインスタンス化(実体化)である事が判明した。

ブロックチェーン

これまでのところ、この記事は、誇大広告を信じるならば、ビットコインの主発明であるブロックチェーンに触れていない。ナカモトがこの用語に全く言及していない事はあなたには驚きかも知れない。実際、ブロックチェーンという用語には標準的な技術的定義はないが、ビットコインとその台帳に様々なレベルの類似性を有するシステムを参照するために様々な関係者によって使用される緩やかな傘である。

ブロックチェーンの恩恵を受けているアプリケーション例を議論する事で、用語の様々な使い方を明確にするのに役立つ。まず、銀行のコンソーシアム間でのトランザクションのデータベース・バックエンドを考えてみる。トランザクションは毎日終了し、中央銀行で決済される。そのようなシステムは、少数のよく特定された関係者を持つため、ナカモト合意は過剰なものとなる。口座は従来の通貨建てであるため、オン・ブロックチェーン通貨はどちらか一方は必要ない。一方、連結されたタイムスタンプは、ネットワーク遅延に対してトランザクションの一貫性のあるグローバルな順序付けを少なくともある程度は安全にする事は明らかに有用である。状態の複製も有用である。銀行はデータのローカルコピーが中央銀行が決済に使用するものと同一であることを知っている。これにより、銀行は現在実行しなければならない高価な調停プロセスから自由になる。

次に、金融証券、不動産、またはその他の資産の所有権を追跡する文書の登録簿などの資産管理アプリケーションを検討する。ブロックチェーンを使用する事は相互運用性が強まり、参入障壁が低くなる。私たちは安全でグローバルな文書の登録簿、理想的に市民の参加を可能にするものを求めている。これは基本的に、1990年代と2000年代のタイムスタンプサービスが提供しようとしていたものである。パブリック・ブロックチェーンは、今日これを達成するための特に効果的な方法を提供する(データ自身は、チェーンの外で保存され、メタデータのみがチェーン上に保存される)。他のアプリケーションには、タイムスタンプや公開の電子掲示板の抽象化、最も注目すべきは電子投票によって恩恵を受ける。

資産管理の例を見てみる。ブロックチェーンを介して資産のトランザクションを実施したいと仮定し、そこに記録するだけではないとする。これは、資産がブロックチェーン自身でデジタルで発行され、ブロックチェーンがスマートコントラクトをサポートしている場合に可能である。この場合、スマートコントラクトは、資産が移転された場合にのみ支払いが行われる事を保証する”等価交換(fair exchange)”問題を解決する。より一般的には、スマートコントラクトは、全ての必要な入力データ(資産、価格など)がブロックチェーン上に表現されていれば、複雑なビジネス・ロジックを符号化できる。

アプリケーションにブロックチェーンの特質をマッピングする事で、潜在的な可能性を認識するだけでなく、切望していた懐疑心(dose of skepticism)を注入する事もできる。第一に、ブロックチェーンの多くの提案されたアプリケーションは、特に銀行業において、ナカモト合意を使用しない。むしろ、彼らは台帳データ構造とビザンチン契約を使用する。これは示されているように90年代のものである。これはブロックチェーンが新しい革命的な技術であるという主張に反する。その代わり、ブロックチェーンを巡る話題は、銀行が”石のスープ”の寓話のように共有台帳技術を導入するための集団行動を開始する手助けとなる。ビットコインは、分散化された台帳が動作することを非常に目に見える証拠としても役立ち、ビットコイン・コア・プロジェクトは必要に応じて適用できる便利なコードベースを提供している。

第二に、ブロックチェーンは従来の登録簿よりも安全だという誤解を招く主張がしばしばよくある。理由を考えてみると、システムまたはプラットフォーム全体の安定性をエンドポイントのセキュリティ、つまりユーザとデバイスのセキュリティから分離しなければならない。実際、ブロックチェーンのシステミック・リスクは、多くの中央集権型機関のリスクよりも低くなる可能性はあるが、ブロックチェーンのエンドポイントのセキュリティリスクは従来の機関の類似するリスクよりもはるかに悪い。ブロックチェーンのトランザクションは、ほぼ即時で不可逆的であり、パブリック・ブロックチェーンでは意図的に匿名化されている。ブロックチェーンベースの株主登録では、ユーザ(または仲買人や代理人)は自分の秘密鍵を失くした場合(電話を紛失したり、コンピュータ上でマルウェアに侵される以上のことはない)、ユーザは資産を失う。ビットコインのハッキング、盗難、詐欺の異常な歴史は、大きな信頼を呼び起こすものではない。ある見積もりによれば、流通しているビットコインの6%は少なくとも1度は盗まれている39

結びの知識

ここに説明されている歴史は、実務者や学者にとって豊かな(補完的な)教訓を提供する。実務者は革命的技術の主張に懐疑的であるべきだ。ここに示すように、分散型台帳やビザンチン契約など、企業の中で興奮状態を引き起こしたビットコインのアイデアのほとんどは、実際には20年以上前のものである。あなたの問題はブレイクスルーを必要としないかもしれないことを認識している。研究論文に長い間忘れられた解決策があるかも知れない。

学問の世界は、少なくともこのインスタンスでは、根本的、外因性のアイデアへの抵抗に正反対の問題を持っているようだ。ビットコインのホワイトペーパは、多くのアイデアが流行しているにも関わらず、ほとんどの学術研究よりも奇抜であった。更に、ナカモトは学術的な査読を気にせず、それを歴史に完全に結び付けなかった。その結果、学者は本質的にビットコインを数年間無視していた。多くの学術コミュニティは、理論的なモデルや過去のシステムの経験に基づいて、ビットコインが実際に動作していたにも関わらず、ビットコインが動作できないと非公式に主張した。

私たちは、研究文献のアイデアは徐々に忘れ去られたり、真価を認めず誤魔化す事を、特に彼らが研究の一般的分野であっても時間を先取りしているなら、繰り返し見てきた。実務者と学者の双方が、現在のシステムのための洞察を収集するために古いアイデアを再検討するためにうまく行くだろう。ビットコインは、その要素の研究の最先端であったわけではなく、以前は無関係だった多くの分野から古いアイデアを組み合わせたため、珍しく成功した。これは、完全に異なる用語や仮定を橋渡しする必要があるため、実行することは簡単ではないが、イノベーションのための重要な青写真である。

実務者は、過大評価された技術を特定できることから利益を得る。誇大宣伝のいくつかの指標は、技術革新を特定するのは難しい、おそらく技術的用語の意味を明確にするのは難しい、企業が自社製品を流行にくっつけるのを切望しているため、解決されている問題を特定するのが難しい、そして最後に社会問題を解決する、あるいは経済的/政治的な激変を引き起こすテクノロジーの主張である。

対照的に、学問はそのイノベーションを受け入れさせる事が難しい。例えば、オリジナルのプルーフ・オブ・ワークの研究者はビットコインの賞賛を得られないのは残念であり、おそらくその研究は学術界の外でよく知られていなかったためである。コードの公開や実務者との共同作業などの活動は、学会の中で十分に報われていない。事実、学問的なプルーフ・オブ・ワークのオリジナルの分岐は、ビットコインの存在を認めずに今日でも続けられている! 現実の世界に関与することが、信用を得るのに役立つだけでなく、再発明を減らし、新鮮なアイデアの源泉である。

補足記事

Sybil-resistantネットワーク

シビル攻撃に関する彼の論文で、John DouceurはBFTプロトコルに参加している全てのノードがhashcashパズルを解く必要があると提案した。あるノードがN個偽装されていた場合、時間内にN個のパズルを解くことができず、偽の身元が除去される。しかし、悪意のあるノードが、一つの身元のみを要求した正直なノードよりもわずかな利点を得ることがまだできる。2005年の補足論文では1、正直なノードは悪意のあるノードの動作を模倣し、計算上は要求できるほど多くの仮想アイデンティティを主張するべきであると提案した。これらの仮想アイデンティティがBFTプロトコルを実行すると仮定すると、「ノードのf分の1が障害になる」という仮定は、「故障したノードによって制御される総計算パワーの割合が最大でfである」という仮定に置き換えることができる。従って、身元を検証する必要はなくなり、オープンなピア・ツー・ピア・ネットワークはBFTプロトコルを実行できる。ビットコインはこのアイデアを厳密に利用する。しかし、ナカモトはさらなる疑問を問うた。ノードが計算上高価なプルーフ・オブ・ワークを実行するモチベーションは何だろうか? 答えは電子マネーという更なるジャンプが必要である。

スマートコントラクト

スマートコントラクトでは、データを安全な台帳に入れるというアイデアと計算を拡張する。言い換えると、それは公開で指定されたプログラムを正しく実行するための合意プロトコルである。ユーザは、これらのスマートコントラクト・プログラム内の機能を、プログラムによって指定された制限に従って呼び出すことができ、機能コードはマイナーによってタンデムに実行される。ユーザは計算をやり直す必要なく、出力を信頼でき、他のプログラムの出力に作用する独自のプログラムを書く事ができる。スマートコントラクトは、問題のプログラムがそれ自身で資金を管理し、転送し、破壊し、場合によっては印刷できるため、暗号化プラットフォームと組み合わせると特に強力である。

ビットコインはスマートコントラクトのために制限用法のプログラミング言語を実装している。標準トランザクション(言い換えれば、通貨を1つの住所から別の住所に移動させる)は、この言語の短いスクリプトとして指定される。Ethereumはより寛容的で強力な言語を提供する。

スマートコントラクトのアイデアは、1994年にNick Szaboによって提案され41、彼は法的契約の類似物として見ていたためそう名付けられたが、自動執行だった。(この見立ては、Karen Levy31とEd Felten16によって批評されている。) 予知的に、Szaboはスマートコントラクトを電子マネーのプロトコルの拡張として提示し、ビザンチン合意とデジタル署名(とりわけ)はブロック構築として使われる事を認識していた。暗号通貨の成功はスマートコントラクトを実用化し、その上このテーマに関する研究が開花した。例えば、プログラミング言語の研究者は、スマートコントラクトの中のバグを自動的に発見し、検証可能な正しいものを書くために、それらの手法とツールを採用した。

承認されたブロックチェーン

この記事は、プライベートあるいは許可されたブロックチェーンがビットコインのイノベーションの大部分を省略していることを強調しているが、これはこの場所で起こっている興味深い仕事を軽んじる事を意味するものではない。許可されたブロックチェーンは、誰がネットワークに参加できるか、トランザクションに書き込むか、ブロックをマイニングするかを制限する。特に、マイナーが信頼できる参加者のリストに限定されている場合、プルーフ・オブ・ワークはより伝統的なBFTアプローチを支持して廃止することができる。従って、研究の多くはBFTの再構築であり、次のような質問をする。合意アルゴリズムを単純化するためにハッシュ木を使用できるか? ネットワークがある特定の方法でしか故障しない場合はどうなるか?

更に、身元と公開鍵基盤、アクセス権限、ブロックチェーンに格納されたデータの機密性に関する重要な考慮事項がある。これらの問題は、パブリック・ブロックチェーン環境ではほとんど発生せず、従来のBTF文献でも研究されていない。

最後に、高いスループットのためにブロックチェーンをスケーリングし、サプライチェーンの管理や金融技術など様々なアプリケーションに適用するエンジニアリング作業もある。


謝辞

著者は、Adam Back、Andrew Miller、Edward Felten、Harry Kalodner、Ian Goldberg、Ian Grigg、Joseph Bonneau、Malte Möser、Mike Just、Neha Narula、Steven Goldfeder、そして草稿に貴重なフィードバックをくれたStuart Haberに感謝する。

参考文献

  1. Aspnes, J., et al. 2005. Exposing computationally challenged Byzantine imposters. Yale University Department of Computer Science; http://cs.yale.edu/publications/techreports/tr1332.pdf
  2. Back, A. 1997. A partial hash collision based postage scheme; http://www.hashcash.org/papers/announce.txt
  3. Back, A. 2001. Hash cash; https://web.archive.org/web/20010614013848/http://cypherspace.org/hashcash/
  4. Back, A. 2002. Hashcash—a denial of service counter measure; http://www.hashcash.org/papers/hashcash.pdf
  5. Bayer, D., Haber, S., Stornetta, W. S. Improving the efficiency and reliability of digital time-stamping. Proceedings of Sequences 1991; https://link.springer.com/chapter/10.1007/978-1-4613-9323-8_24
  6. Benaloh, J., de Mare, M. 1991. Efficient broadcast timestamping; http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.9199
  7. Boyle, T. F. 1997. GLT and GLR: Component architecture for general ledgers; https://linas.org/mirrors/www.gldialtone.com/2001.07.14/GLT-GLR.htm
  8. Castro, M., Liskov, B. 1999. Practical Byzantine fault tolerance. Proceedings of the Third Symposium on Operating Systems Design and Implementation; http://pmg.csail.mit.edu/papers/osdi99.pdf
  9. Chaum, D. 1981. Untraceable electronic mail, return addresses, and digital pseudonyms. Communications of the ACM 24(2): 84-90; https://dl.acm.org/citation.cfm?id=358563
  10. Chaum, D. 1983. Blind signatures for untraceable payments. Advances in Cryptology: 199-203
  11. Chaum, D. 1985. Security without identification: transaction systems to make Big Brother obsolete. Communications of the ACM 28(10): 1030-1044; https://dl.acm.org/citation.cfm?id=4373
  12. Chaum, D., et al. 1988. Untraceable electronic cash. Advances in Cryptology: 319-327; https://dl.acm.org/citation.cfm?id=88969
  13. Dai, W. 1998; http://www.weidai.com/bmoney.txt
  14. Douceur, J. R. 2002. The Sybil attack; https://dl.acm.org/citation.cfm?id=687813
  15. Dwork, C., Naor, M. 1992. Pricing via processing or combatting junk mail; https://dl.acm.org/citation.cfm?id=705669
  16. Felten, E. 2017. Smart contracts: neither smart nor contracts? Freedom to Tinker; https://freedom-to-tinker.com/2017/02/20/smart-contracts-neither-smart-not-contracts/
  17. Franklin, M. K., Malkhi, D. 1997. Auditable metering and lightweight security; http://www.hashcash.org/papers/auditable-metering.pdf
  18. Gabber, E., et al. 1998. Curbing Junk E-Mail via Secure Classiffication. http://www.hashcash.org/papers/secure-classification.pdf
  19. Garay, J. A., et al. 2015. The bitcoin backbone protocol: analysis and applications. Advances in Cryptology: 281-310; https://eprint.iacr.org/2014/765.pdf
  20. Goldberg, I. 2000. A pseudonymous communications infrastructure for the Internet. Ph.D. dissertation, University of California Berkeley; http://moria.freehaven.net/anonbib/cache/ian-thesis.pdf
  21. Grigg, I. 2005. Triple entry accounting; http://iang.org/papers/triple_entry.html
  22. Haber, S., Stornetta, W. S. 1991. How to timestamp a digital document. Journal of Cryptology 3(2): 99-111; https://link.springer.com/chapter/10.1007/3-540-38424-3_32
  23. Haber, S., Stornetta, W. S. 1997. Secure names for bit-strings. In Proceedings of the 4th ACM Conference on Computer and Communications Security: 28-35; http://dl.acm.org/citation.cfm?id=266430
  24. Jakobsson, M., Juels, A. 1999. Proofs of work and bread pudding protocols; http://www.hashcash.org/papers/bread-pudding.pdf
  25. Juels, A., Brainard, J. 1999. Client puzzles: a cryptographic countermeasure against connection completion attacks. Proceedings of Networks and Distributed Security Systems: 151-165; https://www.isoc.org/isoc/conferences/ndss/99/proceedings/papers/juels.pdf
  26. Just, M. 1998. Some timestamping protocol failures; http://www.isoc.org/isoc/conferences/ndss/98/just.pdf
  27. Lamport, L., et al. 1982. The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems 4(3): 382-401; https://dl.acm.org/citation.cfm?id=357176
  28. Lamport, L. 1989. The part-time parliament. Digital Equipment Corporation; https://computerarchive.org/files/mirror/www.bitsavers.org/pdf/dec/tech_reports/SRC-RR-49.pdf
  29. Lamport, L. 2001. Paxos made simple; http://lamport.azurewebsites.net/pubs/paxos-simple.pdf
  30. Laurie, B. 2014. Certificate Transparency. acmqueue 12(8); https://queue.acm.org/detail.cfm?id=2668154
  31. Levy, K. E. C. 2017. Book-smart, not street-smart: blockchain-based smart contracts and the social workings of law. Engaging Science, Technology, and Society 3: 1-15; http://estsjournal.org/article/view/107
  32. Melara, M., et al. 2015. CONIKS: bringing key transparency to end users. Proceedings of the 24th Usenix Security Symposium; https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-melara.pdf
  33. Merkle, R. C. 1980. Protocols for public key cryptosystems. IEEE Symposium on Security and Privacy; http://www.merkle.com/papers/Protocols.pdf
  34. Nakamoto, S. 2008. Bitcoin: a peer-to-peer electronic cash system; https://bitcoin.org/bitcoin.pdf
  35. Nakamoto, S. 2008. Re: Bitcoin P2P e-cash paper; http://satoshi.nakamotoinstitute.org/emails/cryptography/11/
  36. Narayanan, A., et al. 2016. Bitcoin and Cryptocurrency Technologies: A Comprehensive Introduction. Princeton University Press; http://bitcoinbook.cs.princeton.edu/
  37. Pass, R., et al. 2017. Analysis of the blockchain protocol in asynchronous networks. Annual International Conference on the Theory and Applications of Cryptographic Techniques; https://link.springer.com/chapter/10.1007/978-3-319-56614-6_22
  38. Pinkas, B., Sander, T. 2002. Securing passwords against dictionary attacks. Proceedings of the Ninth ACM Conference on Computer and Communications Security: 161-170; https://dl.acm.org/citation.cfm?id=586133
  39. Reuters. 2014. Mind your wallet: why the underworld loves bitcoin; http://www.cnbc.com/2014/03/14/mind-your-wallet-why-the-underworld-loves-bitcoin.html
  40. Sirer, E. G. 2016. Bitcoin guarantees strong, not eventual, consistency. Hacking, Distributed; http://hackingdistributed.com/2016/03/01/bitcoin-guarantees-strong-not-eventual-consistency/
  41. Szabo, N. 1994. Smart contracts; http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html
  42. Szabo, N. 2008. Bit gold. Unenumerated; https://unenumerated.blogspot.com/2005/12/bit-gold.html
  43. Wattenhofer, R. 2016. The Science of the Blockchain. Inverted Forest Publishing
  44. Rivest, R. L., Shamir, A. 1996. PayWord and MicroMint: Two simple micropayment schemes. International Workshop on Security Protocols