公链开发学习笔记(三):图灵完备和非图灵完备操作码解析

0 首先得有一个交易

  • 交易是状态读取和修改的基础
  • BTC的交易:bip125,可以用更多的fee代替原来的fee,使得交易优先被打包
  • ETH的交易:nonce,记录账号中的交易的序号,和比特币中bip125的功能类似,可以用nonce值更大的交易(更加新的交易)代替之前的交易
  • BTC和ETH的共同点:都有区块和交易相关的参数

1 Bitcoin非图灵完备操作码设计

  • 主要以检查状态为主
  • 没有loop:无法完成循环,比如累加计算
  • 栈式操作码,从左向右
  • bitcoin操作码实例
    • 普通的比特币地址交易:OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
    • 锁定: OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
    • bug bounty:OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL

2 EVM图灵完备操作码的边界控制

  • EVM是一个沙盒
  • EVM中主要做计算valid state:进行状态的修改,但是仅限于和链不相关的修改
  • EVM通过很多的操作码组成
  • EVM扩展设计流程
    • EVM是一个256 bit的电脑,因为需要能适应256位的ETH hash algorithm(sha3)
    • precompile contract的工程实现,可以脱离原有的gas设计
    • 增加新操作码需要在opcode增加,需要对solidity进行更改
  • EVM操作码的边界的控制
    • 沙盒:读取状态为主,修改状态要注意
    • 兼容性:以增加操作码为主
    • 复杂度:由于相关function需要全节点执行,所以不能太高

3 图灵完备EVM设计的必要性

  • 需要了解真实的需求,是否需要全部操作
    • 如果只是需要以交易为主的公链,则不需要图灵完备
    • 如果需要在链上开发dApp,则需要图灵完备的虚拟机,添加新的opcode,改造solidity语言
  • 需要判断是否需要设计尺寸很大的交易
  • 需要评估更改EVM的难度以及实际工程师技术栈是否对应

4 工程设计的选择:wasm或EVM扩展

  • wasm
    • 可扩展性强
    • 多平台
    • 适用于CPU架构
    • 例如EOS:关注点不在虚拟机上,而是设计一套治理机制,VM只是一个实现工具,所以选择速度更快的wasm
  • EVM扩展
    • 设计更多的precompiled contract
    • dapp开发者的学习成本更低
    • 可以更好的定点支持function
    • EVM是一个沙盒,不能从外界拿取数据,否则其他节点难以对计算的结果进行验证

你可能感兴趣的:(公链开发学习笔记(三):图灵完备和非图灵完备操作码解析)