7章 Proof of Work

Tweet

ネットワーク上のすべてノードで正しい情報を共有する方式として、「Proof of Work」が考案されたんや。

Proof of Workのプロセス

Proof of Workは下の図のようにプロセスを実行するで。

新しいブロックが生成されると、 ブロックはチェーンの先端に接続される。この時、大量にハッシュ計算が行われているんや。
例えば、ブロックチェーンのどこかを改ざんすると、つながっているブロックのすべてのデータが変わってしまうんや。
もし、変更がうまくいったとしても、連なるデータのハッシュを再度計算する必要があるで。

あ、不正すると仮想通貨自体の価値が下がるから攻撃しにくいってのもあるわ

Nonceを変えてハッシュ計算

Nonceを除くブロックヘッダが作成できたら、Nonceを変えながらハッシュ計算を行うんや。ハッシュ計算は、一定条件を満たすまで繰り返すで。

ハッシュ計算のイメージ

言いたいこと=>ハッシュ計算は値がちょっとでも違うと全然違うの出てくるで！

[入力]

import hashlib

input_txt = "kijima"

for nonce in range(20):
    input_data = input_txt + str(nonce)
    hash = hashlib.sha256(input_data.encode("UTF-8")).hexdigest()
    print(input_data + "=>" + hash)

[出力]

kijima0=>51829b32e9664d98c7ae3aa2a9b5ee7d6de723036158dee960420a7c878ed468
kijima1=>442f64f8df426c03f2eb079f235452890aef90330fef8a1957b21af0365e4f9f
kijima2=>c04820d14e94da6c650cb5d1bc541d9b9b44f34d95482ddd5d279bf02b596851
kijima3=>e87276079ff902147dce3076057f2ddd66d09f9690850ef21fb196e016cf1642
kijima4=>7da55046bbccf11039f6d67d124266720d48090e33beeae3d41fdeb791eefd64
kijima5=>dbbed7331b99d961f58b1eb391dad42539801aa85f68064483ec8609a58ad146
kijima6=>dd9b230613852abe40434d39fa74ae3d4ca5ced210ca724c4314e4045394ebac
kijima7=>dd388879c0438dabfb97c341cc9de31f4ea92561cabe132137ad73e86ca70b62
kijima8=>ae616351de00e6fcfc8569244af89caff0896c7f7e2d620eb04a10362689e378
kijima9=>c8d15cf80a2cca4a65a098a16b475897b4b08c14bb278c026190c6f81f6ea4df
kijima10=>d91596116a7e0ff1c3576fcf89f94639fd68328775848896a1272c1545e861c5
kijima11=>3c748d4b9c507fb4354921d793b00b7da230f8c0fcf85c9cc62aa1fd94dfe4d6
kijima12=>c639b1ae2d361785724ce678e896c2b078b95330d4e5f036616efc6e6857f58e
kijima13=>73ef57bbff7ec47826b9d366cd81f05561405eb0221a57a44cbc6931e657bda7
kijima14=>8ebc8be3de8444269494c4a00e5f0c4929bbac7dddea5f9585062735b2cb92dc
kijima15=>fa9f1a7215a578266de23feebe669c513b634005c866f85aeeacf4d40ee7d4dd
kijima16=>534c37a7edbececa1320b47717d3d0897009bddd754e84aeedef4f0f7b5806c3
kijima17=>5ce44262c077779e4f5df95f9509e12ce41ce60f1ea556cdae26cd83aabf47d3
kijima18=>071c5ac0c730be36ef027fc041a4551eb9fdeb56c9d3ade38703e94e8eb1ce8e
kijima19=>c005d6878b5278280116b9ea64aebb5becb417ac7c6ea964b64f14bc8accee0e

Difficulty bits と Difficulty Target

いろんなところで「"条件"を満たすハッシュ値」と書いてきた。
今回は、"条件"について記すわ。
ブロックヘッダのDifficulty bitsに答えがある。この4バイトのフィールドには、ハッシュ値が満たすべき条件が格納されとるわ。
(記述例)
0X1e777777のような形で記述される。これを前半1バイトと後半3バイトに分けるで

• 前半：1e(指数部)[exponent]
• 後半：777777(係数部)[coefficient]

これ面白いのが右から[exponent]バイト目から○○までとか記述するらしいわ,,,ややこしくない？？

はなしそれたわ,,,
Proof of workにおいて、ブロックヘッダはDouble-SHA256でハッシュ化する
=>出力ハッシュ値は32バイトやで。

32バイトのハッシュ値が「右からexponentバイト目から、cofficientが始まる32バイト値」
これを条件とする！！別名、「Difficulty Target」

実際にbitsからTargetに変換する際は以下の計算式を用いる
Target = cofficient × 2の8乗
この計算式基づき、「0x1e777777」を変換プログラムは以下のようになる
[入力]

target = 0x777777 * 2 **(8*(0x1e - 0x03))
print(target)

#10進数 => 16進数
target_hex = hex(target)[2:].zfill(64)
print(target_hex)

[出力]

824528581084176575145518374651615721673290736390910993533830975258099712
0000777777000000000000000000000000000000000000000000000000000000

ナンスを変えるプログラム

ブロックヘッダを生成しナンスの値を少しずつ変え、ハッシュ値を計算するプログラムは、下記の通り。
[入力]