For NFT minting - Standard says to emit transfer event with value of from as zero address. But i was wondering a dedicated event let's say mint sound more better and clear.
event Mint(address to, string tokenId)
Also it gives us advantage of one more variable to be indexed in event as max three value can be indexed.
Can anyone please clear this ? What is best way?
Pasted from a comment below my other answer answering a question
why not to use dedicated mint event ?
I can't speak for the authors and reviewers of the ERC-721 standard, why they chose this specific way. But from my understanding, it was already a common practice to emit Transfer event log with zero sender address when minting ERC-20 tokens, when they were creating the 721 standard. So one of the reasons might have been reusability of code for offchain apps such as blockchain explorers, to be able to handle token minting in a more generalized way.
To add context to your more specific question about the advantage of being able to pass more values:
Apart from Transfer, you can also emit other event logs, including this arbitrary Mint as well, when you're minting new tokens.
Since this Mint event is not standardized, it will not be recognized by most offchain apps (such as Etherscan) as token mint. They will only show it on the transaction detail page as "some event named Mint that we don't recognize", but their internal aggregated database of "who owns which tokens" and "these tokens were minted during this transaction" will still reflect only the values passed to the Transfer event.
However, you'll be able to handle this arbitrary event from your own offchain apps.
Related
I am new to blockchain, please help me understand.
How the smart contract's state variables are stored on the blockchain if a smart contract is immutable (because it was deployed as a transaction = byte-code is stored in a transaction)?
Ok, maybe every new state of a state variable is stored with a new method-update call (set) in the transaction, but how then does the smart contract know how to address them if it was created earlier?
And here I found a mention of a state storage on every EVM. "Technically you don’t need to store this on disk, you could just play back all transactions when you boot up the node" - again, how it is possible to play back all transactions related to a contract, how are they connected to a contract?
Immutability applies only to data placed directly in the blockchain, that is, to transaction data. In Ethereum, the values of smart contract variables are determined specifically by each node when processing a transaction on its EVM instance.
As for, for example, Hyperledger Fabric, the final results of calculations are also transmitted along with the transaction, and the node simply records them in its state database. But at the same time, he himself determines whether to accept or not to accept this transaction.
i have the code in solidity, i'm wondering something: I deploy code for the 0x583... first, i send 1 eth to another account. Before i click withdrawAllMoney, i click destroySmartContract, 1 eth 's automatically send to receiver (this is okie!). But after that, i keep going send the 1 eth from 0x583.. to another account, it still take out eth from 0x583.. but the orther can't receive it.
I'm wondering: when i call the selfdistruct, is the contract real deleted (can't send or recieved...)
Thank you!
when i call the selfdistruct, is the contract real deleted (can't send or recieved...)
selfdestruct() effectively removes the deployed bytecode from the contract address.
In the next block, this (former contract) address will act as a regular address without a smart contract, so it is able to receive tokens and ETH.
But, since it doesn't hold any bytecode anymore, you won't be able to interact with the contract (it's not there anymore).
In deflationary smart contract, How will the developer stop burning of the token in future prior to running out of token. I believe smart contract cannot be changed after deployment. Please I need enlightening regarding it.
Depends on which specific smart contract you're referring to.
Most deflationary smart contracts implement the burning into specific user-actions such as performing transactions since there's no such thing as CronJobs on blockchains.
If you burn a percentage of a transaction, you will never "run out of tokens", so there's no need to "stop" the burning.
I believe smart contract cannot be changed after deployment. Please I need enlightening regarding it.
This also depends on the specific implementation. A smart contract could have a function that lets the deployer stop or change the amount of burning (which wouldn't be decentralized at all).
Say I want to make it so certain wallets can never, ever receive my token, or maybe so that interactions with a specific, known malicious contract, or broken functions on an otherwise working contract on chain always revert. How do I go about doing this?
In my specific case, I would like to make it so that for a period after deployment, but before a hardcoded unix timestamp, people can add or remove liquidity to a uniswap pool, but no swaps can occur, so that the price stays constant while everyone adds liquidity, until the timestamp passes and swaps are then able to occur, and so that they can all safely remove their liquidity from the pool if something goes wrong before the timestamp passes with no impermanent loss.
For the "blacklist" functionality, you could maintain a mapping containing the blacklisted accounts. Then whenever a transfer of your token occurs, you can require that the address not be in the blacklist, otherwise the transfer reverts. You could also add a function to "un-blacklist" an account, if you so wished.
As for the second point - i'm curious as to how you're defining the 'price' of your token if no swaps can occur, and what incentivises anyone to add liquidity under that arrangement?
I am developing a blockchain for IoT applications, where there are a number of gateways (miners) spread throughout the city and several nodes (sensors) connected to each of them. Each gateway can be added by an end user so this is a untrusted environment. How can I make sure that there isn't fake data being sent to the chain by one of the miners?
I have looked up some consensus protocols by find that none fit this specific problem since there is no value being exchanged.
Every miners sends a ping to a master server and receives from it the list of miners on the network. Then they connect to each other by p2p.
Any ideas of how could I solve this?
Blockchain can be used in both cases permission-less or permissionned, if you want to prevent that anyone can broadcast data, then you have to authenticate the nodes before they can join the network. If even after authenticating the nodes there is a chance that an authenticated node send "fake data" then a trust mechanism must be implemented, nodes verify the trustworthiness of the data's source and decide if the node is trusted and accept the data or not.
In order to prevent spamming or fake data being posted, it has to be added as a consensus rule to the protocol. Otherwise, it requires another layer that validates data based on off-chain data (but doesn't prevent data from being stored in blocks). Blockchain is for achieving distributed consensus, in a permission-less system. Restricting who can participate is not a permission-less system, and would be a centralized system because someone has to determine who is allowed to participate.
The answer to the query lies in Blockchain Oracles.
Oracles to-date are centralized services, meaning any smart contract using such services has a single point of failure, which nullifies any benefits gained from the decentralized nature of smart contracts.
To fill this gap, Chainlink was developed as the first decentralized oracle that can provide external data to smart contracts. As a result, the security and determinism of smart contracts can be combined with the knowledge and breadth of real-world external events. Chainlink will provide a smart contract with access to any external API needed.
As according to chainlink here and here
Blockchains and smart contracts cannot access data from outside of
their network. In order to know what to do, a smart contract often
needs access to information from the outside world that is relevant to
the contractual agreement, in the form of electronic data, also
referred to as oracles. These oracles are services that send and
verify real world occurrences and submit this information to smart
contracts, triggering state changes on the blockchain.