So from my understanding when creating a contract the two variables that are used in determining what the address of the contract will be are the msg.sender and the nonce value. So if I create two contracts in the same transaction such as I did with this code https://ropsten.etherscan.io/address/0xcb7d7e99e56406a675173f0ddbde7d8cc3392e5e#code
Why did it generate two contracts at two different addresses, what I though would happen is that they would generate at the same address and the one would simply overwrite the other or something like that.
You're understanding of the contract address determined by the address of the message creator and the nonce is correct. However, in the example you posted, msg.sender is the address of the Test contract.
These are the steps that occured:
You initiated the transaction to deploy Test from your external account (0x98081ce968e5643c15de9c024de96b18be8e5ace). According to the transaction information, the nonce of the account at that time was 639.
This resulted in the Test contract having an address of 0xcb7d7e99e56406a675173f0ddbde7d8cc3392e5e.
During the deployment of Test, the constructor then creates two new contracts through "internal transactions". Divert is deployed from the contract address at 0xcb7d7e99e56406a675173f0ddbde7d8cc3392e5e with nonce=1. OverRide is deployed from the same address with nonce=2.
You can view the details of the internal transaction here.
Related
I need to analyze blocks and txs to find if there is a transfer ETH to address from my list. When some user makes a direct transfer it is clear, I can check to parameter of the transaction. But sometimes users execute smart contracts which transfer ETH to address from my list, in this case to is the address of the smart contract, so I can't match it with my list. Is there a way to handle such cases?
If you mean something like an "internal tx" of a forwarding contract like this example. Which does a value call (address.call()()). Then there is no way of knowing the final destination with tracing the transaction. Alternatively some contracts could emit an event or in the case of forwarding contracts, you could read the 'parentAddress' set during contract init.
Etherscan parses the trace for you so you can see those internal transfers afaik (see example above).
I want to deploy my own ERC-20 token on different blockchains, so is there any possibility to deploy the same token contract on different blockchains. If we do that we can't give the same name and symbol for three blockchains. can anybody tell me what is the solution for this problem? Or can we deploy the contract with the same contract address on three blockchains?
can we deploy the contract with same contract address on three blockchains.
It depends on the network that you're deploying to and the address that you're deploying from. Assuming that the networks of your choice have the same 1) address format and 2) calculation of deployed contract address - then yes, you'll be able to deploy your contract on the same address on multiple networks.
For example Ethereum and BSC do have both of these features. But even though Tron network supports EVM-compatible smart contracts, it has a different way to calculate its addresses, so it won't be possible to deploy your contract on Tron network with the same address as on Ethereum or BSC.
The key to deploy the contract to the same address on multiple networks, is to deploy from the same address, and using the same params:
In case of the regular CREATE opcode, the transaction deploying the contract needs to have the same nonce (and the same from) value across all networks.
Or if you're using the CREATE2 opcode, you need to pass the same contract bytecode, the same salt (to the CREATE2), and again, you need to send the deploying transaction from the same address.
If we do that we can't give the same name and symbol for three blockchains
It is technically possible, so I'm assuming it's "just" a limitation of your business case or some tool that you're using, or a possible simple misunderstanding of how the ERC-20 standard works.
pragma solidity ^0.8;
contract MyToken {
string public constant name = "MyToken";
string public constant symbol = "MyT";
// TODO rest of your token contract source code
}
I'm a new beginner in the ethereum Blockchain.
I want to implement a smart contract that verifies the authenticity of a user and then send a message to a cloud service (with is the smart contract creator) in case of positive verification to grant access to the user.
My question is it possible for a smart contract to return results of his methods invocation to another blockchain user and how we can do it?
A smart contract cannot make calls outside of the blockchain. i.e., you cannot have it call an http endpoint or something similar.
In ethereum, the usual way of achieving something like this is:
Have the user make a transaction passing relevant data to your smart contract
The smart contract runs whatever verification logic it must on that data
The smart contract logs an Event
You have an ethereum node that your code connects to and listens for these events.
This question is a little conceptual, so hopefully this picture will help clear up my misunderstanding.
Image there is a crowdsale smart contract deployed on address 0x2. A User at address 0x01 buys a token.
Here is my understanding of what happens:
The crowdsale contract (# address: 0x2) accepts ether from the user account (# address: 0x1)
The crowdsale contract stores 0x1 as having purchased a token (important: this information is stored in the smart contract #address 0x2)
Now my Question: If 0x1 is a user account (and not a smart contract) there is no code at address 0x1. I thought a user account just consisted of an address + ether associated with the address, how can it also store the fact that 0x1 owns an ERC20 token? For example, I can login to MetaMask and (before clicking the "add token" option) MetaMask can see that I have a token... how is this possible?
Every ERC20 contract has the following function:
function balanceOf(address _owner) public view returns (uint256 balance) {
return balances[_owner];
}
Your wallet just calls this function from the known token contracts with your address. Since it's a view function it doesn't cost any gas.
I recon most ERC20 token get added rather quickly to a wallet like Metamask or MEW. But if your balance doesn't automatically show, you can add the contract address manually (in MEW at least, not sure about Metamask) and it will show up afterwards.
In solidity there are two ways to get the address of the person who sent the transaction
tx.origin
msg.sender
In your example, in the method inside ERC20 Token.sol, the value tx.origin will be 0x1 and msg.sender will be 0x2
So to answer your question, how does the ERC20 token know about 0x2 is: it depends on how the token contract is written and whether it uses tx.origin or msg.sender. I would imagine it uses msg.sender, because that is the more prevalent one.
If it does use msg.sender you can still make the crowdsale contract work by first buying the tokens and then immediatelly transfering the tokens from the crowdsale contract to the caller.
For more information, refer to What's the difference between 'msg.sender' and 'tx.origin'?
how can it also store the fact that 0x1 owns an ERC20 token?
Token transfers, or transfers in accounting in general, are kept in a ledger. In this case, the ledger is ERC-20 smart contract that internally keeps balances who owns and what in its balances mapping. Or, the smart contract manage the storage (EVM SSTORE instructions) where the records of ownership are kept.
Note that some other blockchains, like Telos and EOS (and mayne Solana) might be opposite and there the storage is maintained on the user account (user account has associated RAM and tables for any token user owns).
Currently I'm trying to learn ethereum and smart contract. I read this tutorial: Dapps for beginners
I'm just wondering now, if I have to call everytime a function from a contract (as in the tutorial above) or is it possible that a specific function is executed when I just transfer some ethereum to that contract address?
Example:
I execute the code below, and the receiver address is also a address with a contract. One specific function should now be executed at the receiver function.
eth.sendTransaction({from:sender, to:receiver, value: amount})
You should create a nameless payable function in your smart contract.
This will then be the default function to execute if someone sends a raw transaction at your contract's address.
function() payable public {
}
Also, the other answer here states that you need to know the contract ABI to communicate with contracts but this is not true.
You need to know the contract address, the function name and the input and output parameter types. (You could use Web3's method.call or method.sendTransaction to send the encoded data in the transaction object and interact with the contract.)
The ABI may have this information, but the ABI is not required itself.
You can only communicate with contracts if you know the ABI which is the application binary interface.
In general, an ABI is the interface between two program modules, one of which is often at the level of machine code. The interface is the de facto method for encoding/decoding data into/out of the machine code. In ethereum, it's basicly how you can encode solidity contracts for the EVM and backwards how to read the data out of transactions.
If you have the JSON ABI of a contract, you still have to decide if you want to make calls or transactions. The difference between a call and a transaction is the following:
Transactions are created by your client, signed and broadcasted to the network. They will eventually alter the state of the blockchain, e.g., by manipulating balances or values in smart contracts.
Calls are only executed locally on your computer and not broadcasted to the network, e.g., a dry run.
Calls are usefull for debugging smart contracts as they do not cost transaction fees or gas.
So if you only send a transaction to a contract without using any interface, you wont be able to execute any code on the contract.