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是一个沙盒，不能从外界拿取数据，否则其他节点难以对计算的结果进行验证
