How to detect if an Ethereum address is an ERC20 token contract? - ethereum

If I only get an Ethereum address from the input, is there a way to find out whether it matches the ERC20 token standard?

ERC165 tackles this problem, but, unfortunately, most ERC20 implementations don't support it (as of Nov 2018, at least OpenZeppelin doesn't). This means that you could try calling the supportsInterface function, but it would revert anyway and you'd rather complicate things.
Nevertheless, here's how it's defined in ERC721:
bytes4 private constant _InterfaceId_ERC721 = 0x80ac58cd;
/*
* 0x80ac58cd ===
* bytes4(keccak256('balanceOf(address)')) ^
* bytes4(keccak256('ownerOf(uint256)')) ^
* bytes4(keccak256('approve(address,uint256)')) ^
* bytes4(keccak256('getApproved(uint256)')) ^
* bytes4(keccak256('setApprovalForAll(address,bool)')) ^
* bytes4(keccak256('isApprovedForAll(address,address)')) ^
* bytes4(keccak256('transferFrom(address,address,uint256)')) ^
* bytes4(keccak256('safeTransferFrom(address,address,uint256)')) ^
* bytes4(keccak256('safeTransferFrom(address,address,uint256,bytes)'))
*/
Although it's not guaranteed for all implementations to define the interface id, there's a higher chance it will work in the case of ERC721, given the fact the community agreed on applying ERC165 right from the get-go. If the return value of the query below is true, then it means you have a compliant contract, otherwise just revert the transaction.
// you can call this in your contracts
IERC721(contractAddress).supportsInterface(0x80ac58cd)
Also, a useful resource for manually checking the bytes4 of a given method is 4byte.directory

If you are asking about off-chain, so use these functions:
getContract(url, smartContractAddress){
const Web3Eth = require('web3-eth');
const abi_ = this.getABI();
const web3Eth = new Web3Eth(Web3Eth.givenProvider || url);
return new web3Eth.Contract(abi_, smartContractAddress);
}
async getERCtype(contract){
const is721 = await contract.methods.supportsInterface('0x80ac58cd').call();
if(is721){
return "ERC721";
}
const is1155 = await contract.methods.supportsInterface('0xd9b67a26').call();
if(is1155){
return "ERC1155";
}
return undefined;
}
getABI(){
return [
{"constant":true,"inputs": [
{"internalType":"bytes4","name": "","type": "bytes4"}],
"name": "supportsInterface",
"outputs": [{"internalType":"bool","name": "","type": "bool"}],
"payable": false,"stateMutability":"view","type": "function"}
];
}
like this:
const contract = getContract(url, smartContractAddress);
const type = await getERCtype(contract);
console.log(type);

There are many possible ways to achieve this. One possible quick and dirty solution is to check if a ERC20 function exists on the contract address by calling the following:
eth.call({to:contractAddress, data:web3.sha3("balanceOf(address)")})
A non-ERC20 will return a 'null' 0x hex response whereas an ERC20 will give you a 32byte uint, in this case 0 but if you provide an address in the data then it will give you the actual token balance for that address.
This is not a guaranteed way of determining a contract is ERC20 since other contracts may expose the same function, however it is a quick and easy check. You could add additional calls on totalSupply() etc. for more confirmation.

the question states that given an Ethereum address, is this an Ethereum contract address or not?
First thing, you have to decide if this address is a contract address or an externally owned account address. How to find out if an Ethereum address is a contract
If it is a contract address, then you can only get the bytecode that is stored in the blockchain. Now you have to reverse engineer the bytecode to get the contract functions but this is almost impossible. There are some decompilers but they are not perfectly creating the contract code from the bytecode.
ERC165 just checks if the current contract signature supports the given interfaceId or not. Since you have only ethereum address, this will not help in this question.

Related

Best plan of attack for digital certificates for proof of completion on EVM

I am looking to explore the option of creating a digital certificate (as in proof) when someone has completed a portion of training, and for this to be issued on an EVM-compatible blockchain using Solidity.
I have prototyped using ERC721 NFTs to encode a "certificate" however, I'd like to prevent recipients from being able to transfer these certificates. To prevent transfer, I attempted to use the Pause.sol functionality from OpenZeppelin, however, this would result in the entire contract being paused, as opposed to a specific tokenId.
Does anyone have any recommendation on an approach? Am I overcomplicating it if I don't want recipients to be able to trade the certificates (i.e. for them to remain static)? Any pointers would be much appreciated!
The simplest and most raw solution is to just set a mapping value.
pragma solidity ^0.8;
contract TrainingResults {
enum Stage {
NONE,
STAGE_1,
STAGE_2,
COMPLETED
}
mapping (address => Stage) public participantStage;
function setParticipantStage(address _graduate, Stage _stage) external {
require(msg.sender == address(0x123), "Not authorized");
participantStage[_graduate] = _stage;
}
}
Or if you want them to be able to see some kind of NFT in their wallet (that supports NFTs), you can modify the ERC-721 contract to disallow transfers.
For example the OpenZeppelin implementation uses a function named _beforeTokenTransfer() (GitHub link) that can be overwritten to disallow transfers altogether.
pragma solidity ^0.8;
import "#openzeppelin/contracts/token/ERC721/ERC721.sol";
contract TrainingResults is ERC721 {
constructor() ERC721("TrainingResults", "TR") {}
function _beforeTokenTransfer(address from,address to, uint256 tokenId) override internal {
// Allow only for the admin
// as this function is called on token mint as well
require(msg.sender == address(0x123), "Cannot transfer tokens");
}
}

Aave aaveLendingPool.withdraw() return value validation

I am writing a pull payment function and, as with any external call it is good practice validate the result and check successful execution. I am using the following interface:
interface IAaveLendingPool {
function deposit(
address asset,
uint256 amount,
address onBehalfOf,
uint16 referralCode
) external;
function withdraw(
address asset,
uint256 amount,
address to
) external;
function getReservesList() external view returns (address[] memory);
}
aAveLendingPool= IAaveLendingPool(0x0543958349aAve_pooladdress)
The interface provided by Aave doesn't specify a return either. The withdraw function of the LendingPool.sol contract returns external override whenNotPaused returns (uint256).
The question: Can I use the returned uint to validate successful execution or aAveLendingPool.withdraw() returns a boolean? Will the following work as expected?
///#notice assigns dai to caller
require( aaveLendingPool.withdraw(
address(dai),
amount,
msg.sender), "Error, contract does not have enough DAI")
Please provide a solidity docs link to external function call return value, if any.
According to the Consensys Diligence Aave V2 audit:
ERC20 implementations are not always consistent. Some implementations of transfer and transferFrom could return ‘false’ on failure instead of reverting. It is safer to wrap such calls into require() statements to these failures.
Therefore, wrapping the transfer call in a require check is safe and sufficient.
require( aaveLendingPool.withdraw(
address(dai),
amount,
msg.sender), "Error, contract does not have enough DAI")

Way in solidity to match users address with address defined in array

I am looking for an efficient way to check if the the person invoking a function is allowed to access a function defined in a smart contract by comparing msg.sender with array of addresses that I am hardcoding at the time of deployment in solidity. I can do it using for loop but that takes a lot of gas. Thanks in advance.
Use mapping to store this.
mapping(address => bool) public blacklisted;
...
require(!_blacklisted[msg.sender]);
You could also use it as a modifier:
modifier notBlacklisted() {
require(!blacklisted[msg.sender]);
_;
}
then in a function:
function foo() notBlacklisted public
{
// do stuff
}
only users who are not blacklisted will be able to use the function.
At first I was tempted to tell you there's no way around it, but then I got intriguing idea and it turned out to work out pretty well! Note however, that this will only work in case you know the addresses at compile time.
Note: In my experiment, I've modified the task a bit - I will be comparing msg.sender to list of blacklisted addresses. Changing this to your usecase is straightforward.
Intuitive solution
The intuitive way to implement the functionality you are proposing would be probably following:
pragma solidity ^0.4.18;
contract DataInStorage {
uint counter;
address[] public blackListed = [ 0x281055afc982d96fab65b3a49cac8b878184cb16, 0x6f46cf5569aefa1acc1009290c8e043747172d89 ]
function increment() public {
for (uint i=0; i<blackListed.length; i++) {
require(msg.sender != blackListed[i]);
}
counter += 1;
}
}
The gas costs turned out to be following:
<number of addresses> | <gas spent>
100 | 124808
200 | 207708
So it seems that the cost of one iteration is about 829 (829 * 100 = 82900 = 207708 - 124808)
Why is this expensive?
First of all, why is iterating addressed and comparing them to msg.sender expensive? It's not because of the for loop, it's not because of the if comparisons. The reason is that EVM needs to read from contract storage. Reading and writing to storage are the most expensive operations.
Contract code vs Contract storage
So here comes the idea. What if we don't put these addresses into contract storage, but contract code instead? Let's give it a try
pragma solidity ^0.4.18;
contract DataInCode {
uint counter;
function increment() public {
require(0x281055afc982d96fab65b3a49cac8b878184cb16 != msg.sender);
require(0x6f46cf5569aefa1acc1009290c8e043747172d89 != msg.sender);
counter += 1;
}
}
I've tried this pattern with higher number of addresses, and here's an interesting result
<number of addresses> | <gas spent>
100 | 45338
200 | 49038
So one address verification costs us in this case only 37 gas. That's about 22 times better than the solution with contract storage.
If someone can provide more technical explanation why loading code in EVM is much cheaper than loading data storage, I would love to hear it.
Full example
Data In Code (100 addresses) https://ethfiddle.com/mDB9OM2azy
Data In Code (200 addresses) https://ethfiddle.com/nIt2QwBLTX
Data In Storage (100 addresses) https://ethfiddle.com/Wg5CMAN0OU
Data In Storage (200 addresses) https://ethfiddle.com/5NVVCVUT0R
Tested with Truffle

How to sign a transaction send by contract

I am trying to understand the basics behind signing an ethereum transaction.
I come across Gnosis's MultiSigWallet :
https://github.com/gnosis/MultiSigWallet/blob/master/contracts/MultiSigWallet.sol
In which, a modifier onlyWallet requires a transaction must be sent from the contract itself, but the transaction is signed by one of the owners of the contracts:
modifier onlyWallet() {
require(msg.sender == address(this));
_;
}
for functions like:
function replaceOwner(address owner, address newOwner)
public
onlyWallet
ownerExists(owner)
ownerDoesNotExist(newOwner)
{...}
I have successfully deployed the contracts on my testnet, and tried its functionalities using their dapp https://wallet.gnosis.pm/#/transactions
However, I cannot understand how a transaction is signed and sent to meet the onlyWallet requirement, since signing a transaction using metamask for example will cause the msg.sender to be my own wallet address.
If possible, an example of this ethereumjs-tx's functions would be much appreciated.
like:
const privateKey = Buffer.from('<private key 1>','hex');
const txParams = {
nonce: web3.utils.toHex(11),
gasPrice: web3.utils.toHex(1000000000),
gasLimit: web3.utils.toHex(300000),
to: '<contract address>',
value: web3.utils.toHex(web3.utils.toWei("1",'ether')),
data: '0x00',
chainId: 1
};
let tx = new EthTx(txParams);
tx.sign(tx.serialize().toString('hex');
web3.eth.sendSignedTransaction(`0x${tx.serialize().toString('hex')}`,
(error, data) => {
if(!error) {
console.log(data);
}else console.log(error);
}
);
Thank you very much
Adding and removing an owner follows the same rules as confirming any transactions from the MultiSigWallet. Assume the wallet was deployed with 3 EOA addresses as owners and requiring 2 confirmations for execution. For any regular transaction, say donate funds from the wallet to a FundRaisingContract, one of the owners would need to first call submitTransaction() passing in the address of FundRaisingContract, the amount of ether, and the hash for the donate function. After submission, you still need 1 of the other owners to confirmTransaction (the submitter is automatically confirmed). Once completed, now executeTransaction can be successfully run which will execute the call to donate() from the MultiSigWallet address.
That last part is what you're looking for to answer your question. To add an owner, repeat the example but use the MultiSigWallet address and the hash of the addOwner method. When one of the other owners confirms the transaction, addOwner will be called and it will pass the onlyWallet modifier check.

Creating instance of contract inside another contract and calling it's methods results in thrown exception

I have 2 basic contracts: one is for token and the second is for sale.
Token сontract:
contract MyToken is StandardToken, Ownable {
string public constant name = "My Sample Token";
string public constant symbol = "MST";
uint32 public constant decimals = 18;
function MyToken(uint _totalSupply) {
require (_totalSupply > 0);
totalSupply = _totalSupply;
balances[msg.sender] = totalSupply;
}
}
Sale Contract
contract Sale {
address owner;
address public founderAddress;
uint256 public constant foundersAmount = 50;
MyToken public token = new MyToken(1000);
uint256 public issuedTokensAmount = 0;
function Sale() {
owner = msg.sender;
founderAddress = 0x14723a09acff6d2a60dcdf7aa4aff308fddc160c;
token.transfer(founderAddress, foundersAmount);
}
function() external payable {
token.transfer(msg.sender, 1);
owner.transfer(msg.value);
}
}
StandardToken and Ownable are all standard implementations from OpenZeppelin repository. Full contract source is available here.
So basically in my Sale Contract I create an instance of my token contract with fixed supply and assign all of the tokens to the caller. Then I transfer some amount of tokens to founder address. When I try to send some ethereum to Sale contract I'm attempting to transfer some of my tokens to the sender (Running all code in Remix browser, I create an instance of Sale contract and call "fallback" method specifying some ether amount). However, this fails with "Exception during execution. (invalid opcode). Please debug the transaction for more information." message. All that I can see when debugging is that code fails in payable method at line:
token.transfer(msg.sender, 1);
I can't see the exact reason for this as I'm not able to step into this method and see whats going on inside.
Interesting thing is that when I remove a call to transfer method on token instance in Sale Contract constructor - code seems to run fine without any exceptions.
What am I missing?
I debugged into the the contract using remix, and the invalid opcode is thrown by:
290 DUP8
291 DUP1
292 EXTCODESIZE
293 ISZERO
294 ISZERO
295 PUSH2 012f
298 JUMPI
299 PUSH1 00
301 DUP1
302 INVALID
I left out the rest, but essentially it loads the address of the token contract and calls EXTCODESIZE which retrieves the contracts code size, and checks that it's not equal to 0 (the token contract exists), unfortunately, it did equate to 0. At this point, I'm unsure whether this is a limitation in remix or I've misunderstood the setup.
I tried the identical contract setup on truffle + testrpc and it deployed, accepted the currency successfully. Do note however that testrpc indicated:
Gas usage: 59137
Meaning that this is above the default sendTransaction w/ no data default (21,000 gas). This means that in a live environment, ensure that you inform users to include extra gas, otherwise the fallback function would probably fail due to OOG errors.
The reason behind this is that you're using a fallback function. Try using a normal function and it should happen.