zoukankan      html  css  js  c++  java
  • 区块链:最小可行区块链原理解析1

    加密货币, 特别是比特币,几乎从各个方面都得到了大量关注:规则,管理,税务,技术,产品创新等等,不胜枚举。“点对点(去中心化)电子现金系统”的概念颠覆了我们以前对货币和金融所持有的设想。

    即便如此,把数字货币方面搁到一边,还有一个可以说是更有趣更深远的创新,即底层的区块链技术。 无论你对比特币或是它的山寨币衍生品有什么看法,作为一种货币和价值存储手段,它们背后的运作基础都来自于中本聪概括的区块链原理:

    我们运用点对点网络提出了重复花费问题的解决方案。网络通过将交易散列到一个进行中的基于散列的工作量证明链,来对交易进行时间戳标记,并形成一个记录,这个记录只有在重做工作量证明的情况下才能被改变。最长的链不仅作为它所见证事件发生时序的证据,而且也证明它来自最大的CPU功率池……网络本身要求架构最小化。

    区块链对任何“货币”都是不可知的。 事实上,它可以(并且将)适用于促成很多其他使用案例。 因此,理解“最小可行区块链”背后的方法和原理是有好处的:

    • 以下不是对比特币区块链的分析。事实上,我有意省略了讨论货币方面,以及比特币区块链在当今生产环境中运用的很多附加特性。

    • 以下试图从头开始解释为什么需要特定的部分(数字签名,工作量证明,交易区块),以及它们如何集合起来形成具有卓越性能的“最小可行区块链”。

    我很久以前就认识到,写作可以帮我提炼和改进自己草率粗浅的想法,于是有了这篇文章。虽然写这篇文章主要为了梳理自己的思路,但我也希望能对别人有所帮助。欢迎反馈,在下面留言!

    • 用三式记账法保障交易安全
    • 用公钥基础设施(PKI)保障交易安全
    • 余额 = Σ(收据)
    • 多方转移与验证
    • 重复消费与分布式一致性
      • 分布式一致性网络的需求
      • 保护网络免受Sybil攻击
      • 参与所要求的工作量证明
    • 建立最小可行区块链
      • 添加“区块”和交易费用激励
      • 竞争以赢取交易费用
      • 解决链冲突
      • 没有哪个区块是“最后一个”
    • (最小可行)区块链属性

    用三式记账法保障交易安全

    Alice和Bob是集邮爱好者。不是很严肃的那种,主要是为了社交层面的见面,交流故事,偶尔也会做做交易。如果双方都看到喜欢的东西,可以当场协商完成交换。换言之,这是个简单的以物易物的系统。

    有一天Bob拿来一枚邮票,Alice觉得她必须要收藏,但问题是Bob对Alice所提供的交换物都不是特别感兴趣。Alice沮丧不已,她继续和Bob协商,最后达成一致:他们做个单方交易,Bob先把邮票给Alice,Alice承诺以后再偿还Bob。

    Bob和Alice已经认识有一阵子了, 但是为了确保两个人都信守承诺(主要是Alice),他们同意让朋友Chuck来对交易“进行公证”。

    他们把上图这个可以表明Bob给了Alice一枚“红色邮票”的交易收据做了三个副本(三方各持一份)。Bob和Alice可以用收据来记录他们的交易, Chuck存储副本作为交易证据。这个设定很简单,但其中有一些很重要的属性:

    1. Chuck可以鉴定Alice和Bob两个人的真实性,以确保不会有人在他们不知情的情况下蓄意伪造交易。

    2. Chuck的账簿中的收据证明了交易发生。如果Alice声称交易从未发生,那么Bob可以去找Chuck,用他的收据来证明Alice说谎。

    3. 如果Chuck的账簿中没有收据,就证明交易未发生过。Alice和Bob都不能伪造交易。他们可以伪造交易收据,声称对方说谎,但同样的,他们可以去找Chuck,查看他的账簿。

    4. Alice和Bob都不能篡改当前的交易。如果任意一方篡改了交易,他们可以去Chuck那儿,用储存在Chuck账簿中的副本核实他们的副本。

    以上操作的就是“三式记账法”,操作简便,对参与双方都能提供很好的保障。但当然你也看到了它的缺点,对吧?我们对中间人寄予了很大的信任。如果Chuck决定和另一方串通,那么整个系统就土崩瓦解了。

    这个故事说明什么道理呢?选择中间人一定要(非常)慎重!

    用公钥基础设施(PKI)保障交易安全

    Bob不满于使用“可靠中间人”的不安全性,他决定研究一下,发现公钥密码可以免去使用中间人的需要!这里需要解释一下……

    公钥密码,也叫做不对称密码,指的是一种密码算法,它需要两个单独的钥匙,一个是秘密的(私有的),另一个是公共的。尽管这个钥匙对的两部分不同,但有数学联系。公钥用于对纯文本加密或者查验数字签名;私钥用于解密密码文本或者创建数字签名。

    运用第三方(Chuck)的原本意图是要确认有三个属性:

    • 验证真实性: 不能有恶意的一方伪装成其他人。
    • 不可否认性: 事实发生后,参与方不能声称交易没有发生过。
    • 完整性:事实发生后,不能再修改交易收据。

    结果是,公钥密码可以满足以上所有要求。简单地说,工作流程如下:

    1.Alice和Bob分别生成一个固定的公钥-私钥对。

    2.Alice和Bob公布出他们的公钥。

    3.Alice以纯文本的形式写一个交易收据。

    4.Alice用她的私钥对交易信息的纯文本进行加密。

    5.Alice在密码文本上添加一个“由……签名”的纯文本备注。

    6.Alice和Bob都储存相应的输出结果。

    注意只有在多方参与的时候才需要第五步:如果你不知道是谁签署了信息,就不知道该用谁的公钥来解密。这个问题很快就会变得有关紧要……

    这看起来像是没什么特别理由的大量工作,但我们还是来检验一下新收据的属性:

    1.Bob不知道Alice的私钥,但问题不大,因为他可以查询她的公钥(公钥是全世界共享的),然后用公钥来解密交易的密码文本。

    2.Alice并不是真的在给交易内容“加密”,而是通过使用她的私钥给她“签名”的交易编码:任何人都可以用她的公钥对密码文本进行解密,由于她是唯一拥有私钥的人,这个机制保证了只有她能生成交易的秘密文本。

    Bob或针对这个问题的任何其他人,如何获得Alice的公钥?有很多种方法来分发公钥——例如,Alice公布在她的网站上。我们可以假定有这样的合适的机制。 因此,使用公钥基础设施(PKI)可以满足我们之前所有的要求:

    1.Bob可以用Alice的公钥通过解密密码文本来证明签名交易的真实性。

    2.只有Alice知道她的私钥,因此Alice不能否认交易的发生——她已经签名了。

    3.没有Alice的私钥,Bob或任何其他人都不能伪造或修改交易。

    注意第二条,Alice可以否认她是那个有争议的公钥-私钥对的真正所有者——比如第一条中提到的人伪造了她的身份。钥匙对来标识关联是钥匙分发机制需要考虑的问题。

    Alice和Bob只储存了签名交易的副本,消除了对中间人的需要。“神奇”的公钥密码和双方以物易物系统完美匹配。

    余额 = Σ(收据)

    随着公钥基础设施到位,Bob和Alice又完成了一些交易:Alice从Bob处得到另一张邮票,Bob从Alice那儿也挑了一张邮票。 它们都按照与之前相同的步骤,生成签名交易并将它们附加到各自的分类账簿中。

    记录是安全的,但有一个小问题:不清楚是否任何一方有未结余额。先前只有一个交易,很清楚是谁欠谁的(Alice欠Bob)以及欠了多少(一枚红色邮票),但是有多个交易以后,情况变得模糊起来。所有的邮票都是等值的吗?如果是,那么Alice有一个负余额。如果不是,那就谁也说不准了!为了解决这个问题,Alice和Bob达成一致如下:

    • 黄色邮票的价值是红色邮票的两倍。

    • 蓝色邮票和红色邮票等值。

    最后为了确保他们新协议的安全性,他们用交易的相对值更新了每个交易,重新生成了分类账簿。新的账簿看起来像下面这样:

    这样,计算最终余额现在变成了一个简单的事,循环访问所有的交易,将适当的借贷记录应用于各方。最终结果是Alice欠Bob 2个……价值单位。什么是“价值单位”? 它是由Alice和Bob都同意的任意交换媒介,另外,由于“价值单位”并不耳熟能详,Alice和Bob同意将1个价值单位称为1个chroma(复数形式:chroms)。

    上面这些看起来都是小事,但每一个参与者的余额都是分类账簿中所有收据的一个函数这一事实有重要的意义:任何人都可以计算大家的余额。不需要任何可靠的中间人,也不必对系统进行审计。任何人都可以遍历整个分类账簿,核实交易,计算出每一方的未结余额。

    下一篇文章我们将会介绍《区块链(32):最小可行区块链原理解析2》

    本文翻译自W3C网络性能工作组联席主席 & 谷歌员工 Ilya Grigorik的大作《Minimum Viable Block Chain》。感谢朝夕团队Azure, Bob的翻译和校验。

    这篇文章也收录在《程序员》杂志2017年1月的封面专题区块链中:http://geek.csdn.net/news/detail/132424

  • 相关阅读:
    生日小助手源码运行的步骤
    关于生日小助手跨平台兼容性的临时解决方案
    生日小助手V3.0——跨平台的农历生日提醒软件
    生日小助手V3.1——跨平台多语言的农历生日提醒软件
    有关生日小助手的内容,请浏览生日小助手官方网站……
    生日小助手的详细规划——本博文随时更新,持续有效
    生日小助手V2.0发布了——可以正式投入使用!
    前端开发入门的几本推荐书籍
    多想一想,JS中函数声明和函数表达式的区别
    table固定宽度大小
  • 原文地址:https://www.cnblogs.com/hzcya1995/p/13313413.html
Copyright © 2011-2022 走看看