Where exactly the contract code get stored, i read that it kind of
stores in block chain, so does that mean every node that has a
instance of a full block chain has the contract code too??
The state gets stored in the blockchain, yes. You are also correct in saying that every full-node has a copy of the entire blockchain, including all the states.
Should a miner in order to mine a new block first run all the contract
calls and set the values and then start too looking for POW puzzle
solving and nonce value, and if so then can we have ASIC miners for
ethereum like bitcoin, because they can do only a specific job but
running a contract codes are different every time??
The miners job is to simply solve the POW puzzle. When they do that, they have the ability to mine the block. They now choose which transactions they want included in that specific block. These transactions define all the state changes that were made, so the miner technically doesn't have to look into that.
In terms of the ASIC question, Ethereum POW was designed to be memory-hard, meaning that it is difficult for ASICs to mine.
When a miner wants to verify a transaction which has a contract call
should it run the contract code?? if so, does it mean that each
contract gets to run multiple time until finally one miner can find
the right nonce and solve the pow puzzle? if thats true it means the
contract code gets to run many times unnecessarily?
See my answer above as the answer to this question as well. To summarize, the miner simply chooses a transaction. The reason it doesn't get run multiple times is because there is only one miner that finds the block first and gets rewarded for it. This is the only miner that broadcasts the transaction, as well as the contract calls, to the Ethereum network.
Where does the values of contract variables store, i mean if we have a
solidity mapping it can contains lots of key values, so where does
this key, values stores?? if they store in block chain then they
should be stored in every node that has a copy of block chain which
means a massive data gets to store over and over and over again, and
that would be such a storage waste
See answer one. You are correct—blockchains (as they stand) are quite inefficient and slow, and each node does hold a copy of this state.
When a contract Self-destructs what exactly happens, it mentioned that
the code will be removed from block chain, so does it mean a
transaction make it unavailable for following transactions or it
really really alter the block chain and remove it coded from older
blocks??
It does not alter the blockchain, as that is impossible. What it does do (without getting too technical) is disallows anybody from calling that contract again. The best example to look at is the Parity wallet exploit, as it is a critical example of the usage of selfdestruct.
As Ismael points to in the comments, it would seem that the author of the linked comment in the OP's question was not pointing to SuperRare being on-chain and Foundation off-chain, but was emphasizing that the value of SuperRare as a curator. The "on-chain" provenance comment likely means that being able to point to an NFTs on-chain history means it can be traced back to where it was purchased from on-chain, and having been in SuperRare is part of what one is purchasing when they purchase such an NFT (in the thread author's opinion.)
There's something we should really unpack here as an additional note on the question: NFTs, according to the ERC-721 (and 1155) standard that they are based on, do not (generally) "include" a JPEG or other image. There is generally a field in the NFT that contains some kind of pointer (if you look at the standard, this is the extension called the Metadata extension) traditionally a URL or IPFS (or similar) hash, to a JSON. The JSON, in turn, links to the media. This is very significant, as it means in many cases that the media can become either unlinked (in the case of the JSON pointing to a centralized IPFS gateway, for example) or even actively changed (in the case of it pointing to someone's traditional web site, for example). That's a bit tangential, but very useful in terms of understanding NFTs.
Best Answer
In most cases, a failed transaction to a contract address means that some modifier or require(...) did not hold, and therefore the whole transaction was reverted.
If you look closely, the ethers were actually not taken, as it says [CANCELLED].
Actually, by looking at the empty data field of that transaction, I assume this address was calling the default callback function of the contract or that maybe you did not properly called the desired function of the contract, but instead the contract itself, and therefore it failed WITHOUT CHARGING THE SENT ETHERS.
Hope this helped. Try to be more specific if it did not.