连载:Qtum量子链设计文档(六):x86虚拟机重塑智能合约生态

量子链Qtum2018-06-25 18:29:55  阅读 -评论 0

连载:Qtum量子链设计文档(六):x86虚拟机重塑智能合约生态点击上方蓝字关注QTUM公众号,了解最新行业资讯

连载:Qtum量子链设计文档(六):x86虚拟机重塑智能合约生态

以下内容整理来自Qtum量子链吴明


Qtum原始设计文档汇总(6)-- Qtum x86虚拟机

前面的章节中我们介绍过,Qtum采用分层的设计,利用Qtum AAL,使得以太坊虚拟机EVM可以运行于底层的UTXO模型之上,从而能够兼容以太坊的智能合约。然而,EVM本身有诸多限制,且目前只兼容Solidity这一种高级语言进行智能合约编写,其安全性和成熟度都还需要时间的验证。Qtum AAL在设计之初就考虑兼容多种虚拟机,因此在初始兼容EVM之后,Qtum团队就致力于兼容更加主流架构的虚拟机,进而兼容主流编程语言与工具链。

Qtum x86虚拟机是Qtum项目2018年的开发重点,旨在打造一个兼容x86指令集的虚拟机,并提供类似操作系统层面的调用,旨在将智能合约开发推向主流。

以下截取部分早期Qtum开发团队针对Qtum x86虚拟机的相关原始设计文档(附中文翻译)(ps:文档中QTUM<#>或QTUMCORE<#>为内部设计文档编号):

QTUMCORE-103:[x86lib] Add some missing primary opcodes Description:There are several missing opcodes in the x86 VM right now. For this story, complete the following normal opcodes (it should just be a lot of connecting code, nothing too intense) //op(0x9C, op_pushf); //op(0x9D, op_popf); //op(0xC0, op_group_C0); //186 // C0 group: _rm8_imm8; rol, ror, rcl, rcr, shl/sal, shr, sal/shl, sar //op(0xC1, op_group_C1); //186 // C1 group: _rmW_imm8; rol, ror, rcl, rcr, shl/sal, shr, sal/shl, sar Notes: •   Make sure to look at existing examples of similar code in the VM code. •   Look at the x86 design document references for some good descriptions of each opcode •   Ask earlz directly about any questions •   At the top of opcode_def.h there is a big comment block explaining the opcode function name standard and what things like "rW" mean •   Implement the first opcode listed and then have earlz review to make sure things looks correct Task:【x86lib】添加一些遗漏的主操作码 描述:目前在x86虚拟机中遗漏了一些操作码(opcodes)。在该任务中,完成下述标准的操作码(应该只是一些连接代码,不需要太紧张) //op(0x9C, op_pushf); //op(0x9D, op_popf); //op(0xC0, op_group_C0); //186 // C0 group: _rm8_imm8; rol, ror, rcl, rcr, shl/sal, shr, sal/shl, sar //op(0xC1, op_group_C1); //186 // C1 group: _rmW_imm8; rol, ror, rcl, rcr, shl/sal, shr, sal/shl, sar 注意: •   确保在VM(虚拟机)代码中查看现有的类似代码示例 •   查看x86设计文档,以便更好地了解每个操作码 •   有任何问题直接问Earlz •   在opcode_def.h的顶部,有一大段注释,解释操作码函数名称标准以及“rW”等关键字的意思 •   实现列出的第一个操作码,然后让Earlz检查以确保代码看起来是正确的。

QTUMCORE-106: [x86lib] Add some more missing primary opcodes Description: There are several missing opcodes in the x86 VM right now. For this story, complete the following normal opcodes (it should just be a lot of connecting code, nothing too intense) //op(0x60, op_pushaW); //186 //op(0x61, op_popaW); //186 //op(0x6C, op_insb_m8_dx); //186 //op(0x6D, op_insW_mW_dx); //186 //op(0x6E, op_outsb_dx_m8); //186 //op(0x6F, op_outsW_dx_mW); //186 Notes:  •   Make sure to look at existing examples of similar code in the VM code. •   Look at the x86 design document references for some good descriptions of each opcode •   Ask earlz directly about any questions •   At the top of opcode_def.h there is a big comment block explaining the opcode function name standard and what things like "rW" mean •   Implement the first opcode listed and then have earlz review to make sure things looks correct Task:【x86lib】添加一些遗漏的主操作码 描述:目前在x86虚拟机中遗漏了一些操作码。在该任务中,完成下述标准的操作码(应该只是一些连接代码,不需要太紧张) //op(0x60, op_pushaW); //186 //op(0x61, op_popaW); //186 //op(0x6C, op_insb_m8_dx); //186 //op(0x6D, op_insW_mW_dx); //186 //op(0x6E, op_outsb_dx_m8); //186 //op(0x6F, op_outsW_dx_mW); //186 注意: •   确保在VM(虚拟机)代码中查看现有的类似代码示例 •   查看x86设计文档,以便更好地了解每个操作码 •   有任何问题直接问Earlz •   在opcode_def.h的顶部,有一大段注释,解释操作码函数名称标准以及“rW”等关键字的意思 •   实现列出的第一个操作码,然后让Earlz检查以确保代码看起来是正确的。

QTUMCORE-104: [x86lib] Add some missing extended opcodes Description: There are several missing opcodes in the x86 VM right now. For this story, complete the following extended (0x0F prefix) opcodes (it should just be a lot of connecting code, nothing too intense) opx(0xA0, op_push_fs); //386 opx(0xA1, op_pop_fs); // 386 opx(0xA8, op_push_gs); //386 opx(0xA9, op_pop_gs); //386 opx(0xAF, op_imul_rW_rmW); //386 opx(0xB0, op_cmpxchg_rm8_al_r8); //48 opx(0xB1, op_cmpxchg_rmW_axW_rW); //486 for(int i=0;i<8;i++) { opx(0xC8 + i, op_bswap_rW); } Notes:  •   Make sure to look at existing examples of similar code in the VM code. •   Look at the x86 design document references for some good descriptions of each opcode •   Ask earlz directly about any questions •   At the top of opcode_def.h there is a big comment block explaining the opcode function name standard and what things like "rW" mean •   Implement the first opcode listed and then have earlz review to make sure things looks correct Task:【x86lib】添加一些遗漏的扩展操作码 描述:目前在x86虚拟机中遗漏了一些操作码。在该任务中,完成以下扩展(0x0F前缀)操作码(应该只是一些连接代码,不需要太紧张) opx(0xA0, op_push_fs); //386 opx(0xA1, op_pop_fs); // 386 opx(0xA8, op_push_gs); //386 opx(0xA9, op_pop_gs); //386 opx(0xAF, op_imul_rW_rmW); //386 opx(0xB0, op_cmpxchg_rm8_al_r8); //48 opx(0xB1, op_cmpxchg_rmW_axW_rW); //486 for(int i=0;i<8;i++) { opx(0xC8 + i, op_bswap_rW); } 注意: •   确保在虚拟机代码中查看现有的类似代码示例 •   查看x86设计文档,以便更好地了解每个操作码 •   有任何问题直接问Earlz •   在opcode_def.h的顶部,有一大段注释,解释操作码函数名称标准以及“rW”等关键字的意思 •   实现列出的第一个操作码,然后让Earlz检查以确保代码看起来是正确的。

以上一系列任务实现了x86虚拟机内核部分(x86lib)大多数必须的操作码,这些是虚拟机能够识别和运行x86指令的基础,其功能相当于x86指令的模拟器。

QTUMCORE-105: [x86lib] Research how to do automated testing for x86lib Description: Research and look for viable ways to do automated testing of x86lib's supported opcodes Task:研究怎样对x86lib进行自动测试 描述:研究并寻找可行的方法对x86lib支持的opcodes进行自动测试

Qtum团队通过上述任务实现了对x86虚拟机内核的自动化测试,因为底层指令的解析和运行错误往往很难通过调试发现,必须借助一些自动化测试工具。这确保了x86lib内核的正确性。

QTUMCORE-108: [x86] Add missing device manager functions Description: In device_manager.cpp there are several stub functions that have no functionality. such as MemorySystem::Remove(). These have not been needed so far, but will soon be needed. Add these missing functions, refactor the existing code there if needed, and add unit tests for the entire class Task:【x86】添加遗漏的设备管理函数 描述:在device_manager.cpp中,有一些没有功能的stub函数,例如MemorySystem::Remove()。目前为止,这些函数还不需要,但很快就会用到。添加这些漏掉的函数,必要的时候重构现有的代码,并对整个类进行单元测试

上述任务预留了未来可能用到的设备管理相关函数。

QTUMCORE-109:[x86] Add "reason" field for all memory requests Description:In order to prepare for the upcoming gas model, a new field needs to be added to every memory access. This field basically gives the reason for why memory is being accessed so that it can be given a proper gas cost. Possible reasons: Code fetching (used for opcode reading, ModRM parsing, immediate arguments, etc) Data (used for any memory reference in the program, such as mov [1234], eax. also includes things like ModRM::WriteWord() etc) Internal (used fro any internal memory reading that shouldn't be given a price.. probably not used right now outside of testbench/testsuite code) This "reason" code can be place in MemorySystem(). It shouldn't go in each individual MemoryDevice object Task:[x86]对所有的内存请求添加“reason”字段 描述:为即将使用的gas模型做准备,需要在每个内存访问中添加一个新的字段。这个字段基本上给出了为什么内存被访问的原因,这样就可以给出合适的gas花费。 可能的原因有: •   抓取代码(用于opcode读取,ModRMB解析,即时的参数,等等) •   数据(用于程序中的内存引用,例如mov[1234],eax,也包括类似ModRM::WriteWord()的操作等等) •   内部请求(用于任何不需要花费gas的内部的内存读取…目前只在testbench/testsuite代码中使用) “reason”代码可以放在MemorySystem()中。它不应该放在任何单个的MemoryDevice对象中。

上述任务主要针对Qtum x86全新的gas模型,预留了单独的字段用于辨别不同类型的内存访问请求。目前仅用于验证可行性,未来会用于计算真实的gas价格。

QTUMCORE-114: [x86] Add various i386+ instructions Description: Implement (with unit tests for behavior) the following opcodes and groups: //op(0x62, op_bound_rW_mW); //186 //op(0x64, op_pre_fs_override); //386 //op(0x65, op_pre_gs_override); //386 // op(0x69, op_imul_rW_rmW_immW); //186 (note: uses /r for rW) // op(0x6B, op_imul_rW_rmW_imm8); //186 (note: uses /r for rW, imm8 is sign extended) //op(0x82, op_group_82); //rm8, imm8 - add, or, adc, sbb, and, sub, xor, cmp task:【x86】添加各种i386+指令 描述:实现(并进行单元测试)下列操作码和groups: //op(0x62, op_bound_rW_mW); //186 //op(0x64, op_pre_fs_override); //386 //op(0x65, op_pre_gs_override); //386 // op(0x69, op_imul_rW_rmW_immW); //186 (note: uses /r for rW) // op(0x6B, op_imul_rW_rmW_imm8); //186 (note: uses /r for rW, imm8 is sign extended) //op(0x82, op_group_82); //rm8, imm8 - add, or, adc, sbb, and, sub, xor, cmp

QTUMCORE-115: [x86] Implement more i386+ opcodes Description: Implement with unit tests the following opcodes: (notice opx is extended opcode) //op(0xC8, op_enter); //186 for(int i=0;i<16;i++) { opx(0x80+i, op_jcc_relW); //386 opx(0x90+i, op_setcc_rm8); //386 } opx(0x02, op_lar_rW_rmW); opx(0x03, op_lsl_rW_rmW); opx(0x0B, op_unknown); //UD2 official unsupported opcode opx(0x0D, op_nop_rmW); //nop, but needs a ModRM byte for proper parsing opx(0xA0, op_push_fs); //386 opx(0xA1, op_pop_fs); // 386 opx(0xA2, op_cpuid); //486 opx(0xA3, op_bt_rmW_rW); //386 opx(0xA4, op_shld_rmW_rW_imm8); //386 opx(0xA5, op_shld_rmW_rW_cl); //386 opx(0xA8, op_push_gs); //386 opx(0xA9, op_pop_gs); //386 opx(0xAA, op_rsm); //386 opx(0xAB, op_bts_rmW_rW); //386 opx(0xAC, op_shrd_rmW_rW_imm8); //386 opx(0xAD, op_shrd_rmW_rW_cl); //386 make sure to remove these opcodes from the commented todo list as they are implemented Task:【x86】实现更多的i386+指令 描述:实现以下操作码并进行单元测试: (注意opx是扩展操作码) //op(0xC8, op_enter); //186 for(int i=0;i<16;i++) { opx(0x80+i, op_jcc_relW); //386 opx(0x90+i, op_setcc_rm8); //386 } opx(0x02, op_lar_rW_rmW); opx(0x03, op_lsl_rW_rmW); opx(0x0B, op_unknown); //UD2官方不支持的操作码 opx(0x0D, op_nop_rmW); //nop,但需要一个ModRM字节来进行正确的解析 opx(0xA0, op_push_fs); //386 opx(0xA1, op_pop_fs); // 386 opx(0xA2, op_cpuid); //486 opx(0xA3, op_bt_rmW_rW); //386 opx(0xA4, op_shld_rmW_rW_imm8); //386 opx(0xA5, op_shld_rmW_rW_cl); //386 opx(0xA8, op_push_gs); //386 opx(0xA9, op_pop_gs); //386 opx(0xAA, op_rsm); //386 opx(0xAB, op_bts_rmW_rW); //386 opx(0xAC, op_shrd_rmW_rW_imm8); //386 opx(0xAD, op_shrd_rmW_rW_cl); //386 这些操作码实现后确保从注释的TODO列表中删除它们。

QTUMCORE-118: Implement remaining opcodes in x86lib Description: The remaining opcodes that do not result in an error or change of behavior should be implemented with unit tests. Take particular care and use many references for some of the weird opcodes, like nop_rm32. Task:实现x86lib剩余的操作码 描述:剩余的不会导致出错或行为改变的操作码应该通过单元测试来实现。需要特别小心,并参考一些怪异的操作码,比如nop_rm32。

上述一系列任务进一步增加了对i386+操作码的支持,并实现了最后一部分必要的其余操作码。至此x86lib已经可以支持大部分i386+的指令。

QTUMCORE-117: Begin leveldb-backed database for x86 contracts Description: For this story, the code work should done as a sub-project from Qtum Core, and can be done direclty in the Qtum Core github. For now, unit and integration tests should be used to confirm functionality. It will be integrated into Qtum Core later. You might need to modify Qtum Core some so that the project is built with proper dependencies however. This story will implement the beginnings of a new database that will be used for smart contracts. This will only store meta-data, contract bytecode, and constructor data for right now:  The leveldb dataset for this data should be named "contracts". The key for this dataset should be a 256-bit contract address (exact format will be specified later) represented as a hex string. The value data should contain the following: •   txid of contract creation (with this the chainstate db can be used to lookup blockhash) •   VM version •   contract creation parameters (see "contract deployment" page in design) •   contract creation data (the constructor data) •   contract bytecode The interface for reading and writing into this database should be clear and extensible. Although it is being designed for the x86 VM, other VMs in the future will also use it. Task:实现x86合约中支持leveldb的数据库 描述:对于该任务,应该在Qtum Core的子项目中编写代码,并且可以直接在Qtum Core github上完成。目前,应该使用单元测试和集成测试来确认功能的正确性,后面代码会集成到Qtum Core中。可能需要适当修改Qtum Core,使得该项目具有合适的dependencies。该任务将实现一个可用于智能合约的新数据库的雏形。这个数据库目前只存储meta-data,合约字节码,以及构造函数数据。 数据的leveldb数据集应该命名为“合约”。数据集的密钥应该是一个256位十六进制字符串的合约地址(具体的格式将在后面指定)。 Value数据应该包含以下部分: •   合约创建的交易id(链状态数据库可以用它来查找区块哈希) •   虚拟机版本 •   合约创建参数(见设计中的“合约部署”页面) •   合约创建数据(构造函数数据) •   合约字节码 数据库读取和写入的接口应该是清晰和可扩展的。虽然是为了x86虚拟机设计的,但是将来其他的虚拟机也可以使用。

上述任务实现了x86合约可用的最基本的leveldb数据库,该数据库目前只存储一些特定的诸如合约代码的数据,未来可以继续扩充。并且在设计上强调了接口的通用性,为未来其他虚拟机的调用提供了便利。

QTUMCORE-119: Research needed functions in Qtum's version of libc Description: We should evaluate the C99 standard library specifications to determine which functions should be supported in the x86 VM, with easy to use tooling provided to developers (ie, a custom toolchain). List the headers and functions that are common enough to warrant support, as well as is agnostic to the operating system, or can in some way fit into the operating system like model of Qtum's x86 VM. Task:研究Qtum的libc版本中需要的功能 描述:我们应该评估C99标准库规范,以确定在x86虚拟机中应该支持哪些功能,并可以较容易地使用提供给开发者的工具(例如,一个定制的工具链)。列出最常见的必须要支持的函数头和函数,这些函数头和函数对操作系统是不可知的,或者在某种程度上适合类似于Qtum x86虚拟机模型的操作系统。

基于c99标准库规范,Qtumx86虚拟机实现了简化版的libc库,供智能合约开发者使用。

QTUMCORE-126: [x86] [Compiler] Figure out and document a way of compiling/packaging the QtumOS GCC toolchain for Windows, Linux, and OSX Description: We should evaluate the C99 standard library specifications to determine which functions should be supported in the x86 VM, with easy to use tooling provided to developers (ie, a custom toolchain). List the headers and functions that are common enough to warrant support, as well as is agnostic to the operating system, or can in some way fit into the operating system like model of Qtum's x86 VM. Task:[x86][编译器]找出并记录一种适用于Windows,Linux和OSX的编译/打包QtumOS GCC工具链的方法 描述:作为一个合约开发者,我不希望在开发x86虚拟机合约的时候一定要编译QtumOS工具链。 对于该任务,研究并记录怎样构建用于Windows,Linux和OSX的QtumOS GCC工具链。在所有的平台上使用该工具链应该具有相同的体验。照着该文档,任何人都应该能编译GCC的pre-built版本。

为了使在任何通用平台下都能使用相同的编译工具,上述任务实现了跨平台的预编译好的gcc工具,方便智能合约开发者使用。

QTUMCORE-127: [x86] [libqtum] Add basic blockchain data APIs Description: As a contract devleoper, I want to be capable of getting basic blockchain data like network weight without needing to know how to write assembly code.  For this story, create a new project for libqtum to compile to libqtum.a using the QtumOS compiler, and place all definitions in a qtum.h file. The first operations to be added are some basic system calls for the following: •   Access to past 256 block hashes •   Block gas limt •   MPoS staking address for block (only the 0th address indicating the block creator) •   Current block difficulty •   Previous block time •   Current block height These functions are not yet built into the x86 VM or Qtum, so these will just be mocks for now that can't be tested until later. API list: •   previousBlockTime() -> int32 – syscall(0) •   blockGasLimit() -> int64 – syscall(1, &return); •   blockCreator() -> address_t – syscall(2, &return); •   blockDifficulty() -> int32 – syscall(3); •   blockHeight() -> int32 – syscall(4); •   getBlockHash(int number) -> hash_t (32 bytes) – syscall(5, number, &return); Note, this inline assembly code can be used as a template for safely using the "int" opcode from C code, and should be capable of being put into a .S assembly file and used via: //in C header extern long syscall(long syscall_number, long p1, long p2, long p3, long p4, long p5, long p6); //in .S file ; User mode .global syscall ; long syscall(long number, long p1, long p2, long p3, long p4, long p5, long p6) syscall: push %ebp mov %esp,%ebp push %edi push %esi push %ebx mov 8+0*4(%ebp),%eax mov 8+1*4(%ebp),%ebx mov 8+2*4(%ebp),%ecx mov 8+3*4(%ebp),%edx mov 8+4*4(%ebp),%esi mov 8+5*4(%ebp),%edi mov 8+6*4(%ebp),%ebp int $0x40 pop %ebx pop %esi pop %edi pop %ebp ret task:[x86][libqtum]添加基本的区块链数据APIs 描述:作为一个合约开发者,我希望不会编写汇编代码的情况下也能获取基本的区块链数据,比如网络weight。 对于该任务,创建一个libqtum的新项目,使用QtumOS编译器编译成libqtum.a,并将所有的定义放入qtum.h文件中。第一个需要添加的操作就是基本的对以下各项的系统调用: •   访问过去的256个区块哈希 •   区块gas limit •   区块的MPoS staking地址(只有第0个地址指示区块的创建者) •   当前区块难度 •   前一个区块的时间 •   当前区块的高度 这些功能还没有构建到x86虚拟机或者Qtum中,因此这些只是暂时的模拟,以后才能进行测试 API列表: •   previousBlockTime() -> int32 – syscall(0) •   blockGasLimit() -> int64 – syscall(1, &return); •   blockCreator() -> address_t – syscall(2, &return); •   blockDifficulty() -> int32 – syscall(3); •   blockHeight() -> int32 – syscall(4); •   getBlockHash(int number) -> hash_t (32 bytes) – syscall(5, number, &return); 注意,这个内联汇编代码可以作为安全使用C代码的“int”操作码的模板使用,并且应该能够被放入到一个.S的汇编文件中,并通过以下方法使用: //in C header extern long syscall(long syscall_number, long p1, long p2, long p3, long p4, long p5, long p6); //in .S file ; User mode .global syscall ; long syscall(long number, long p1, long p2, long p3, long p4, long p5, long p6) syscall: push %ebp mov %esp,%ebp push %edi push %esi push %ebx mov 8+0*4(%ebp),%eax mov 8+1*4(%ebp),%ebx mov 8+2*4(%ebp),%ecx mov 8+3*4(%ebp),%edx mov 8+4*4(%ebp),%esi mov 8+5*4(%ebp),%edi mov 8+6*4(%ebp),%ebp int $0x40 pop %ebx pop %esi pop %edi pop %ebp ret

区块链的基本数据在智能合约编写时非常有用,然而对于普通智能合约开发者,在不提供更多工具的情况下很难获取这些数据。上述任务提供了获取区块基本数据的API,使得开发者能够快速获取相关区块数据,从而提高智能合约开发效率。

QTUMCORE-128: [x86] [VM] Add very basic gas system Description: As a contract devleoper, I want to test how intensive my prototype x86 smart contracts will be on a real blockchain. For this story, add a very basic gas model to the x86 VM. There should be a new option added to Execute() that allows for specifying an absolute gas limit that execution will error upon hitting. It should also be possible to retrieve how much gas was used during the execution of the program. For this basic gas model, each instruction is 1 gas. It is ok if there are edge cases where an instruction might not be counted. Task:[x86][VM]添加最基本的gas系统 描述:作为一个合约的开发者,我想测试我的原型x86智能合约在真正的区块链上的强度。 对于该任务,添加一个非常基本的gas模型到x86虚拟机中。应该有一个新的选项添加到Execute()中,允许指定一个绝对的gas limit,只要达到该值运行就一定会出错。还应该可以在程序运行的过程中计算使用了多少gas。对于这个基本的gas模型,每个指令为1gas。如果出现指令可能没有被计算的边界场景,也是可以的。

上述任务实现了x86虚拟机最基本的gas系统,可用于计算合约在真实区块链上具体需要消耗的gas。

QTUMCORE-129: [x86] [DeltaDB] Add very basic prototype version of DeltaDB Description: As a contract developer, I want my prototype x86 contracts to persist within my own personal blockchain so that I can do more than just execute them. I need to be able to call them after deployment. Right now, we will only concern ourselves with loading and writing contract bytecode. The key thus should be "bytecode_%address%" and the value should be the raw contract bytecode. The contract bytecode will have an internal format later so that bytecode, constant data, and contract options are distinguishable in the flat data. The exposed C++ class interface should simply allow for the smart contract VM layer to look up the size of an address's code, load the address's code into memory, and write code from memory into an address's associated data store. Look at how the leveldb code works for things like "txindex" in Qtum and model this using the Bitcoin database helper if possible. There is no need for this to be tied to consensus right now. It is also OK to ignore block disconnects and things that would cause the state to be reverted in the database. Please do all work based on the time/qtumcore0.15 branch in Qtum Core for right now. Also, for the format of an "address", please look for "UniversalAddress" in the earlz/x86-2 branch, and copy the related code if needed. Task:[x86][DeltaDB]添加最基本的DeltaDB原型版本 描述:作为一个合约的开发者,我希望我的原型x86合约可以在我自己的区块链中存在下去,这样我能做的就不仅仅是运行它们。我希望在部署之后能够调用它们。 现在,我们只关心加载和写入合约字节码。因此,关键的应该是"bytecode_%address%",并且值应该是原始的合约字节码。合约字节码将会有一个内部格式,这样字节码、常量数据以及合约选项可以在flat数据中区分开。 公开的C++类接口应该允许智能合约虚拟机层查找地址代码的大小,将地址的代码加载到内存中,并将代码从内存中写入地址的关联数据存储中。 看看在Qtum中“txindex”这类东西的leveldb代码如何工作,如果可以的话,使用比特币数据库helper对其进行建模。现在没有必要把这个问题和共识关联起来。也可以暂时忽略区块断开以及将导致数据库中状态恢复的情况。 现在请基于Qtum Core的time/qtumcore0.15分支完成所有的工作。另外,对于“地址”的格式,请在earlz/x86-2分支中查找"UniversalAddress",需要时可以复制相关代码。

上述任务为x86虚拟机增加了最基本的数据库DeltaBD,可以用来存储合约状态,是合约调用的必要条件。

QTUMCORE-130: [x86] [UI] Add "createx86contract" RPC call Description: As a smart contract developer, I want to be capable of easily deploying my contract code without too much worrying. In this story, add a new RPC call named "createx86contract" which accepts 4 arguments: gas price, gas limit, filename (ELF file), and sender address. The ELF file should be tore apart into a flat array of data representing the contract data to be put onto the blockchain. 1. int32 size of options 2. int32 size of code 3. int32 size of data 4. int32 (unused) 5. options data (right now, this can be empty, and size is 0) 6. code memory data 7. data memory data Similar ELF file processing exists in the x86Lib project and that code can be adapted for this. Note that there should be some way of returning errors and warnings back to the user in case of problems with the ELF file. After the contract data is extracted and built, a transaction output of the following type should be constructed (similar to createcontract) <gasprice> <gaslimit> <contractdata> OP_CREATE The RPC result should be similar to what is returned from createcontract, except for a warnings/errors field should be included, and the contract address should be a base58 x86 address, and any other fields invalid for x86 should be excluded Task:[x86][UI]添加“createx86contract”RPC调用 描述:作为一个智能合约的开发者,我希望能很简单地部署我的合约代码。 在该任务中,增加一个命名为“createx86contract”新的RPC调用,它接受4个参数:gas price,gas limit,filename(ELF文件),以及发送方地址。 ELF文件应该被拆分成一组数据,表示合约数据被放到了区块链上。 1. int32 size of options (options,整形32比特大小) 2. int32 size of code(代码,整形32比特大小) 3. int32 size of data(数据,整形32比特大小) 4. int32 (未使用) 5. options data(options data,现在为空,大小为0) 6. code memory data (代码内存数据) 7. data memory data (数据内存数据) 在x86lib项目中存在类似的ELF文件处理,并且其代码可以根据这里的需求进行修改。注意,在ELF文件出问题时,应该有一些方法可以将错误和警告返回给用户。 在提取和构建合约数据之后,将构建一个以下类型的交易输出(类似于createcontract) <gasprice> <gaslimit> <contractdata> OP_CREATE RPC结果应该和createcontract中返回的结果类似,除了包含警告/错误字段这一点,并且合约的地址应该是base58编码的x86地址,任何其他对于x86无效的字段都应该被排除。

上述任务增加了新的qtum rpc调用,即createx86contract。该rpc能够直接从elf可执行文件中载入智能合约,并部署到区块链上,同时增加了错误返回机制,使开发者确切知道合约部署状态。

小结

本章内容囊括了Qtum x86虚拟机最关键的一些实现细节,基于这些任务,Qtum团队已经实现了首个可部署和运行x86智能合约的虚拟机。并且提供了C语言编写智能合约的相关工具,原型机目前已可支持用c语言编写合约。Qtum x86虚拟机的实现工作仍在继续,后续Qtum项目组还会继续公开原始设计文档,请感兴趣的读者继续保持关注。

连载:Qtum量子链设计文档(六):x86虚拟机重塑智能合约生态


关注Qtum量子链(qtumchain)公众号,回复关键字查阅Qtum量子链相关资料,以下是部分文档关键字

回复:‘白皮书’,查看《Qtum量子链白皮书,设计原理,实现方案,及应用》

回复:‘未来’,查看《Qtum量子链未来2年技术路线规划-简略版》

回复:‘指南’,查看《首篇Qtum量子链区块链开发指南系列面世》

回复:‘专访’,查看《Nasdaq专访Qtum:区块链会成为世界最大的信任服务商》

回复:‘文档’,查看英文版本《Qtum量子链实现文档》

回复:‘中文文档’,查看中文版本《Qtum量子链实现文档》

连载:Qtum量子链设计文档(六):x86虚拟机重塑智能合约生态

连载:Qtum量子链设计文档(六):x86虚拟机重塑智能合约生态

声明:链世界登载此文仅出于分享区块链知识,并不意味着赞同其观点或证实其描述。文章内容仅供参考,不构成投资建议。投资者据此操作,风险自担。此文如侵犯到您的合法权益,请联系我们kefu@lianshijie.com

参与讨论 (0 人参与讨论)

相关推荐

NULS社区2020年11月上半月简报 |NULS异构跨链生态NerveNetwork成功打通与BSC的异构跨链功能

NULS社区2020年11月上半月简报 |NULS异构跨链生态NerveNetwork成功打通与BSC的异构跨链功能

一、技术产品进度 ​1、进行新版Nabox的UI设计,后端也已进入开发阶段; 2、IOS的Nabox已提交苹果审核,疫情期间审核时间较长,请用户耐心等待; 3、配合NTC进行BSC的接入开发,当前已完成测试和产品验收;Nerve新版本发布后,将支持ETH和BSC网络资产互通; 4、配合NTC进行NerveDEX的移动端开发,已进入测试阶段; 5、开始进行Nab

Curve + zkSync L2:以太坊的ZK Rollup 智能合约

Curve 和 Matter Labs 团队很高兴宣布以安全且去中心化的方式向以太坊扩展迈出了一大步:今天,我们和 Curve Finance 一起发布了第一个常驻 dapp 的 zkSync L2 智能合约测试网。 为什么选择 ZK Rollup ? 扩展性是以太坊一个迫切的需求 - 隧道尽头有一个亮灯。Vitalik Buterin 刚刚宣布 Rollup 是现阶段扩展以太坊的“唯一选

EOS生态现在如何了?还有机会靠DeFi翻盘吗?

尽管如此,依然还有许多人在坚持,EOS生态中的DeFi应用也不少,那么它能否有机会就此翻盘呢?从目前情况来看,这个赛道是EOS上DeFi竞争最激烈和充分的,也因此逐步诞生了三家各有千秋的SWAP项目。

​Web3.0中国峰会暨分布式存储生态大会到底密谋着什么?灵动IPFS分布式存储企业

​Web3.0中国峰会暨分布式存储生态大会到底密谋着什么?灵动IPFS分布式存储企业

在2020年11月12日,Web3.0中国峰会暨分布式存储在生态大会是深圳的会展中心的隆重展开开幕仪式,作为"2020中国国际高新技术成果交易会"重要组成部分,除活动的自带流量以外,同时共享着高交会来自智能科技、互联网、物联网、人工智能、大数据、新基建等行业在超40万名的专业观众,加强分布式存储在WEB 3.0中的技术应用、生态链、场景落地及广泛交流合作提供强有力的合作平台。灵动IPFS分布式云存

Bebt交易所:深入分析自动化做市商发展掣肘与设计改进

Bebt交易所:深入分析自动化做市商发展掣肘与设计改进

在基于区块链的分布式系统 (如 Ethereum) 上重构一个新的金融世界时,必须认识到区块链世界与链下世界相比,有着完全不同的动态属性。最值得注意的是,链上并非连续计时,而是通过区块来量化时间的流逝。但因为它受到区块大小的限制,这又导致了延迟问题和计算能力的限制。由于这些结构上的差异,分布式金融的设计者应该具有与中心化世界的设计者完全不同的思路。例如,由于区块链的成本和技术基础设施,做市商在基于

智能合约开发的最佳实践

软件开发的历史已有数十年之久。我们受益于半个世纪以来积累的最佳实践,设计模式和智慧。 相反,智能合约开发才刚刚开始。2015 推出的以太坊和 Solidity 仅有几年的时间。 加密空间是一个不断发展的未知领域。没有确定的工具堆栈来构建去中心化应用。对于智能合约,没有诸如设计模式[3]或代码整洁之道[4]之类的开发人员手册。有关工具和最佳实践的信息遍布各处。 你正在阅读我这份希望它已经存在的指南。

Text.finance智能合约安全漏洞分析

北京时间11月12日,CertiK安全研究团队发现DeFi项目text.finance智能合约代码部分存在安全漏洞。 分析之前,先考考大家的眼力,看看下图里面的文字说了什么。 如果看不清,不妨点击图片后把屏幕亮度调至最高。 有的时候,某些不想让你看到的因素,正是通过排版或者这样的方式,被刻意隐藏了起来。 接下来说说该项目中存在的两处漏洞。大家不妨在阅读文章的时候注意一下图中【fu

比特币有什么缺点?

1.交易平台的脆弱性。比特币网络很健壮,但比特币交易平台很脆弱。交易平台通常是一个网站,而网站会遭到黑客攻击,或者遭到主管部门的关闭。2.交易确认时间长。比特币钱包初次安装时,会消耗大量时间下载历史交易数据块。而比特币交易时,为了确认数据准确性,会消耗一些时间,与p2p网络进行交互,得到全网确认后,交易才算完成。3.价格波动极大。由于大量炒家介入,导致比特币兑换现金的价格如过山车一般起伏。使得比

麦妖榜
更新日期 2019-09-03
排名用户贡献值
1牛市来了30910
2BitettFan24187
3等待的宿命23810
4区块大康20369
5六叶树20310
6linjm122719429
7天下无双16192
8lizhen00215280
9让时间淡忘14586
10yelanyi050511349
返回顶部 ↑