Why would create2 revert? - ethereum

I'm debugging a reverted transaction on Polygon and this is all the information I have: https://mumbai.polygonscan.com/tx/0xfa86dc4957e3a3da9298b7672b11a20ebe921854fa494dc073920c067c1e693f#internal
If I'm reading it correctly, it seems to be saying that a CREATE2 reverted. But what are some reasons why a CREATE2 can revert? I'm aware that it would revert if something already existed at the address, but this isn't the case here, as you can see from here: https://mumbai.polygonscan.com/address/0x6bb03ca906c0372f384b845bd5ce9ca4327ffbe6

The linked transaction makes a message call (aka internal transaction) to contract deployed at 0x1079b7398b6efd9845c4db079e6fac8d21cf67b3.
This 0x1079b7... contract then tries to deploy a new contract on address 0x6bb03ca906c0372f384b845bd5ce9ca4327ffbe6, you can see the bytecode of the new contract for example in the Tenderly debugger.
As far as I'm aware, create2 can revert for 3 reasons:
Not enough gas left to perform the deployment
Not an issue in this case. Acording to the debugger there was ~9M gas units left and the deployment would take only ~1M gas units.
Deploying contract to address where another contract instance is already deployed.
Because you can predetermine the contract address with create2, this can happen. However not in this case either, the 0x6bb03c... address is empty, there's no contract deployed.
So we're left with uncaught exception during executing the constructor.
pragma solidity ^0.8;
contract MyContract {
constructor() {
require(false);
}
}
A code like this fails the deployment and effectively causes the create2 code to revert.
Unfortunately, without the new contract source code, it's hard to tell what exactly is the cause of constructor revert. Whether it's unexpected length or input params to the constructor, logical error, trying to make a call to non-existing contract, or anything else.

It turns out that I'm misreading Polygonscan and that just because there's a red mark next to an internal transaction doesn't mean that it's the internal transaction itself that reverted; it means that the whole transaction reverted. Anyways, using the Tenderly debugger helped me identity the real bug.

Related

IERC20 public declaration with another address?

I am new to solidity, but checking through a specific contract I found the following line of code in the IERC20 declaration:
IERC20 public "TOKEN NAME" = IERC20("THE ADDRESS OF ANOTHER CONTRACT");
This code was found in a contract that is effectively a fork of another project, but the developers say they are unrelated. Of course, people are just FOMO into the token - I know this forum here is not for this type of discussion so I'll abstain from the same.
However, from a solidity coding perspective, why would one write this line of code directly referencing another contract address (the forked address) when making the IERC20 declaration - what does this do, is there a purpose to this?
It seems to me that this is easier and more reliable. Alternatively, you can pass this address in constructor parameters, or provide a special method to set it.
The IERC20 is an interface that defines expected functions arguments and return values.
It helps validating whether the caller is passing correct data types, amount of arguments, and helps parsing the returned data to expected types.
Let's show it on a very simple interface
interface IGame {
function play(uint256 randomNumber) returns (bool won);
}
Elsewhere in your contract, you define a variable that uses this interface
IGame game = Game("0xthe_game_address");
You can then directly call the other contract's methods defined in the interface and pass the return values to your variables.
bool didIWin = game.play(1);
The call would fail if the game contract didn't have the play method or didn't return any value (plus in few other cases).
As for why is the address hardcoded, it's probably just to simplify the development as Mad Jackal already said in their answer.
One more plausible reason in some cases is to gain more trust by showing users that the contract admins are not able to cheat you by changing the destination address (possibly to a contract made by them doing whatever they want).
Edit: If the another contract's address is really unrelated and useless (meaning, the fork is not calling it), it's probably just a human error and the developer forgot to remove it.

How to get the address of the code being executed from CALLCODE?

I want to write a library which can be callcalled by any contract.
As part of this, I want to write a function which returns the contract address of the library to the contract which callcalled it.
address(this) is normally the solution, but in the case of callcode, it can only be used to check if the contract is being callcalled through if(address(this)==msg.sender) which become always true.
So how to perform this without having to rewrite the code each time because of the requirement to predict the future library’s contract address ?

VM Exception while processing transaction:Gas estimation errored

it is deployed into node by using testrpc it not working in that node especially transferto function and the withdrawal function.how to fix this problem.it's only working in compiler version:0.4.25+commit.59dbf8f1.Emscripten.clang, it's working in higher version of compiler.
The reason why it could be working in higher versions is because you have constructor() function. If you want to have this contract work for previous versions create the constructor function as function ethertransfer() also when you have revert errors most probably it will happen because the conditions you have written in require() statements. Require Statement also accept second parameter a string which you can put description. Check all require statements carefully, another option I would highly suggest is use remix browser ide. There you can debug through the debug tool in that it will help you step in and step over the transaction flow. So that at the end it will be very easy to identify the root cause of the issue.
It seems code is fine,
Make sure that contract has some ethers on balance require(address(this).balance >= amount);
and you calling these functions from owner address require(msg.sender == _owner);
If you use solidity version >= 5.0.0, use withdrawal pattern https://solidity.readthedocs.io/en/v0.5.0/common-patterns.html#withdrawal-pattern

Cannot find functions in call graph

I am beginning with Solidity and have begun experiencing this problem in my Contract. I created a test case to show the issue(pictured below with console log included) that is also getting the same error. Functions and events are not being recognized in the call graph and I am not quite sure why because they are explicitly there.

How to deploy truffle contract to dev network when using inheritance?

I have been attempting to deploy a contract using the Truffle framework, I have recently been testing these contracts on the development network.
My contract was very large and when I attempted to deploy it to a test net, I was instructed to split it up so that the contract wouldn't exceed the gas limit. Although, bearing in mind this contract did deploy onto the development network with the default gas limit.
So I took out parts of the contract and derived another contract from the base and added the deleted sections in there. I attempted to deploy it to the development network in order to test it again, I now get the error:
'Error: The contract code couldn't be stored, please check your gas amount.'
So the steps I took was to:
Change my gasLimit to 100,000,000 which didn't solve it
Check to see if my contract is 'abstract'
My understanding of this is that a contract is abstract if it or its
parent has any functions without an implementation. Mine don't.
I then deleted all of the code other than the constructor from the
derived contract and I still get this error
I deleted the file and the deployment worked with just my base contract as before, therefore the parent contract must not have any non-implemented functions AND it still doesn't work when I attempt to derive an empty contract from it (making sure nothing was abstract in the derived contract).
I then split my migration files up so that the migrations happen
separately, still no luck.
My parent contract is around 300 lines long so no point posting it all in here - I know some people will say 'it may just be too large' however, it deployed when it was 500 lines long on the dev network and now it is only 250 lines long with a deriving contract of 275 lines long, it does not deploy.
The error:
Running migration: 2_deploy_contracts.js
Replacing ERC20Token...
... 0xcae613274de1aa278e7ae5d1239f43445132a417d98765a4f227ea2439c9e4fc
ERC20Token: 0xeec918d74c746167564401103096d45bbd494b74
Replacing Crowdsale...
... 0x0ffc7291d84289c1391a81ed9f76d1e165285e3a3eadc065732aa288ea049b3a
Crowdsale: 0x0d8cc4b8d15d4c3ef1d70af0071376fb26b5669b
Saving successful migration to network...
... 0x7f351d76f61f7b801913f59b808688a2567b64933cdfdcf78bb18b0bf4e4ff69
Saving artifacts...
Running migration: 3_more_deployed_contracts.js
Deploying StagedSale...
... 0x216136bb24d317b140a247f10ec4d6791559739111a85932133cd4a66b12a1d9
Error encountered, bailing. Network state unknown. Review successful
transactions manually.
Error: The contract code couldn't be stored, please check your gas
amount.
at Object.callback
(/usr/local/lib/node_modules/truffle/build/cli.bundled.js:329221:46)
at /usr/local/lib/node_modules/truffle/build/cli.bundled.js:39618:25
at /usr/local/lib/node_modules/truffle/build/cli.bundled.js:331159:9
at /usr/local/lib/node_modules/truffle/build/cli.bundled.js:175492:11
at /usr/local/lib/node_modules/truffle/build/cli.bundled.js:314196:9
at XMLHttpRequest.request.onreadystatechange
(/usr/local/lib/node_modules/truffle/build/cli.bundled.js:329855:7)
My base contract is too large to post, and it deploys fine on its own meaning its not abstract.
My derived contract is:
pragma solidity ^0.4.16;
import "./SafeMath.sol";
import "./Crowdsale.sol";
contract StagedSale is Crowdsale {
using SafeMath for uint256;
/*
* Setup the contract and transfer ownership to appropriate beneficiary
*/
function StagedSale
(
uint256 _stage1Duration,
uint256 _stage2Duration
) public {
uint256 stage1duration = _stage1Duration.mul(1 minutes);
uint256 stage2duration = _stage2Duration.mul(1 minutes);
}
My migration file for the derived contract:
var StagedSale = artifacts.require("./StagedSale.sol");
module.exports = function(deployer) {
const stage1Duration = 1;
const stage2Duration = 1;
deployer.deploy(StagedSale, stage1Duration, stage2Duration);
};
I have posted this question here as I fear this may be a common issue with Truffle deployment.
To conclude, I don't believe this has anything to do with the actual gas limits and is instead, failing for some unknown reason and printing this error message anyway.
I've found a fix to this, basically if you are inheriting from a base contract, you must deploy the base contract within the inherited contracts constructor like so:
OLD VERSION:
Simply deployed the base, then deployed the inheriting contract with a reference to 'is Crowdsale' in class name
deployer.deploy(ERC20Token, initialAmount, tokenName, decimalUnits,tokenSymbol).then(function() {
return deployer.deploy(Crowdsale, softCap, hardCap, etherCostOfEachToken, sendFundsTo, toChecksumAddress(ERC20Token.address), durationInMinutes);
});
deployer.deploy(FinalizableSale);
NEW VERSION
Only deploy the inheriting contract and create a new instance of base within that constructor
deployer.deploy(ERC20Token, initialAmount, tokenName, decimalUnits,tokenSymbol).then(function() {
return deployer.deploy(Finalizable, softCap, hardCap, etherCostOfEachToken, sendFundsTo, toChecksumAddress(ERC20Token.address), durationInMinutes);
});
FINALIZABLE CONSTRUCTOR:
function FinalizableSale(uint256 _fundingGoalInEthers, uint256 _fundingLimitInEthers, uint256 _etherCostOfEachToken, address _sendFundsTo, address _tokenAddress, uint256 _durationInMinutes)
Crowdsale(_fundingGoalInEthers, _fundingLimitInEthers, _etherCostOfEachToken, _sendFundsTo, _tokenAddress, _durationInMinutes)
{
//do something
}
NOTE: That the base contract is initialised BEFORE the opening brackets to the constructor function.
I no longer get the 'out of gas' error and my contract runs as before.