I am trying to verify my contracts via etherscan and hardhat. Everything seems fine with contracts without constructor arguments. I do it with
npx hardhat verify ${address} --network goerli
The problem is with one of my contracts that has bytes argument in the constructor. I can't pass bytes in the command line. Hex strings like "\x01\x02\x03\x04" dont work either. Converted to chars doesn't work also.
Is there a way to write script that passes the arrayified variable as constructor argument?
Following this docs
When the constructor has a complex argument list, you'll need to write
a javascript module that exports the argument list. The expected
format is the same as a constructor list
you should have a file like arguments.js
module.exports = [
50,
"a string argument",
{
x: 10,
y: 5,
},
// bytes have to be 0x-prefixed
"0xabcdef",
];
this is arguments for a contract. and in commandline:
npx hardhat verify --constructor-args arguments.js DEPLOYED_CONTRACT_ADDRESS
Related
Using openzeppelin's UUPS upgradeable proxy contracts results in the following slither error. Are they false positives or should I be concerned?
Enviornment:
"#openzeppelin/contracts-upgradeable": "^4.5.2",
$ slither .
'npx hardhat compile --force' running
hardhat solidity version 0.8.9
Error 1:
ERC1967UpgradeUpgradeable._functionDelegateCall(address,bytes) (node_modules/#openzeppelin/contracts-upgradeable/proxy/ERC1967/ERC1967UpgradeUpgradeable.sol#198-204) uses delegatecall to a input-controlled function id
- (success,returndata) = target.delegatecall(data) (node_modules/#openzeppelin/contracts-upgradeable/proxy/ERC1967/ERC1967UpgradeUpgradeable.sol#202)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#controlled-delegatecall
Error 2:
ERC1967UpgradeUpgradeable._upgradeToAndCallUUPS(address,bytes,bool).slot (node_modules/#openzeppelin/contracts-upgradeable/proxy/ERC1967/ERC1967UpgradeUpgradeable.sol#98) is a local variable never initialized
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#uninitialized-local-variables
Error 3:
ERC1967UpgradeUpgradeable._upgradeToAndCallUUPS(address,bytes,bool) (node_modules/#openzeppelin/contracts-upgradeable/proxy/ERC1967/ERC1967UpgradeUpgradeable.sol#87-105) ignores return value by IERC1822ProxiableUpgradeable(newImplementation).proxiableUUID() (node_modules/#openzeppelin/contracts-upgradeable/proxy/ERC1967/ERC1967UpgradeUpgradeable.sol#98-102)
ERC721Upgradeable._checkOnERC721Received(address,address,uint256,bytes) (node_modules/#openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol#393-414) ignores return value by IERC721ReceiverUpgradeable(to).onERC721Received(_msgSender(),from,tokenId,_data) (node_modules/#openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol#400-410)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#unused-return
No, slither often flags OpenZepplin contracts, because they often use low-level functions like delegatecall or use assembly to deal with the return data.
So it's fine just keep in mind that while slither is an amazing piece of software it can't detect everything correctly.
I need to call a contract function from Etherscan that takes a 2d array as an argument, namely: foo (address[][]).
I have tried every thinkable way to call the function with no success. Etherscan displays error
expected array value (arg="foo", coderType="array", value="0xabscde1234567887654321abcde")
What is the correct way to call the function?
This works with Remix, but not etherscan. No quotes necessary. Should work for addresses too.
[[1,2],[6,9],[2323,10]]
Try this statement to pass into a function an address multidimensional array:
[["ADDRESS_1","ADDRESS_2"]]
If you want to pass more address in a second index of matrix you can use this statement:
[["ADDRESS_1","ADDRESS_2"],["ADDRESS_1", "ADDRESS_2"]]
inside a Solidity contract there is a declaration as follows:
contract Lottery is VRFConsumerBase, Ownable {
address payable[] public players;
...
...
elsewhere in the same contract,there is a an assignment as follows:
....
....
recentWinner = players[someIndex];
....
....
}
the deploy.py Python script is used to deploy the contract. the function deploying the contract is:
def deploy_lottery():
Lottery.deploy(....)
....
....
After deployment and doing other stuff... the contract's recentWinner variable is accessed from python script using parenthesis as follows:
def end_lottery():
print(f"{lottery.recentWinner()} is the winner!")
My rather basic question is, why are parenthesis used? recentWinner is not a function that was defined in the Lottery contract. If I ran the script without the paranthesis, I get the following output.
<ContractCall 'recentWinner()'> is the winner!
Terminating local RPC client...
so it seems like the paranthesis is necessary. can somebody explain what is going on please? why should I treat this variable like a function in order to retrieve its value? if you can also point me to some related posts/reading material that would be much appreciated. thank you!
EVM does not have public variables, only public accessor functions.
Behind the scenes, the Solidity compiler generates a function called recentWinner() for you. This is called accessor or getter function. Unlike in Java etc. languages there is no get prefix for the function.
My understanding is that you can define an operator when instantiating a custom ERC-777, that can make transfers without needing to be approved by the senders using the operatorSend function. However, can't seem to get the address of the contract that deploys the token into the inherited constructor. I tried pushing the address into the array in the body of the constructor, but that doesn't seem to take.
contract MainToken is ERC777 {
address[] ops=;
constructor () ERC777("MYTOKEN", "MTK",ops) {
ops.push(msg.sender);
}
...
}
If I try putting it directly into the constructor like so ERC777("MYTOKEN", "MTK",[msg.sender]), I get
Invalid type for argument in modifier invocation. Invalid implicit
conversion from address[1] memory to address[] memory requested.
Solidity currently doesn't allow defining a dynamic-size array in one expression. Note: [msg.sender] from your example is a fixed-size array definition.
Also, your approach with defining the ops property doesn't work, because of the order how EVM processes the constructor.
Storing child (MainToken) constructor arguments to memory (in your case no arguments)
Executing parent constructor.
In your case the execution of ERC777("MYTOKEN", "MTK", ops) fails, because the storage variable ops is not available yet.
Executing child constructor (in your case ops.push(msg.sender);)
So the easiest Solution I could come up with, is passing the address from the MyToken argument. This is useful if you have control over the deployment process and can manually pass the value of msg.sender when you're deploying the contract.
pragma solidity 0.8.4;
import 'https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC777/ERC777.sol';
contract MyToken is ERC777 {
constructor(address[] memory defaultOperators)
ERC777('MYTOKEN', 'MTK', defaultOperators) {
}
}
If you're not going to have control over the deployment and need to assign msg.sender in constructor, I suggest copying the ERC777 contract locally and modifying its constructor, so that it only adds the msg.sender.
So my understanding of currying (based on SO questions) is that it lets you partially set parameters of a function and return a "truncated" function as a result.
If you have a big hairy function takes 10 parameters and looks like
function (location, type, gender, jumpShot%, SSN, vegetarian, salary) {
//weird stuff
}
and you want a "subset" function that will let you deal with presets for all but the jumpShot%, shouldn't you just break out a class that inherits from the original function?
I suppose what I'm looking for is a use case for this pattern. Thanks!
Currying has many uses. From simply specifying default parameters for functions you use often to returning specialized functions that serve a specific purpose.
But let me give you this example:
function log_message(log_level, message){}
log_error = curry(log_message, ERROR)
log_warning = curry(log_message, WARNING)
log_message(WARNING, 'This would be a warning')
log_warning('This would also be a warning')
In javascript I do currying on callback functions (because they cannot be passed any parameters after they are called (from the caller)
So something like:
...
var test = "something specifically set in this function";
onSuccess: this.returnCallback.curry(test).bind(this),
// This will fail (because this would pass the var and possibly change it should the function be run elsewhere
onSuccess: this.returnCallback.bind(this,test),
...
// this has 2 params, but in the ajax callback, only the 'ajaxResponse' is passed, so I have to use curry
returnCallback: function(thePassedVar, ajaxResponse){
// now in here i can have 'thePassedVar', if
}
I'm not sure if that was detailed or coherent enough... but currying basically lets you 'prefill' the parameters and return a bare function call that already has data filled (instead of requiring you to fill that info at some other point)
When programming in a functional style, you often bind arguments to generate new functions (in this example, predicates) from old. Pseudo-code:
filter(bind_second(greater_than, 5), some_list)
might be equivalent to:
filter({x : x > 5}, some_list)
where {x : x > 5} is an anonymous function definition. That is, it constructs a list of all values from some_list which are greater than 5.
In many cases, the parameters to be omitted will not be known at compile time, but rather at run time. Further, there's no limit to the number of curried delegates that may exist for a given function. The following is adapted from a real-world program.
I have a system in which I send out command packets to a remote machine and receive back response packets. Every command packet has an index number, and each reply bears the index number of the command to which it is a response. A typical command, translated into English, might be "give me 128 bytes starting at address 0x12300". A typical response might be "Successful." along with 128 bytes of data.
To handle communication, I have a routine which accepts a number of command packets, each with a delegate. As each response is received, the corresponding delegate will be run on the received data. The delegate associated with the command above would be something like "Confirm that I got a 'success' with 128 bytes of data, and if so, store them into my buffer at address 0x12300". Note that multiple packets may be outstanding at any given time; the curried address parameter is necessary for the routine to know where the incoming data should go. Even if I wanted to write a "store data to buffer" routine which didn't require an address parameter, it would have no way of knowing where the incoming data should go.