公链开发学习笔记（二）

公链设计两种思路

1.由顶向底：目前设计者经验不足，难以驾驭

2.由底向顶：从一个原始的区块链项目，主键增加函数，形成一个功能齐备的公链。本课程采用这样的方式。

如何选择共识机制

• POW的工程化实际实现

• POS的工程化实际实现

• 通过实现的目标选择共识

  • PoW：更加去中心化

    • 先演示一个只有POW的简单区块链，代码在 https://github.com/GenaroSanada/Course中可以找到，演示了一个PoW挖矿的实现过程。

    • go run pow/main.go，启动服务程序

    • 打开新的命令行，用curl命令： curl -i -X POST -H 'Content-Type: application/json' -d '{"Result": 42}' http://localhost:8080

    • 服务端接收到命令，开始挖矿

    • PoW通过difficulty设置难度值，可以根据memory hard分为抗asc矿机和不抗asc矿机的类型

  • PoS：更加低功耗

    • 主要是根据押注的大小设计排序方式，无论是随记排序还是顺序排序

    • go run pos/main.go，启动程序。

    • 在命令行输入：nc localhost 8545，输入token balance和Result

    • 和POW不同，POS没有在generis block中做太多的事情，而是在如何做排列上做了很多事情。POS的核心就是找到一个合理的排列的方法，可以是随机或者顺序的，只要排列的方法难以凑成固定的顺序。如果顺序是有规律的，就可能引发连环作恶的可能。需要有额外的信息来生成随机数，因为没有额外的信息，区块链中的随机数都不是真的随机数，区块链也很难记录下随机数。

    • 随机数是需要被证明的，而随机数的过程难以证明。如果过程容易证明，那么就是一个固定的数而不是随机数。所以需要去合理地设计一个随机的过程。

  • PoX：自定义的proof需要满足几个特性

    • 节点的参与需要有门槛

      • 门槛的范围必须一开始是小范围，然后慢慢扩大。在工程化的过程中，这种方式可以比较快的找到问题并进行处理。

    • 签名验证时间短

      • proof，即验证，需要的时间要短，才可能有比较高的tps。

    • 节点提供时间维度的信息

      • POX是一种异步的点对点的系统，节点如果不提供时间维度的信息的话，就有人能在时间维度进行作弊。

如何使用通信协议

• 通信协议的选择

  • go get -d github.com/libp2p/go-libp2p，可以直接用IPFS的P2P进行快速开发。目前点对点的协议比较成熟，基本都是根据DHT分布式哈希表进行逐步演进的。

  • DHT分布式哈希表，三代DHT

    • Chord(通过自己找到上下家，然后再找上下家，如此遍历)、Pastry（查找速度比较快，全部查找，组成圆形的结构）

    • Tapestry

    • Kadmelia：是目前工程上主要使用的是第三代的分布式哈希表。

      • Kad协议

        • 主要使用项目：Ethereum、Emule、IPFS、Genaro

        • 使用的主要原因：有账户系统（nodeID），快速查找节点，可以防止flood攻击，适用于KV系统

  • 在项目文件夹目录下运行：go run main.go -l 10000 -secio，启动节点

  • 然后复制产生的新的连接当前节点的命令，新打开一个命令行，运行，例如:go run main.go -l 10006 -d /ip4/127.0.0.1/tcp/10004/ipfs/QmNyoZF6tHdfPNme1K7XKk5a47pa9uir8zUKBSQWBpZvyx -secio

主流公链设计比较

• Bitcoin

  • 工程化的使用POW实现了去中心化，开启了新纪元

  • UTXO需要更少的空间，提供了账户的隐私。

  • 开启了大航海时代

• Ethereum

  • POW的抗asic的改造——dagger，memory hard的POW方式

  • 基于Kad改造的P2P协议创造了account系统

  • 加入EVM，开启了智能合约时代。

  • 加入gas的设计，防止黑客的攻击

• EOS

  • 非常完善的治理结构设计

  • 相对比较大的账户系统——开户费

  • 偏向于中心化的高速TPS公链——适合金融为主的dApp

• NEO

  • 趋向于中心化的节点设计

  • 相对完善的社区提交机制

  • dBFT共识：继承了BFT的优点以及竞选在里面

• Qtum

  • POS共识机制更低功耗

  • x86虚拟机兼容性更高

  • AAL涵盖了UTXO和account

• Genaro

  • SPoR+POS低功耗的同时加入存储提供辅助

  • EVM虚拟机上加新的pocode保证dapp开发者迁移

  • Kad同构允许一个账户nodeID绑定储存和公链

设计高tps公链的工程思路

• 更好的共识机制

• 更快的验证时间

• 高TPS=部分去中心化