Nice solution, and a very well coded contract @ekr990011
… apologies for the delayed response!
Your transfer event and corresponding emit statement are both correct and well coded. The emit statement is in the correct position in the transfer() function body and will log appropriate data when the transfer() function is successfully executed.
Regarding your question about whether or not to index specific event parameters, we need to be clear that this specifically relates to the extent to which the frontend, using a library such as web3.js, is able to filter historic event data when searching for specific events. What it doesn’t relate to is our ability to look up standard transaction data using a block explorer.
Every ethereum transaction will contain data such as the transaction hash, transaction status, calling address (msg.sender), address of the smart contract interacted with, input values (arguments) and return values, any Ether value sent, and the gas/transaction fee (amongst other things). You are right that we can look up this data on a block explorer, either for specific transactions using the transaction hash, or for transactions associated with a specific ethereum address. However, events allow specific sets of data to be defined and logged for specific transactions, and are also able to capture values which would not otherwise be included in the standard transaction data, such as a value calculated within the function body and not returned.
Marking event parameters as indexed
allows their names to be used as search parameters to filter logged event data. However, each event parameter that is indexed (up to a maximum of 3 per event declaration) increases the gas cost, so they should only be indexed when this is actually necessary. Therefore, deciding whether or not to index event parameters will depend on whether we will need to retrieve historical event data and, if so, whether we require the returned dataset to have been filtered according to specific event parameters other than the event name.
For example …
event balanceAdded(uint amount, address indexed depositedTo);
- If we need to retrieve the historical event data just for the deposits made by a specific address, then we need to index the address parameter corresponding to the depositor’s address.
- If we don’t need to retrieve the historical event data just for deposits of a specific amount, then indexing the
amount
parameter won’t be necessary. - If we need to retrieve the historical event data just for the deposits of a specific amount made by a specific address, then we need to index both of these parameters.
The following question-and-answer thread illustrates this nicely …
https://ethereum.stackexchange.com/q/50501
And here’s a link to a helpful discussion about indexing, which I think explains quite well how this works in practice: https://ethereum.stackexchange.com/q/8658
So, by this I mean the convention is to start the event name with a capital letter, not the event
keyword itself e.g. event BalanceAdded( )
It’s not wrong to start the event name with a lower case letter (as you have, and as shown in the video); but to avoid confusion we should then be consistent about this across all our events (as you have also been with both of your events).
Example = New Event(uint number, address from);
Yes … but this is incorrect because an event declaration (i) starts with the event
keyword, (ii) has no assignment operator (=
), and (iii) has no new
keyword (which starts with a lower case letter, anyway).
Let me know if anything is still unclear, or if you have any further questions