作者作为对区块链和加密货币的零基础小白, 尝试通过本文来整理区块链和加密货币的初步知识和理解. 有谬误之处还请指正. 在此也推荐一个全面引见比特币的博客链接(英文): https://github.cBNBom/bitcoinbook/
bitcoinbook一 、区块链1.1 区块链区块本身是记录任何信息的载体. 则区块链的意义在于, 通过一串有序区块记录的信息历史. 为了保证历史信息的记录"不被篡改",BNB 需要使修改历史的成本变得极高而不可行.
以比特币所依赖的区块链为例, 设每个区块均有一个编号 Block#iBlock\ \#i, 也称为区块高度(Height). 第 ii 块记录的信息为 InfoBNBiInfo_i,考虑一个哈希函数 SHA256
SHA256, 首先该函数输出固定长度的结果, 且哪怕输入类似数据, 输出也大为不同. 则每一个区块放入这个哈希函数后得到的结果 hashi=SHA25BNB6(Block#i,Infoi)hash_i=SHA256(Block\ \#i,Info_i)
都是独一确定的.为了将区块连成链, 要求 InfoiInfo_i 中包含两部分信息 ，一部分称为DatBNBaiData_i; 余下一部分为 hashi−1hash_{i-1} 即前一个区块枚举问题的哈希值. 一旦修改前面任何区块的信息, 或者互换区块的位置都会使得
hashihash_i 发生变化, 所以保BNB证了历史信息的一致性, 但此时的区块链的一致性仍然依赖区块链维护机构的信誉, 中心化的区块链并没有突破传统的共识机制.1.2 分布式区块链与共识机制The essence of blockchain:BNB "consensus system" involving multiple parties and a "strong security mechanism under an open architBNBecture" (Cai 2018).
为了进一步消除对区块链维护机构的依赖, 需要所有参与节点的去中心化(decentralization). 以比特币区块链网络为例, 其建立在一个异步p2p网络之上BNB(Asynchronous Peer-to-Peer Network)
, 要求每一个参与节点均保有相同的区块链, 即分布式区块链(Distributed Blockchain).由于各节点可能存在广播BNB失效或恶意广播的行为, 如何对当前区块链记录达成共识便成为了一个挑战, 该问题便是广为所知的
拜占庭将军问题. 该类问题的处理方法称为Byzantine Fault Tolerance System(BBNBFT). 比特币的BFT设计如下:考虑在区块链的 InfoiInfo_i 中再加入一个特殊变量
nonceinonce_i. 则调查如下运算: 矿工节点通过枚举变量 nonceinonce_i, 使得 BNBhashi=SHA256(Block#i,Datai,hashi−1,noncei)
hash_i=SHA256(Block\ \#i,Data_i,hash_{i-1},nonce_i)<\text{BNBdifficulty}, 其中difficulty为事先决定的常数. 只要成功解算的区块才可以被矿工节点广播并添加到区块链上. 同时要求所有节点(买卖节点 、矿工节点)均执行如下协议: 当出现新加入的区BNB块不一致时, 总是以更长的链为准; 如果长度一致(极小概率), 则保留分叉以至出现更长的链.
显然枚举 nonceinonce_i 需要花费一定算力(称为哈希率, hash rate). 任何修改 BBNBlock#i,Datai,hashi−1Block\ \#i,Data_i,hash_{i-1}
的行为都会导致计算出的 nonceinonce_i 不再为枚举问题的解, 如果修改更往期的区块, BNB会使得被修改的块及其之后的块的所有 noncenonce 值都不再可用, 除非重新计算所有失效的
noncenonce.因而, 如果一个矿工节点在恶意修改区块链记录的基础上解算新块并广播BNB, 则所有人会收到两个版本的新块. 只需该节点不掌握51%以上的算力, 那么这个恶意更改最终会成为孤块(orphaned blocks)
. 而且被恶意修改的块越靠前, 恶意节点所需修改的后续nonceBNBnonce更多, 成本更高. 所以在进行比特币买卖时, 一般需要在买卖写入区块链后多等几个块再确认买卖.上述机制保证了一旦区块被添加到区块链, 则链上信息极难更改.比特币正是通过利用
noncenonBNBce 的计算所消耗的算力来保证共识达成. 因而 nonceinonce_i 便是每个区块所凝结的“劳动”, 又称为 proof-of-work.1.3 比特币的节点、客户端以比特币为例, 买卖节点可通BNB过
Bitcoin Core (社区官方) 等软件参与比特币网络. 有两种买卖节点(与矿工节点不同), 一种称为全节点(full node) 另一种为轻量客户端(light client). 全节点将储BNB存全网所有历史买卖数据的节点(只保存最新版本 ，保留过往所有版本的为更臃肿的archive node), 因而全节点可完整执行区块链中所有规定的验证计算, 具有可自我验证性. 但由于全节点数据过大(目前BNB上百个G)，所以一般买卖所等机构会更多采用全节点(Bitcoin core就是全节点). 而对于普通买卖者 ，可选择轻量客户端(比如Electrum), 但轻量客户端必须通过连接到有全节点的服务器才能正BNB常执行买卖操作. (详见
https://bisontrails.co/blockchain-client-types/).一般买卖客户端都可以生成一个个钱包(wallet)来储存一些公钥私钥对(pubBNBlic-private key pairs)
, 以提交买卖所需的信息. 此外, 客户端还会计算出持有比特币的余额(后面会看到比特币区块链本身不记录余额).买卖节点通过买卖客户端发布比特币的买卖信息 、收BNB听矿工节点广播的区块; 而矿工节点将收听到的信息打包成区块并解算相应
noncenonce, 然后将解算好的区块广播并添加到之前收听的区块链上.二 、加密货币由于分布式区块链网络具有可信的信息BNB记录, 因而可以在区块链中记录各种买卖对应的等价交换价值; 而这种信誉需要矿工节点的算力以维持, 必然要在添加新块的同时给予成功解算出新块的矿工以一定激励价值. 正是这两点缘由共同催生了分布式区块链网BNB络的内生的货币. 比特币就是最好的例子.
由于算力随着矿工节点数目的添加(减少)而变强(变弱), 为了维持稳定的解出速度/出块速度, 需要相应提高(降低) difficulty. 在比特币的例子中, dBNBifficulty一般是一个以多个0开头固定长度的16进制数. difficulty越高, 开头的0数目越多. 调整周期为两个星期.(这种设计也存在问题, 拥有大量算力的矿池可以突然减少算力使得难度调BNB低, 在接下来的2个星期低难度的环境下再突然恢复高算力以获取更大相对优势).
三、信息传递的匿名性与零知识证明在具体进入比特币区块链的买卖方式之前, 本节先讨论如何在藏匿身份情况下验证身份.考虑参与人 BNBAA 向 BB 发送信息内容 mm, 则除 AA 之外的人如何证明的确由
AA 发出信息, 且信息内容是 mm 呢？ 设所有参与人 ii 都有公钥 pubkeyipubkey_BNBi 和私钥 privkeyiprivkey_i. 所有人都晓得所有人的公钥, 但所有人的私钥均对外人保密.
则通过数字签名算法 SigSig, AA 通过计算 signBNBature=Sig(m;privkeyA)signature=Sig(m;privkey_A) 便得到 AA 对信息内容
mm 的独一签名, 即任何对 mm 的修改均会得到不BNB一样的签名, 不同发出人的签名也不同.因而 AA 在向 BB 发送信息 mm 的同时还需发送相应签名 signaturesignature
. 而通过验证函数 SigVerify(pubkeyABNB,m,signature)SigVerify(pubkey_A,m,signature) 取值能否为真, 便可晓得能否是 AA 发出的信息 ，且信息内容为
mm.这种在不晓得 privkeyApriBNBvkey_A 时证明真实性的方法称为零知识证明(zero-knowledge proof).四、买卖记录方式比特币的账簿系统并非记录所有人的余额(Balance), 否则账簿仍然会记录每个独立BNB账户的所有买卖. 相反，一笔比特币买卖数据本质上是一个invoice账单. 在付款人(sender)领取时, 通过回溯付款人之前买卖中收到的invoice来确认当前这笔买卖的资金来源. 这种回溯性也保BNB证了至多在逻辑上每笔买卖不会被
双花(Double Spending), 但现实中由于区块链的特点仍有可能出现双花.据此, 每一笔比特币的买卖(Transaction, TX)一般包含如下内容:4.1 BNB买卖(TX)所包含的内容TX Output
: 包括: 本次买卖所需付给各个收款人的金额(value)和包含账单地址(Invoice Address, 本质是hashed receivers publiBNBc keys)的脚本.收款人在后续买卖使用这笔invoice之前, 这笔TX Output都被标记为一个
Unspent Transaction Output(UTXO). 每笔TX被添加到区块链后所有BNB全节点均会标记产生的的UTXO, 进而生成一个 UTXO set, 记录相应的金额与账单地址脚本.但由于无法通过账单地址反推收款人的公钥, 因而仅有收款人的储存了相应公钥的钱包客户端在收听到区块链中的BNB这个UTXO后才会晓得这笔UTXO是领取给本人的, 进而将这个UTXO加入余额.
可以将UTXO比喻为一个匿名的漂流瓶, 仅有收款人能识别并证明所有权. 因而账单地址脚本又称redeem conditiBNBon/locking script.TX Input: 包括: 本次买卖所需援用(refer to)之前sender作为收款人的买卖中, sender拥有使用权的UTXO. 然后需要sender以脚本BNB方式1提供相应公钥 、签名以证明两点: 1. sender确实拥有UTXO的所有权；2. sender的确为本次input发起人.
可以将这两点验证比喻为解锁匿名漂流瓶, 因而也称这个脚本为unlockiBNBng script.在买卖确认后, 这笔output会被记为spent. 则一旦TX input这两步验证成功且在区块链上成功确认, 则被redeemed的UTXO变为spent transactioBNBn output(STXO), 便从所有全节点的UTXO set中除名, 则sender无法再发出同样的买卖信息, 也就保证了UTXO的一次性使用. 而且一旦UTXO变为STXO, 也就暴露了所有者(BNB也即sender)的公钥.
按照这个思路, 下面简述比特币的两种具体买卖脚本类型:4.1 P2PKH(Pay-to-Public-Key-Hash)举例以如下买卖例: 记第1号 为 TX1TX1, 其BNB中Bob向Clement领取50 Satoshi.
付款人(Bob)需要解锁本人的UTXO: Bob通过援用之前本人为收款人的UTXO以作为 TX1TX1 的资金来源 (refer to soBNBme UTXO of TX0TX0 where Bob is receiver as the input ingredient for
TX1TX1). 假设在之前存在一笔买卖 TXBNB0TX0, 其中index为0的output中, Alice曾向Bob领取过60 Satoshi, 且该Output未被花费(unspent), 则
TX0TX0 的 output BNB#0 可被援用. 这个信息包含如下要素:output{TX0#0}:={value0=60,scriptPubKey0:=Hash160(PubkeyBob)}
output_{\{TX0\ \#0\}BNB}:=\{value_0 = 60, scriptPubKey_0:=Hash160(Pubkey_{Bob})\}.留意, 真实的 scriptPubKey
0scriptPubKey_0 还需包BNB含相应的脚本命令, 这个 scriptPubKey0scriptPubKey_0 就是 TX0TX0 的locking script/redeem condition;
下面说明Bob在发起领取时提交的BNB inputinput 所需包含的要素:第一, Bob 需要在买卖 TX1TX1 中援用 TX0TX0 中index为0的UTXO:
previous_txid=HBNBash(TX0),index=0previous\_txid=Hash(TX0),index=0. 其中, txidtxid: transaction identifier.
因而所有全节点客BNB户端可以通过买卖的哈希值回溯到 output{TX0#0}output_{\{TX0\ \#0\}} 中, 并找到金额与locking condition: scriptPubKey0scriptPuBNBbKey_0
.第二, 为了验证 Bob 有权使用该笔output (TX0TX0, #0), 需要提供 Bob 本人的public key:PubkeyBobPubkey_{Bob}因BNB此各个客户端只需计算
Hash160(PubkeyBob)Hash160(Pubkey_{Bob}) 能否等于 scriptPubKey0scriptPubKey_0 中 Hash160(PubkeBNByBob)Hash160(Pubkey_{Bob})
便可验证 Bob 能否有使用权.第三, 为了验证 TX1TX1 确实由 Bob 本人发起, 需要查验Bob在input中提交的signaturBNBe:Signature=ECDSA(scriptPu
bKey0,PrivkeyBob)Signature = ECDSA(scriptPubKey_0,Privkey_{Bob}), 其中 ECDSBNBAECDSA: Elliptic Curve Digital Signature Algorithm.
则通过验证函数 Checksig(Signature,PubkeyBob)=?{True,FalsBNBe}Checksig(Signature,Pubkey_{Bob})=^{?}\{True,False\}
即可验证发起人能否为 Bob.记 scriptSig1:={PubkeyBob,SiBNBgnature}scriptSig_1:=\{Pubkey_{Bob},Signature\}. 留意, 真实的
scriptSig1scriptSig_1 还需包含相应的脚本命令. 综上, Bob 通BNB过提交如下 inputinput 便可发起领取:input:={previous_txid,index,scrip
tSig1}={previous_txid,index,{PubkeyBob,SignBNBature}}input:=\{previous\_txid,index,scriptSig_1\}=\{previous\_txid,index,\{Pubkey_{Bob},Signature\}BNB\}
然后说明Bob在发起领取时提交的 outputoutput 所需包含的要素:与 TX0TX0 中 Alice向Bob领取的60 Satoshi 时相同, 此时Bob向Clement领取BNB50 Satoshi
output:={value=50,scriptPubKey1:=Hash160(PubkeyClement)}output:=\{value = 50, scriptPubKeyBNB_1:=Hash160(Pubkey_{Clement})\}
outputoutput中一般还包括找零:由于被援用UTXO可能出现大于领取金额的情况, 所有剩余均会领取给矿工作为买卖费(TransacBNBtion Fee). 因而一般output中还需包含以sender本身为收款人的找零
找零(Change), 本例中10 Satoshi 将分为找零与买卖费.可以发现, 一笔UTXO就是一个锁定的待使用BNB的比特币, 所有UTXO就是比特币的存量, 比特币买卖的本质上就是这种right to unlock/redeem的流转.
4.2 P2SH(Pay-to-Script-Hash) 原理根据 GavinBNB Andresen 的说法, "(P2SH) Is to move the responsibility for supplying the conditions to redeem a transaBNBction from the sender of the funds to the redeemer". 在P2PKH下, 一笔买卖的output中需要sender提供包含redeemer/receiBNBver invoice address的locking script. 但当redeemer对接收地址的安全性有特殊需求时, 会将redeem condition/locking script设计得比BNB较复杂。
此时sender无需对这种复杂的安全设计担任，而该当交由redeemer本人来担任处理sender仅需知晓这种复杂设计通过加密后产生的P2SH address即可. 具体实现如下:设redeeBNBmer所设计的
Full Redeem Script 为 FRSFRS. 一般情况下, FRS={pubkey1,...,pubkeyn}FRS=\{pubkey_1,...,pubkey_n\} BNB即包括了一组公钥. 因而sender以P2SH方式付款给redeemer时仅需提供包含
P2SHaddress=Hash(FRS)P2SH\ address=Hash(FRS) 的 scriptPubBNBKey0scriptPubKey_0 脚本作为redeem condition.则redeemer使用这笔UTXO时, 需要提供
inputinput 如下: 首先, 需要提供完整的 FRSFRS.BNB 通过计算FRSFRS 的 HashHash 函数值, 与被援用买卖的scriptPubKey0scriptPubKey_0 中P2SH invoice address进行比对. 而在原来的P2PKHBNB中, 需要提交redeemer单个public key生成的invoice address进行比对, 这个区别正是P2
PKH与P2SH名字中的差别.之后与P2PKH一样, 需要提交签名, 签名通过reBNBdeemer private keys 与 redeemed output information加工而成. 此时允许多个签名
signature:={sig1,...,sigm}signature:=BNB\{sig_1,...,sig_m\}. 则此时仍记 scriptSig:={FRS,Signature}scriptSig:=\{FRS,Signature\}
.这种 redeemBNB condition 称为 mm-of-nn multi-signature transaction.除了上述两种脚本类型之外还有一种bc1, 这里不再详述.4.3 具体买卖操作
可通过具有HierarBNBchical deterministic wallet(HD wallet) 功能的的客户端, 通过12个英文单词作为seed生成一个包含一定数目的(一般为100)公钥私钥对的钱包. 通过一个公钥, BNB可以确定地生成一个
收款地址(invoice address, P2PKH以1开头, P2SH以3开头, bech32以bc1开头).对于每一笔收款该当使用独一的invoice(也意味着为一的公钥私钥对BNB以备未来redeem这笔收入). 考虑一个批发商作为收款方的情况, 如果Alice已经付款后, Bob拿着同样的已经公开的invoice来谎称这笔付款是Bob而非Alice领取的, 由于比特币网络的匿BNB名性, 无法实名找到付款人, 因而会引起纠纷. 同样, 在进行领取时需要要求收款人提供独一的invoice.
除此之外, 在收付款时必须确保收款人保有这笔invoice对应的私钥. 例如当用一个重生成的BNB地址收款时, 如果不慎丢失了对应的公钥(比如钱包回滚到之前未生成新地址时的钥匙备份), 则一旦有付款汇入这个地址, 任何人将永远无法再解锁这笔UTXO, 因而使用HD wallet可通过保存seed来BNB生成所需钥匙对来避免这个问题.
还木有评论哦，快来抢沙发吧~