建立:2019.3.19
第2讲:比特币中的密码学原理
用到的主要功能:1.哈希函数 2.签名 密码学中的哈希被称为cryptographic hash function
哈希主要性质: 1.哈希碰撞(collision resistance) 假如有一个256位的哈希,其输入最多有2^256种,但输入有无限种,所以肯定会发生碰撞。
2.Hiding:计算过程不可逆,根据计算结果无法推算出原数据 成立条件(不容易被破解):1.输入空间足够大,很难使用brute-force破解2.输入取值分布均匀
以上两者结合在一起,可以实现digital commitment(有时也称为digital equivalent of a sealed envelope)
实际中操作:(输入空间不足够大)在输入添加一个随机数,一起取哈希,保证了输入随机、取值分布均匀。
比特币中用到的哈希函数还有第三个性质:puzzle friendly 提前无法预算结果,若想要值落入某个范围只能一个个试
建立:2019.3.19
第14讲:ETH-以太坊概述
比特币出块时间:10分钟 以太坊出块时间:十几秒 以太坊为了适应新的出块时间设计了一套GHOST协议的共识机制
第二个改进:mining puzzle 比特币:计算密集型,比拼哈希计算速度。所以需要专业挖矿设备。使用ASIC芯片
以太坊(memory hard mining puzzle):需要大量内存。在一定程度限制ASIC使用,ASIC resistance [proof of work(工作量证明)+proof of stake 混合共识机制] (BTC的共识机制PoW可能导致 51%攻击)
三:支持smart contract(智能合约) (BTC)BitCoin:decentralized currency (ETH)Ethereum:decentrialized contract
建立:2019.3.20
第15讲:以太坊的账户
一、 1.比特币:transaction based measure 系统不显示记录账户上多少钱,利用UTXO推算。 好处:每笔交易记录了钱的来源,隐私保护好 问题:(使用别扭)等号两边必须相等,必须说明来源,必须花完所有钱 面临主要挑战:double spending attack (双花攻击)花出去的钱又花了一次 具体:1)51%攻击: http://baijiahao.baidu.com/s?id=1601520668493386036&wfr=spider&for=pc https://www.jianshu.com/p/d6be6637edc1 2)时间窗口:https://www.chainnode.com/post/176206
2.以太币:account-based ledger 系统显式记录系统上有多少以太币 交易时只检查钱是否够,不检查钱的来源 好处:以太坊的交易模式 有效防御了double spending attack 不会引发 有人篡改自己的余额数据 的数据,(状态树)因为系统全节点维护的状态中保存了余额信息 面临挑战:replay attack (重放攻击)放了两次交易 e.g:A给B转账10 ETH,将这个交易放到网络上,过了一段时间交易被写到了区块链上,B又将这个交易重新广播了一遍,结果A向B转账了两次。 解决:以太坊加了一个计数器nonce计算一个用户有史以来的交易次数。转账时,当前交易次数(每次新的交易+1)成为交易内容的一部分,都受着发布交易者签名的保护。 [系统中每个节点维护一个账户,不仅要维护它的balance(余额),还要维护其nonuce。] 如果有人重放这个交易,看其nonce值,若nonce与之前的重复,说明这个交易已经进行过了,就不会再执行一遍。
二、以太坊中的两类账户 1.外部账户(普通账户):有balance和nonce 利用公私钥(类似比特币),有私钥的一方有控制权 只有外部账户能发起交易 2.合约账户:有balance,nonce ,code,storage(包括每个变量的取值) 不能自己发起交易,但可以:外部账户向合约账户A发起一个交易,然后A调用合约账户B 如何被调用:创建一个合约时会返回一个合约的地址 调用过程中,状态会发生变化(存储会变)
建立:2019.3.20
第16讲:以太坊中的状态树(部分,未完)
状态是外部账户和合约账户的状态 实现 账户地址到账户状态的映射
以太坊中用的addr是160 bits的,一般表示为40个十六进制数。
1.将哈希表的内容组成一棵Merkle Tree? 不可行。 如果用Merkle Tree,每有一个新交易、增加一个区块,就要重新生成一棵Merkle Tree。 (比特币中Merkle Tree是把区块里包含的交易变成一棵树,区块里的交易每发布一个新的区块对应生成一棵树,构建完后不会更改。 每个交易大概250MB,区块里最多4000个交易(上限),最后把这几百个、几千个交易构建成一个Merkle Tree)??? 若以太坊将所有的以太账户遍历一遍构建成一个Merkle Tree,代价太大了
Merkle Tree除了 提供Merkle Proof 证明账户上有多少钱 以外, 还有 维护各个全节点间状态的一致性(每个全节点在本地维护一个哈希表,不放出根哈希值,无法知道自己的数据结构状态和别人的是否一致;对当前区块有哪些交易,全节点要有共识)。 (方法不可行,每次构建Merkle Tree的代价太大 :每个全节点在本地维护一个哈希表,需要构建Merkle Tree时再将 根哈希值发到Merkle Tree里)
2.不用哈希表,直接把所有账户放进Merkle Tree 不可行。 1.Merkle Tree不提供高效的查找、更新的方法。 2.要不要排序(Sorted Merkle Tree) 1)不排序: (1)查找速度慢 (2)如果不规定账户在叶节点出现顺序,构建出来的Merkle Tree不是唯一的,算出的根哈希值也是不一样的 【在比特币中交易顺序也是不一样的,但有一个区别:每个节点在本地组装一个候选区块,自己决定哪些交易以什么顺序被打包到区块里;挖矿后获得记账权的那个节点发布自己的区块,决定顺序】 在以太坊中不适用:每个全节点自己决定怎么把账户组织成一个Merkle Tree,算出哈希值,挖矿后,发布到区块里,但发布的是所有账户的状态,而不是区块里包含的交易。比特币中发布交易只有几百个、几千个,一个区块里的交易只能改很少的账户,大多数账户状态不变,而以太坊若要发布账户状态不是一个数量级的。 2)排序: 新增一个账户,地址是随机的,可能是插在中间的,那么后面的那些树的结构都要变,代价太大。
3.以太坊采用MPT结构(Merkle ) 前提补充:Trie树(从“retrieval信息检索(前缀树,字典树)”来的)