Solidity基础面试题

本文主要是介绍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)的限制,合约的最大大小取决于以下几个因素:

可用gas限制每个交易在EVM中执行时都需要消耗一定的gas,gas的总量是有限的。合约的大小会影响部署和执行合约所需的gas消耗。
区块gas限制每个区块只能包含有限的gas用于执行交易。如果合约代码过大,可能需要多个区块的gas才能部署。
区块大小限制由于每个区块的大小有上限(当前约为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 变体,它允许一个合约去执行另一个合约的代码,同时保持调用合约的状态不变。具体来说:

当合约A通过delegatecall调用合约B的函数时,合约B的代码会在合约A的数据存储上下文中执行。
合约B无法访问或改变自身的状态变量,只能访问和改变合约A的状态。
delegatecall返回的是被调用合约执行的结果数据。
调用者(合约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、在区块链上创建随机数的挑战是什么？

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

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

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

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

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