从solc编译过程来理解solidity合约结构

栏目: 编程语言 · 发布时间: 5年前

内容简介:现在以一个最简单的代码来开始我们的逆向旅程,为了方便学习,所有的代码编译和分析都在在Remix 上输入上述代码,点击Start to Compile 对代码进行编译,可以在Details 按钮里面获取编译出来的结果.结果包含如下:

从solc编译过程来理解solidity合约结构

现在以一个最简单的代码来开始我们的逆向旅程,为了方便学习,所有的代码编译和分析都在 http://remix.ethereum.org/# 上进行.默认IDE 选项是关闭代码优化(Enable Optimization)和使用0.4.25 版本的solidity 编译器编译.

pragma solidity ^0.4.24;

    contract test {

        function a() {
            uint a = 123;
        }

    }

在Remix 上输入上述代码,点击Start to Compile 对代码进行编译,可以在Details 按钮里面获取编译出来的结果.结果包含如下:

METADATA  编译器元数据,包含:编译器版本,编译器设置,源码信息等
    BYTECODE  合约编译完整的字节码结果
    ABI  应用程序接口,用于标识合约提供了哪些函数给外部调用
    WEB3DEPLOY  Web3js版合约部署代码
    METADATAHASH  元数据哈希
    GASESTIMATES  编译器计算函数调用需要消耗的Gas表
    RUNTIME BYTECODE  合约运行时字节码
    ASSEMBLY  字节码反汇编

读者们会注意到,编译结果里面有ByteCode 和Runtime Bytecode ,分别表示什么意思呢,在此先略过这个疑问,我们关注Runtime Bytecode 中返回的字节码.对代码结构分析和字节码分析的标注后所有代码如下:

000 PUSH1 80
    002 PUSH1 40
    004 MSTORE             ;  把0x80 写到[0x40 ,0x40 + 0x20] 这块内存里面,因为内存是空的,这会创建新的内存
    005 PUSH1 04
    007 CALLDATASIZE       ;  获取CALLDATA 的长度
    008 LT                 ;  LT 和PUSH1 0x4 对应,判断CALLDATA 的长度是否小于0x4
    009 PUSH1 3f
    011 JUMPI              ;  如果小于0x4 就往下跳转到0x3F
    012 PUSH1 00
    014 CALLDATALOAD       ;  CALLDATALOAD 0x0 ,PUSH1 0x0 是给CALLDATALOAD 的参数,意思要获取CALLDATA 数据的偏移位置
    015 PUSH29 0100000000000000000000000000000000000000000000000000000000
    045 SWAP1
    046 DIV                ;  DIV 和PUSH29 对应,意思是把上面的数据向左移28 字节,剩下4 字节是调用合约函数名的哈希
    047 PUSH4 ffffffff
    052 AND                ;  AND 和PUSH4 0xFFFFFFFF 对应,保留低位4 字节数据,高位去处
    053 DUP1
    054 PUSH4 0dbe671f     ;  这个是合约有的函数名,经过sha3() 精简过的
    059 EQ                 ;  判断传递过来的函数调用名是否相等
    060 PUSH1 44
    062 JUMPI              ;  如果两值相等就往下跳转到0x44
    063 JUMPDEST           ;  空指令
    064 PUSH1 00
    066 DUP1
    067 REVERT             ;  没有匹配到相应的函数就撤销所有操作,Revert(0,0)
    068 JUMPDEST
    069 CALLVALUE          ;  获取用户转帐数额
    070 DUP1
    071 ISZERO             ;  如果用户转帐数额为0
    072 PUSH1 4f
    074 JUMPI              ;  转帐数额不为0 则跳到0x4F,否则就退出
    075 PUSH1 00
    077 DUP1
    078 REVERT             ;  因为调用函数a() 是不需要附加转帐金额的,所以检测到带有附加金额的函数调用就退出,参考payable 关键字
    079 JUMPDEST
    080 POP
    081 PUSH1 56
    083 PUSH1 58
    085 JUMP               ;  跳转到地址88
    086 JUMPDEST
    087 STOP               ;  停止执行
    088 JUMPDEST
    089 PUSH1 00
    091 PUSH1 7b
    093 SWAP1
    094 POP
    095 POP
    096 JUMP               ;  跳转到地址86
    097 STOP
    ----  合约代码结束分界线  ----
    098 LOG1
    099 PUSH6 627a7a723058
    106 SHA3
    107 MUL
    108 PUSH15 5fd8c2f6fe4103dba9baf9c48c052e
    124 CALLDATALOAD
    125 INVALID
    126 PUSH1 d9
    128 INVALID
    129 INVALID
    130 TIMESTAMP
    131 STATICCALL
    132 INVALID
    133 INVALID
    134 DUP13
    135 INVALID
    136 TIMESTAMP
    137 INVALID
    138 NUMBER
    139 STOP
    140 INVALID

标注信息把合约代码的结构和执行过程的思路都理清了,但是读者们会发现以下的问题:

1.为什么会有合约代码结束分界线,多出来的代码究竟是什么
    2.为什么会有很多多余的跳转
    3.JUMPDEST 是无意思的字节码,为什么会多次出现

要解决这些疑问,那么就需要深入到solidity 编译器的源码分析.在 https://github.com/ethereum/solidity 中找到solc 编译器的源码,定位到libsolidityCodegenContractCompiler.cpp 文件的ContractCompiler::compileContract() 函数,对该函数的分析如下:

void ContractCompiler::compileContract(
        ContractDefinition const& _contract,
        std::map<const ContractDefinition*, eth::Assembly const*> const& _contracts
    )  //  合约编译
    {
        // ...

        initializeContext(_contract, _contracts);  //  初始化执行环境上下文
        appendFunctionSelector(_contract);         //  根据合约内使用到的函数进行汇编构造
        appendMissingFunctions();                  //  链接不公开的函数(非public 声名)
    }

initializeContext() 函数主要功能是初始化执行环境上下文,并把初始化的机器码输出到字节码缓存.

void ContractCompiler::initializeContext(
        ContractDefinition const& _contract,
        map<ContractDefinition const*, eth::Assembly const*> const& _compiledContracts
    )
    {
        m_context.setExperimentalFeatures(_contract.sourceUnit().annotation().experimentalFeatures);
        m_context.setCompiledContracts(_compiledContracts);
        m_context.setInheritanceHierarchy(_contract.annotation().linearizedBaseContracts);
        CompilerUtils(m_context).initialiseFreeMemoryPointer();  //  初始化EVM 内存指针
        registerStateVariables(_contract);
        m_context.resetVisitedNodes(&_contract);
    }

    const size_t CompilerUtils::freeMemoryPointer = 64;
    const size_t CompilerUtils::zeroPointer = CompilerUtils::freeMemoryPointer + 32;
    const size_t CompilerUtils::generalPurposeMemoryStart = CompilerUtils::zeroPointer + 32;

    void CompilerUtils::initialiseFreeMemoryPointer()
    {
        m_context << u256(generalPurposeMemoryStart);  //  generalPurposeMemoryStart 的值为0x80,输出0x80 到字节码缓存
        storeFreeMemoryPointer();
    }

    void CompilerUtils::storeFreeMemoryPointer()
    {
        m_context << u256(freeMemoryPointer) << Instruction::MSTORE;  //  freeMemoryPointer 的值为0x40 ,输出0x40 和指令MSTORE 到字节码缓存
    }

根据上面的代码可以知道,ContractCompiler::initializeContext() 会输出MSTORE 0x40,0x80 到合约字节码的头部,也就是我们常看到合约机器码的开头部分:6080604052 .appendFunctionSelector() 函数是把合约里面编译好的函数和合约初始化检测的代码组合在一起,如果没有深入了解appendFunctionSelector() 的代码生成过程,那就很难理解solc 为什么会这样生成字节码.

void ContractCompiler::appendFunctionSelector(ContractDefinition const& _contract)
    {
        map<FixedHash<4>, FunctionTypePointer> interfaceFunctions = _contract.interfaceFunctions();  //  合约中声名的公开函数列表
        map<FixedHash<4>, const eth::AssemblyItem> callDataUnpackerEntryPoints;  //  函数代码入口点

        if (_contract.isLibrary())  //  判断合约是否为库代码
        {
            solAssert(m_context.stackHeight() == 1, "CALL / DELEGATECALL flag expected.");
        }

        FunctionDefinition const* fallback = _contract.fallbackFunction();
        eth::AssemblyItem notFound = m_context.newTag();    //  创建新的汇编Tag ,Tag 的意义是用来标注汇编代码块声名和跳转到某一段汇编用的
        // directly jump to fallback if the data is too short to contain a function selector
        // also guards against short data
        m_context << u256(4) << Instruction::CALLDATASIZE << Instruction::LT;  //  判断CALLDATA 内容长度是否大于等于4 字节
        m_context.appendConditionalJumpTo(notFound);    //  插入条件跳转,LT 判断不通过就跳转到notFound 代码块

        // retrieve the function signature hash from the calldata
        if (!interfaceFunctions.empty())
            CompilerUtils(m_context).loadFromMemory(0, IntegerType(CompilerUtils::dataStartOffset * 8), true);  //  从CALLDATA 中提取要调用的函数哈希
            //  构造代码PUSH 0x00 ,CALLDATALOAD ,PUSH29 0100000000000000000000000000000000000000000000000000000000 ,SWAP1 ,DIV ,PUSH4 0xFFFFFFFF ,AND

        // stack now is: <can-call-non-view-functions>? <funhash>
        for (auto const& it: interfaceFunctions)
        {
            callDataUnpackerEntryPoints.insert(std::make_pair(it.first, m_context.newTag()));  //  对函数入口创建新汇编代码块声名
            m_context << dupInstruction(1) << u256(FixedHash<4>::Arith(it.first)) << Instruction::EQ;  //  构造代码:DUP1 ,PUSH4 函数哈希 ,EQ
            m_context.appendConditionalJumpTo(callDataUnpackerEntryPoints.at(it.first));  //  如果数值相同,则跳转到目的函数地址,对应PUSH + JUMPI 指令
        }
        m_context.appendJumpTo(notFound);  //  没有找到的话就跳转到notFound 触发revert(0) 退出

        m_context << notFound;  //  声名notFound 的代码段
        if (fallback)
        {
            solAssert(!_contract.isLibrary(), "");
            if (!fallback->isPayable())
                appendCallValueCheck();

            solAssert(fallback->isFallback(), "");
            solAssert(FunctionType(*fallback).parameterTypes().empty(), "");
            solAssert(FunctionType(*fallback).returnParameterTypes().empty(), "");
            fallback->accept(*this);
            m_context << Instruction::STOP;
        }
        else
            // TODO: error message here?
            m_context.appendRevert();
        //  对notFound 的代码进行填充,因为fallback=fakse ,执行m_context.appendRevert() ,所以notFound 的代码序列是 PUSH1 0x00 ,DUP1 ,REVERT .意思是revert(0x0)

        //  上面是构造合约执行数据检测的代码,下面是对各个公开调用(指public 声名)的函数进行入口点构造
        for (auto const& it: interfaceFunctions)
        {
            FunctionTypePointer const& functionType = it.second;
            solAssert(functionType->hasDeclaration(), "");
            CompilerContext::LocationSetter locationSetter(m_context, functionType->declaration());

            m_context << callDataUnpackerEntryPoints.at(it.first);
            if (_contract.isLibrary() && functionType->stateMutability() > StateMutability::View)  //  库函数且关键字声名不是pure 和view 的函数
            {
                // If the function is not a view function and is called without DELEGATECALL,
                // we revert.
                m_context << dupInstruction(2);
                m_context.appendConditionalRevert();
            }
            m_context.setStackOffset(0);
            // We have to allow this for libraries, because value of the previous
            // call is still visible in the delegatecall.
            if (!functionType->isPayable() && !_contract.isLibrary())  //  如果函数没有启用Payable 关键字或者这是库函数的话,都不支持接收合约调用携带转帐金额
                appendCallValueCheck();    //  添加对转帐金额检测代码

            // Return tag is used to jump out of the function.
            eth::AssemblyItem returnTag = m_context.pushNewTag();  //  对函数创建返回代码段声名
            if (!functionType->parameterTypes().empty())  //  如果函数有参数的话
            {
                // Parameter for calldataUnpacker
                m_context << CompilerUtils::dataStartOffset;  //  CompilerUtils::dataStartOffset 指的是函数参数数据在TXDATA 里的偏移
                m_context << Instruction::DUP1 << Instruction::CALLDATASIZE << Instruction::SUB;  //  计算函数参数的大小
                CompilerUtils(m_context).abiDecode(functionType->parameterTypes());    //  从TXDATA 中获取参数
            }
            m_context.appendJumpTo(m_context.functionEntryLabel(functionType->declaration()));  //  调转到函数入口点
            m_context << returnTag;  //  声名函数返回的代码段
            // Return tag and input parameters get consumed.
            m_context.adjustStackOffset(
                CompilerUtils(m_context).sizeOnStack(functionType->returnParameterTypes()) -
                CompilerUtils(m_context).sizeOnStack(functionType->parameterTypes()) -
                1
            );
            // Consumes the return parameters.
            appendReturnValuePacker(functionType->returnParameterTypes(), _contract.isLibrary());  //  构造函数返回值处理
        }
    }

上面的代码分析可能看起来有些晦涩难懂,作者把上面分析到的编译过程一一对应到编译结果并标注,汇编代码如下:

-----  initializeContext() -> initialiseFreeMemoryPointer()  ----
    000 PUSH1 80         ;  initialiseFreeMemoryPointer()  ,  m_context << u256(0x80)
    002 PUSH1 40         ;  storeFreeMemoryPointer()
    004 MSTORE           ;  storeFreeMemoryPointer()  , m_context << u256(0x40) <<  Instruction::MSTORE;
    -----  initialiseFreeMemoryPointer()  -----
    -----  appandFunctionSelector() Create Code Start ---
    005 PUSH1 04         ;  /--
    007 CALLDATASIZE     ;  |
    008 LT               ;  |  检测CallData 是否合法,CallData 会带有4 字节函数哈希
    009 PUSH1 3f         ;  |
    011 JUMPI            ;  --
    012 PUSH1 00         ;  /--
    014 CALLDATALOAD     ;  |
    015 PUSH29 0100000000000000000000000000000000000000000000000000000000
    045 SWAP1            ;  |
    046 DIV              ;  |  处理CallData 里面带入的函数哈希.默认读出来数据是在高位,现在处理成低位
    047 PUSH4 ffffffff   ;  |
    052 AND              ;  --
    053 DUP1             ;  /--
    054 PUSH4 0dbe671f   ;  |
    059 EQ               ;  |
    060 PUSH1 44         ;  |  根据函数哈希找入口
    062 JUMPI            ;  |
    063 JUMPDEST         ;  --
    064 PUSH1 00         ;  /--
    066 DUP1             ;  |  notFound 代码填充
    067 REVERT           ;  --
    -----  appandFunctionSelector() 会给每个函数根据参数调用来分配函数头入口初始化检测代码 ---
    068 JUMPDEST         ;  Address 0x44 , function a() Entry ..
    069 CALLVALUE        ;  /--
    070 DUP1             ;  |
    071 ISZERO           ;  |
    072 PUSH1 4f         ;  |
    074 JUMPI            ;  |  solc  /libsolidity/Codegen/ContractCompiler.cpp:appendCallValueCheck()
    075 PUSH1 00         ;  |
    077 DUP1             ;  |
    078 REVERT           ;  --
    -----  Tag function_A_pre_JumpTo_function_A_Tag_Code  ----
    -----  m_context.appendJumpTo(m_context.functionEntryLabel(functionType->declaration()));
    079 JUMPDEST         ;  JUMPDEST 是无意义的代码,它的唯一意义是用来标识这是一个Label 起始头
    080 POP
    081 PUSH1 56         ;  eth::AssemblyItem returnTag = m_context.pushNewTag();  0x56 is Return Address
    083 PUSH1 58         ;  /
    085 JUMP             ;    m_context.appendJumpTo(m_context.functionEntryLabel(functionType->declaration()));
    -----  Tag function_A_return_Code  ----
    086 JUMPDEST         ;  Address 0x56
    087 STOP             ;  ContractCompiler::appendReturnValuePacker();
    -----  Tag function_A_Main_Code  ----
    -----  CompilerContext 是保存每一个函数编译好的代码
    088 JUMPDEST         ;  Address 0x58 , m_context.functionEntryLabel("a"); ..
    089 PUSH1 00
    091 PUSH1 7b
    093 SWAP1            ;  0x7B ,0x00  == SWAP => 0x00 ,0x7B .意义是对栈进行平衡
    094 POP
    095 POP
    096 JUMP              ;  Jump 0x56
    097 STOP              ;
    -----  appandFunctionSelector() Create Code End ---
    098 LOG1
    099 PUSH6 627a7a723058
    106 SHA3
    107 MUL
    108 PUSH15 5fd8c2f6fe4103dba9baf9c48c052e
    124 CALLDATALOAD
    125 INVALID
    126 PUSH1 d9
    128 INVALID
    129 INVALID
    130 TIMESTAMP
    131 STATICCALL
    132 INVALID
    133 INVALID
    134 DUP13
    135 INVALID
    136 TIMESTAMP
    137 INVALID
    138 NUMBER
    139 STOP
    140 INVALID

结合编译器的编译过程和编译出来的结果来阅读理解代码之后,可以知道合约汇编代码的结构:

1.初始化EVM memory
    2.检测TXDATA 里面是否带有合法的函数哈希
    3.函数跳转
    4.函数预校验代码
    5.函数参数获取代码
    6.函数返回代码
    7.函数主体代码

读者可能会有一个疑问,为什么在汇编代码097 STOP 的后面还有多余的代码呢,这些代码的意义何在.我们来阅读CompilerStack::compileContract() 的代码:

void CompilerStack::compileContract(
        ContractDefinition const& _contract,
        map<ContractDefinition const*, eth::Assembly const*>& _compiledContracts
    )
    {

        // ...

        shared_ptr<Compiler> compiler = make_shared<Compiler>(m_evmVersion, m_optimize, m_optimizeRuns);
        compiledContract.compiler = compiler;

        string metadata = createMetadata(compiledContract);  //  创建元数据
        compiledContract.metadata = metadata;

        bytes cborEncodedMetadata = createCBORMetadata(  //  生成CBOR 元数据
            metadata,
            !onlySafeExperimentalFeaturesActivated(_contract.sourceUnit().annotation().experimentalFeatures)
        );

        try
        {
            // Run optimiser and compile the contract.
            compiler->compileContract(_contract, _compiledContracts, cborEncodedMetadata);  //  编译合约
        }
        catch(eth::OptimizerException const&)
        {
            solAssert(false, "Optimizer exception during compilation");
        }

        // ...

    }

可以看到,编译合约的时候cborEncodedMetadata 的数据也带入compileContract() ,compileContract() 代码如下:

void Compiler::compileContract(
        ContractDefinition const& _contract,
        std::map<const ContractDefinition*, eth::Assembly const*> const& _contracts,
        bytes const& _metadata
    )
    {
        ContractCompiler runtimeCompiler(nullptr, m_runtimeContext, m_optimize);  //  初始化合约编译类
        runtimeCompiler.compileContract(_contract, _contracts);    //  编译合约代码
        m_runtimeContext.appendAuxiliaryData(_metadata);   //  把CBOR 元数据附加在编译之后合约代码末端

        // ...
    }

那么回来阅读createCBORMetadata() 的代码,发现它其实是使用了元数据来构造出的数据.

bytes CompilerStack::createCBORMetadata(string _metadata, bool _experimentalMode)
    {
        bytes cborEncodedHash =
            // CBOR-encoding of the key "bzzr0"
            bytes{0x65, 'b', 'z', 'z', 'r', '0'}+
            // CBOR-encoding of the hash
            bytes{0x58, 0x20} + dev::swarmHash(_metadata).asBytes();
        bytes cborEncodedMetadata;
        if (_experimentalMode)
            cborEncodedMetadata =
                // CBOR-encoding of {"bzzr0": dev::swarmHash(metadata), "experimental": true}
                bytes{0xa2} +
                cborEncodedHash +
                bytes{0x6c, 'e', 'x', 'p', 'e', 'r', 'i', 'm', 'e', 'n', 't', 'a', 'l', 0xf5};
        else
            cborEncodedMetadata =
                // CBOR-encoding of {"bzzr0": dev::swarmHash(metadata)}
                bytes{0xa1} +
                cborEncodedHash;
        solAssert(cborEncodedMetadata.size() <= 0xffff, "Metadata too large");
        // 16-bit big endian length
        cborEncodedMetadata += toCompactBigEndian(cborEncodedMetadata.size(), 2);
        return cborEncodedMetadata;
    }

我们从Bytecode 中提取出CBOR 编码,数据为a165627a7a723058207ba6766efb653d5e4d3b7d5893d345b79718b5513bd5a87d5bf8256fa895c58d0029 ,对它的标注如下:

a1                ;  Flag : experimental = False
    65627a7a72305820  ;  CBOREncodeHash
    7ba6766efb653d5e4d3b7d5893d345b79718b5513bd5a87d5bf8256fa895c58d  ;  BZZA hash
    0029              ;  hash 长度

弄懂solidity 的编译过程和为什么会编译出这样的结果之后,现在回来解答前面提出的两个问题:

1.为什么会有合约代码结束分界线,多出来的代码究竟是什么
    多出来的代码是CBOR 元数据编码

    2.为什么会有很多多余的跳转
    多余的跳转是因为appendFunctionSelector() 会帮助函数去构造预处理代码,参数提取代码和返回代码,最后才跳转到函数的主体代码.solidity 和x86 arm 等的汇编不同,它的对函数的参数和返回值处理都不是由函数主体来完成的.

    3.JUMPDEST 是无意思的字节码,为什么会多次出现
    编译器在生成编译代码时,可以看到JUMP 和JUMPI 指令会跳转到JUMPDEST 指令.JUMPDEST 指令是solidity 编译器用来标识汇编代码的区段声名(Tag).所以后面的示例汇编代码都会在JUMPDEST 前记录代码区段的意思标注.

至此,本文还有一个疑问没有被解决:ByteCode 和Runtime Bytecode 分别表示什么意思呢?我们来回顾Compiler::compileContract() 的完整代码:

void Compiler::compileContract(
        ContractDefinition const& _contract,
        std::map<const ContractDefinition*, eth::Assembly const*> const& _contracts,
        bytes const& _metadata
    )
    {
        ContractCompiler runtimeCompiler(nullptr, m_runtimeContext, m_optimize);  //  编译runtime 代码
        runtimeCompiler.compileContract(_contract, _contracts);
        m_runtimeContext.appendAuxiliaryData(_metadata);  //  插入CBOR 编码

        // This might modify m_runtimeContext because it can access runtime functions at
        // creation time.
        ContractCompiler creationCompiler(&runtimeCompiler, m_context, m_optimize);  //  编译creation 代码
        m_runtimeSub = creationCompiler.compileConstructor(_contract, _contracts);

        m_context.optimise(m_optimize, m_optimizeRuns);  //  优化汇编代码
    }

可以看到Compiler::compileContract() 里面分两部分来编译合约代码:runtime 的代码指的是合约编写逻辑的代码;creation 的代码指的是constructor() 的代码.我们回来看ByteCode 和RuntimeCode 的汇编代码来做对比

ByteCode 汇编:

----  Binary  ----
    6080604052348015600f57600080fd5b50608d8061001e6000396000f300608060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680630dbe671f146044575b600080fd5b348015604f57600080fd5b5060566058565b005b6000607b9050505600a165627a7a72305820026e5fd8c2f6fe4103dba9baf9c48c052e35ca60d9cdee42faca258c284224430029

    ----  Constructor() Code  ----
    PUSH1 0x80 
    PUSH1 0x40 
    MSTORE 
    CALLVALUE 
    DUP1 
    ISZERO 
    PUSH1 0xF 
    JUMPI 
    PUSH1 0x0 
    DUP1 
    REVERT 
    JUMPDEST 
    POP 
    PUSH1 0x8D 
    DUP1 
    PUSH2 0x1E 
    PUSH1 0x0 
    CODECOPY 
    PUSH1 0x0 
    RETURN 
    STOP 
    ----  Contract Code  ----
    PUSH1 0x80 
    PUSH1 0x40 
    MSTORE 
    PUSH1 0x4 
    CALLDATASIZE 
    LT 
    PUSH1 0x3F 
    JUMPI 
    PUSH1 0x0 
    CALLDATALOAD 
    PUSH29 0x100000000000000000000000000000000000000000000000000000000 
    SWAP1 
    DIV 
    PUSH4 0xFFFFFFFF 
    AND 
    DUP1 
    PUSH4 0xDBE671F 
    EQ 
    PUSH1 0x44 
    JUMPI 
    JUMPDEST 
    PUSH1 0x0 
    DUP1 
    REVERT 
    JUMPDEST 
    CALLVALUE 
    DUP1 
    ISZERO 
    PUSH1 0x4F 
    JUMPI 
    PUSH1 0x0 
    DUP1 
    REVERT 
    JUMPDEST 
    POP 
    PUSH1 0x56 
    PUSH1 0x58 
    JUMP 
    JUMPDEST 
    STOP 
    JUMPDEST 
    PUSH1 0x0 
    PUSH1 0x7B 
    SWAP1 
    POP 
    POP 
    JUMP 
    STOP

RuntimeCode 汇编:

----  Binary  ----
    608060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680630dbe671f146044575b600080fd5b348015604f57600080fd5b5060566058565b005b6000607b9050505600a165627a7a72305820026e5fd8c2f6fe4103dba9baf9c48c052e35ca60d9cdee42faca258c284224430029

    ----  Contract Code  ----
    PUSH1 0x80 
    PUSH1 0x40 
    MSTORE 
    PUSH1 0x4 
    CALLDATASIZE 
    LT 
    PUSH1 0x3F 
    JUMPI 
    PUSH1 0x0 
    CALLDATALOAD 
    PUSH29 0x100000000000000000000000000000000000000000000000000000000 
    SWAP1 
    DIV 
    PUSH4 0xFFFFFFFF 
    AND 
    DUP1 
    PUSH4 0xDBE671F 
    EQ 
    PUSH1 0x44 
    JUMPI 
    JUMPDEST 
    PUSH1 0x0 
    DUP1 
    REVERT 
    JUMPDEST 
    CALLVALUE 
    DUP1 
    ISZERO 
    PUSH1 0x4F 
    JUMPI 
    PUSH1 0x0 
    DUP1 
    REVERT 
    JUMPDEST 
    POP 
    PUSH1 0x56 
    PUSH1 0x58 
    JUMP 
    JUMPDEST 
    STOP 
    JUMPDEST 
    PUSH1 0x0 
    PUSH1 0x7B 
    SWAP1 
    POP 
    POP 
    JUMP 
    STOP

所以,我们可以明白在部署合约的时候,EVM 执行Constructor() 函数的代码初始化合约数据,后续用户通过Web3 调用节点上的合约函数时,是直接在RuntimeCode 中开始执行合约代码.TXDATA 中是带有用户希望调用函数的哈希和函数的参数数据的,接下来合约代码初始EVM Memory 之后,根据TXDATA 里面指向用户希望调用的函数哈希来进行代码跳转.执行函数主体代码前做一些预检测并从TXDATA 中提取函数参数到栈,最后执行函数主体代码并退出.


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Java Web开发实例大全(基础卷)

Java Web开发实例大全(基础卷)

软件开发技术联盟 / 清华大学出版社 / 2016-1 / 128.00

《Java Web开发实例大全(基础卷)》筛选、汇集了Java Web开发从基础知识到高级应用各个层面约600个实例及源代码,每个实例按实例说明、关键技术、设计过程、详尽注释、秘笈心法的顺序进行了分析解读。全书分为6篇23章,主要内容有开发环境搭建、Java语言基础、HTML/CSS技术、JSP基础与内置对象、JavaBean技术、Servlet技术、过滤器与监听器技术、JSTL标签库、JavaS......一起来看看 《Java Web开发实例大全(基础卷)》 这本书的介绍吧!

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码

RGB HSV 转换
RGB HSV 转换

RGB HSV 互转工具

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具