跳到主要内容

Core 空间交易常见问题

如何发送交易?

使用钱包(如Conflux Fluent)发送交易的最简单方法是直接设置金额并单击“发送”。 如果您是开发人员,可以使用Conflux SDK(JS,Java,Go)自己构建交易,然后通过节点RPC将其发送到链上。

是否可以取消或替换交易?

如果一笔交易还没有被打包进区块,仍在交易池中,那么可以通过发送一个新交易,nonce相同但是gasPrice更高的方式,替换原来的交易。

交易无法取消,但可以用价值为0的交易替换。 这是一种达到与取消交易相同结果的方法。

在发送交易时,燃气费和存储费是什么?

燃气费是执行交易所需的费用。 矿工需要对打包和执行交易收取一定数量的费用。 计算燃气费的方式是 gasFee = gasPrice * gasUsed。 此外,交易的执行可能会占用新的存储空间。 尽管您无需为占用这些空间支付费用,但需要抵押一定数量的 CFX 以使用这些存储空间。 随着存储空间的释放,抵押的 CFX 将被返还。 存储费指的是用于所使用存储空间的抵押 CFX 数量,每使用 1024 字节需要 1 CFX。

使用SDK发送交易时,需要指定哪些信息(参数)?

如果您使用JS-SDK进行简单的 CFX 转账,则只需要指定from(从哪个账户转出)、to(转账到哪个账户)、value(转账金额,单位:Drip)。

如何获得正确的nonce?

通过 cfx_getNextNonce RPC,可以获取一个账户的下一个可用 nonce 值。 使用过的 nonce 值不能再次使用。 如果使用一个大于当前 nonce 值的 nonce,交易将无法被打包。

nonce 何时会增加? 如果交易失败,nonce 值会增加吗? 为什么交易已发送但 nonce 值未发生变化?

交易被执行后,无论成功或失败,nonce 值都会增加。 在交易被发送后,通过 cfx_getNextNonce 查询到的 nonce 值不会发生变化,因为交易尚未被执行。 此时,交易可能在交易池中等待打包,也可能刚刚被打包并处于defer状态,等待被执行。

如何计算交易中实际使用的燃气费用?

On ConfluxScan, users can view gas usage, gas price, gas fee, and other relevant information of a transaction, which is obtained through cfx_getTransactionReceipt: gasFee = gasCharged * gasPrice, but the gasCharged is not necessarily equal to gasUsed. 在 Conflux 中有一个规则:gas 被用来设置交易中可用的最大燃气量上限。 在 Conflux 中,交易中的 gas 必须大于实际使用的燃气量(gasUsed)的值。 对于超出实际使用的部分,最多只会退还 1/4 的 gas 费用:如果超出部分小于 gasLimit 的 1/4,将全部退还;但如果超出部分大于 gasLimit 的 1/4,只有 1/4 的 gas 费用会被返还。 因此,在发送交易时,尽量给出准确的 gas 值是很重要的。

如何释放存储抵押金?

当存储空间被释放时,抵押金会自动返还。 例如,如果 ERC20 代币的余额从非零值变为 0,存储抵押金将会被返还。 如果一个合约被销毁,所有地址和该合约之间交互产生的存储抵押金也将被返还。

为什么与合约进行交互后余额没有改变,但交易燃气费已被支付?

Conflux 网络具有赞助机制。 如果一个合约有赞助者,该合约与其他账户之间的交互所产生的燃气费用和存储费用将由赞助者支付。

如果您想批量发送交易,如何管理 nonce?

当批量发送交易时,需要手动管理 nonce 值。 每次发送交易时,需要手动将 nonce 值加一。 在这种情况下,如果有一个交易失败,导致它的 nonce 没有被使用,您需要手动调整交易参数并重新发送该交易。 因此,在批量发送交易时,您需要保留所有交易的哈希值,并监控这些交易的状态。

How to know the amount of gas and storage used by a transaction?

可以使用 cfx_estimateGasAndCollateral RPC 方法来估算交易需要使用的燃气量和存储量,但是这种估算并不是百分之百准确的。 因此,返回的 gas 值可以手动调整,例如乘以 1.3

How do I know that a transaction has been successfully executed?

Check the status field of the transaction or the outcomeStatus field of the receipt to determine whether the transaction is successful, 0 means success and 1 means failure.

How to determine whether a transaction is safe and confirmed?

If the epochNumber of the epoch that the transaction belongs to is less than the currently confirmed epochNumber, it is considered safe. You can also get the confirmationRisk of the block that the transaction belongs to through the cfx_getConfirmationRiskByHash RPC. If the obtained value is less than 1e-8, it is considered safe.

What is a receipt, and what information does it contain?

A receipt is the receipt information of a transaction. Through a receipt, you can know some results of the transaction execution, such as whether the transaction is successful, whether a contract is created, gas fee usage, eventLog generated by a transaction execution, etc.

How does the status of the transaction change?

After the transaction is submitted through RPC, it will go through several states: Waiting for packaging -> packaging -> execution -> confirmation.

Why does a transaction fail?

There are several reasons for a failure of a transaction:

  1. Reuse an old nonce.
  2. Used a new nonce, but there is a transaction with the same nonce in the transaction pool.

Why does a transaction keep on waiting to be packaged?

If a transaction has not been packaged for a long time, it’s likely that either the nonce is set incorrectly or the balance is not sufficient.

Why would a transaction execution fail?

Transaction execution failures are roughly divided into the following situations:

  • Vm reverted, Reason provided by the contract: ’xxxxx’: the contract execution failed, and the contract returned detailed information
  • VmError(ExceedStorageLimit): the specified storage limit is not enough
  • NotEnoughCash {required: 22625000000010862646, got: 22062499999972687418, actual_gas_cost: 10862646, max_storage_limit_cost: 22625000000000000000}: insufficient balance
  • VmError(OutOfGas): the specified gas fee is not enough
  • VmError(BadInstruction {instruction: 238 }): contract deployment failed
  • Vm reverted: the contract execution failed, but the contract did not return detailed information.