Solidity基础面试题

目录

1、私有、内部、公共和外部函数之间的区别？

2、智能合约大小大约可以有多大？

3、create 和 create2 之间有什么区别？

4、Solidity 0.8.0版本对算术运算有什么重大变化？

5、代理需要哪种特殊的 CALL 才能工作？

6、在区块链上创建随机数的挑战是什么？

7、ERC20中的 transfer 和 transferFrom 之间有什么区别？

8、对于地址 allowlist，使用映射还是数组更好？为什么？

9、为什么不应该使用 tx.origin 进行身份验证？

10、以太坊主要使用什么哈希函数？

11、1 个Ether 相当于 多少个 gwei ？

12、assert 和 require 之间有什么区别？

13、tx.origin 和 msg.sender 之间有什么区别？

1、私有、内部、公共和外部函数之间的区别？

1、私有函数(private)

• 只能在定义它的合约内部被访问
• 甚至是合约内的其他函数也无法访问该私有函数
• 提供了最高级别的隐私保护

2、内部函数(internal)

• 可以在定义它的合约内部以及从该合约继承的所有子合约中访问
• 类似于OOP中的"protected"访问修饰符

3、公共函数(public)

• 可以从合约外部调用,包括其他合约和以太坊账户
• 公共函数是开放的,能够在区块链上被任何人访问

4、外部函数(external)

• 只能从合约之外调用,包括其他合约和账户
• 内部函数无法直接调用外部函数
• 消耗的gas更少,因为它不需要通过EVM的上下文切换
• 通常用于编写公共函数

2、智能合约大小大约可以有多大？

Solidity智能合约的大小受到以太坊虚拟机(EVM)的限制,合约的最大大小取决于以下几个因素:

1. 可用gas限制 每个交易在EVM中执行时都需要消耗一定的gas,gas的总量是有限的。合约的大小会影响部署和执行合约所需的gas消耗。
2. 区块gas限制 每个区块只能包含有限的gas用于执行交易。如果合约代码过大,可能需要多个区块的gas才能部署。
3. 区块大小限制 由于每个区块的大小有上限(当前约为1MB),如果合约代码过大,它可能无法被包含在一个区块中。

通常来说,一个典型的合约大小应该控制在24KB以内。更精确地说:

• 较小的合约(小于16KB)可以被很好地传播和执行
• 中等大小的合约(16-24KB)在部署和执行时需要更多gas
• 超过24KB的合约被认为非常大,可能会遇到gas不足或无法部署的问题

3、create 和 create2 之间有什么区别？

create 和 create2 都是 Solidity 中用于部署新合约的操作码,但它们有以下区别:

1、地址确定性

create 用于部署一个新合约,新合约的地址是由创建者的地址、创建者的nonce值以及部署合约的字节码通过一个确定性的计算得到的。这种方式无法预先确定新合约的地址。

create2 则可以在部署前就计算出新合约的地址。新合约的地址由4个参数通过一个哈希函数确定: 创建者地址、盐值(salt)、初始化代码和部署合约的字节码。只要这4个参数保持不变,新合约的地址就是确定的。

2、重新部署

create 无法保证同一份字节码连续部署两次会得到同一个地址。

create2 由于地址是确定的,因此连续两次使用相同的4个参数部署同一个字节码,得到的合约地址将完全相同。这在一些需要可重入地址的场景下非常有用。

3、版本

create 指令在 EVM 的最初版本中就有了。

create2 是在 EVM 的 Byzantine 分叉中引入的,用于增加地址确定性。

        总的来说,create2 通过增加盐值作为额外的输入,解决了 create 无法获得确定性地址的问题。这对于一些复杂的智能合约应用(如状态分片、钻石模式等)非常有帮助。但 create 由于简单和广泛支持,在大多数情况下仍是更常用的选择。

4、Solidity 0.8.0版本对算术运算有什么重大变化？

Solidity 0.8.0版本对算术运算做出了一些重大变化,主要包括:

1. 溢出和下溢检查

在0.8.0版本之前,算术运算如果发生溢出或下溢,结果会自动进行环绕。从0.8.0开始,缺省情况下溢出和下溢会导致恢复失败(revert),从而避免了意外的结果。例如:

uint8 a = 255;
a++;  // 0.8.0之前结果为0, 现在会恢复失败

可以使用未检查的操作来获得旧有行为。

2. 除法的行为变化

在0.8.0之前,如果除数为0,除法运算会返回结果0。从0.8.0开始,任何被0除都会导致恢复失败。例如:

uint256 x = 5 / 0; // 0.8.0之前返回0, 现在会恢复失败

3. 新增的微调编码操作

引入了新的位移运算编码,使得二进制比特级编码更容易:

`>>>`无符号右移
`<<`左移
`&`按位与
`|` 按位或
`^`按位异或
`~`按位取反 

        这些操作使得在Solidity中进行低级别的按位运算成为可能。

        0.8.0版本的这些变化增强了算术运算的安全性和可靠性,但也要求开发人员更加注意溢出和除零等边缘情况。这些变化符合其他高级语言的惯例,有助于编写更加健壮的智能合约代码。

5、代理需要哪种特殊的 CALL 才能工作？

在Solidity中,代理合约需要使用 delegatecall 这种特殊的低级 CALL 指令才能正常工作。

    delegatecall 是EVM提供的一种特殊的 CALL 变体,它允许一个合约去执行另一个合约的代码,同时保持调用合约的状态不变。具体来说:

1. 当合约A通过delegatecall调用合约B的函数时,合约B的代码会在合约A的数据存储上下文中执行。
2. 合约B无法访问或改变自身的状态变量,只能访问和改变合约A的状态。
3. delegatecall返回的是被调用合约执行的结果数据。
4. 调用者(合约A)必须为被调用者(合约B)提供合适的数据结构,否则可能导致状态混乱。

        这种特性非常适合实现"代理模式",即将逻辑合约的状态存储在代理合约中,由代理通过delegatecall来执行逻辑合约的函数。这样就能在不改变代理合约部署地址的情况下升级逻辑合约。

        除了delegatecall外,标准的call指令不能用于实现代理,因为call会在被调用的上下文中执行代码,而代理需要在调用者的上下文中执行。

        总之,delegatecall是实现Solidity代理模式必须使用的特殊CALL变体。正确使用它可以实现合约的可升级性,是编写可升级智能合约的关键。

示例代码：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.21;

// delegatecall和call类似，都是低级函数
// call: B call C, 上下文为 C (msg.sender = B, C中的状态变量受影响)
// delegatecall: B delegatecall C, 上下文为B (msg.sender = A, B中的状态变量受影响)
// 注意B和C的数据存储布局必须相同！变量类型、声明的前后顺序要相同，不然会搞砸合约。

// 被调用的合约C
contract C {
    uint public num;
    address public sender;

    function setVars(uint _num) public payable {
        num = _num;
        sender = msg.sender;
    }
}

// 发起delegatecall的合约B
contract B {
    uint public num;
    address public sender;

    // 通过call来调用C的setVars()函数，将改变合约C里的状态变量
    function callSetVars(address _addr, uint _num) external payable{
        // call setVars()
        (bool success, bytes memory data) = _addr.call(
            abi.encodeWithSignature("setVars(uint256)", _num)
        );
    }
    // 通过delegatecall来调用C的setVars()函数，将改变合约B里的状态变量
    function delegatecallSetVars(address _addr, uint _num) external payable{
        // delegatecall setVars()
        (bool success, bytes memory data) = _addr.delegatecall(
            abi.encodeWithSignature("setVars(uint256)", _num)
        );
    }
}

6、在区块链上创建随机数的挑战是什么？

        在区块链上生成真正的随机数存在一些固有的挑战,主要原因是区块链是一个确定性的系统,而真正的随机性需要引入不可预测的外部元素。具体挑战包括:

1. 可重复的计算 区块链上的所有计算都需要是完全可重复和确定性的,以确保所有节点得到同样的结果。但是真正的随机数需要一些不可预测和不可重复的数据源。
2. 透明可审计 区块链的全部状态对所有参与节点是透明的,参与节点可以查看并重放所有历史操作。但随机数生成的过程如果是透明的,就意味着种子可被预测,从而失去随机性。
3. 区块链去中心化 区块链旨在去中心化,避免任何单点故障或第三方干预。但生成随机数通常需要引入一些可信赖的外部数据源,这往往需要引入中心化的权威机构。
4. 矿工可能作恶 在许可链中,矿工或验证者可能试图作恶来影响他们有利的随机数生成结果。在许可链中,这是一个更大的威胁。
5. 种子熵问题 要产生具有高熵和不可预测性的种子是一个巨大的挑战。低熵的种子可能导致产生可预测的随机数序列。

        为了克服这些挑战,通常需要使用各种密码学技术和算法来生成"足够随机"的数字,比如通过组合多个可能的熵源、使用延迟性随机函数、引入可信的外部预言机等。但无论使用何种技术,在区块链上生成完全随机的数字都是一个极具挑战性的问题。

        有一些解决方案可以尝试产生"足够随机"的数字。以下是一些常见的方法:

1. 使用链外数据源(Oracle) 通过连接链外可信的随机数生成服务(如random.org),将热源引入区块链。但这需要引入中心化的信任。
2. RANDAO 利用每个区块的hash和矿工提交的随机种子组合,构建一个可验证、去中心化的随机源。以太坊正在采用这种机制。
3. 区块链博弈 让矿工互相对赌下注一个秘密数字,公开最后的结果作为随机数。作恶动机会被抵消。
4. BLS门限签名 采用密码学的BLS门限签名方案,多个节点联合生成随机数,任何节点单独作恶都难影响结果。
5. 延迟函数 通过在种子生成和结果揭晓之间引入一定的延迟期,增加预测的困难度。
6. 组合多种源 充分组合上述各种机制,综合利用多个可信赖的热源,提高最终随机数的不可预测性。

7、ERC20中的 transfer 和 transferFrom 之间有什么区别？

        ERC20标准中的 transfer 和 transferFrom 函数都用于转移dai bi ,但它们的使用场景和工作方式有所不同:

1. transfer(address recipient, uint256 amount)
   • transfer函数是从调用者的账户直接向recipient转移amount数量的代币。
   • 只涉及两个账户,调用者和接收者。
   • 在转账前需要检查调用者账户的余额是否足够。
2. transferFrom(address sender, address recipient, uint256 amount)
   • transferFrom函数允许某个指定操作员(spender)从发送者(sender)账户转移代币到接收者(recipient)账户。
   • 涉及三个账户,发送者、接收者和被允许的操作员。
   • 在转账前需要检查:
     1. 发送者账户余额足够
     2. 发送者已经通过approve函数给予足够的操作额度
   • 常用于交易所、钱包等场景,允许用户事先批准一个操作员从自己账户转出一定金额的dai bi 。

两个函数的关键区别是:

• transfer直接从自己账户转账,transferFrom可以从他人账户转出(在被授权额度范围内)
• transfer只涉及两个账户,transferFrom涉及三个账户
• transferFrom提供了一种"操作员"代理机制,扩展了代币转移的授权能力

        所以transfer更简单直接,而transferFrom则具备更高的灵活性,可以支持诸如交易所、钱包等复杂的代币管理场景。正确使用这两个函数是实现ERC20标准的关键。

8、对于地址 allowlist，使用映射还是数组更好？为什么？

        对于实现地址allowlist(白名单)功能,使用映射(mapping)通常比使用数组(array)更加合适,主要有以下几个原因:

1. 查找效率 映射以键值对的形式存储数据,查找操作的时间复杂度为O(1),非常高效;而数组需要线性查找,时间复杂度为O(n),效率较低。
2. 空间利用率 映射只存储具有键值的数据,而数组需要事先分配固定大小,并填充默认值(如0地址),浪费存储空间。
3. 动态大小 映射可以无限扩展,添加新条目时自动分配存储;而数组大小通常是固定的,超出长度需要重新分配内存。
4. 简洁性 映射操作更加简单直观,如allowlist[addr] = true即可将地址加入白名单;而数组需要维护长度变量,并处理越界等边缘情况。
5. 去重能力 映射天然具备去重能力,相同的键值只存储一次;而数组中可能包含重复元素,需要额外去重。
6. gas成本 由于效率和存储利用率更高,使用映射通常可以节省gas开销。

        当然,如果allowlist的成员数量非常有限且固定,使用固定长度的bytes32数组并通过位运算进行压缩也是一种选择,可以进一步节省gas。但从代码可读性和可维护性角度考虑,映射在大多数情况下会是更好的选择。

9、为什么不应该使用 tx.origin 进行身份验证？

在Solidity智能合约中,不建议使用 tx.origin 进行身份验证或访问控制,主要有以下几个原因:

1. 违反设计原则 tx.origin被设计为提供一个只读的外部账户地址(EOA),它是最初发起整个交易链的账户地址。然而,将其用于访问控制并不是原本的设计用途,这违反了最小权限原则。
2. 存在中间人攻击风险 通过tx.origin,智能合约无法区分交易的发起者是外部账户还是另一个合约。一个恶意的中间合约可以伪装成受信任的外部账户地址,从而绕过基于tx.origin的访问控制。这就是著名的中间人攻击漏洞。
3. 无法适应复杂场景 在复杂的交易场景中,如多级合约调用栈情况下,tx.origin不能有效反映交易中各个合约的权限边界。这可能导致权限管理混乱和意外行为。
4. 限制回调功能 如果一个外部合约需要回调当前合约,但当前合约的访问控制基于tx.origin,那么回调的权限将被不当限制。

        为了避免上述问题,Solidity官方文档明确建议使用 msg.sender 进行身份验证和访问控制。msg.sender提供了合约调用的直接发起者,能够更好地与Solidity的控制流程模型相匹配。

10、以太坊主要使用什么哈希函数？

以太坊主要使用两种密码学哈希函数:Keccak-256和RLP。

1、Keccak-256

Keccak-256是以太坊所使用的主要哈希函数。它基于Keccak算法,输出长度为256位(32字节)的哈希值。Keccak-256广泛应用于以下场景:

• 计算交易和区块的哈希值
• 计算状态树的节点哈希
• 生成账户地址
• 构造合约地址
• 其他需要加密哈希的场合,如数字签名等

Keccak-256的设计目标是抵御各种密码学攻击,如长度扩展攻击、冲突攻击等。它是实现以太坊核心功能的基础。

2、RLP(Recursive Length Prefix)

        RLP是以太坊使用的另一种编码和哈希方案。它用于对复杂的非规则数据结构(如字符串、列表等)进行编码和解码。RLP编码后的数据可被视为扁平字节数组,并可计算SHA3-256哈希。

        RLP常用于编码区块头、交易数据等复杂数据结构,并计算其哈希值。它确保了这些数据结构在网络传输和存储时保持一致性和不可篡改性。

        除了Keccak-256和RLP之外,以太坊也使用其他一些通用的密码学哈希函数,例如SHA256用于挖矿过程中的工作量证明。但从整体上看,Keccak-256和基于其之上的RLP方案是以太坊最核心和最主要使用的哈希算法。

11、1 个Ether 相当于 多少个 gwei ？

1 Ether = 1,000,000,000,000,000,000 Wei 

            =  1,000,000,000 Gwei

12、assert 和 require 之间有什么区别？

   assert 和 require 都是 Solidity 中用于检查条件并在条件不满足时恢复(revert)交易的函数,但它们有几个重要区别:

1. 检查条件的位置
   • require 用于检查输入值、外部条件、状态条件等,防止在执行代码前出现异常。
   • assert 用于检查内部条件、不变量、代码逻辑错误等,发现编码中的错误。
2. 使用时机
   • require 应该用在函数执行的关键入口点,防止浪费gas。
   • assert 可以在任何代码位置使用,常用于捕捉内部逻辑错误。
3. 错误消息
   • require 可提供自定义的错误消息,有利于调试。
   • assert 无法提供自定义消息,错误更加简单和通用。
4. Gas消耗
   • require 的gas开销略低于 assert。
   • assert 用于检查内部错误,如果发生将消耗所有剩余gas作为惩罚。
5. 建议用法
   • 优先使用 require 过滤用户输入和外部条件。
   • assert 主要用于捕捉内部逻辑错误,检查不变量。

        总的来说,require 更多用于外部条件和预防性检查,而 assert 则是对内部错误的最后保护。合理使用这两个函数可以提高合约的健壮性和安全性。根据 Solidity 官方建议,应优先使用 require。

13、tx.origin 和 msg.sender 之间有什么区别？

    tx.origin 和 msg.sender 都是Solidity中的全局变量,用于获取交易或消息的发送者地址,但它们有着重要的区别:

1、tx.origin

• tx.origin是指发起整个交易序列的原始账户地址,即最初的交易发送者。
• 它保证了指向一个外部拥有私钥的人类账户(EOA),而不是一个合约账户。
• 一旦确定,tx.origin在整个交易链路中保持不变。

2、msg.sender

• msg.sender是指直接调用当前合约函数的直接发送者地址。
• 发送者可以是一个外部账户,也可以是另一个合约账户。
• 在每一次合约内函数调用中,msg.sender的值可能会发生变化。

举个例子:

• 如果外部账户A直接调用合约B,那么在B中tx.origin和msg.sender都是A。
• 但如果A调用合约B,B再调用合约C,那么在C中tx.origin是A,但msg.sender是B的地址。

主要区别在于:

• tx.origin是整个交易链最原始的发起者
• msg.sender是当前合约调用的直接发起者

        一般来说,应该使用msg.sender进行权限管理,因为tx.origin的使用容易导致潜在的安全漏洞。只有在特殊情况下,如防止恶意调用等,才使用tx.origin作为辅助手段。

14、view 和 pure 之间有什么区别？

view

• view 函数可以读取区块链上的状态数据,例如调用其他的view或pure函数、访问当前链的信息等。
• 但是view函数不能修改区块链上的任何状态数据。

pure

• pure 函数不仅不能修改链上数据,甚至连读取链上数据都不允许。
• pure 函数只能执行一些不涉及任何链上数据的纯计算操作。
• 它们只能使用函数参数和一些常量进行计算,不能访问this指针。

由于 pure 函数的限制更多,因此相比之下:

• view 函数可以被认为是一个接受输入并返回结果的查询,不改变链上状态。
• pure 函数则是一个无状态的、确定性的函数,给定相同的输入总是返回相同的结果。

        执行 view 和 pure 函数时不需要消耗gas,也不会创建、修改链上的状态数据。这为这两类函数提供了极大的gas优化空间。