I have some functions that I'm trying to save gas on.
onlyOwner modifier is self explanatory.
This is related to a previous question that I had, where I noticed that address(this) is different from msg.sender in a given contract. Upon further reading I get the impression that address(this) is a hash of msg.sender, but the two are not considered the same. Is this correct?
Since address(this) is related to the owner address, is the owner address (msg.sender, set within the contract's constructor) considered different enough from the contract address address(this) so as to be considered external visibility?
// can the owner (set in the constructor) call this function once it is deployed on the blockchain?
function setXYZ(address _address) external onlyOwner returns (bool success) {
XYZ[_address] = 4;
return true;
}
Seems to work when I test it within my IDE, but I don't know if there is a difference in implementations between my test environment and the blockchain environment.
Upon further reading I get the impression that address(this) is a hash of msg.sender, but the two are not considered the same. Is this correct?
address(this) returns address of the currently executed contract. When a contract is deployed, it's assigned an address which is determined by hash of "the deployer address combined with other data". Once the contract address is assigned, it never changes.
On the other hand, msg.sender reflects address of whoever is currently executing the contract. So if Alice executes a function, msg.sender is her address - and if Bob executes the same function, msg.sender reflects his address.
As the OpenZeppelin Ownable code shows, the deployer address (msg.sender in constructor) becomes the initial owner.
And the onlyOwner modifier validates whether the current msg.sender is the owner. If they match - all good. If the currrent msg.sender is different from the owner, it reverts the transaction.
Seems to work when I test it within my IDE, but I don't know if there is a difference in implementations between my test environment and the blockchain environment.
This code will work the same on all EVM networks.
There are few very small differences between the EVM implementation in emulators and live networks (as well as between different live networks). But they mostly affect low-level features such as ordering of transactions in a block or gas usage optimizations.
Related
I want to build a smart contract function, which use caller's password as params.
I have no knowledge about blockchain security, so I ask the following question:
When calling a smart contract function, do the params record on blockchain?
Further more, what information will record in blockchain if an address calls a function of a smart contract?
I think the logs emit by the events must record on blockchain, besides these, anything more?
I've learned before that a contract address calling leaves logs on blockchain, but an account address(EOA) calling doesn't. Is it true?
Function parameters are part of the transaction, which is part of the calldata. So calldata is also persisted. Eventhough it is persisted, that doesn't mean it is easily available. Calldata is not indexed, and is not available at runtime. But the data is available to the nodes (for sure to those who runs full node, not sure about the light nodes).
Calldata can be accessed by running a localnode, which means it is not available for any functions at runtime, the only calldata that is available at runtime is the parameters for that particular transaction.
So, if you call a function with a password parameter, someone somewhere can see it for sure.
I want to create a smart contract which people can transfer tokens without ether in their wallet.
Suppose A want to transfer ERC20 tokens to B, but he does not have ether in his wallet.
Does third party C can send the transaction for A and therefore pay the gas? Is it possible to create a function in the contract for this usgae?
I have searched online for a soloution and could not find one.
This is a key issue of Ethereum dApp development, but also of tokens. Here is a very old thread on Ethereum Stack Exchange, and also this one.
There are 2 options with their pros and cons:
Use signatures
Every function in your smart contract must have signature parameter.
People who want to interact with the smart contract must sign the function parameters with their account's private key and send it to the smart contract owner (via any communication channel).
The owner then submits the parameters along with the signature to the blockchain, paying for gas. The signature guarantees that the message was approved by the user.
Refund used gas at the end of the transaction. A modifier refundGasCost can be used for this (see below).
But (1) is really hard to apply to token transfers where you just don't know who uses the token and (2) does not really address the issue.
There is a lot happening recently, there is this blog post about How to save your Ethereum Dapp users from paying gas for transactions, and since you ask about tokens, there is an ERC that suggests to Pay transfers in tokens instead of gas, in one transaction which would be nice if you have tokens but no ETH.
I hope this helps.
Exactly this case is already defined in the ERC20 standard. Its this function:
function transferFrom(address from, address to, uint tokens) public returns (bool success);
But before party C could use it and send tokens from A to B, A would have to approve C to do this via the following function, which is also defined in the ERC20 standard:
function approve(address spender, uint tokens) public returns (bool success);
No, in a standard ERC20 token contract, the token holder must initiate at least one transaction (to call transfer() or approve()), and a transaction must always be paid for by its initiator.
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.
this https://theethereum.wiki/w/index.php/ERC20_Token_Standard eth wiki describes erc20 standard as a set of functions and attributes a token needs to have implemented. some of them are pretty self explanatory like
function transfer(address to, uint tokens) public returns (bool success);
which takes coins from your wallet and transfers it to somebody elses.
But on the other hand
function approve(address spender, uint tokens) public returns (bool success);
or
function allowance(address tokenOwner, address spender) public constant returns (uint remaining);
How am I supposed to know what is the logic behind these methods? are there any extra docs describing it? and last but not least: what are upsides of tokens being ERC20 compliant?
ERC20 standard contains a set of functions that were proposed EIP-20 which were reviewed and voted on by community. As per abstract states the following:
This standard provides basic functionality to transfer tokens, as well as allow tokens to be approved so they can be spent by another on-chain third party.
See here for more some analogous examples on what approve and allowance do, but basically these are functions that allow an account owner to approve moving a fixed amount of tokens from their account to another account. approve allows you to authorize an address to move a fixed amount, while allowance simply returns this amount.
Looking at the EIP and ERC20 documentation can be a bit daunting at once, but one you start playing with the functions it makes a lot more sense. For quickest way to start testing I'd suggest using Ethereum's remix.
If you think the documentation on that wiki is not enough, you can look at the original EIP and look at all of the discussions involved that led to the final version, along with links to additional documentation and code examples to further explain the intention of each function. Note that all of the ERCs have a corresponding EIP, so you can refer to those for all of the other token standards.
what are upsides of tokens being ERC20 compliant?
The upside is that others will know how to work with your token.
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.