How is uniswap assembly create2 function working? - solidity

I was going through uniswap code trying to understand the code and most of it is pretty clear but I do have a few questions.
in this function:
function createPair(address tokenA, address tokenB) external returns (address pair) {
require(tokenA != tokenB, 'UniswapV2: IDENTICAL_ADDRESSES');
(address token0, address token1) = tokenA < tokenB ? (tokenA, tokenB) : (tokenB, tokenA);
require(token0 != address(0), 'UniswapV2: ZERO_ADDRESS');
require(getPair[token0][token1] == address(0), 'UniswapV2: PAIR_EXISTS'); // single check is sufficient
bytes memory bytecode = type(UniswapV2Pair).creationCode;
bytes32 salt = keccak256(abi.encodePacked(token0, token1));
assembly {
pair := create2(0, add(bytecode, 32), mload(bytecode), salt)
}
IUniswapV2Pair(pair).initialize(token0, token1);
getPair[token0][token1] = pair;
getPair[token1][token0] = pair; // populate mapping in the reverse direction
allPairs.push(pair);
emit PairCreated(token0, token1, pair, allPairs.length);
There is the assembly line. According to solidity docs this deploys a new contract but I don't understand how it works where it gets the code from and so on.
So is it possible to "translate" this into solidity somehow? Thanks a lot!

It makes use of the create2 opcode allowing you to deploy a contract to an address determinable by its bytecode and salt.
Uniswap V2 was written in Solidity 0.5 that didn't have a way to produce the create2 opcode directly from the language. So you had to use a low-lewel assemly to actually use this opcode.
The current version 0.8 allows passing the salt param producing the create2 (instead of the regular create) opcode.
pragma solidity ^0.8;
contract UniswapV2Pair {
}
contract MyContract {
function createPair() external {
bytes32 salt = 0x1234567890123456789012345678901234567890123456789012345678901234;
address pair = address(
new UniswapV2Pair{salt: salt}()
);
}
}
Uniswap uses a combination of the pair token addresses as the salt, and the bytecode is always the same. Which effectively allows to deploy just one contract for each unique pair combination.
Example:
Tokens 0x123 and 0x456 would always result in UniswapV2Pair contract address 0xabc.
But once you change the salt, it changes the deployed contract address. So tokens 0x123 and 0x789 would always result in UniswapV2Pair contract address 0xdef.

Related

How can I get metadata and my image to show up on OpenSea Testnet?

I followed along with Remix's beginner NFT course and successfully deployed a few NFTs using the Goerli testnet and their provided IPFS data. I uploaded my own image and metadata and can see it on IPFS but neither the metadata nor the image is populating on OpenSea.
Here is the code for the contract I am deploying:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.2;
import "#openzeppelin/contracts#4.4.0/token/ERC721/ERC721.sol";
import "#openzeppelin/contracts#4.4.0/access/Ownable.sol";
contract Donation is ERC721, Ownable {
constructor() ERC721("Donation", "DONO") {}
function _baseURI() internal pure override returns (string memory) {
return "https://ipfs.io/ipfs/QmXZKcU9WDZxvXvxoAL4YdZVR5Ssj97ayEYRPqYBHrRSb2";
}
function safeMint(address to, uint256 tokenId) public onlyOwner {
_safeMint(to, tokenId);
}
}
Please see the URL that I return for my metadata and subsequent link to my image. Is there anything you see that is immediately wrong that would indicate why nothing is populating (in the JSON file, code, or otherwise)?
For ERC721, the _baseURI will essentially be the base to be combined with the NFT's token id, so for example NFT with token ID 0 will have the tokenURI of:
https://ipfs.io/ipfs/QmXZKcU9WDZxvXvxoAL4YdZVR5Ssj97ayEYRPqYBHrRSb2/0
which in this case after checking is invalid as https://ipfs.io/ipfs/QmXZKcU9WDZxvXvxoAL4YdZVR5Ssj97ayEYRPqYBHrRSb2 should be the valid tokenURI itself. OpenZeppelin designed the ERC721 contract this way as it is the most gas-efficient way to create a standard ERC721 NFT. However, the drawback is that it made it difficult to provide modified URI for each token ID.
If you like to set tokenURI with different base for different token ID, then you should instead check ERC721URIStorage in the contract wizard. This way, the ERC721 NFT contract will have the _setTokenURI(tokenId, uri) function, which allows you to modify the tokenURI for different token ID. However, keep in mind that this will be very expensive on the user side as string inputs cost a lot in EVMs.
Hope this helps~

Tron Wallet address declaration format in Solidity

I'm trying to build a simple contract that just forwards any incoming transferred amount to a set wallet address. I managed to get this contract to work using the Remix IDE with ethereum addresses but I cannot port it to Tron now. In the TronIDE I cannot compile the line declaring the wallet address.
Here is the contract code I am using. Can anyone shed some light on what format the tron wallet address needs to be in. I tried converting it to hex (transferTo variable) and it didn't work, I tried using the base58 address and it didn't work.
Aparently it does compile fine in the TronIDE compiler with the ethereum address though, I even managed to deploy it to Shasta without any issues (except for it to forward the actual transferred amounts of course).
// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.7.0 <0.9.0;
contract PaymentForwarder {
address constant transferTo = 414dbc78301522ae1529d01f4093ae3daad3f26827; // this throws a ParseError: Identifier-start is not allowed at end of a number.
address constant transferToAlternative = TH4EovGaTrmWxhJSmeMVKy5ZpnDGE3DgJ8; // this thows a DeclarationError: Undeclared identifier.
address constant workingDeclaration = 0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2; // this works fine in the tron solidity compiler even though it's an ethereum address
event TransferReceived(address _from, uint _amount);
constructor() {
}
receive() payable external {
address payable paya = payable(transferTo);
paya.transfer(msg.value);
emit TransferReceived(msg.sender, msg.value);
}
}
Can anyone shed some light on why this is and what format does the wallet address need to be in?
Thank you
If you already have the hexstring like transferTo (from quick glance), then you can simply add the hexstring with 0x in the beginning, and convert it to EVM address with the following function.
/**
* #dev convert uint256 (HexString add 0x at beginning) tron address to solidity address type
* #param tronAddress uint256 tronAddress, begin with 0x, followed by HexString
* #return Solidity address type
*/
function convertFromTronInt(uint256 tronAddress) public view returns(address){
return address(tronAddress);
}
On the other hand, transferToAlternative is still in its original TRON address form, then you'll need to use tronweb TRON's official library and convert the address to its hexstring form with the following function:
tronWeb.address.toHex("TH4EovGaTrmWxhJSmeMVKy5ZpnDGE3DgJ8")
Then simply, continue to the step above to convert it fully to EVM address.
Hope this helps!
Source:
Contract Address Using in Solidity Language: https://developers.tron.network/v4.4.0/docs/contract-address-using-in-solidity-language
Tronweb address Reference: https://developers.tron.network/reference/address
Cheers~

create2 not working in tron, gives empty bytecode

So, I've a contract which deploys using create2 i.e., custom salt. Its working perfectly in Ethereum but with Tron it's not. When its called, the result of the contract ( which is created by create2 ) is empty. The contract ABI and Bytecode both shows null. I dont know why its happening. Am I missing something?
Here is the part of the code of my contract
function deploy(address _owner, uint256 _salt) public returns (address addr) {
bytes memory bytecode = getBytecode(_owner);
assembly {
addr := create2(
0,
add(bytecode, 0x20),
mload(bytecode),
_salt
)
if iszero(extcodesize(addr)) {
revert(0, 0)
}
}
emit Deployed(addr, _salt);
}
function getBytecode(address _owner) public pure returns (bytes memory) {
bytes memory bytecode = type(Forwarder).creationCode;
return abi.encodePacked(bytecode, abi.encode(_owner));
}
Forwarder is my Contract
This is one of my contract which is deployed by create2
If anyone need anymore info, Let me know.
I wanna solve this.
So, we cannot get ABI and bytecode of a contract deployed using create2 said by tron support team.
and they provided a solution i.e.,
let instance = await tronWeb.contract().at("TREwN2qRkME9TyQUz8dG6HfjEyKGMPHAS5");
instance.loadAbi([{"constant":true,"inputs":[],"name":"name","outputs":[{"name":"","type":"string"}],"payable":false,"stateMutability":"view","type":"function"}]);
let res = await instance.totalSupply().call({_isConstant:true})
so we can get the instance from contract address and load the ABI
and then we can call the contract function and perform operation.

Burning Deployed ERC Tokens In an NFT Mint Function - Compiles, but Transaction Fails

I am very new to Solidity, and have recently been working on trying to learn the ropes. For reference, I have been using code from this video (https://www.youtube.com/watch?v=tBMk1iZa85Y) as a primer after having gone through the basic crypto zombies tutorial series.
I have been attempting to adapt the Solidity contract code presented in this video (which I had functioning just fine!) to require a Burn of a specified amount of an ERC-20 token before minting an NFT as an exercise for myself. I thought I had what should be a valid implementation which compiled in Remix, and then deployed to Rinkeby. I call the allowAccess function in Remix after deploying to Rinkeby, and that succeeds. But, when I call the mint function with the two parameters, I get: "gas estimation errored with the following message (see below). The transaction execution will likely fail. Do you want to force sending? execution reverted."
If I still send the transaction, metamask yields "Transaction xx failed! Transaction encountered an error.".
I'm positive it has to do with "require(paymentToken.transfer(burnwallet, amounttopay),"transfer Failed");", though I'm not sure what's wrong. Below is my entire contract code. I'm currently just interacting with the Chainlink contract on Rinkeby as my example, since they have a convenient token faucet.
pragma solidity ^0.8.0;
import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol";
import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/IERC20.sol";
import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/access/Ownable.sol";
import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/Counters.sol";
contract myNFTwithBurn is ERC721, Ownable {
address externalTokenAddress = 0x01BE23585060835E02B77ef475b0Cc51aA1e0709; //Token Type to burn on minting
uint256 amounttopay = 5; //number of these tokens to burn
IERC20 paymentToken = IERC20(externalTokenAddress); //my code: create an interface of the external token
address burnwallet = 0x000000000000000000000000000000000000dEaD; //burn wallet
using Counters for Counters.Counter;
Counters.Counter private _tokenIds;
using Strings for uint256;
// Optional mapping for token URIs
mapping (uint256 => string) private _tokenURIs;
// Base URI
string private _baseURIextended;
constructor() ERC721("NFTsWithBurn","NWB") {
}
function setBaseURI(string memory baseURI_) external onlyOwner() {
_baseURIextended = baseURI_;
}
function _setTokenURI(uint256 tokenId, string memory _tokenURI) internal virtual {
require(_exists(tokenId), "ERC721Metadata: URI set of nonexistent token");
_tokenURIs[tokenId] = _tokenURI;
}
function _baseURI() internal view virtual override returns (string memory) {
return _baseURIextended;
}
function tokenURI(uint256 tokenId) public view virtual override returns (string memory) {
require(_exists(tokenId), "ERC721Metadata: URI query for nonexistent token");
string memory _tokenURI = _tokenURIs[tokenId];
string memory base = _baseURI();
// If there is no base URI, return the token URI.
if (bytes(base).length == 0) {
return _tokenURI;
}
// If both are set, concatenate the baseURI and tokenURI (via abi.encodePacked).
if (bytes(_tokenURI).length > 0) {
return string(abi.encodePacked(base, _tokenURI));
}
// If there is a baseURI but no tokenURI, concatenate the tokenID to the baseURI.
return string(abi.encodePacked(base, tokenId.toString()));
}
function allowAccess() public
{
paymentToken.approve(address(this), 5000000); //This is my attempt to allow the contract access to the user's external tokens, in this case Chainlink (paymentToken)
}
function mintItem(address to, string memory tokenURI)
public
onlyOwner
returns (uint256)
{
require(paymentToken.transfer(burnwallet, amounttopay),"transfer Failed"); //Try to transfer 5 chainlink to the burn wallet
_tokenIds.increment();
uint256 id = _tokenIds.current();
_mint(to, id);
_setTokenURI(id, tokenURI);
return id;
}
}
If anybody can at least point me to what I'm doing completely wrong in the code that I've added, please do! TIA!
I'm not sure why are you trying to burn link in order to mint and nft but first check if the link code does not have a require that check if the destination address is the burn address if it has then burn the link is not possible and you should use any other erc20 maybe your own erc20, also your contract probably does not have any link and if you want to transfer the link from the user you should do this in the contract paymentToken.transferFrom(msg.sender,destinationAddress,amount) and if the user previously approve your contract you will able to send the tokens, and i suppose that the purpose of the allowAccess function is to make the user approve the contract to move the tokens that will never work, the approve function let's anyone that call it approve any address to move an amount of tokens, the thing is that to know who is approving to let other to move the tokens the function use msg.sender to explain how this work take a look at this example
let's say that your contract is the contract A and the link contract is the contract B
now a user call allowAccess in the contract A, so here the msg.sender is the user because they call the function
now internally this function call approve on contract B, here the contract A is the msg.sender, because the contract is who call the function
so what allowAccess is really doing is making the contract approving itself to move their own tokens that I assume it doesn't have

safeTransfer with token erc1155 in solidity 0.8

I get this error
ERC1155: transfer to non ERC1155Receiver implementer when try to transfer to a smart contract I found this doc https://docs.openzeppelin.com/contracts/4.x/api/token/erc1155 but still don't know how to fix this do I have to abstract IERC1155Receiver interface in my holder token 1155
The receiving contract needs to implement the onERC1155BatchReceived() function based on the ERC-721 definition.
pragma solidity ^0.8;
contract MyContract {
function onERC721Received(address _operator, address _from, uint256 _tokenId, bytes memory _data) external returns(bytes4) {
// here you can (but don't have to) define your own logic - emit an event, set a storage value, ...
// this is the required return value described in the EIP-721
return bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"));
}
}