公链开发学习笔记（三）：图灵完备和非图灵完备操作码解析

0 首先得有一个交易

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

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

• 主要以检查状态为主
• 没有loop：无法完成循环，比如累加计算
• 栈式操作码，从左向右
• bitcoin操作码实例
  • 普通的比特币地址交易：OP_DUP OP_HASH160<pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
  • 锁定：<expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> 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是一个沙盒，不能从外界拿取数据，否则其他节点难以对计算的结果进行验证