Category: Blockchain

vagrant@vagrant-ubuntu-trusty-64:~/bitcoin/src/bitcoin$ sudo make install
Making install in src
make[1]: Entering directory `/home/vagrant/bitcoin/src/bitcoin/src’
make[2]: Entering directory `/home/vagrant/bitcoin/src/bitcoin/src’
make[3]: Entering directory `/home/vagrant/bitcoin/src/bitcoin’
make[3]: Leaving directory `/home/vagrant/bitcoin/src/bitcoin’
CXX libbitcoin_server_a-blockencodings.o
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[2]: *** [libbitcoin_server_a-blockencodings.o] Error 4
make[2]: Leaving directory `/home/vagrant/bitcoin/src/bitcoin/src’
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/vagrant/bitcoin/src/bitcoin/src’
make: *** [install-recursive] Error 1

なに？？？？？？？？？
c++: internal compiler error: Killed (program cc1plus)　はメモリが足りない？？

メモリを増設するか、swap領域を確保するか。
メモリ増設だとvagrant fileか？

  # config.vm.provider "virtualbox" do |vb|
  #   # Display the VirtualBox GUI when booting the machine
  #   vb.gui = true
  #
  #   # Customize the amount of memory on the VM:
  #   vb.memory = "1024"
  # end

現状を確認します。
swapは0Bか？
vagrant@vagrant-ubuntu-trusty-64:~/bitcoin/src/bitcoin$ cat /etc/fstab
LABEL=cloudimg-rootfs / ext4 defaults 0 0
vagrant@vagrant-ubuntu-trusty-64:~/bitcoin/src/bitcoin$ swapon -s
Filename Type Size Used Priority
vagrant@vagrant-ubuntu-trusty-64:~/bitcoin/src/bitcoin$ free -h
total used free shared buffers cached
Mem: 489M 209M 279M 720K 7.0M 37M
-/+ buffers/cache: 165M 324M
Swap: 0B 0B 0B

swapファイルを作成する
vagrant@vagrant-ubuntu-trusty-64:~/bitcoin/src/bitcoin$ sudo fallocate -l 2G /swapfile
vagrant@vagrant-ubuntu-trusty-64:~/bitcoin/src/bitcoin$ ls -lh /swapfile
-rw-r–r– 1 root root 2.0G Oct 28 14:21 /swapfile
vagrant@vagrant-ubuntu-trusty-64:~/bitcoin/src/bitcoin$ sudo chmod 600 /swapfile
vagrant@vagrant-ubuntu-trusty-64:~/bitcoin/src/bitcoin$ ls -lh /swapfile
-rw——- 1 root root 2.0G Oct 28 14:21 /swapfile
vagrant@vagrant-ubuntu-trusty-64:~/bitcoin/src/bitcoin$ sudo mkswap /swapfile
Setting up swapspace version 1, size = 2097148 KiB
no label, UUID=fa2787e1-8129-4685-9586-651f61fb0d8e
vagrant@vagrant-ubuntu-trusty-64:~/bitcoin/src/bitcoin$ sudo swapon /swapfile
vagrant@vagrant-ubuntu-trusty-64:~/bitcoin/src/bitcoin$ free -h
total used free shared buffers cached
Mem: 489M 211M 278M 720K 7.1M 38M
-/+ buffers/cache: 166M 323M
Swap: 2.0G 0B 2.0G

きたーーーーーーーーーー

で、もう一回、bitconfのディレクトリでmakeします。今度は行けるか？
あれ、もしかして来たか？？

ブロックチェーンでは、電子署名によってトランザクションの正当性を保証している
各トランザクションに一つずつ電子署名が付与され、電子署名を検証するための公開鍵もセットで付与される
電子署名を検証することで、トランザクションの内容が偽造・改ざんされていてないことを確認できる
ビットコインではSHA-256(256ビット)のハッシュ関数が採用されている

ビットコインのブロックは、ブロックヘッダ+トランザクション情報(複数)からなる
ブロックヘッダは「前ブロックヘッダのハッシュ値+ナンス+トランザクションのハッシュ値」から構成されている

ところで、リミックスなど、取引所でコインが盗まれる、というのはどういう事象を指しているのだろうか？トランザクションはチェーンに記録として残るのだから、盗難したコインの送付先は解るようみ見えるのだが、、
何からのトランザクションを追えない仕組みで送付しているのかな。

そういえば、サトシ・ナカモトは論文を発表しただけでなく、ブロックチェーン基盤自体の開発にも携わってるんですね。。知らんかった。

PoWやPoSと同様Byzantine Faultモデルだが、ファイナリティの不確実性や性能問題を解消している

– PBFTではネットワークのすべての参加者をあらかじめ知っている必要がある
– 参加者の1人がプライマリーとなり、要求を全参加者に送る。要求に対する結果を集計し、多数を占めている値を採用することでブロックを確定。
– 不正なノード数をf個とする場合、ノード数は3f+1個である必要があり、確定にはf+1個以上のノードが必要
– 分岐しない為、性能的に非常に高速

Sieve
IBMで考案されたPBFTを拡張したアルゴリズム
Paxos、Raftなどのコンセンサスアルゴリズムもある

考え方によるが、中央集権型か、合意形成型かで大きく異なる様ですね。しかし、PoWのビットコインがこれだけ仮想通貨の中で支持を集めているというのは、ネットが登場して、現代社会というのは本当に変わりましたな。

– 貨幣量を多く所有している承認者が優先的にブロックを作成できる
– 貨幣量によってハッシュ計算の難易度が下がる
– Proof of Workの代替案
– マイニングによる消費電力がない
– コンセンサスに必要な時間が短い
– ASIC等を使ったマイナーによる中央集権化のリスクが少ない

ビットコインの取引処理件数は7件/1秒と言われており、Visaカードの
50,000件/1秒に比べて取引速度が大きく劣る

Coin Age
コインの保有量 x コインの保有期間　が大きければ大きいほどマイニングに成功しやすくなる

Randomized Proof of Stake
コインの保有量に比例して、ランダムに取引承認者を選ぶ

ただし、コインをため込まれると、通貨の流動性が下がる
PoSでは格差が広がり易い

PoSの公式

SHA256(prevhash + address + timestamp) <= 2^256 * balance / diff [/code] GitHubにblock chainのサンプルがありますね。 https://github.com/AvinashNath2/Block-Chain-Example/blob/master/Block_Chain.py

1.walletがトランザクションを発行し、参加者全員にブロードキャスト
2.受け取った承認者がハッシュ計算。先に見つけたブロックがブロックチェーンに追加
3.walletが別のトランザクションを発行し、全員にブロードキャスト
4.受けっとた承認者がハッシュ計算。複数のノードが同時に見つけた場合はブロックチェーンは分岐する
5.次に別のノードがブロックを追記した時、追記されたブロックチェーンが正となる
Byzantine Faultに対応
参加サーバはローカル通信のみでよい
多数決の代わりとなるのはCPU演算力
電気代が安い地域に集中する懸念がある

from random import randint 
from hashlib import sha256 

previous_hash = "****"
cnt = 1
nonce = str(randint(0, 1000000))

header = sha256(f'{previous_hash}{nonce}'.encode()).hexdigest()

while header[:4] != "0000":
	text = 'loop:{}, header:{}, header[:4], nonce:{}\n'
	print(text.format(cnt, header, header[:4], nonce))

	nonce = str(randint(0, 1000000))
	header = sha256(f'{previous_hash}{nonce}'.encode()).hexdigest()
	cnt += 1 

text = 'loop:{}, header:{}, header[:4]:{}, nonce:{}'
print(text.format(cnt, header, header[:4], nonce))

ビザンチン将軍問題の解決が重視され、パブリック型では、悪意のある者が紛れ込んでいることを想定した仕組みが構築される
コンソーシアム型はPoWは必要なし
コンセンサスアルゴリズムが整理と真偽判断をする
Proof of Stake はPoWの改良版

問題
– 特定のマイナー(ブロック作成者)が計算能力を占有すると、PoWが正常に機能しなくなる
– チェーンが分岐したときの決済完全性が完璧ではない、不確実性が存在する
– 通信時間のネットワーク性能の限界
– 容量の増加

コンセンサスアルゴリズムの種類
– Proof of Work
– Proof of Stake
– Paxos
– Raft
– PBFT
– Sieve

障害時の想定モデルが異なる

Bitcoin core(初回)
1. DNSによる探索
2. クライアントにハードコーディングされている準永久的ノード一覧の参照
3. コマンドラインによるIP指定
※ハードコーディングとは、本来記述すべきでないリソースをソースコードの中に埋め込む事
2回目以降は、ノード一覧を保持したDBを参照して連携
— データの送受信はハッシュをinvメッセージとして相手クライアントに送り、getdataメッセージの送受信から、情報本体をやりとりする

Ethereum
1. あらかじめハードコーディングされているブートストラップノードの一覧を参照して接続
ブートストラップノードは起動時にコマンドラインから指定することもできる
— ハッシュがすべてのノードによって共有されている空間にチェーンとして保存され、ワークプールとして利用される

Hyperledger Fabric
-起動時に指定された起点となるノードに対してディスカバリープロトコルを発行して参加者一覧を入手
-その後、validating peerの場合は、全てのvalidating peerとメッシュ状のネットワークを形成、non-validating peerの場合は、接続許可されている最も近いvalidating peerとのみ接続
— ノード間の通信にgRPCを利用しており、双方向でストリーミングのメッセージングがやりとり可能。シリアライズ化にProtocol buffersを利用

あれ、BitcoinとEthereumって、P2Pも情報の送受信も仕組みが全く違うやんけ。。。
DNS-IPはネット回線のネットワークとしては基本のように思うが、なぜこんなにハードコーディングが使われるんだろうか。。キュリオシティをそそりますね。

Proof of Work(計算量証明)をコンセンサスアルゴリズムに採用

1. P2Pトランザクションのノード(ノードX)が取引データを送信　※この時点では、取引自体は未成立
2. トランザクションが全参加者宛に伝播
3. トランザクションを受け取った全ノードがマイニングを実施し、条件に合うハッシュ値を発見すると、既存のブロックチェーンに新しいブロックを追加
4. 新しいブロックを追加したノードは、ブロックをP2Pネットワークにブロードキャスト
5. ブロックを受け取った各ノードは、ブロックが正当なものであるかを検証し、正しいものであれば、ブロックチェーンを更新。この時点で取引が成立

なるほど、取引成立までにProof of Workが入っているのね。

疑問点
-> Proof of Workのロジックは、ランダム関数を使っているのか？？
-> ブロックチェーンのトランザクションの伝播対象は、取引所までか？それとも、ユーザー単位なのか？例えば、サービスにブロックチェーン決済を取り込んだ場合は、トランザクションはサービス提供者までに留まるのか？
-> マイニング業者の競争は、単純にCPUの性能の勝負なのか？それともマイニングアルゴリズムなども左右されるのか？

1. Bitcoin Core (Bitcoin Foundation)
https://bitcoin.org/ja/download
ビットコインリファレンス実装
Proof of Work

2. Ethereum (Ethereum Foundation)
https://www.ethereum.org/
分散型アプリケーションDapps構築
Proof of Stake

3. Hyperledger Fabric (Hyperledger Project)
https://www.hyperledger.org/projects/fabric
P2P分散レッジャー技術基盤
Practical Byzantine Fault Tolerance

4. Corda (R3 CEV)
https://www.corda.net/
金融向け分散型台帳基盤

5. Chain Open Standard 1 (Chain.inc)
https://www.openchainproject.org/get-started
ブロックチェーン暗号化など

6. mijin (テックビューロ)
https://mijin.io/
プライベート型ブロックチェーン

7. Orb1 (Orb)
https://imagine-orb.com/
定期的に取引を確定させることで、決済完了性を確保

8. Eris (Eris Industries)
https://erisindustries.com/
パーミッション型ブロックチェーン

——–
スマートコントラクト、電子署名・ハッシュ関数、コンセンサスアルゴリズム、P2Pネットワーク

——–
誰でも参加型(パブリック型)、信頼する参加者のみに絞り込むか(コンソーシアム型、プライベート型)
->参加者形態により、マイニング、ブロックチェーン閲覧、ブロック生成、マイニング報酬　などが異なる

——–
ブロックチェーンブロック
-> 前ブロックヘッダのハッシュ値、ナンス、トランザクション群のハッシュ
-> トランザクションの内容