1、区块链中的智能合约EVM 架构原理当前智能合约的问题Go 智能合约常见问题及其防护EVM 架构原理以太坊Geth以太坊GethSolidity合约上链0 x6080合约创建交易ERC20调用请求合约执行交易合约上链交易广播和共识以太坊合约的执行EVM 字节码合约上链合约代码服务寻址EVM 字节码业务逻辑EVM 字节码EVM 字节码整体结构合约服务跳转表合约初始化合约运行时构造合约业务逻辑实现初始化 Storage 变量、构造子合约等返回合约运行时合约运行时的入口合约具体业务逻辑实现StackMemory 协议返回 内部参数 内部返回Storage 状态变量 局部变量Call DataEVM 存
2、储系统EVM 交易传参参数会以一定方式编码成字节传输调用返回跟参数使用同样的编码方式EVM Memory使用长度00000 x00:0 x20:0 x40:0 x60:草稿区用户区Solidity 没有内存复用，新变量直接由空地址开始存放Solidity 中所有内存对象都占用 32 个字节的整数倍Solidity 内存不支持变长类型EVM/Solidity Storage基本类型：依次排列，落在一个 256 位字内部组合类型：起始位置 256 位对齐，成员按顺序编码0 x00:0 x20:0 x40:0 x60:对象编码编码开始EVM/Solidity Storage变长数组：长度放在当前位置
3、，数据从 Keccak256(cur)开始存放长度数据curKeccak256(cur)编码开始EVM/Solidity Storage0 x0000数据 kcurKeccak256(cur.k)编码开始字典：当前 32 字节弃用，key k 对应的数据放在 Keccak256(cur.k)EVM 结构图上下文信息：对应于 Solidity 中 block.xx、tx.xx交易信息：对应于 Solidity 中 msg.xxEVM 字节码栈内存Call DataStateDB交易信息PC上下文信息Ret Data栈内存StateDBEVM 解释器EVM 字节码PC随机寻址随机寻址随机寻址直接访
4、问操作栈顶上下文信息交易信息Call DataRet DataEVM 执行模型局限性EVM 的局限性（1）EVM 没有适合编译优化的中间表示（Solidity 提供并改进中）EVM 没有任何的编译优化相关的内容（分析、动静态优化）EVM 没有任何层次上的并行模型（SIMD、MIMD、VLIW、）EVM 没有自动甚至手动存储管理（Solidity 也很简单）EVM 同时只能操作 17 个局部变量（受限于 Swap 指令）EVM 的局限性（2）Solidity 的中间表示层还不太稳定Solidity 目前只有简单的编译优化Solidity 没有并行执行模型（EVM 不提供）Solidity 没有自
5、动存储管理，手动管理也很粗糙其他选择只有 SIMD 而已NEO：.NET NEO（没有并行）EVM 的 SIMD 指令（EIP 616，进展缓慢）eWASM：SIMD 使能了，多线程还不支持Go 智能合约设计智能合约需要什么确定性：不确定性导致的不可重复验证安全性：智能合约的隔离终止性：Gas 控制确定性带来的问题在库层面做裁剪（常见方案是不支持所有已有库）在预编译过程做裁剪（目前没有具体实践）在语法树上做裁剪（目前没有具体实践）加强编译器语义检查（目前没有具体实践）语言标准中的未定义行为消除（EVM 没有，EOS 提及少但很重视）裁剪执行指令集（常见方案，因此禁止了很多高性能方案）不确定行为
6、审计、监测、动态管理（联盟链有类似方案）私链跟公链不一样私链可以提供严格的审查制度，可以考虑保留高性能特性私链的智能合约不应该只做简单的转账交易Go 语言的优势完善的编译优化框架和算法（分析、动静态优化）完善的并行模型（SIMD、MIMD、VLIW、）完善的存储管理成熟的同步异步并行执行模型成熟的自动存储管理，如引用计数和 GC 等Go 智能合约合约编译：约定合约构造函数、构建跳转表合约上链：源代码上链合约执行：调用执行+启动缓存安全管理：合约池做进程隔离、API 做链数据库权限管理合约管理：合约通过严格审计测试后再上线Go 智能合约的应用用于开发 360 磐石链共识的股权抵押和 VRF 自选举股权抵押数据需要达成全网共识，需要使用智能合约VRF 函数不可能使用 Solidity 开发在我们能确保它的确定性的情况下，我们选择了 go
sgpjbg002
工作日 8:30 - 17:30
报告分类
