深入解析 fuels-ts 中 FuelVM 二进制文件从 Sway 编译产物到反汇编与链上部署【免费下载链接】fuels-tsFuel Network Typescript SDK项目地址: https://gitcode.com/GitHub_Trending/fu/fuels-ts本指南围绕 Fuel Network TypeScript SDKfuels-ts文档中「理解 FuelVM 二进制文件」一章展开系统讲解当你对 Sway 合约执行forc build后得到的.bin字节码究竟是什么、为什么直接查看时不可读、如何用forc parse-bytecode将其反汇编为可读的 FuelVM 汇编以及这份二进制文件最终是如何被 fuels-ts SDK 打包进交易并交给 Fuel 虚拟机执行与部署的。阅读完成后你将能独立解读一份 Sway 合约的编译产物并理解 SDK 部署合约时 bytecode 所扮演的核心角色。编译的产物forc build生成的字节码文件在 Fuel 网络上Sway 合约并不是直接以源码形式执行的。当你对合约工程执行forc build命令时编译器会把 Sway 源码编译成机器码风格的字节码并落盘为一个二进制文件默认位于out/debug/name.bin。这份二进制文件承载的是 Fuel Virtual MachineFuelVM可以直接解释执行的编译后指令序列。本指南配套使用的示例合约源码位于 apps/docs/sway/echo-values/src/main.sw其核心定义如下contract; use std::b512::B512; abi EchoValues { fn echo_u8(value: u8) - u8; fn echo_str_8(value: str[8]) - str[8]; fn echo_str(value: str) - str; fn echo_tuple(tuple: (u8, bool, u64)) - (u8, bool, u64); fn echo_b512(input: B512) - B512; fn echo_u64(value: u64) - u64; fn echo_u64_array(u64_array: [u64; 2]) - [u64; 2]; } impl EchoValues for Contract { fn echo_u8(value: u8) - u8 { value } // ... 其余方法实现 }合约公开了一组echo_*方法用来在 FuelVM 中往返传递u8、定长/变长字符串、元组、B512、u64与定长数组等类型。对这组 Sway 代码执行forc build之后会在out/debug/目录下生成对应的二进制文件echo-values.bin。为什么.bin直接查看时“乱码”由于编译产物是给 FuelVM 读取的字节码而非给人阅读的文本直接将其当作文本输出必然呈现为乱码。指南中给出的真实文件内容如下$ cat out/debug/echo-values.bin GT]]I]GIsH]GIsHr{6]DJ]C%E]J$Ͼ{RD^%其中绝大部分字节并不落在可打印 ASCII 字符区间这与你打开任意一段可执行机器码时的观感是一致的。因此任何依赖人眼直接审阅该文件的调试方式都不现实我们需要借助编译工具链提供的反汇编手段。使用forc parse-bytecode将字节码反汇编为 FuelVM 汇编forc为这类字节码提供了一个非常有用的解释器forc parse-bytecode命令。它接收二进制文件路径并把其中的每条机器指令还原为等价的 FuelVM 汇编助记符形式输出$ forc parse-bytecode out/debug/echo-values.bin half-word byte op raw notes 0 0 JI(4) 90 00 00 04 jump to byte 16 1 4 NOOP 47 00 00 00 2 8 Undefined 00 00 00 00 data section offset lo (0) 3 12 Undefined 00 00 00 34 data section offset hi (52) 4 16 LW(63, 12, 1) 5d fc c0 01 5 20 ADD(63, 63, 12) 10 ff f3 00 6 24 LW(17, 6, 73) 5d 44 60 49 7 28 LW(16, 63, 1) 5d 43 f0 01 8 32 EQ(16, 17, 16) 13 41 14 00 9 36 JNZI(16, 11) 73 40 00 0b conditionally jump to byte 44 10 40 RVRT(0) 36 00 00 00 11 44 LW(16, 63, 0) 5d 43 f0 00 12 48 RET(16) 24 40 00 00 13 52 Undefined 00 00 00 00 14 56 Undefined 00 00 00 01 15 60 Undefined 00 00 00 00 16 64 XOR(20, 27, 53) 21 51 bd 4b输出各列的含义forc parse-bytecode的输出是五列对齐的表格逐列解读如下列含义half-word指令在字节码流中以半字half-word4 字节为单位的序号每条指令占据一个半字槽位byte该指令起始位置在二进制文件中的字节偏移例如第 4 行的16表示该指令从第 16 个字节开始op反汇编得到的 FuelVM 操作码及其操作数如JI(4)、LW(63, 12, 1)、RET(16)raw该指令在文件中对应的原始 4 字节机器码如JI(4)对应90 00 00 04notes编译器/工具自动附加的注释用于解释关键指令的行为如跳转目标、数据段偏移等从反汇编结果读懂指令流观察上表可以重建这段合约字节码的执行骨架第 0 个半字JI(4)是无条件跳转指令notes 明确指出jump to byte 16——程序首先跳过紧随其后的几条指令直达真正的执行体。被跳过区域第 13 半字包含一条NOOP空操作与两块标记为Undefined的数据区它们实际上是合约的数据段起始偏移lo/hi 组合起来给出数据段地址 52。第 45 个半字LW(63, 12, 1)表示从内存加载一个 word 到寄存器 63ADD(63, 63, 12)做寄存器加法这类序列通常是函数入口为调用方栈帧准备空间的标准指令。第 68 个半字LW与EQ(16, 17, 16)的组合在功能上等价于比较两个值是否相等可联想到EchoValuesABI 入口处对方法选择子的匹配逻辑。第 9 个半字JNZI(16, 11)是一条条件跳转指令notes 标注conditionally jump to byte 44。结合紧随其后的第 10 个半字RVRT(0)回滚/撤销可以推断若上面的比较不成立则进入RVRT分支使本次调用失败回滚若成立则跳到第 11 个半字继续。第 1112 个半字LW(16, 63, 0)加载函数返回值RET(16)从合约中返回完成一次 ABI 入口的调用流程。需要强调的是Undefined行并不代表错误它们通常对应数据段、常量池或对齐填充区这些区域的内容交由后续指令按偏移读取。从这些原始指令中可以直观感受到 FuelVM“寄存器 内存 显式跳转”的经典虚拟机执行模型。这份二进制文件在 SDK 部署流程中的角色当使用 fuels-ts SDK 部署合约时.bin字节码扮演了决定性角色它会被打包进一笔交易并发送给 FuelVM由 FuelVM 解释执行后合约才得以真正上链。文档对此明确说明二进制文件通过交易送达 FuelVM供其解释并执行你的智能合约。在源码层面这一过程的核心实现位于 packages/contract/src/contract-factory.ts 中的ContractFactory类。构造ContractFactory时第一个参数就是合约的 bytecodeconstructor( bytecode: BytesLike, abi: JsonAbi | Interface, accountOrProvider: Account | Provider | null null, storageSlots: StorageSlot[] [] ) { // Force the bytecode to be a byte array this.bytecode arrayify(bytecode); // ... }随后在 deployAsCreateTx 或 createTransactionRequest 中字节码会以 witness见证数据的形式被写入CreateTransactionRequestconst transactionRequest new CreateTransactionRequest({ bytecodeWitnessIndex: 0, witnesses: [bytecode], ...options, }); transactionRequest.addContractCreatedOutput(contractId, stateRoot);这里有两个值得注意的细节字节码作为交易见证数据witness发送而不是作为普通的函数参数。witness 是交易的一部分FuelVM 在验证并执行 create 交易时从中取出合约代码。合约 ID 由字节码派生。createTransactionRequest会先调用getContractId(bytecode, options.salt, stateRoot)计算出contractId再构造输出。也就是说同一份字节码配合固定 salt 与 storage root会推导出确定性的合约地址。字节码大小决定部署路径并非所有合约都适合用单笔 create 交易整包部署。查看 deploy 方法的实现 可以确认SDK 会先从链上读取共识参数中的contractMaxSize再拿它与字节码长度比较自动选择部署方式async deployT extends Contract TContract( deployOptions: DeployContractOptions {} ): PromiseDeployContractResultT { const account this.getAccount(); const { consensusParameters } await account.provider.getChain(); const maxContractSize consensusParameters.contractParameters.contractMaxSize.toNumber(); return this.bytecode.length maxContractSize ? this.deployAsBlobTx(deployOptions) : this.deployAsCreateTxT(deployOptions); }字节码不超过链上限时走deployAsCreateTx整份 bytecode 放进单笔 create 交易。字节码超过链上限时走deployAsBlobTx把 bytecode 按块切分先以 blob 形式逐块上链再基于 blob ID 生成 loader 字节码并提交一笔 create 交易完成部署。关于大合约分块部署含chunkSizeMultiplier参数取值约束 01的完整说明参见 Deploying Contracts 指南关于部署后的调用与合约交互流程可继续阅读 Contracts 章节入口。面向实战的操作建议不要用文本方式审阅.bin。cat、less等文本工具无法呈现字节码语义只会输出乱码正确的检查姿势是forc parse-bytecode out/debug/name.bin。把反汇编输出当作调试与教学工具。当合约行为异常、或你想理解编译器为某段 Sway 代码生成了怎样的指令序列时parse-bytecode的输出操作码、字节偏移、跳转注释远比二进制内容有价值。理解 SDK 部署与字节码的关系。凡是需要部署合约、计算合约地址、或手动传入 bytecode 的 SDK 场景如ContractFactory、typegen 生成的工厂类其底层最终都会回到“bytecode 作为 witness 进入交易”这条主线上。小结本文以「理解 FuelVM 二进制文件」为核心线索串起了三条知识链编译链forc build产出不可读的.bin、反汇编链forc parse-bytecode把字节码还原为带注释的 FuelVM 汇编指令流、以及SDK 集成链fuels-ts 的ContractFactory将 bytecode 作为 witness 写入 create 交易并交给 FuelVM 执行。理解这三者之间的流转关系是深入掌握 Fuel 合约编译产物、链上部署与类型安全工具链的基础。原文出处understanding-the-fuelvm-binary-file.mdfuels-ts 仓库文档目录。若要继续追踪部署过程如何使用这份字节码推荐通读 contract-factory.ts 与 部署合约指南。【免费下载链接】fuels-tsFuel Network Typescript SDK项目地址: https://gitcode.com/GitHub_Trending/fu/fuels-ts创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
深入解析 fuels-ts 中 FuelVM 二进制文件：从 Sway 编译产物到反汇编与链上部署
深入解析 fuels-ts 中 FuelVM 二进制文件从 Sway 编译产物到反汇编与链上部署【免费下载链接】fuels-tsFuel Network Typescript SDK项目地址: https://gitcode.com/GitHub_Trending/fu/fuels-ts本指南围绕 Fuel Network TypeScript SDKfuels-ts文档中「理解 FuelVM 二进制文件」一章展开系统讲解当你对 Sway 合约执行forc build后得到的.bin字节码究竟是什么、为什么直接查看时不可读、如何用forc parse-bytecode将其反汇编为可读的 FuelVM 汇编以及这份二进制文件最终是如何被 fuels-ts SDK 打包进交易并交给 Fuel 虚拟机执行与部署的。阅读完成后你将能独立解读一份 Sway 合约的编译产物并理解 SDK 部署合约时 bytecode 所扮演的核心角色。编译的产物forc build生成的字节码文件在 Fuel 网络上Sway 合约并不是直接以源码形式执行的。当你对合约工程执行forc build命令时编译器会把 Sway 源码编译成机器码风格的字节码并落盘为一个二进制文件默认位于out/debug/name.bin。这份二进制文件承载的是 Fuel Virtual MachineFuelVM可以直接解释执行的编译后指令序列。本指南配套使用的示例合约源码位于 apps/docs/sway/echo-values/src/main.sw其核心定义如下contract; use std::b512::B512; abi EchoValues { fn echo_u8(value: u8) - u8; fn echo_str_8(value: str[8]) - str[8]; fn echo_str(value: str) - str; fn echo_tuple(tuple: (u8, bool, u64)) - (u8, bool, u64); fn echo_b512(input: B512) - B512; fn echo_u64(value: u64) - u64; fn echo_u64_array(u64_array: [u64; 2]) - [u64; 2]; } impl EchoValues for Contract { fn echo_u8(value: u8) - u8 { value } // ... 其余方法实现 }合约公开了一组echo_*方法用来在 FuelVM 中往返传递u8、定长/变长字符串、元组、B512、u64与定长数组等类型。对这组 Sway 代码执行forc build之后会在out/debug/目录下生成对应的二进制文件echo-values.bin。为什么.bin直接查看时“乱码”由于编译产物是给 FuelVM 读取的字节码而非给人阅读的文本直接将其当作文本输出必然呈现为乱码。指南中给出的真实文件内容如下$ cat out/debug/echo-values.bin GT]]I]GIsH]GIsHr{6]DJ]C%E]J$Ͼ{RD^%其中绝大部分字节并不落在可打印 ASCII 字符区间这与你打开任意一段可执行机器码时的观感是一致的。因此任何依赖人眼直接审阅该文件的调试方式都不现实我们需要借助编译工具链提供的反汇编手段。使用forc parse-bytecode将字节码反汇编为 FuelVM 汇编forc为这类字节码提供了一个非常有用的解释器forc parse-bytecode命令。它接收二进制文件路径并把其中的每条机器指令还原为等价的 FuelVM 汇编助记符形式输出$ forc parse-bytecode out/debug/echo-values.bin half-word byte op raw notes 0 0 JI(4) 90 00 00 04 jump to byte 16 1 4 NOOP 47 00 00 00 2 8 Undefined 00 00 00 00 data section offset lo (0) 3 12 Undefined 00 00 00 34 data section offset hi (52) 4 16 LW(63, 12, 1) 5d fc c0 01 5 20 ADD(63, 63, 12) 10 ff f3 00 6 24 LW(17, 6, 73) 5d 44 60 49 7 28 LW(16, 63, 1) 5d 43 f0 01 8 32 EQ(16, 17, 16) 13 41 14 00 9 36 JNZI(16, 11) 73 40 00 0b conditionally jump to byte 44 10 40 RVRT(0) 36 00 00 00 11 44 LW(16, 63, 0) 5d 43 f0 00 12 48 RET(16) 24 40 00 00 13 52 Undefined 00 00 00 00 14 56 Undefined 00 00 00 01 15 60 Undefined 00 00 00 00 16 64 XOR(20, 27, 53) 21 51 bd 4b输出各列的含义forc parse-bytecode的输出是五列对齐的表格逐列解读如下列含义half-word指令在字节码流中以半字half-word4 字节为单位的序号每条指令占据一个半字槽位byte该指令起始位置在二进制文件中的字节偏移例如第 4 行的16表示该指令从第 16 个字节开始op反汇编得到的 FuelVM 操作码及其操作数如JI(4)、LW(63, 12, 1)、RET(16)raw该指令在文件中对应的原始 4 字节机器码如JI(4)对应90 00 00 04notes编译器/工具自动附加的注释用于解释关键指令的行为如跳转目标、数据段偏移等从反汇编结果读懂指令流观察上表可以重建这段合约字节码的执行骨架第 0 个半字JI(4)是无条件跳转指令notes 明确指出jump to byte 16——程序首先跳过紧随其后的几条指令直达真正的执行体。被跳过区域第 13 半字包含一条NOOP空操作与两块标记为Undefined的数据区它们实际上是合约的数据段起始偏移lo/hi 组合起来给出数据段地址 52。第 45 个半字LW(63, 12, 1)表示从内存加载一个 word 到寄存器 63ADD(63, 63, 12)做寄存器加法这类序列通常是函数入口为调用方栈帧准备空间的标准指令。第 68 个半字LW与EQ(16, 17, 16)的组合在功能上等价于比较两个值是否相等可联想到EchoValuesABI 入口处对方法选择子的匹配逻辑。第 9 个半字JNZI(16, 11)是一条条件跳转指令notes 标注conditionally jump to byte 44。结合紧随其后的第 10 个半字RVRT(0)回滚/撤销可以推断若上面的比较不成立则进入RVRT分支使本次调用失败回滚若成立则跳到第 11 个半字继续。第 1112 个半字LW(16, 63, 0)加载函数返回值RET(16)从合约中返回完成一次 ABI 入口的调用流程。需要强调的是Undefined行并不代表错误它们通常对应数据段、常量池或对齐填充区这些区域的内容交由后续指令按偏移读取。从这些原始指令中可以直观感受到 FuelVM“寄存器 内存 显式跳转”的经典虚拟机执行模型。这份二进制文件在 SDK 部署流程中的角色当使用 fuels-ts SDK 部署合约时.bin字节码扮演了决定性角色它会被打包进一笔交易并发送给 FuelVM由 FuelVM 解释执行后合约才得以真正上链。文档对此明确说明二进制文件通过交易送达 FuelVM供其解释并执行你的智能合约。在源码层面这一过程的核心实现位于 packages/contract/src/contract-factory.ts 中的ContractFactory类。构造ContractFactory时第一个参数就是合约的 bytecodeconstructor( bytecode: BytesLike, abi: JsonAbi | Interface, accountOrProvider: Account | Provider | null null, storageSlots: StorageSlot[] [] ) { // Force the bytecode to be a byte array this.bytecode arrayify(bytecode); // ... }随后在 deployAsCreateTx 或 createTransactionRequest 中字节码会以 witness见证数据的形式被写入CreateTransactionRequestconst transactionRequest new CreateTransactionRequest({ bytecodeWitnessIndex: 0, witnesses: [bytecode], ...options, }); transactionRequest.addContractCreatedOutput(contractId, stateRoot);这里有两个值得注意的细节字节码作为交易见证数据witness发送而不是作为普通的函数参数。witness 是交易的一部分FuelVM 在验证并执行 create 交易时从中取出合约代码。合约 ID 由字节码派生。createTransactionRequest会先调用getContractId(bytecode, options.salt, stateRoot)计算出contractId再构造输出。也就是说同一份字节码配合固定 salt 与 storage root会推导出确定性的合约地址。字节码大小决定部署路径并非所有合约都适合用单笔 create 交易整包部署。查看 deploy 方法的实现 可以确认SDK 会先从链上读取共识参数中的contractMaxSize再拿它与字节码长度比较自动选择部署方式async deployT extends Contract TContract( deployOptions: DeployContractOptions {} ): PromiseDeployContractResultT { const account this.getAccount(); const { consensusParameters } await account.provider.getChain(); const maxContractSize consensusParameters.contractParameters.contractMaxSize.toNumber(); return this.bytecode.length maxContractSize ? this.deployAsBlobTx(deployOptions) : this.deployAsCreateTxT(deployOptions); }字节码不超过链上限时走deployAsCreateTx整份 bytecode 放进单笔 create 交易。字节码超过链上限时走deployAsBlobTx把 bytecode 按块切分先以 blob 形式逐块上链再基于 blob ID 生成 loader 字节码并提交一笔 create 交易完成部署。关于大合约分块部署含chunkSizeMultiplier参数取值约束 01的完整说明参见 Deploying Contracts 指南关于部署后的调用与合约交互流程可继续阅读 Contracts 章节入口。面向实战的操作建议不要用文本方式审阅.bin。cat、less等文本工具无法呈现字节码语义只会输出乱码正确的检查姿势是forc parse-bytecode out/debug/name.bin。把反汇编输出当作调试与教学工具。当合约行为异常、或你想理解编译器为某段 Sway 代码生成了怎样的指令序列时parse-bytecode的输出操作码、字节偏移、跳转注释远比二进制内容有价值。理解 SDK 部署与字节码的关系。凡是需要部署合约、计算合约地址、或手动传入 bytecode 的 SDK 场景如ContractFactory、typegen 生成的工厂类其底层最终都会回到“bytecode 作为 witness 进入交易”这条主线上。小结本文以「理解 FuelVM 二进制文件」为核心线索串起了三条知识链编译链forc build产出不可读的.bin、反汇编链forc parse-bytecode把字节码还原为带注释的 FuelVM 汇编指令流、以及SDK 集成链fuels-ts 的ContractFactory将 bytecode 作为 witness 写入 create 交易并交给 FuelVM 执行。理解这三者之间的流转关系是深入掌握 Fuel 合约编译产物、链上部署与类型安全工具链的基础。原文出处understanding-the-fuelvm-binary-file.mdfuels-ts 仓库文档目录。若要继续追踪部署过程如何使用这份字节码推荐通读 contract-factory.ts 与 部署合约指南。【免费下载链接】fuels-tsFuel Network Typescript SDK项目地址: https://gitcode.com/GitHub_Trending/fu/fuels-ts创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
 查看谁能访问你的文件与目录)
