The 21st century: 區塊鏈

顯示具有 區塊鏈 標籤的文章。顯示所有文章

Gob 的編碼與解碼

https://blog.golang.org/gobs-of-data

三篇相同內容的：
https://www.jishuwen.com/d/2M7g/zh-hk
https://studygolang.com/articles/1005
https://mikespook.com/2011/03/%E3%80%90%E7%BF%BB%E8%AF%91%E3%80%91gob-%E7%9A%84%E6%95%B0%E6%8D%AE/

为了让某个数据结构能够在网络上传输或能够保存至文件，它必须被编码然后再解码。当然已经有许多可用的编码方式了，比如 JSON、XML、Google 的 protocol buffers 等等。而现在又多了一种，由Go语言 encoding/gob 包提供的方式。

Gob 是Go语言自己以二进制形式序列化和反序列化程序数据的格式，可以在 encoding 包中找到。这种格式的数据简称为 Gob（即 Go binary 的缩写）。类似于 Python 的“pickle”和 Java 的“Serialization”。

Gob 和 JSON 的 pack 之类的方法一样，由发送端使用 Encoder 对数据结构进行编码。在接收端收到消息之后，接收端使用 Decoder 将序列化的数据变化成本地变量。

Go语言可以通过 JSON 或 Gob 来序列化 struct 对象，虽然 JSON 的序列化更为通用，但利用 Gob 编码可以实现 JSON 所不能支持的 struct 的方法序列化，利用 Gob 包序列化 struct 保存到本地也十分简单。

Gob 不是可外部定义、语言无关的编码方式，它的首选的是二进制格式，而不是像 JSON 或 XML 那样的文本格式。Gob 并不是一种不同于 Go 的语言，而是在编码和解码过程中用到了 Go 的反射。

Gob 通常用于远程方法调用参数和结果的传输，以及应用程序和机器之间的数据传输。它和 JSON 或 XML 有什么不同呢？Gob 特定的用于纯 Go 的环境中，例如两个用Go语言写的服务之间的通信。这样的话服务可以被实现得更加高效和优化。

Gob 文件或流是完全自描述的，它里面包含的所有类型都有一个对应的描述，并且都是可以用Go语言解码，而不需要了解文件的内容。

只有可导出的字段会被编码，零值会被忽略。在解码结构体的时候，只有同时匹配名称和可兼容类型的字段才会被解码。当源数据类型增加新字段后，Gob 解码客户端仍然可以以这种方式正常工作。解码客户端会继续识别以前存在的字段，并且还提供了很大的灵活性，比如在发送者看来，整数被编码成没有固定长度的可变长度，而忽略具体的 Go 类型。

http://c.biancheng.net/view/4597.html

編碼細節：

https://cloud.tencent.com/developer/section/1141539

https://stackoverflow.com/questions/33228700/is-encoding-gob-deterministic

Since:

A stream of gobs is self-describing. Each data item in the stream is preceded by a specification of its type, expressed in terms of a small set of predefined types.

This means if you encode a value of a type for the first time, type information will be sent. If you encode another value of the same type, the type description will not be transmitted again, just a reference to its previous spec. So even if you encode the same value twice, it will produce different byte sequences as the first will contain type spec and the value, the second will contain only a type ref (e.g. type id) and the value.

對相同的值進行兩次編碼，會產生不同的 byte 序列，參考下列的演示：https://play.golang.org/p/3Gc2cPY7F4o

As seen the first Encode() generates lots of bytes plus the value for our Int value being [5 255 130 1 2 0], the second and third calls add the same [5 255 130 1 2 0] sequence.

But if you create 2 different gob.Encoders and you write the same values in the same order, they will produce exact results.

Note that in the previous statement "same order" is also important. Because type specification is transmitted when first value of such type is sent, sending values of different types in different order will transmit type specs in different order too, and so the references/identifiers of the types may differ, which implies that when a value of such type is encoded, different type reference/id will be used/sent.

Also note that the implementation of the gob package may change from release to release. These changes will be backward compatible (they must explicitly state if for some reason they would make backward incompatible changes), but being backward compatible does not mean the output is the same. So different Go versions may produce different results (but all is decodeable with all compatible versions).

如果創建 2 個不同的 gob.Encoders 並以相同的順序寫入相同的值，則它們將產生精確的結果。

注意，在前面的陳述中「相同的順序」也很重要。因為類型規範是在發送該類型的第一個值時發送的，所以以不同順序發送不同類型的值也會以不同順序發送類型規範，因此類型的「引用/標識符」可能會有所不同，這意味著當此類類型已編碼，將「使用/發送」不同的類型「引用/id」。

還要注意，gob 軟件包的實現可能因版本而異。這些更改將是向後兼容的（如果出於某種原因它們將進行向後不兼容的更改，則必須明確聲明），但是向後兼容並不意味著輸出是相同的。因此，不同的 Go 版本可能會產生不同的結果（但是所有兼容版本都可以解碼）。

比特幣的數據儲存方式 blk.dat

blk.dat
Raw blockchain data files 原始區塊鏈數據文件: https://learnmeabitcoin.com/guide/blkdat

Magic Bytes: https://learnmeabitcoin.com/guide/magic-bytes

完整解析，包括程式讀寫細節：
https://zhuanlan.zhihu.com/p/31924911
https://blog.csdn.net/t46414704152abc/article/details/90174727

几乎所有数据都是以小端类型（Little-Endian）存储的，但是 Transaction Input/Output 里的script除外。它们是以大端方式（Big-Endian）存储的。

magic number是一个固定的数，其值为 0xD9B4BEF9

variable integer本身的长度不定，在 1 到 9 字节之间。具体的解析规则如下：

如果第一个字节小于 253，那么直接返回该字节所代表的数值

如果第一个字节等于 253，那么往后再读一个字节作，将其值作为返回值

如果第一个字节等于 254，那么往后再读四个字节作，将其值作为返回值

如果第一个字节等于 255，那么往后再读八个字节作，将其值作为返回值

如果我们把之前的数据按照上述规则带入的话可以得到如下图表。

JavaScript: SHA256, byte array, 16進制字串轉換等

JavaScript SHA-256 demo: https://geraintluff.github.io/sha256/

https://github.com/emn178/js-sha256

到 https://cdnjs.com/ 搜尋
=> https://cdnjs.cloudflare.com/ajax/libs/js-sha256/0.9.0/sha256.min.js

A simple SHA-256 / SHA-224 hash function for JavaScript supports UTF-8 encoding.

It also supports byte `Array`, `Uint8Array`, `ArrayBuffer` input

https://github.com/brix/crypto-js
https://code.google.com/archive/p/crypto-js/
https://blog.zhengxianjun.com/2015/05/javascript-crypto-js/

<script src="https://cdnjs.cloudflare.com/ajax/libs/crypto-js/3.1.9/crypto-js.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/crypto-js/3.1.9/hmac-sha256.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/crypto-js/3.1.9/enc-base64.min.js"></script>

var hash = CryptoJS.SHA256("Message").toString();

https://github.com/brix/crypto-js/issues/157

var hash = CryptoJS.HmacSHA256("Message", "key");

// Message 是按照使用者的規則拼接的字串
// key為設置密鑰

https://github.com/digitalbazaar/forge

<script src="https://cdn.jsdelivr.net/npm/node-forge@0.7.0/dist/forge.min.js"></script>
<script type="text/javascript">
"use strict";

var md = forge.md.sha256.create();
md.update('The quick brown fox jumps over the lazy dog');
console.log(md.digest().toHex());

console.log(hexToBytes(md.digest().toHex()));

console.log(bytesToHex(hexToBytes(md.digest().toHex())));

// Convert a hex string to a byte array
function hexToBytes(hex) {
for (var bytes = [], c = 0; c < hex.length; c += 2)
bytes.push(parseInt(hex.substr(c, 2), 16));
return bytes;
}

// Convert a byte array to a hex string
function bytesToHex(bytes) {
for (var hex = [], i = 0; i < bytes.length; i++) {
var current = bytes[i] < 0 ? bytes[i] + 256 : bytes[i];
hex.push((current >>> 4).toString(16));
hex.push((current & 0xF).toString(16));
}
return hex.join("");
}

</script>

//十六进制字符串转字节数组
function StrToBytes(str) {
var pos = 0;
var len = str.length;

if(len %2 != 0) {
return null;
}
len /= 2;
var hexA = new Array();

for(var i=0; i<len; i++) {
var s = str.substr(pos, 2);
var v = parseInt(s, 16);
hexA.push(v);
pos += 2;
}
return hexA;
}

//字节数组转十六进制字符串
function BytesToStr(arr) {
var str = "";

for(var i=0; i<arr.length; i++) {
var tmp = arr[i].toString(16);

if(tmp.length == 1) {
tmp = "0" + tmp;
}

str += tmp;
}
return str;
}

javascript 使用 toString 10進位轉2或8或16進位.

toString()：預設是10進位轉其它進位，同時，配合正則，可匹配字符。

範例：

<script language="javascript">
var x = 100;
var y1 = x.toString(2);
var y2 = x.toString(8);
var y3 = x.toString(16);
var z = "2進位 = " + y1 + "<br>8進位 = " + y2 + "<br>16進位 = " + y3;
document.write(z);
</script>

各種編碼如 base64、哈希演算法如 SHA-256 等等的輸出情況

密碼學：https://chaindesk.cn/witbook/15

哈希值的輸出值一般是16進制的字符串。
而16進制字符串，每兩個字符佔一個字節。
一個字節 = 8bit

SHA256
無論輸入多長，都輸出 64 個字符，共32字節（byte），256位（bit）
輸出只包含數字0~9和字母A~F，大小寫不敏感
https://play.golang.org/p/Mm1-YK0KhE8

RIPEMD160
無論輸入多長，都輸出 40 個字符，共20字節（byte），160位（bit）
https://play.golang.org/p/v72c3ms4PcP

Base64, Base32 和 Base16：
https://studygolang.com/articles/10799
https://zhuanlan.zhihu.com/p/51316306

BASE16 = "0123456789ABCDEF"

BASE32 = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567"

BASE32_HEX = "0123456789ABCDEFGHIJKLMNOPQRSTUV"

BASE64 = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"

BASE64_URL = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_"

計算機中，存儲的的二進制碼，是一個字節（8位）一組。 Base 系列編碼，本質上就是將字節切片組合，然後為重組後的數字找一個對應的、可見的 ASCII 字符，這就是 Base 系列編碼了。

base 系列編碼並不屬於字符編碼，他們主要用於把一串「無意義的」八位二進製字節編碼為可見 ASCII 字符。 base64 大概浪費了 25% 的空間，base32 是 37.5%，base16 是 50%。

「無意義」是指 base 編碼可編碼任意二進制而無需知道其意義。

反思：如果從節省空間的角度考慮，為什麼不用 base128 呢？

Base32 將任意字符串按照字節進行切分，並將每個字節對應的二進制值（不足8bits高位補0）串聯起來，按照5bits一組進行切分，並將每組二進制值轉換成十進制來對應32個可打印字符中的一個。

由於數據的二進制傳輸是按照8bit一組進行（即一個字節），因此Base32按5bits切分的二進制數據必須是40bits的倍數（5和8的最小公倍數）。例如輸入單字節字符“%”，它對應的二進制值是“100101”，前面補兩個0變成“00100101”（二進制值不足8bits的都要在高位加0直到8bits），從左側開始按照5比特切分成兩組：“00100”和“101”，後一組不足5比特，則在末尾填充0直到5比特，變成“00100”和“10100”，這兩組二進制數分別轉換成十進制數，通過上述表格即可找到其對應的可打印字符“E”和“U”，但是這裡只用到兩組共10比特，還差30比特達到40比特，按照5比特一組還需6組，則在末尾填充6個“=”。

填充“=”符號的作用是方便一些程序的標準化運行，大多數情況下不添加也無關緊要，而且，在URL中使用時必須去掉“=”符號。

與Base64相比，Base32具有許多優點：

適合不區分大小寫的文件系統，更利於人類口語交流或記憶。
結果可以用作文件名，因為它不包含路徑分隔符 “/”等符號。
排除了視覺上容易混淆的字符，因此可以準確的人工錄入。（例如，RFC4648符號集忽略了數字“1”、“8”和“0”，因為它們可能與字母“I”，“B”和“O”混淆）。
排除填充符號“=”的結果可以包含在URL中，而不編碼任何字符。

Base32也比Base16有優勢：

Base32比Base16佔用的空間更小。（1000比特數據Base32需要200個字符，而Base16則為250個字符）

Base32的缺點：

Base32比Base64多佔用大約20％的空間。因為Base32使用8個ASCII字符去編碼原數據中的5個字節數據，而Base64是使用4個ASCII字符去編碼原數據中的3個字節數據。

https://play.golang.org/p/_OP_RqjYyHh

hex也稱為base16，意思是使用16個可見字符來表示一個二進制數組，編碼後數據大小將翻倍,因為1個字符需要用2個可見字符來表示。

base32，意思是使用32個可見字符來表示一個二進制數組，編碼後數據大小變成原來的8/5,也即5個字符用8個可見字符表示，但是最後如果不足8個字符，將用=來補充。

base64，意思是使用64個可見字符來表示一個二進制數組，編碼後數據大小變成原來的4/3,也即3個字符用4個可見字符來表示。

為何要把"hello world!" 這麼明白的東西變成一串看不懂的東西，其實是這個例子使用了可見字符而已，而有很多字符是不可見的，我們需要把這些不可見字符變成可見字符。

那為何要變成可見字符？你是看著亂碼舒服還是看著可見字符舒服呢？其實不僅僅舒不舒服的問題，有些時候還必須要用可見字符，例如在網絡中傳輸數據時，不同路由器對於不可見字符的處理是不同的，因此可能出現數據錯誤，因此還必須使用可見字符。

hex, base32, base64 的區別主要就是空間效率的區別，base64是具有比較高的空間效率的。
hex編碼不區分大小寫，但是base32與base64是區分的。

聯繫就是大家都是一種穩定地把二進制數組變成可見字符的編碼方式。

base32中StdEncoding和HexEncoding所使用的字符不同。

base64中URLEncoding一般用於編碼URL。

「字符編碼」是指 ASCII, Unicode, UTF-8 等

挖礦難度：nBits 與 target 的轉換

google "bitcoin bits target difficulty"

https://zhuanlan.zhihu.com/p/32739785

https://teakki.com/p/5c7f7022b1029f607607feae

https://bitcoin.stackexchange.com/questions/30467/what-are-the-equations-to-convert-between-bits-and-difficulty/30470

https://zhuanlan.zhihu.com/p/51140710

http://www.qukuai.top/d/290

https://github.com/btcsuite/btcd/blob/master/blockchain/difficulty.go
https://play.golang.org/p/DksBw9KCwH4

比特幣存在多種地址格式

一個錢包地址通常由 26-35 個字母數字字符組成，是發送和接收比特幣所需要的全部。任何比特幣地址都可以用來將加密貨幣傳輸到網絡上的任何其他地址，前提是發送方的錢包軟體支持該地址類型。由於有多種地址格式可供選擇，而錢包提供商和交易所只支持某些特定的地址類型，因此需要了解比特幣的不同地址格式。

就像我們知道網際網路協議有 IPv4 和 IPv6 等多個版本一樣，比特幣也存在多種地址格式。大多數情況下，這些不會相互衝突，交易可以在託管錢包和非託管錢包之間無縫進行。有三種主要的比特幣輸出腳本格式可供選擇：P2PKH、P2SH 和 Bech32，只有少數服務提供商支持所有這些格式，很可能你首選的錢包或交易所至少不支持其中一種格式，其中 Bech32 最有可能被忽略。

了解每種地址格式的優缺點和獨特的地方，可以更好地選擇兼容的比特幣錢包、交易所或平台。它還會讓你更深入地了解比特幣的內部工作原理，並揭示各種格式在安全性、靈活性和功能性方面的利弊。

如果您的比特幣地址以1開頭，您使用的是 P2PKH 或傳統地址，例如 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 。這是比特幣最初的地址格式，至今仍能正常工作。順便說一下，P2PKH 是 Pay-to-Pubkey Hash 的縮寫，即支付給收件人的公鑰的哈希值。傳統地址與 segwit 不兼容，但是您仍然可以將 BTC 從 P2PKH 地址發送到 segwit 地址，而不會出現任何問題。但是，從 P2PKH 地址發送時的平均費用可能高於從 segwit 地址發送時的平均費用，因為傳統地址事務的大小更大。

比特幣現金地址可以採用傳統格式（以 1 開頭），也可以採用更常見的現金地址（ Cash Addr ）格式。它基於 bech32 ，以「 q 」或「 bitcoincash:q 」開頭。BCH wallet 支持這兩種格式，用戶可以使用工具在現金 Addr 和舊格式之間切換。使用現金 Addr 格式的主要原因是為了區分 BCH 和 BTC ，從而防止資金被發送到錯誤的地址。

https://en.bitcoin.it/wiki/Base58Check_encoding#Version_bytes

Golang: base58 編碼 & 解碼

base58 編碼 (包含解說)
https://play.golang.org/p/8l6HGHxblQM

base58 解碼 (包含解說)
https://play.golang.org/p/nv8AzrVeebn

base58 編碼 & 解碼完整程式碼 (可運行測試)
https://play.golang.org/p/H9pLcU87ejj

比特幣存在多種地址格式
https://21st.each1.net/2019/07/blog-post_7.html
https://play.golang.org/p/_Uesr4ck2Yr

用 Golang 搭建自己的區塊鏈

Bitcoin in Go: https://github.com/btcsuite/

Building Blockchain in Go. 使用 Golang 建構區塊鏈
https://jeiwan.cc/

Part 1: Basic Prototype 基本原型
https://jeiwan.cc/posts/building-blockchain-in-go-part-1/
https://annatarhe.github.io/2017/12/29/building-blockchain-in-go-part-1-basic-prototype.html
https://github.com/Jeiwan/blockchain_go/tree/part_1
完整程式碼的演示：https://play.golang.org/p/6zOWpS_Yna0

Part 2: Proof-of-Work 工作量證明
https://jeiwan.cc/posts/building-blockchain-in-go-part-2/
https://annatarhe.github.io/2017/12/30/building-blockchain-in-go-part-2-proof-of-work.html
https://github.com/Jeiwan/blockchain_go/tree/part_2
合併程式碼 (Ctrl+S 存檔到本機後編譯才能運作)：https://play.golang.org/p/JFBU1hWQkhQ

Part 3: Persistence and CLI 持久化與命令行
https://jeiwan.cc/posts/building-blockchain-in-go-part-3/

https://annatarhe.github.io/2017/12/30/building-blockchain-in-go-part-3-persistence-and-cli.html
https://github.com/Jeiwan/blockchain_go/tree/part_3

合併程式碼 (Ctrl+S 存檔到本機後編譯才能運作)：https://play.golang.org/p/xIk3j-_mLTd

比特幣的數據儲存方式 blk.dat：https://21st.each1.net/2019/12/blkdat.html

Part 4: Transactions 1 交易 1
https://jeiwan.cc/posts/building-blockchain-in-go-part-4/
https://annatarhe.github.io/2018/01/01/build-blockchain-in-go-part-4-transactions-1.html
https://github.com/Jeiwan/blockchain_go/tree/part_4
合併程式碼，並添加了部分修正 (Ctrl+S 存檔到本機後編譯才能運作)：
https://play.golang.org/p/AGudHIBN6WG

在 func (cli *CLI) printChain() 中加入更完整的區塊細節打印

Part 5: Addresses 地址
https://jeiwan.cc/posts/building-blockchain-in-go-part-5/
https://annatarhe.github.io/2018/01/02/building-blockchain-in-go-part-5-addresses.html
https://cordate.github.io/2018/03/28/blockchain/%E6%AF%94%E7%89%B9%E5%B8%81/Bitcoin%E4%B8%ADBase58Check/
https://github.com/Jeiwan/blockchain_go/tree/part_5
合併程式碼 (Ctrl+S 存檔到本機後編譯才能運作)：https://play.golang.org/p/e4Ws_uN-Yrl

Part 6: Transactions 2 交易 2
https://jeiwan.cc/posts/building-blockchain-in-go-part-6/
https://annatarhe.github.io/2018/01/06/building-blockchain-in-go-part-6-transactions-2.html
https://github.com/Jeiwan/blockchain_go/tree/part_6
合併程式碼 (Ctrl+S 存檔到本機後編譯才能運作)：https://play.golang.org/p/yEo5xdfDKvA

Part 7: Network 網絡
https://jeiwan.cc/posts/building-blockchain-in-go-part-7/
https://annatarhe.github.io/2018/01/12/building-blockchain-go-part-7-network.html
https://github.com/Jeiwan/blockchain_go/tree/part_7
合併程式碼，並添加了教程說明中所需要的環境變數 (Ctrl+S 存檔到本機後編譯才能運作)：https://play.golang.org/p/rII18zokMTv

在 func main() 中加入 os.Setenv("NODE_ID", "3000")

最新版本：
https://github.com/Jeiwan/blockchain_go/tree/master
修正了比特幣存在多種版本的地址格式：https://21st.each1.net/2019/07/blog-post_7.html

從 Part 4 之後的範例，實測後發現 bugs，當同一個 address 自己轉給自己，查詢餘額時會發現餘額增加... 透過打印出完整的區塊細節，可以先找出一個 bug 發生的地方，然後可以再延伸出其他 bugs...

檢查後發現，這些 bugs 的起因是由於 returns a list of transactions containing unspent outputs 這個部分的函數，
當同一個地址自己轉給自己時，會在同一個 transaction 內生成兩個相同地址的 outputs (一個是轉帳的金額，一個是找零)，
但是當後續的交易再引用上述 outputs 時，若只用到同一個 transaction 內的其中一個 output 時，該 transaction 仍然會被列在 list of transactions containing unspent outputs 內，然後後續的程式流程卻誤以為這個 transaction 內的所有 outputs 都是 unspent，因而導致了可用餘額憑空增加。

從代碼來看，就是從下面這個方法開始的邏輯流程發生錯誤
func (bc *Blockchain) FindUnspentTransactions(address string) []Transaction {
}

除錯後，總共修正了三個函數：
https://play.golang.org/p/YpFzoFvFLHK

整併為
https://play.golang.org/p/SA_55kFhOtq

Part 7 實測後發現許多 bugs，比如說相同節點的多筆帳戶互轉、同節點的多筆帳戶互轉相同金額，同一個地址轉給自己等等...

檢查後發現，
相同節點的多筆帳戶互轉、同一個地址轉給自己的 bugs 是延續 Part4 的問題...

而其他問題比如說同一個地址轉帳給兩個帳戶，然後才一起挖掘時，會去引用同一筆輸出，導致雙花 (double spending) ...

綜合來看，是文中所提及還沒有完成的諸多工作，比如說應該驗證『區塊內的交易是否符合規則』。

以比特幣的做法來說，比特幣的雙重支付意味著一筆幣（UTXO）被花費了兩次。通常，這意味著A將她的0.413 BTC發送給了B，然後她又把同一筆比特幣又發送給了C。
比特幣的解決方法是，其中一筆交易會納入一個區塊，由此來決定實際誰得到了報酬。如果兩筆交易不知何故都傳遞到了多個區塊，那麼後面發生的區塊，就會被軟件給拒絕掉。如果兩筆交易都在同一個區塊當中，那麼這個區塊也會遭到軟件的拒絕。

Code your own blockchain in less than 200 lines of Go

所有教程的完整代碼
https://github.com/mycoralhealth/blockchain-tutorial

Part I 一個單機上的區塊鏈生成與展示
https://medium.com/@mycoralhealth/code-your-own-blockchain-in-less-than-200-lines-of-go-e296282bcffc

Part II 仍然需要主節點的分散式架構 (比較簡單的架構，但尚未達到完全去中心化)
https://medium.com/@mycoralhealth/part-2-networking-code-your-own-blockchain-in-less-than-200-lines-of-go-17fe1dad46e1

工作證明
Code your own blockchain mining algorithm in Go
https://medium.com/@mycoralhealth/code-your-own-blockchain-mining-algorithm-in-go-82c6a71aba1f

了解如何使用IPFS通過區塊鏈存儲數據

Learn to securely share files on the blockchain with IPFS

https://medium.com/@mycoralhealth/learn-to-securely-share-files-on-the-blockchain-with-ipfs-219ee47df54c

編寫區塊鏈 P2P 網路

Code a simple P2P blockchain in Go

英文原文：https://medium.com/@mycoralhealth/code-a-simple-p2p-blockchain-in-go-46662601f417

中文翻譯：https://codertw.com/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/510718/

中文翻譯內的資源連結是失效的，需要到英文原文才能連結查看更多相關文件

p2p 協議概述：
https://blog.csdn.net/echoaiya/article/details/45887843

根据拓扑结构的关系可以将P2P研究分为四种形式：

中心化拓扑（Centralized Topology）、
全分布式非结构化拓扑（Decentralized Unstructured Topology）、
全分布式结构化拓扑（Decentralized Structured Topology, 也称为DHT网络）、
半分布式拓扑（Partially Decentralized Topology）。

(1)
中心化拓扑最大的优点是维护简单、发现效率高。缺点是与传统C/S结构类似，易造成单点故障。这是第一代P2P网络采用的结构模式，经典案例是著名的MP3共享软件Napster。

(2)
全分布非结构化网络在重叠网络采用了随机图的组织方式，结点度数服从“Power-law”规律，从而能够较快发现目的结点，面对网络的动态变化体现了较好的容错能力，因此具有较好的可用性。同时可以支持复杂查询，如带有规则表达式的多关键词查询，模糊查询等，最典型的案例是 Gnutella。

（因为此类网络采用了随机图、泛洪等机制，构建的系统没有固定的结构，故称为非结构化）
（随机图的“随机”二字体现在边的分布上。一个随机图实际上是将给定的顶点之间随机地连上边，参考网址：http://blog.csdn.net/foreverdengwei/article/details/7337429）

Gnutella 是一个P2P文件共享系统，它和 Napster 最大的区别在于 Gnutella 是纯粹的P2P系统，没有索引服务器，它采用了基于完全随机图的泛洪（Flooding）发现和随机转发（Random Walker）机制。为了控制搜索消息的传输，通过TTL（Time To Live）的减值来实现。详情参见 [Gnutella 协议]。

随着网络节点的不断增多，网络规模不断扩大，通过这种泛洪方式定位对等点的方法将造成网络流量急剧增加，从而导致网络中部分低带宽节点因网络资源过载而失效。所以在初期的Gnutella网络中，存在比较严重的分区、断链现象。也就是说，一个查询访问只能在网络的很小一部分进行，因此网络的可扩展性不好。所以，解决Gnutella网络的可扩展性对该网络的进一步发展至关重要。

(3)
全分布式结构化拓扑网络。目前研究的重点放在了如何有效地查找信息上，最新的成果都是基于DHT的分布式查找和路由算法。这些算法都避免了类似Napster的中央服务器，也不像Gnutella那样基于广播进行查找，而是通过分布式散列函数，将输入的关键字惟一映射到某个结点上，然后通过某些路由算法同该结点建立连接。

DHT类结构能够自适应结点的动态加入/退出，有着良好的可扩展性、鲁棒性、结点ID分配的均匀性和自组织能力。由于重叠网络采用了确定性拓扑结构，DHT可以提供精确的发现。只要目的节点存在于网站中，DHT总能发现它，发现的准确性得到了保证，最经典的案例是Tapestry，Chord，CAN和Pastry。

DHT类结构维护机制较为复杂，尤其是节点频繁加入/退出造成的网络波动会极大增加DHT的维护代价。

DHT仅支持精确关键词匹配查找，无法支持内容/语义等复杂查询。

(4)
半分布式结构吸取了中心化结构和全分布式非结构化拓扑的优点，选择性能较高（处理、存储、带宽等方面性能）的节点作为超级节点（SuperNodes， Hubs），在各个超级点上存储了系统中其他部分节点的信息，发现算法仅在超级节点之间转发，超级节点再将查询请求转发给适当的叶子节点。半分布式结构也是一个层次式结构，超级点之间构成一个高速转发层，超级点和所负责的普通节点构成若干层次。最典型的的案例是KaZaa。

半分布式结构的特点是性能、可扩展性较好；较容易管理，对超级节点依赖性大，易于受到攻击；容错性易受影响。

比较标准/拓扑结构	中心化拓扑	全分布式非结构化拓扑	全分布式结构化拓扑	半分布式拓扑
可扩展性	差	差	好	中
可靠性	差	好	好	中
可维护性	最好	最好	好	中
发现算法效率	最高	中	高	中
复杂查询	支持	支持	不支持	支持

https://murphymind.blogspot.com/2017/09/bitcoin.mechanics.html

在 Bitcoin 中，如何讓大家知道新的 transaction 發生了？

Bitcoin 採用的作法是 gossip process - 把消息通知自己知道的人，聽到的人再通知其他人，依此類推。

Bitcoin scripts

Bitcoin transaction 裡的 input "addresses" 及 output "addresses" 實際上是 scripts：

習慣上，input "addresses" 的 script 稱為 scriptSig，
output "addresses" 的 script 稱為 scriptPubKey。
因為在最簡單的情況下，output script 指定 public key，而 input script 指定 signature。

要驗證一筆 transaction 是否 valid，把 input script 及 output script 結合起來執行，如果沒有 error，就視為是一筆 valid transaction。

更多參考資料：

精通比特幣：http://book.8btc.com/master_bitcoin
精通比特幣第二版：http://book.8btc.com/masterbitcoin2cn
比特幣改進提案：https://en.bitcoin.it/wiki/Category:BIP
從原理解析，探討密碼學、橢圓曲線的原理，以及程式碼的撰寫：https://yhheho.gitbooks.io/bitcoin/
Block Chain Basic Knowledge: https://developpaper.com/block-chain-basic-knowledge/
指標與位址的教程：http://edisonshih.pixnet.net/blog/post/27961535

大數 big.NewInt(), .Lsh() vs 一般數的 >>右移 <<左移位運算符：https://play.golang.org/p/__ityUdxwlt

在 Go 裡面做大數運算：
https://studygolang.com/static/pkgdoc/pkg/math_big.htm
http://weijr-note.blogspot.com/2013/04/go.html
.Cmp 比较x和y的大小。x<y时返回-1；x>y时返回+1；否则返回0。

big.Int 是一个结构体(struct)，相当于C++中的class，所以每次新建 big.Int 时可以用 x := new(big.Int), 返回一个指针。注意对 big.Int 的算术操作，要使用该對象的成員函數，比如說 Add()。

用 Golang 的 flag 套件建置 CLI (Command line)：https://21st.each1.net/2019/05/golang-flag-cli-command-line.html

bytes.Join 的用法：https://play.golang.org/p/sQOBBheA0Y5

Golang 的 Map:
https://www.cnblogs.com/igloo1986/p/3546337.html
https://blog.golang.org/go-maps-in-action

Golang: 合併 slice 的 append 方法
https://21st.each1.net/2019/06/golang-slice-append.html

Golang: base58 編碼 & 解碼
https://21st.each1.net/2019/06/golang-base58.html

使用 String() 方法來客製化字符串的輸出
https://21st.each1.net/2019/06/string.html

Golang 環境變量：https://21st.each1.net/2019/05/golang.html

時間格式處理：
https://www.jianshu.com/p/fe56edd8d30b
https://blog.csdn.net/skh2015java/article/details/70051512

google "源码分析比特币"
google "源码分析 p2p"
google "源码分析比特币 p2p"
google "源码分析乙太坊 p2p"
google "源码分析 bt p2p"
google "p2p 协议"

利用go語言實現比特幣的一些中文教學
google 『比特幣 UTXO golang』
https://www.twblogs.net/a/5b80a1d42b71772165a8628c
https://shanma.pro/tutorial/57052.html

Why separate execution of unlocking and locking scripts (為什麼單獨執行解鎖和鎖定腳本):
https://bitcointalk.org/index.php?topic=5095376.msg49150302#msg49150302
https://github.com/bitcoinbook/bitcoinbook/blob/second_edition_print3_rc2/ch06.asciidoc#tx_script

為何比特幣從 Berkeley DB 轉換成 LevelDB

https://bitcoin.stackexchange.com/questions/51435/migration-from-berkeley-db-to-leveldb

https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

2010年8月15日，1840億枚比特幣漏洞

https://blog.fangweb.com/2019/03/04/%E6%AF%94%E7%89%B9%E5%B9%A3%E9%BB%91%E6%AD%B7%E5%8F%B21840%E5%84%84%E6%9E%9A%E6%AF%94%E7%89%B9%E5%B9%A3%E6%BC%8F%E6%B4%9E/zh-tw/

比特幣區塊74638有些不同尋常。最初發現它的是核心開發人員Jeff Garzik，他對「相當奇怪」的交易輸出(每個交易量為92233720368.54 BTC)發表了評論。不到一個小時，另一名論壇用戶開始了一個名為「嚴重溢出錯誤」的帖子，他在帖子中懇求「我們需要盡快修復」。那是2010年8月15日，比特幣遇到迄今為止最大的漏洞。

比特幣遇到了一個非常大的問題

在導致1840億比特幣憑空誕生的整數溢出漏洞之前，比特幣已經經歷了至少四個主要漏洞。比特幣維基百科列出了40個以上不同程度的漏洞。然而，CVE-2010-5139不同於比特幣社區過去所見過的任何情況。

在74638區塊發現的這個漏洞是比特幣的第一個通脹漏洞。考慮到加密貨幣的總供應量將被限制在2100萬枚，委婉地說，增加1840億枚比特幣是一個大問題。整數溢出導致事務值為負。Bitcointalk論壇用戶Ifm解釋道:

通常，輸入等於事務的輸出。唯一的例外是交易要收取「費用」。網路允許任何人自願支付一定的費用。當總和為負時，與輸入的差值就像一個費用。它通過了所有的檢查。

一個未知的攻擊者發現了這個漏洞，並利用它生成了數量高得離譜的比特幣。如果他們把目標定在一個更適度的總數上，那麼他們的開采可能會被隱瞞超過90分鐘才被發現。一旦被發現，一個補丁不可避免地會被匆匆通過，於是它就發生了。在2010-5139年度常見的漏洞和曝光事件發生後的兩個小時內，核心開發商Gavin Andresen和Satoshi Nakamoto就參與了此案，這筆價值1,840億的BTC交易被從74638區塊清除。

中本聰保證道，「一旦超過50%的節點能力升級，好的鏈取代壞的鏈，那麼0.3.10個節點將使任何壞的事務都很難得到確認。」比特幣的創造者非常重視這種規模的漏洞，並在帖子中發表了十幾次帖子，致力於比特幣漏洞的發現和根除。

區塊鏈滿負荷運行 - 比特幣交易長時間未被確認 - 會發生哪些問題？

https://www.chainnews.com/articles/579717148076.htm

比特幣區塊非常擁堵，經常會遇到長時間得不到確認的交易。這些交易得不到確認會被怎麼處理，會退回到用戶的錢包嗎？會丟幣嗎？

1. 比特幣交易生命週期

2. 礦工節點會嫌棄低手續費的交易

3.
我們必須知道的是，如果你交易遲遲得不到確認，肯定不可能自動回到你的錢包上顯示你發送交易之前的餘額。
而且全網一定會有節點接受並繼續幫你的交易進行廣播，所以你的交易會像鬼魂一樣一直在網絡中游盪，而且會一直被挖礦節點拋棄而又接受，又再拋棄。直到全網節點的內存池被逐步清空，手續費降低，你的交易才有可能被確認。
最正確的辦法就是把你的 txid 發給一家礦池，並且額外給礦池一些錢，叫他幫你添加到下一個區塊當中。這就是我們常見的『交易加速處理服務』。

4. 如果使用 "rescan" 和 "zapwallettxes" 命令找回你的交易

Merkle Tree 與 SPV 驗證

https://www.twblogs.net/a/5b7c42492b71770a43da1ded

區塊鏈編程的相關學習資源

https://www.zhihu.com/question/46729645

Peer-to-Peer

比特幣 - 總覽：http://21st.each1.net/2017/03/blog-post_30.html

比特幣的論文標題為 Bitcoin: A Peer-to-Peer Electronic Cash System
其中涉及到 Peer-to-Peer 這類的技術，相關技術筆記整理於本文

BitTorrent協定（簡稱BT，俗稱位元洪流、BT下載）是用在對等網路中檔案分享的網路協定程式。用戶越多，下載同一檔案的人越多，下載該檔案的速度越快。且下載後，繼續維持上傳的狀態，就可以「分享」，成為其用戶端節點下載的種子檔案（.torrent），同時上傳及下載。

根據BitTorrent協定，檔案發布者會根據要發布的檔案生成提供一個.torrent檔案，即種子檔案，也簡稱為「種子」。

種子檔案本質上是文字檔案，包含Tracker資訊和檔案資訊兩部分。Tracker資訊主要是BT下載中需要用到的Tracker伺服器的位址和針對Tracker伺服器的設定，檔案資訊是根據對目的檔的計算生成的，計算結果根據BitTorrent協定內的Bencode規則進行編碼。它的主要原理是需要把提供下載的檔案虛擬分成大小相等的塊，塊大小必須為2k的整數次方（由於是虛擬分塊，硬碟上並不產生各個塊檔案），並把每個塊的索引資訊和Hash驗證碼寫入種子檔案中；所以，種子檔案就是被下載檔案的「索引」。

詳細內容：
https://en.wikipedia.org/wiki/Peer-to-peer
https://en.wikipedia.org/wiki/BitTorrent

How to write a simple BitTorrent application?

https://stackoverflow.com/questions/5400828/how-to-write-a-simple-bittorrent-application
https://en.wikipedia.org/wiki/Libtorrent
https://www.libtorrent.org

比特幣 - Source Code - 筆記

比特幣 - 總覽：http://21st.each1.net/2017/03/blog-post_30.html

檔案：src/base58.h

Base58 是用於 Bitcoin 中使用的一種獨特的編碼方式，主要用於產生 Bitcoin 的錢包地址。相比 Base64，Base58 不使用數字 "0"，字母大寫 "O"，字母大寫 "I"，和字母小寫 "l"，以及 "+" 和 "/" 符號。

設計 Base58 主要的目的是：
1. 避免混淆。在某些字體下，數字 0 和字母大寫 O，以及字母大寫 I 和字母小寫 l 會非常相似。
2. 不使用 "+" 和 "/" 的原因是非字母或數字的字符串，如果作為帳號會比較難被人們所接受。
3. 沒有標點符號，這樣子通常不會被從中間分行。
4. 大部分的軟體支持雙擊選擇整個字符串。

由於 256 不能被 58 整除，Base58 無法像 Base64 那樣轉換為 8bits 的 2 進位後依次取出 6bits 就可以快速完成轉換。因此，Base58 編碼算法需要除法運算實現，如果被編碼的數據較長，則要用特殊的類來處理大數，Bitcoin 使用了 OpenSSL 中的 BIGNUM。

編碼符號表：https://zh.wikipedia.org/wiki/Base58

比特幣區塊鏈的關鍵核心技術，包括採用 Hashcash 演算法來進行工作量證明，讓區塊鏈中的各節點有機會參與驗證，達到公正性，且交易過程採用橢圓曲線數位簽章演算法來確保交易安全，並在每筆交易與每個區塊中使用多次 Hash 函數以及 Merkle Tree，不只是為了節省儲存空間，更重要的是藉由將前一個區塊的 Hash 值加入新區塊中，讓每個區塊環環相扣，也因此做到所謂的可追蹤且不可竄改的特性，同時也使用時間戳來確保區塊序列。

關鍵技術 1
採用工作量證明達到去中心化及公正性

首先，最關鍵的便其工作量證明機制（Proof of Work，POW），這是一個可以讓每個參與的節點可共同參與交易驗證的方式，來實現一個能多方共同維護的單一系統，並共享同一份記錄交易的帳本，以形成一個基於零信任基礎，卻能實現去中心化的P2P網路系統。

工作量證明是讓任一運算節點，花費時間和運算資源來計算出一組數學公式的結果，且要完成一次有效的工作量證明，需經過一連串地嘗試與失敗。不過，一旦這個數值被算出來後，其他參與節點也可用相關的數學公式，便能很容易去驗證這個值是否有效。

比特幣區塊鏈採用Hashcash演算法（雜湊現金演算法）作為工作量證明，讓各節點經由POW計算來產生每一個有效的新區塊，再經由其他節點驗證並接受。

進行POW計算的過程也被稱作挖礦，很多人用解一道數學題、或是解一個數獨來形容，不過，怎樣才是真的算出一個有效的新區塊，這些節點到底在算什麼？

由於每個區塊中Block Header會包含許多固定的值，其中只有Nonce值為一隨機值，因此每個節點進行POW計算時要算的就是，藉由不斷替換這個Nonce值，來讓這個區塊的Block Header Hash值，小於一個被設定好的難度目標值（Difficulty Target），至於為什麼要小於這個目標值，則是因為這個難度值意味著每個區塊在理論上應該要被產生完成。

這裡提到的難度值（Difficulty）是指，節點要運算出低於困難度目標值的Hash值，平均需花多久時間，也就是平均要完成一次POW的時間。而比特幣區塊鏈目前設定為，大約每10分鐘會有節點成功算出新的區塊，不過這10分鐘只是基於理論值，實際每個新區塊產生的時間，有可能只需要17秒（第407062個區塊的實際產生時間），也有可能需要20分鐘以上（第407068個區塊的實際產生時間）。

Difficulty可動態調整，目前每產生2016個區塊會調整一次難度，以每10分鐘產生一區塊估算，大約是每兩周會調整一次Difficulty。由於POW具有一定的難度，因此無法預期哪個運算節點可以最快算出新區塊，藉此來確保交易驗證的公正性。

關鍵技術 2
每筆交易採橢圓曲線數位簽章演算法加密

比特幣區塊鏈便採用橢圓曲線數位簽章演算法（ECDSA），與另一種RSA演算法，都屬於公開金鑰加密演算法（Public Key Cryptography），公開金鑰加密技術在1970年代被發明，也稱為雙金鑰密碼安全系統，每個使用者會擁有公開金鑰（Public Key）與私密金鑰（Private Key）這兩把鑰匙，公開金鑰可讓其他人知道，而私密金鑰則只有本人知道。當A要傳送一筆訊息或交易給B時，需使用B的公開金鑰來將這份交易加密，而這這個加密過的訊息或交易，只有使用B的私密金鑰才能解開。

在比特幣區塊鏈中，比特幣區塊鏈便採用橢圓曲線數位簽章演算法，每一個比特幣區塊鏈中的節點使用者，會同時擁有這兩把金鑰，以及一次性使用的比特幣位址（Address），公開金鑰可讓區塊鏈網絡中的其他人知道，而私密金鑰則須自行保管，可用來接收貨幣、進行電子簽章或是發送貨幣，而Address就像電子郵件一樣可用來當作存取比特幣的地址，使用者可重複取得新的Address，且可以在離線狀態下產生，不過，每個Address只能使用一次。

在比特幣區塊鏈中，每一枚電子貨幣被視為一串數位簽章，使用者要進行比特幣交易時，必須將前一筆交易以及收款方的公開金鑰經由Hash產生數位簽章，加到電子貨幣那串數位簽章的後方。

RSA加密演算法是一種非對稱的加密演算法，利用兩個質數作為加密與解密用的兩把鑰匙，金鑰長度約在40個位元到1024位元。不過比特幣所採用的ECDSA能算出更短的金鑰長度，也就是能夠使用相對較少的資源，做到與RSA相同的安全性。在ECDSA演算法中，由私密金鑰算出公開金鑰很容易，但要從公開金鑰推回私密金鑰卻很困難。

關鍵技術 3
Hashcash演算法及多種Hash函數確保資料不被竄改

前面提到比特幣區塊鏈採用Hashcash演算法來進行工作量證明，Hashcash可將任意長度的資料經由Hash函數轉換為一組固定長度的代碼，原理是基於一種密碼學上的單向雜湊函數 (One Way Hash Function)，這種函數很容易被驗證，但是卻很難破解，還回推出原本的值。先前Hashcash演算法也被用來做阻擋垃圾郵件的機制。

常使用的單向雜湊函數包括MD5、SHA-1、SHA-256、SHA-384及SHA-512等，MD5的Hash值長度為128位元，雖然廣為使用，但因長度不夠較容易破解，SHA-1的Hash值長度有160位元，雖比MD5好但仍然不夠安全，因此美國國家安全局（NSA）又提出多種更複雜的SHA-2演算法，包括224、256、384、512位元長度的Hash值算法。

Hashcash最早在1997年由Adam Back提出，並於2002 正式發表一篇描述雜湊現金系統的論文。比特幣區塊鏈採用Hashcash來建立一套幾乎無法被竄改的電子現金系統，每個區塊的Block Header都會被Hash成一串很難被回推的代碼後，放進下一個區塊中，來確保區塊的正確性。

關鍵技術 4
經由Merkle Tree將大量訊息縮短成一個Hash值

在比特幣區塊鏈中，每筆交易產生後，都已經被Hash成一段代碼才廣播給各節點，不過這樣做還不夠，因為在各節點的區塊中，可能包含數百筆到數千筆的交易，因此，為節省儲存空間並減少資源耗費，比特幣區塊鏈的設計原理採用Merkle Tree機制，讓這些數百到數千筆的交易Hash值，經由兩兩一組形成一個新Hash值的方式，不斷重複進行，直到最後產生一組最終的Hash值，也就是Merkle Tree Root，這個最終的Hash值便會被記錄到Block Header中，只有32 Bytes的大小。Merkle Tree機制可大幅減少資料傳輸量與運算資源消耗，驗證時，只需驗證這個Merkle Tree的Root值即可。

關鍵技術 5
用時間戳伺服器（Timestamp Server）確保區塊序列

比特幣採用時間戳伺服器機制（Timestamp Server），將每個區塊Hash後加上一個時間戳（Timestamp）並發布出去，這個時間戳用來證明資料在特定時間的有效性，每一個時間戳章會與前一個戳章一起進行Hash，這個Hash值會在與下一個時間戳章進行Hash，因此而形成一個用來確保區塊序列的鏈條。

含英文字幕的影片，在 20分鐘左右有 proof-of-work (PoW) 的程式碼實作

https://www.youtube.com/watch?v=5Tr13l0O1Ws

中文字幕，必須等待廣告跑完：https://www.leiphone.com/news/201802/1C2RI7Zrk89Tp8OV.html

區塊鏈的可能應用

分析、預測

隨著不同產業逐漸投入區塊鏈運用層面，甚至有平台運用至「預測未來事件」。Augur 透過區塊鏈技術，允許所有用戶預測未來事件，對可能發生的事情下賭注，其中的獎勵機制促使用戶準確預測。該公司聲稱，整個過程預測過程將是分散的，運用「群體智慧」（Wisdom of Crowds），群眾的預測將會比單獨專家或機構來得更準確。他們的用戶可從股票市場預測到體育，甚至發生自然災害都可以是預測範疇。

加密貨幣尚未被實現的隱藏能力：貨幣分配

英文原文：https://hackernoon.com/why-everyone-missed-the-most-mind-blowing-feature-of-cryptocurrency-860c3f25f1fb

中文翻譯：https://buzzorange.com/techorange/2017/08/15/why-everyone-missed-the-most-mind-blowing-feature-of-cryptocurrency/

關於智慧合約
https://www.zhihu.com/question/27687960

很多人都已經從技術的角度解釋了區塊鏈技術的原理和一些技術細節，不過這些對普通人來說不重要。就好比現在逛網站並不需要懂 TCP/IP 協議一樣。

一句話概括，如果互聯網技術解決的是通訊問題的話，區塊鏈技術解決的是信任問題。

比如我和A賭NBA總冠軍，我說是勇士，A說是騎士。但是A的賭品我深表懷疑，擔心他輸了賴賬不給錢。沒想到A反咬一口，還懷疑我的賭品不好，簡直豈有此理！那咱倆就需要一個可信第三方來做公證人。我們可以各自出20塊錢給我們都信得過的公證人來保管。如果屆時勇士贏了，40塊錢就歸我。如果騎士贏了，40塊錢就歸A。

總決賽系列終於結束了，公證人捲了巨款40元跑了……

人和人最基本的信任到哪裡去了？

出於對人性墮落的失望，我和A決定使用區塊鏈技術來解決這個價值40塊錢真金白銀的問題。
辦法是寫一個『智能合約』來實現對賭。

方法是這樣的，我們先各自出20塊錢打到一個『智能合約』的賬戶裡，這個合約不被任何人控制，只被合約的代碼控制。現在『智能合約』的賬戶上有了40塊錢，我們開始運行智能合約。

合約代碼大概這樣：

比赛结果=NBA官方网站API.get("总决赛")

if(骑士赢)
   pay 40 to A
else
   pay 40 to B

這個賬戶唯一會動賬的可能就是獲取比賽結果後，按照規則支付。我把代碼給A看後，表示無異議。我們就把代碼放到一個區塊鏈上去運行。

這個叫做『智能合約帳號』的賬戶，事實上是一個無人信託，它只會按照代碼去執行。等比賽結果出來了，代碼一執行，誰都賴不了賬。 A再信不過我，我再信不過A，我們都能實現對賭。

別的行業先不說，金融行業裡實在太多這樣的需求要這樣做。

比如私募基金協會出了個新八條，股票配資不讓超過1：1了，賭場老油條們怎麼辦？吃慣優先利息的銀行怎麼辦？

於是大家想了一個利用信託的辦法。劣後資金比如5000萬，要搞個1:3的槓桿，然後銀行出優先資金1.5個億，雙方都把錢打入信託賬戶。這時候信託賬戶上就有2個億了，然後再拿信託的名義去券商開戶做交易。

信託負責審核，如果產品的淨值小於0.8了，那麼平倉，銀行本金和利息拿走，剩下的錢歸劣後拿回去。如果淨值很高，並且到期了，銀行拿走本金和利息，剩下歸劣後。信託是銀行和劣後都認可的可信第三方，問題是這活不是白乾的，信託要收管理費用的。

如今一塊信託牌照大概能賣好幾十億，這錢太好掙了。

整個流程耗時耗財不說，千三的通道費管理費忍了，最關鍵的問題，如果信託公司出問題了呢？信託公司可不是都做無風險業務的，天天嚷嚷著要打破剛兌啥的，如果哪一天真出問題了咋辦。託管賬戶在銀行這裡，銀行也不是沒倒閉的風險。

要解決信任問題的辦法恰恰是誰都不信。咱們再寫個智能合約

净值=券商报告.get(产品名称)

运行天数=DateTime.Now - 起始日期
应计利息=优先资金量×日利息×运行天数
银行应收=优先资金量+应计利息
劣后应得=净值×总额-银行应收

if(净值<=0.8 or 运行天数>=到期天数)
{
    pay 银行应收 to 银行
    pay 劣后应得 to 劣后
}

往區塊鏈上那麼一放，一樣實現這個效果，但你不用擔心任何一個第三方違約或者倒閉，因為這裡並沒有第三方。或者說全世界都是你的第三方。具體的底層技術細節不是碼農兄弟就別管了，就跟你不需要知道鏈路層通訊協議照樣能打王者榮耀一樣。

好了，民間配資公司都可以洗洗睡了。標準優先劣後協議開源後，資金方自己可以打錢進智能合約，等劣後方打錢進去，填寫個產品名稱後就可以跑起來了。配資公司吃掉的利息差有多大，舊模式其實浪費的資源就有多大。比信託的通道費和管理費大多了。

撇開費用不談，想想債券代持的蘿蔔章事件吧，不信任任何第三方是何等的重要。

如果債券代持這筆業務是放在區塊鏈上的話，那根本不可能有公章是偽造這種奇葩藉口。因為區塊鏈上的身份確認，是用高級加密算法的數字簽名來實現的，不是地攤上私刻公章能做出來的。人類科技都發展到這水平了，還在用印章和筆跡來驗證核實身份，這是何等奇怪之事。

說到中間人的浪費，莫過於保險公司了。保費里只有一小部分是真正發揮作用的，你的錢都付給 brokers 和宏觀的核心CBD地段大樓去了。更別說各種模糊摳字眼的不理賠條款了。

我們再寫個智能合約

航班抵达时间=航空公司官网.get(航班号)

pay 30 to I

if(航班抵达时间-预期时间>3小时）
    pay 1000 to C

這裡 I 是保險公司，C是客戶。 I 要先充1000到智能合約裡，B 要充30到智能合約。這是個標準合同，任何人充個1000都能當保險公司，試圖去賺個30塊錢。當然啦，保險公司靠大數定律賺錢，最好別只搞一次。智能合約在區塊鏈上跑不是沒有成本的，是要付費的，但遠比傳統大型金融中介機構要便宜得多得多。

成本還不是主要考量，最最關鍵的是，沒有模糊條款。比起自然語言，代碼沒有歧義性。

如果保險公司和信託公司的違約風險大家沒體會的話，想想場外期權的違約風險，行業是有血的教訓的。比如現在大熱的螺紋鋼，沒有期權不給力啊，搞個場外的話，但交易對手違約風險怎麼辦。

螺纹钢报价=上期所报价.get("rb1801")

Pay 期权费 to Seller

if(DateTime.Now()>=到期日 and 螺纹钢报价>4000)
    内在价格=螺纹钢报价-4000
    pay 内在价值 to Buyer

這和槓桿的保險有點像，這是一張執行價4000的螺紋鋼的歐式看漲期權，期權的買方只需要充值期權費用進去就可以了。關鍵是期權的賣方，保證金充多少進去。到期了，如果期權的賣方保證金不足以支付了怎麼辦？

我們有兩種解決方案，一個是在智能合約裡規定，一旦賣方的保證金不足以支付，直接強制平倉將保證金全部給多頭。另外，智能合約是可以發送消息的，讓賣方追加保證金進去，否則觸發強平。這裡的保證金不是給交易所的，而是打到智能合約的賬戶上的。

雖然是場外，但你也不用擔心對手盤風險了。事實上，合約你可以自己定義規則，不一定要是標準的期權期貨合約，衍生品人人可以設計，不用等交易所上市產品。

A股股票融券難，不易做空？

股价=上交所报价.get("600516")

价差=股价-对赌价

if(价差>0)
    pay 价差 to Long
else
    pay Math.Abs(价差） to Short    //Math.Abs 的意思是取绝对值

多頭（Long）和空頭（Short）都充值保證金進去，然後開始對賭。保證金比例大家商量在合約裡體現，也設計保證金 Margin Call 功能，這就是個股期貨了。看好 600516 的可以獲得沒有配資利息的槓桿，空頭可以不用融券做空。

所謂『現金交割』的金融期貨，無非就是拿個指數對賭。滬深300啦，VIX期貨啦，莫不如此。

其實只要是有公允數據的東西，都可以拿來對賭，NBA比賽和飛機航班是否延誤之外，還能有各種各樣的公開數據，對沖掉你不想要的任何風險，只要你有交易對手。

其實在區塊鏈智能合約出現之前，金融行業裡已經有個東西有點像智能合約。這東西叫信用證，是銀行開具的。什麼意思呢？

大家都用過支付寶。在淘寶上賣家擔心發貨了買家不付款，買家擔心付款了，賣家不發貨。那怎麼辦？買家先打錢給支付寶，然後支付寶收到錢後告訴賣家買家已經付款，發貨收貨完成后買家確認收貨，支付寶放款給賣家。支付寶是淘寶交易的可信第三方。

信用證是貿易過程中，銀行充當可信第三方的角色。比如A公司要買B公司的貨，是筆跨國貿易。 A公司擔心付錢給B公司貨過不來，B公司擔心發貨了A遲遲不打款。於是，A公司給自己的銀行打保證金讓銀行開具一張信用證給B的開戶銀行，信用證裡寫了只要海關數據顯示貨到了，我就會支付給你錢。如果條件遲遲不觸發，那麼銀行會把保證金退還給客戶。這裡銀行就是支付寶的角色。

問題是如果跨國貿易對手是一家名不見經傳的小銀行怎麼辦？信用不足怎麼辦？

誰都別信誰的，大家用區塊鏈技術做。根本不信任任何機構比任何機構要可信。如今，已經有大量的國際信用證開始使用區塊鏈技術來做了。

智能合約怎麼寫？相信大家已經有數了。

供應鏈金融也是區塊鏈技術應用得比較多的一個領域。

放貸方要知道有沒有真實上下游的交易，應收確權等等。誰都別信誰，上區塊鏈，上下游把自己有沒有發貨有沒有應付寫上去。誰都別想賴賬，明明白白的公開賬本。放貸方就能做風險控制了。

上面說的主要是金融方面的應用，區塊鏈技術能做的其他領域的應用還很多。

比如房地產的確權工作，這比一紙地契要可靠，在一些法治程度比較差的地方應用。還節約了房地產交易的費用，當然這不如打保證金去智能合約裡那麼牢靠。畢竟公開賬本里明明白白就是你的地，地方軍閥完全不可以不認賬。

投票系統也是大的應用場景，不用擔心『被代表』了。因為區塊鏈上所有的信息都是靠數字簽名來驗證你的身份的，並且信息的一致性有保證，所以利用區塊鏈技術可以做到非常可信的投票體系。 NasdQ 交易所的區塊鏈交易系統 Linq 就是個好例子，股票的股東在做投票的時候，誰有多少股誰就有多少個投票權，股東決議變得可信而高效。

區塊鏈技術因為是跑在一個完全P2P的網絡裡的，完全不知道運行在網絡裡的哪裡，擁有絕佳的保密性和安全性。所以有一個比較有意思的項目，利用這個做的保密通訊工具。每個人的身份通過數字簽名技術驗證，不需要根證書啥的。

一個不需要中心化網絡的加密通信信道，簡直可以再造一個升級版暗網。

版權也是個大的應用領域，版權的交易可以去中心。這樣的場景在各行各業還有很多，區塊鏈技術的價值還等待大家去挖掘。

值得一提的是，智能合約的設計是區塊鏈這個技術本身就自帶的。第一個版本的 Bitcoin 就是跑一個腳本來解鎖一個加密數字貨幣的。

大意是說：我希望比特幣在 0.1版就能擁有穩定的架構，未來不需要再做底層改變。在過去幾年設計比特幣的過程中，我發現只有使用腳本系統才能完成我希望支持的各種複雜交易類型——擔保交易、連帶合同、第三方仲裁、多方簽名等等。
中本聪：智能合约？比特币自带：http://www.8btc.com/satoshi-smartcontract

這就叫先見之明。

比特幣 - 總覽

Satoshi Nakamoto：http://p2pfoundation.ning.com/profile/SatoshiNakamoto
整個歷史足跡的整理 (當初的 Email、Code 等)：http://satoshi.nakamotoinstitute.org

version 0.1.3：
https://github.com/trottier/original-bitcoin
https://github.com/trottier/original-bitcoin/commit/92ee8d9a994391d148733da77e2bbc2f4acc43cd

[研發筆記] 比特幣 - Source Code：http://21st.each1.net/2018/03/blog-post_20.html
[研發筆記] 相關技術 Peer-to-Peer：http://21st.each1.net/2018/04/peer-to-peer.html

Original Satoshi Nakamoto Bitcoin White Paper：https://bitcoin.org/bitcoin.pdf
白皮書中文翻譯版本 1：http://www.8btc.com/wiki/bitcoin-a-peer-to-peer-electronic-cash-system
白皮書中文翻譯版本 2：https://zhuanlan.zhihu.com/p/28614698

在2010年8月6日，比特幣協議被發現重大漏洞，在不到一小時內，這筆異常交易就被發現，並在漏洞修復後被從交易記錄上刪除，整個網路也更新為新版的比特幣協議。截至目前為止，這是比特幣歷史上唯一發現並被利用的重大安全漏洞。參見
https://21st.each1.net/2019/03/20108151840.html
https://zh.wikipedia.org/wiki/比特幣歷史

警告消息並不經常使用，但在大多數節點上都有此功能。警告消息是比特幣的“緊急廣播系統”，比特幣核心開發人員可以藉此功能給所有比特幣節點發送緊急文本消息。這一功能是為了讓核心開發團隊將比特幣網絡的嚴重問題通知所有的比特幣用戶，例如一個需要用戶採取措施的的嚴重bug。警告系統迄今為止只被用過幾次，最嚴重的一次是在2013年，一個關鍵的數據庫缺陷導致比特幣區塊鏈中出現了一個多區塊分叉。參見 http://zhibimo.com/read/wang-miao/mastering-bitcoin/Chapter06.html

持續更新中的程式碼：
https://bitcoin.org/en/version-history

https://github.com/bitcoin/bitcoin/releases

Bitcoin 比特幣官方客戶端有兩個版本：一個是圖形界面的版本，通常被稱為 Bitcoin-Qt（首字母大寫），以及一個簡潔的版本（稱為 bitcoind）。它們相互間是兼容的，有著同樣的命令行參數，讀取相同的配置文件，也讀寫相同的數據文件。您可以在同一台電腦中運行其中一個（如果您不小心嘗試同時運行另外一個客戶端，它會提示您已經有一個客戶端在運行並且自動退出）。
Bitcoin-Qt 是使用 Qt 開發的比特幣客戶端，目前該項目已經成為比特幣官方的客戶端，合併到比特幣項目中，不再單獨立項。

詳見：http://webcache.googleusercontent.com/search?q=cache:RdoQ6miaNGgJ:wiki.8btc.com/doc-view-95.htm+&cd=2&hl=en&ct=clnk&gl=tw

精通比特幣：https://github.com/bitcoinbook/bitcoinbook

What does the term "Longest chain" mean, as there is only one 'right' blockchain exists? How another longer chain would make the 'right' chain invalid?
https://bitcoin.stackexchange.com/questions/5540/what-does-the-term-longest-chain-mean

Strongest vs Longest chain and orphaned blocks
https://bitcoin.stackexchange.com/questions/29742/strongest-vs-longest-chain-and-orphaned-blocks

區塊鏈的分叉：https://applealmond.com/posts/22846

SPV、SPV節點和SPV錢包：http://8btc.com/thread-15128-1-1.html

比特幣礦場實錄：https://kknews.cc/tech/2aoq5ge.html

比特幣區塊鏈擴容為什麼選擇 2 MB？
https://book.douban.com/review/8010511/

比特幣區塊 1 MB 大小的起初設置主要是為了防止 DOS 網絡攻擊。粗略計算每秒 3.5 次交易意味著一年要容納 110,000,000 次交易，並伴隨一年 52.56 GB 的區塊鏈增長。也意味著地球上 1.6% 的人每年可以交易一次。
https://kknews.cc/zh-tw/tech/q2poe3o.html

比特幣網絡有兩個特性：清算系統，現金系統。

清算系統

比特幣區塊鏈是全球的、分佈式的、有限容量的、代價昂貴的系統。每一筆交易的價值含量是不一樣的，當塊容量不夠用時，我們應該保障高價值的交易進塊。高價值的交易有意願有能力支付足夠高的網絡手續費，從而獲得足夠高的優先級進塊。
隨著比特幣的繁榮，交易數量會越來越大，有限的塊容量會使得低價值的交易（例如發送1分錢）永遠無法進塊，因為低價值的交易不可能支付高網絡手續費。進而網絡退化為清算系統，低價值含量交易被趕出，這些交易由第三方記賬系統進行代替完成。
在閃電網絡出現之前，第三方記賬系統主要是鏈外錢包提供商。用戶信任某第三方錢包平台，把比特幣存入其中，同一平台用戶之間轉賬僅帶來賬戶餘額變更，並不會產生比特幣交易。

現金系統

現金系統意味著所有交易均應該進入區塊，那麼當塊容量不夠用時，則應該及時提高塊體積限制，對系統進行擴容。短時間可能發生交易入塊堵塞，但長期來看所有交易應該均可以入塊。人人都享有比特幣系統帶來的巨大便利和優勢。

https://zhuanlan.zhihu.com/p/33939518

解決比特幣容量和需求問題有幾種方法：

增加區塊容量，讓節點運營商承擔擴容的成本，這會導致部分節點和挖礦的中心化。
進行鏈下交易，但這類交易安全性不高，也沒有去信任化操作。目前已經有人這麼做了，但這類交易被存儲在大型交易所的私有數據庫裡。
閃電網絡等第二層技術。

再陷三元悖論：閃電網路可能仍存流動性不足問題
https://tw.saowen.com/a/69538eb4fa573d2cb3582a913c37c5d6ddb19fa21c39b99f107bb3ebd433d16c

事實證明，比特幣無法滿足不斷增長的需求，但其並不偏離中本聰原來“點對點電子現金系統”的最初設想。

它目的是提供一種不使用傳統的金融體系、快速、安全且低手續費的支付方式。而如今它依然掌握著相對於Visa、萬事達卡很小的一部分流量，且速度變得非常慢、手續費非常昂貴。

解決比特幣的擴容問題已成為開發人員的首要關注點。但事實證明，這個問題很棘手。

而現在它的缺點反而變成優點：比特幣就是“ 數字黃金” 。其2100萬的內建數量限制，讓它成為了一個類似嚴格的金本位硬通貨金融體系的理想錨定物。一個新的支付系統可以建立在這之上。

問題是，不可能通過完全的去中心化、固定的貨幣供應量和足夠的流動性來建立高效的支付系統。這是比特幣的“三元悖論”。

比特幣硬分叉所衍生出來的議題精選：

硬分叉為 BTC 和 BCH ，背後隱含對隔離見證的思考

簡體版原文：https://zhuanlan.zhihu.com/p/31810122
繁體版翻譯：https://read01.com/zh-tw/PMRM0zk.html

重放攻擊

https://kknews.cc/zh-tw/finance/v3myba.html
https://kknews.cc/zh-tw/tech/bkobgxo.html

算力炸彈

http://nmart.pixnet.net/blog/post/65979778

藉由比較比特幣與乙太幣進行硬分叉後的差異來研究探討

http://8btc.com/thread-49402-1-1.html

區塊鏈概論

區塊鏈技術演進史：http://www.ithome.com.tw/news/105370

2008 年出現的比特幣是第一個採用區塊鏈技術打造出來的 P2P 電子貨幣系統應用，不過比特幣區塊鏈並非一項全新的技術，而是將過去數十年所累積的跨領域技術結合。

比特幣之後也陸續出現許多基於區塊鏈技術的電子貨幣，許多年後，大家才終於意識到區塊鏈的真實價值，不僅僅電子貨幣系統，現在的區塊鏈技術與應用，已經遠超過比特幣這項應用。

由於區塊鏈協議幾乎都是開源的，因此要取得區塊鏈協議的原始碼不是問題，重點是要找到好的區塊鏈服務供應商，協助導入現有的系統。

》1982 年
Leslie Lamport 等人提出拜占庭將軍問題，把軍中各地軍隊彼此取得共識、決定是否出兵的過程，延伸至運算領域，設法建立具容錯性的分散式系統，即使部分節點失效仍可確保系統正常運行，可讓多個基於零信任基礎的節點達成共識，並確保資訊傳遞的一致性，而 2008 年出現的比特幣區塊鏈便解決了此問題。

David Chaum 提出注重隱私安全的密碼學網路支付系統，具有不可追蹤的特性，成為之後比特幣區塊鏈在隱私安全面的雛形。

》1985 年
Neal Koblitz 和 Victor Miller 分別提出橢圓曲線密碼學（Elliptic Curve Cryptography，ECC），首次將橢圓曲線用於密碼學，建立公開金鑰加密的演算法。相較於 RSA 演算法，採用 ECC 好處在於可用較短的金鑰，達到相同的安全強度。

》1990 年
David Chaum 基於先前理論打造出不可追蹤的密碼學網路支付系統，就是後來的 eCash，不過eCash 並非去中心化系統。
Leslie Lamport 提出具高容錯的一致性演算法 Paxos。

》1991 年
Stuart Haber 與 W. Scott Stornetta 提出用時間戳確保數位文件安全的協議，此概念之後被比特幣區塊鏈系統所採用。

》1992 年
Scott Vanstone 等人提出橢圓曲線數位簽章演算法（Elliptic Curve Digital Signature Algorithm，ECDSA）

》1997 年
Adam Back 發明 Hashcash（雜湊現金），為一種工作量證明演算法（Proof of Work，POW），此演算法仰賴成本函數的不可逆特性，達到容易被驗證，但很難被破解的特性，最早被應用於阻擋垃圾郵件。Hashcash 之後成為比特幣區塊鏈所採用的關鍵技術之一。

Adam Back 於 2002 年正式發表 Hashcash 論文。

》1998 年
Wei Dai 發表匿名的分散式電子現金系統 B-money，引入工作量證明機制，強調點對點交易和不可竄改特性。不過在 B-money 中，並未採用 Adam Back 提出的 Hashcash 演算法。Wei Dai的許多設計之後被比特幣區塊鏈所採用。

Nick Szabo 發表去中心化的數位貨幣系統 Bit Gold，參與者可貢獻運算能力來解出加密謎題。

》2005 年
Hal Finney 提出可重複使用的工作量證明機制（Reusable Proofs of Work，RPOW），結合 B-money 與 Adam Back 提出的 Hashcash 演算法來創造密碼學貨幣。

》2008 年
Satoshi Nakamoto（中本聰）發表一篇關於比特幣的論文，描述一個點對點電子現金系統，能在不具信任的基礎之上，建立一套去中心化的電子交易體系。

Blockchain 1.0：加密貨幣
數位貨幣與支付系統去中心化。

》約 2012 年之後

Blockchain 2.0：智慧資產、智慧契約
市場去中心化，可作貨幣以外的數位資產轉移，如股票、債券。如 Colored Coin 便是基於比特幣區塊鏈的開源協議，可在比特幣區塊鏈上發行多項資產。

》約 2014 年之後

Blockchain 2.5：金融領域應用、資料層
強調代幣（貨幣橋）應用、分散式帳本、資料層區塊鏈，及結合人工智慧等金融應用。

Blockchain 3.0：更複雜的智慧契約
將區塊鏈用於政府、醫療、科學、文化與藝術等領域。

更多區塊鏈專題報導：http://www.ithome.com.tw/article/105368

高盛 2016 年區塊鏈 79 頁研究報告：https://read01.com/neJeNn.html
( 收錄了正在實現讓現實世界使用區塊鏈應用的 50 個私人企業與 10 個上市企業 )

高盛眼中的區塊鏈五大應用：https://read01.com/0z2RNR.html
應用一：在 Airbnb 等平台上建立信用體系
應用二：家庭發電與供電
應用三：降低房地產市場交易成本
應用四：改良股票交易機制
應用五：有助於反洗錢及金融企業客戶身份核驗

區塊鏈將成救地球藥方：https://buzzorange.com/techorange/2017/06/09/blockchain-save-earth/

以太幣或成虛擬貨幣老大、2018年底超車？
http://www.msn.com/zh-tw/money/topstories/%E6%AF%94%E7%89%B9%E5%B9%A3%E8%AE%93%E8%B7%AF%EF%BC%81%E4%BB%A5%E5%A4%AA%E5%B9%A3%E6%88%96%E6%88%90%E8%99%9B%E6%93%AC%E8%B2%A8%E5%B9%A3%E8%80%81%E5%A4%A7%E3%80%81%E6%98%8E%E5%B9%B4%E5%BA%95%E8%B6%85%E8%BB%8A%EF%BC%9F/ar-BBCBE1z?li=AA4Zjz&ocid=spartandhp

訂閱：文章 (Atom)