Hi 游客

更多精彩,请登录!

比特池塘 区块链前沿 正文
本文是x86虚拟机系列文档,供Qtum量子链团队成员以及所有感兴趣的用户阅读。
# F( B3 I; c% D; r; n- D/ V
# I7 k, X* C! @' s1 l与EVM不同的是,在x86架构中内存使用是不连续的,内存中可能存在空白段。例如,访问0x1000处的内存可能会导致错误,因为该段内存没有被分配,但是在0x2000处可能有一些有用的内容。实际上,大多数虚拟机和CPU架构都把这作为其优势,所以EVM的内存使用方式是比较少见的。在1Mb内存还不常见的时代,8086曾规定的大多数内存都从0开始,而只读BIOS内存位于0xF0000,有时一部分内存实际上被连接到外部设备而不是RAM。
2 [/ a3 n; c4 d" b/ _ ' R4 W" M: T  `3 L+ {0 [
Qtum x86 虚拟机设计也运用了这个特性,以便实现某些内存区域可以共享的特性。! ~: p; H1 V  L: E8 ~4 I1 x0 W
$ y( q( q% x) P9 C9 _% [; x
' D- B) G1 I) g5 _
以下是Qtum Core的内存映射(稍后详细解释):
0 p  H5 G4 n: a' ^/ \' Cl  应急堆栈- 0x100,长度64,读写1 ~5 ?! b" ^& y) n0 z% Q
l  合约代码- 0x1000,长度0x10000 (max),只读
) R; ?5 ]5 H7 P3 F6 h, El  合约数据- 0x100000,长度0x10000 (max),读写
8 E6 O; a7 e' ~l  堆栈内存- 0x200000,长度8196,读写" \; R) s7 x4 v3 j* p. D- w0 r4 `) ?8 y
l  执行数据- 0xD0000000,长度待定,只读
4 g9 M) o1 N7 Dl  交易数据- 0xD1000000,长度可动态调整,只读8 x' ~1 _+ k- ?& {6 i
l  区块链数据- 0xD2000000,长度待定,只读
: Y5 C% A. t: M( `2 ]+ g
; i# g; y/ L* J 注意,各内存块可以在第一次读取时再进行初始化。即在合约需要读取数据之前,没有必要为某个内存块构造数据。首次访问类似的内存区域可能还需要额外的gas费用。, Y' v" W% l, C6 {" K7 t4 ~
* y  a  |. B; p# \& i
01* j& V0 E/ z9 w0 {& T# [7 d
应急堆栈(Emergency stack)
! S- _3 d! G) [- u) N4 s发生double-fault 异常时使用的应急堆栈。暂不使用,因为异常处理暂未支持。
" h8 [, L1 O$ g9 K6 K) J* n # e$ c& i- }, _
02
$ l' e$ P9 \1 ]9 y0 c" A合约代码(Contract Code)/ @+ u  X! m& p5 A; x% a3 O
实际加载合约代码的内存区域。出于安全性和后续优化考虑,该内存区域设置为只读。实际的大小取决于加载的合约代码大小。超出实际大小的内存只能读取不能写入,且值恒为0。% Y; I+ a7 X: b4 y- B

2 v8 ]7 R" q( X$ \  \03
1 r+ m5 _9 F. C, }6 y0 Y合约数据(Contract Data)1 E) i8 P. [5 v6 |% I0 B9 m
加载合约数据的内存区域。与EVM不同的是,对于变量, 无需CPU代码指定预留内存并将其设置为该变量的值。x86中的变量只是一个指向内存地址的简单指针。加载器(loader,在普通的操作系统中对应解析器和加载器,在Qtum中,对应虚拟机的初始化进程)通过这一地址获取变量值。这在实际中非常有用,因为我们可以使用高效的原生代码 (如“memcpy”)一次性完成所有变量的初始化。变量指针最终指向该内存区域。其实际大小暂定为1Mb,但在x86虚拟机原型发布之后有可能进行调整。/ p6 W) f7 G* P9 r3 a( {9 z
$ ]& p( U+ q% e" }& M
请注意,只读数据(取决于链接器配置)存储在代码区域。普通程序中的只读数据包括字符串、常量等。
1 y& Y: d4 u4 ?/ n3 P2 v& t5 s 2 S. ^" v% T) @8 f' l5 |  b8 W
04, z! F" z2 D9 p% X$ f: X
栈内存(Stack Memory) 0 `9 m3 y+ s# n7 w+ |" x
为x86调用栈保留的内存区域。调用栈用于向函数传递参数、存储返回地址、本地变量等。之所以将其他数据和栈数据进行隔离,是因为该内存区域前后都是无效内存。也就是说,一旦栈发送溢出,将很容易被检测到,因为这将导致抛出错误。显式的抛出错误在大多数情况下都比带着错误继续运行要好得多。
- `+ A; t6 A! K. n" q% n
/ Q, [* K% s; M+ g* @4 H05
4 S& d8 f5 _" Y( o调用数据(Execution Data)" \1 r! I; ]0 v2 K- g* e5 U
只读数据,且对于每个合约调用都是特定的。这意味着当在合约中调用合约时,数据将是不同的。这些数据包括发送者地址(发起合约调用的地址)、gas limit和其他数据等。
' X: Z7 W6 o1 K0 X( q9 W$ g
6 Y5 u* a2 H& c& i6 A06
0 X& \( F7 d+ k1 r交易数据(Transaction Data)1 f2 y( b) V% X5 Q6 s
动态长度数据,编码了触发此次合约调用的完整交易数据(包括交易的所有输入输出)。其中既包含了原始脚本的访问,也包含了诸如“发送了100 token到A地址”这样方便使用的数据。关于脚本的解析,qtum-x86会提供相关的辅助库函数。
) ~2 |: g4 y8 \: }% S 1 q. `6 }$ X7 l9 r
07. Q" |) Z5 g. y( d4 ]/ x7 Z' a* G# `
区块链数据(Blockchain Data)
# ~) X. r. a* `4 F, C9 n只读的全局区块链数据,对于当前区块中的所有合约为常量。包括区块的gas limit,当前区块高度,之前区块的哈希值,当前挖矿难度等数据。6 M7 D; A) ]+ \+ o6 {, L2 k9 p7 d( n8 p
3 J$ p" o; X' W8 ?5 |5 D7 Y6 h
设计初衷$ I# }; E* \" s; C& f, r3 F
之所以令上述数据可直接从内存获取,而不是通过系统调用(syscall),其主要原因有两个:
' j* h9 H6 I7 U" d# E0 h" jl  系统调用都有不可忽视的安全风险: v8 D5 [  u- N! E( N+ h
l  系统调用在合约代码大小、合约代码gas消耗以及虚拟机实现速度等方面,开销都比较大;
2 @+ W7 y# t4 c. M0 p# x% c 4 A% {3 m  t# A7 G3 Q
每个系统调用都是一个暴露合约代码的接口,大多数操作系统内核安全漏洞来自系统调用中的bug。因此,应尽量少地将系统调用暴露给虚拟机 ,减少安全风险。1 P9 S6 b- M, i5 C( J2 P' e
0 B& Z' `+ Y8 d; D# Q) s' _( Y2 G$ b) G
系统调用过程总体开销较大,主要体现在以下几个方面。首先,代码虽然不大,但不可忽略。用C语言进行一次系统调用至少需要30字节,其他语言也需要或多或少的消耗内存。其次,系统调用过程中开销最大的部分在于需要在系统调用和标准C接口间进行翻译,这涉及调用帮助函数,预留寄存器,从堆栈中获取数据并将它们存储在寄存器中,执行系统调用,以及最终恢复寄存器等一系列过程。上面提到的30字节只包含帮助函数部分。实际执行的总字节数明显更多,但并没有表现在合约代码尺寸中,因为该代码只编写一次,并用于每个系统调用。
& g$ e6 P, x, C$ C2 K" r1 n% G * {2 X+ p5 j4 J' t7 P* t$ b
最后,除合约本身的效率问题外,每个系统调用都有可能影响虚拟机的性能。在JIT工作流中,虽然硬件CPU可以快速地缓存JIT代码和JIT编译过的合约代码,但是在离开该内存区域去运行另一段代码时,通常必须至少先清除一部分缓存,为新代码腾出空间。在一个真正使用硬件支持的虚拟化工作流中,这类操作的开销会更大,因为它可能涉及上下文切换和硬件级系统调用。这是大多数需要在虚拟机中运行的语言遇到的常见问题,包括Webassembly(据本人了解,最近Webassembly团队才在某种程度上做了一些重大改进),Javascript/V8等等。
7 K, d- M4 e2 L ( \9 a$ r3 Q9 c; Y& O0 a
x86虚拟机原型, m% W: l: g$ B' A+ O+ H1 J
: s) _8 T: O+ Y( A  S/ L
Qtum x86仍处在原型开发中,故本文所述的内存映射设计与最终版本可能有出入。感兴趣的读者请持续关注包括本文在内的x86系列设计文档。
BitMere.com 比特池塘系信息发布平台,比特池塘仅提供信息存储空间服务。
声明:该文观点仅代表作者本人,本文不代表比特池塘立场,且不构成建议,请谨慎对待。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

成为第一个吐槽的人

李凯908 初中生
  • 粉丝

    0

  • 关注

    0

  • 主题

    24