V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
wuyahuang
V2EX  ›  区块链

从程序员的角度思考什么是区块链 ( 一 )

  •  
  •   wuyahuang · 2019-03-21 20:18:53 +08:00 · 1244 次点击
    这是一个创建于 2070 天前的主题,其中的信息可能已经有所发展或是发生改变。

    在现有的互联网公司业务场景中,不管前端跟用户交互的方式是浏览器网站、手机软件还是电脑软件,本质上用户看到的所有信息都来自于数据库,用户的增、删、改、查所有行为也最终都是在与服务提供商的数据库通信。我每天使用手机里的 APP 都会在想,如果某个 APP 后台数据库故障,数据丢失,或者被人恶意篡改。我当如何?是否有解决方案呢?

    方案 A :

    假如我们有一个分布式的数据库 X,它不受任何个人、组织控制,每个人都可以搭建自己的节点,节点的数据始终保持同步,且都拥有新增、修改、删除的权限,所有数据修改记录完全公开透明可追溯。

    A、B、C 三个团队准备将自己的数据存储于 X,分别搭建了自己的节点,由于不信任其他节点的 RPC 接口,所以分别开发了自己的 RPC API 给前端使用,用户可以通过三个团队任意的接口修改自己的数据。假设用户 Alice 的账户余额为 100 元,同时执行了以下三个操作:

    1. 向团队 A 的接口发送请求,给用户 Bob1 转出 70 元,节点 A 修改数据,Bob1 余额新增 70 元,Alice 余额减去 70 元。
    2. 向团队 B 的接口发送请求,给用户 Bob2 转出 80 元,节点 B 修改数据,Bob2 余额新增 80 元,Alice 余额减去 80 元。
    3. 向团队 C 的接口发送请求,给用户 Bob3 转出 90 元,节点 C 修改数据,Bob3 余额新增 90 元,Alice 余额减去 90 元。

    以上 3 条数据修改操作被同时同步到分布式数据库网络中,其他节点到底以谁的记录为准呢?

    从上面的示例可以看出,如果分布式数据库的每一个节点都有增加、删除、修改的权限,那数据会乱套,我们需要避免这种情况,是否可以让分布式数据库中只有一个节点拥有修改数据的权限?显然不行,又回到了老路上,太过于中心化。是否可以随机让某一个节点拥有修改数据的权限?我们来尝试下。

    方案 B1 :

    在方案 A 的基础上,我们做出以下调整:

    1. 每一个节点都可以接收用户的数据修改操作,但是不入库,所有修改操作在分布式数据库网络中实时广播,每十分钟由某一个随机的节点把接收到的数据修改操作统一执行入库。
    2. 为了保证十分钟左右只有一个随机节点获得执行数据入库的权限,我们让所有节点运算同一套数学题,找出以若干个 0 开头的 Hash 值。

    Hash 值是由数字和大小写字母构成的字符串,每一位有 62 种可能性(可能为 26 个大写字母、26 个小写字母,10 个数字中任一个),假设任何一个字符出现的概率是均等的,那么第一位为 0 的概率是 1/62 (其他位出现什么字符先不管),理论上需要尝试 62 次 Hash 运算才会出现一次第一位为 0 的情况,如果前两 2 位为 0,就得尝试 62 的平方次 Hash 运算,以 n 个 0 开头就需要尝试 62 的 n 次方次运算。假如 Hash 值以 18 个 0 开头,理论上需要尝试 62 的 18 次方次,这个数是非常巨大的。

    方案 B2 :

    在方案 A 的基础上,我们做出以下调整:

    1. 每一个节点都可以接收用户的数据修改操作,但是不入库,所有修改操作在分布式数据库网络中实时广播,每 6 秒由某一个随机的节点把接收到的数据修改操作统一执行入库。
    2. 所有分布式数据库节点以及用户进行投票,按得票数选出 21 个节点为超级节点,这 21 个节点按顺序轮流拥有 6 秒执行数据入库的权限。

    以上两个方案 B1、B2 分别代表了 PoW、DPoS 两种共识机制,可以很好的解决随机选出某一节点执行入库操作的问题。如果 Alice 发送上述的 3 条交易,仅有交易 1 会被执行,交易 2、3 由于余额不足将被拒绝执行。

    某一天,团队 D、E 团队决定一起加入分布式数据库 X,准备搭建节点开始同步数据,由于数据量实在太大,预计需要 1 天的时候才能同步完所有的数据操作记录,这个时候 Alice 又来了,她通过团队 D 的接口向用户 Bob4 转出了 100 元,由于新加入的 2 个节点数据未同步完,没有之前 Alice 向账户 Bob1 的转账记录,所以 Alice 的账户余额是 100 元,节点 E 认可这笔交易的合法性,因此这笔交易转账成功。

    在这个时候分布式数据库 X 已经出问题了,节点 A、B、C 的数据显示,Alice 向 Bob1 转出 70 元。节点 D、E 的数据显示,Alice 向 Bob4 转出 100 元。如何避免这种情况?是否可以让所有节点都处在同一个时间线上?

    方案 C :

    在方案 B1 / B2 的基础上,我们做出以下调整:

    1. 把每一个节点执行的所有交易压缩打包在一起,称之为区块,每生成一个新的区块,区块 ID 加 1。
    2. 为防止节点 D 同步区块的中途有人恶意篡改数据,每一个区块都将上一个区块的 Hash 值一起打包生成 Hash 值。

    经过以上调整,新节点 D、E 认可的 Alice 转账交易打包进区块以后,由于跟新接收到的区块数据不一致,导致最终该交易被拒绝执行。

    到这里一个简单的分布式数据库完成了,因为其数据结构是一个一个区块串联在一起,一旦某一个区块被篡改,其 Hash 值将会变更,后面所有的区块都有问题,因此称之为区块链。

    下一期将会聊一聊区块链里面的密码学知识。

    guokeke
        1
    guokeke  
       2019-03-22 00:46:33 +08:00
    菠菜链牛逼
    xianfeng09
        2
    xianfeng09  
       2019-03-23 10:14:47 +08:00
    厉害~这才是真正的区块链~

    我个人业余也会看一些区块链的东西~ 自己要做了一个区块链学习笔记:

    []( https://github.com/xianfeng92/Love-Ethereum)

    有机会可以一起交流~~
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2657 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 36ms · UTC 00:24 · PVG 08:24 · LAX 16:24 · JFK 19:24
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.