I'm looking for an example of a raw json/body of a contract interaction before it is signed and passed to web3py / web3js / ethers
We are using AWS KMS for our wallet setup. There are some automated actions that this wallet is supposed to take. The problem I am facing is that in order to create a signature, the action has to be passed to KMS in a raw format.
I have found tutorials and samples describing the process to transfer a native token (ethereum itself) from the KMS wallet to a recipient, the process described is to create a raw dict containing all the required info, sign it with a given KMS method and then post it as a raw transaction.
For example a simple transaction raw dict should look like this (post EIP-1559)
{
'nonce': nonce,
'to': 0x0131c121,
'value': 1000000000000,
'data': '0x00',
'gas': 160000,
'maxFeePerGas': max_fee_per_gas,
'maxPriorityFeePerGas': max_priority_fee_per_gas,
'type': type,
'chainId': chainid,
}
What we are trying to do, however, is to interact with various contracts that require some changes based on user actions. The way that I believe should work is to figure out what the dictionary body components look like for a given contract interaction. It would be great if someone could point me into the right direction or explain what the raw json/body of a contract interaction looks like
Actually a lot simpler than I thought.
{
'nonce': nonce,
'to': 0x0131c121,
'value': 1000000000000,
'data': '0x00',
'gas': 160000,
'maxFeePerGas': max_fee_per_gas,
'maxPriorityFeePerGas': max_priority_fee_per_gas,
'type': type,
'chainId': chainid,
'data': 0x38ed1739000000000000000000000000000000000000000000000000000000009502f900000000000000000000000000000000000000000000a07e38bf71936cbe39594100000000000000000000000000000000000000000000000000000000000000a00000000000000000000000003c02cebb49f6e8f1fc96158099ffa064bbfee38b00000000000000000000000000000000000000000000000000000000616e11230000000000000000000000000000000000000000000000000000000000000003000000000000000000000000a0b86991c6218b36c1d19d4a2e9eb0ce3606eb48000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2000000000000000000000000528b3e98c63ce21c6f680b713918e0f89dfae555
}
The data field is what describes the interaction with a given recipient address (which is the contract) and works as described in the following specs
https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding
Long story short,
I just used the buildTransaction function on web3py to build a raw transaction with the given abi as such
tx = usdc.functions.transfer(recipient_address, amount).buildTransaction({'from': signing_address})
where usdc is an instance of the contract.
Related
I want to make new coin in solidity.
I found the code how to make subsidy halving in Bitcoin clone coding.
Can I make subsidy halving in solidity?(ERC-20, 721, 1155 whatever)
I can't find any subsidy halving in ERC coin.
Sorry for my poor English.
I want to assume that you mean: "Bitcoin Halving." Given that is the case, in Solidity, what is available is: "Token burning".
To ensure that you understand: Bitcoin Halving is an event that occurs where the block reward given to Bitcoin miners for processing transactions is cut in half.
Token Burning in Ethereum is a way of removing tokens from circulation by sending the tokens to a "dead address" this renders the token "unspendable." This is often done to reduce the amount of the said token in circulation. This ultimately affects the token liquidity.
The simple function below illustrates Polygon MATIC token burning:
function _burn(address account, uint256 value) internal {
require(account != address(0));
_totalSupply = _totalSupply.sub(value);
_balances[account] = _balances[account].sub(value);
emit Transfer(account, address(0), value);
}
The above function is part of the functions deployed when initializing a token contract in solidity. With this function as part of the deployed contract code, you can burn any token type: ERC20, ERC721 ...
You will find this resource useful to understand more: https://academy.binance.com/en/articles/what-is-a-coin-burn
Glad to see blockchain development support on Stack Overflow as resources as very scarce nowadays.
I'm a new kid trying to learn this ecosystem.
How can I add an image logo to a token that I've already created and deployed on remix.ethereum.org?
Should I have done this before deploying it?
Newbie question: Once deployed the same code can never modified?
I'm currently interacting with the token on BSC - seems that all BSC tokens are created as a fork of Solidity and the ETH ERC20 paradigm. (?)
This is my code
pragma solidity ^0.8.0;
import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol";
contract Foobar is ERC20 {
constructor(uint256 initialSupply) public ERC20("Foobar", "FOO") {
_mint(msg.sender, initialSupply);
}
}
Short answer: No, once you deploy a contract to the mainnet, you can't modify nor delete it, it'll be in the blockchain forever (unless you're using a testnet or a private blockchain network to test the contract).
Long answer:
Once a contract is deployed, it can never be modified nor deleted, the only thing you can modify is it's storage (variables that the contract uses) by calling it's defined functions, but you can't modify the logic behind it. If you messed up, you'll need to fix your contract, and re-deploy.
Take in mind that heavy tests and thoughtful inspections are advised before you deploy a contract to the mainnet and set an app into production (and even more if you'r contract will handle sensitive values), mainly because even if you screw up and re-deploy, if you had said contract work in production, its extremly difficult to fix.
For example: You make you'r own tiny bank, the contract recives eth, and it stores it a variable a mapping of addresses with a variable that keeps a count of how much eth from the total eth that the contract is holding is for each user.
contract Bank {
// mapping of address with current money value.
mapping (address user => uint money) balance;
constructor(){}
function withdraw(uint memory money) public {
// Require money parameter is not empty.
require(money != 0, "Can't withdraw 0 eth");
// Big issue here, if we send the money, and then update the balance,
// the user will be able to withdraw money even if hi's balance turns
// to 0 if he spams the withdraw function before he runs out of money.
// The good way would be the other way around, first update balance, and then send.
// Check if the user has enough money.
if (balance[msg.sender].money >= money) {
// Send money
address(msg.sender).transfer(money);
// Update balance.
balance[msg.sender].money -= money;
}
}
...
}
Now this has a critical issue, if someone withdraws money twice very fast, it skips a check iteration that checks if the user has enough money in it's balance to withdraw.
Now to fix this, you'll need to quickly withdraw all the money that the contract has and it's mapping(address user => uint money) ... mapping data, fix and re-deploy the contract, manually send all the money to the new contract, and also set the previous data that it had, and if that wasn't enough you'll need to change you'r front-end app to connect with the new contract.
I know its a long example, but when you start coding contracts from 0, you have to understand that testing and revising the contract is a must.
Once a contract is deployed, it cannot be modified nor deleted, it's there forever, alteast in the mainned, that's why you use private blockchains such as Ganache, or use a public testnet (Ropsten, Kovan, Rinkeby, Goerli).
Also about the logo, most tokens don't have their "logo" in their contract ( unless you're making a NFT [ ERC721 ] ), yet, if you still want to add a logo that anyone can access from your contract, i'd suggest to make a state variable that holds its value (string mainly).
The value can be a IPFS hash (IPFS is a decentralized file system that allows you to upload files of any kind, it will return a hash once it's uploaded, and you can access you'r file via https://HASHTOKEN.ipfs.infura-ipfs.io/, for example:
https://bafybeibctnxu7zpatp3caj2gevofs2oirdvdyo6yulxk2hfyaewxib3pj4.ipfs.infura-ipfs.io/
soo in you'r case, you can upload the logo there, grab the hash, and store it in you'r contract, then in your frontend app you'll only need to add the hash to the url.
A second way of adding you'r logo would be to turn you'r image into base64 and paste the whole thing into you'r contract, that way you have literally the image in the contract, yet, i don't recommend this last solution since base64 strings can get very large depending on how heavy is the file, and the heavier you'r contract is, the more gas it will use when you deploy it, and more expensive for the users when they try to use it.
Yet, if what you mean is to add a logo on sites such as BscScan, you can find a guide here.
When we call a solidity function via web3js, how does the code flows along with data formats during all the process?
For example, if I call a solidity function through web3js, how does it get executed. Can anyone explain the complete flow?
First of all, I recommend taking the time to read How does Ethereum work, anyway?
But for now, a short explanation
When you call a method on a contract through web3.js, the library
will encode your method call as data attribute on the transaction.
Here's a good explanation about ethereum transactions and data
attribute
The ethereum node your web3.js is connected to will receive your transactions and do some basic checks of nonce and balance
Once the basic checks pass, the node will broadcast the transaction to the rest of the network
When a network node receives a transaction with data attribute, it will execute the transaction using the Ethereum EVM. The outcome
of the transaction is modified state of the contract storage. More
about contract storage
The expectation is that the transaction will produce the same state change on every single node in the network. This is how
consensus is reached and the transaction (and the contract state
change) become part of the canonical chain (mined and not belonging
to an uncle block)
Using JSON HTTP POST; what online service do I best use to broadcast a Bitcoin Cash transaction?
I'm looking for the equivalent of https://blockchain.info/pushtx
There are a few options to broadcast a transaction for Bitcoin and Bitcoin-Cash. The first, but also the most expensive in terms of time, is to setup a BitcoinABC node on your machine and let it sync. Once that's done you can simply call the sendrawtransaction API call and it'll get pushed to other nodes in the network.
The second option is to use Wladimir's bitcoin-submittx tool to connect to a number of nodes and submit the transaction to them. This tool was originally written for Bitcoin, but works also for Bitcoin-Cash. It requires a number of node addresses, but you can use the DNS seeds to get some:
python2 bitcoin-submittx mainnet ${TXHEX} $(dig seed-abc.bitcoinforks.org)
This should submit the TX to some random nodes in the network.
https://rest.bitcoin.com provides a REST API for broadcasting transactions. This BITBOX code example shows how to construct a BCH transaction then broadcast it using rest.bitcoin.com:
https://github.com/Bitcoin-com/bitbox-javascript-sdk/blob/master/examples/applications/wallet/send-bch/send-bch.js
In particular, look at the last few lines of the example:
// Broadcast transation to the network
const broadcast = await BITBOX.RawTransactions.sendRawTransaction(hex)
console.log(`Transaction ID: ${broadcast}`)
API documentation:
https://developer.bitcoin.com/bitbox/docs/getting-started
If you already have the raw hex and you want a manual way to broadcast it, you can go directly to the endpoint on rest.bitcoin.com, and paste in the hex:
https://rest.bitcoin.com/#/rawtransactions/sendRawTransaction
An address in Solidity can be an account or a contract (or other things, such as a transaction). When I have a variable x, holding an address, how can I test if it is a contract or not?
(Yes, I've read the chapter on types in the doc)
Yes you can, by using some EVM assembly code to get the address' code size:
function isContract(address addr) returns (bool) {
uint size;
assembly { size := extcodesize(addr) }
return size > 0;
}
The top-voted answer with the isContract function that uses EXTCODESIZE was discovered to be hackable.
The function will return false if it is invoked from a contract's constructor (because the contract has not been deployed yet).
The code should be used very carefully, if at all, to avoid security hacks such as:
https://www.reddit.com/r/ethereum/comments/916xni/how_to_pwn_fomo3d_a_beginners_guide (archive)
To repeat:
Do not use the EXTCODESIZE check to prevent smart contracts from calling a function. This is not foolproof, it can be subverted by a constructor call, due to the fact that while the constructor is running, EXTCODESIZE for that address returns 0.
See sample code for a contract that tricks EXTCODESIZE to return 0.
Checking if a caller is a contract
If you want to make sure that an EOA is calling your contract, a simple way is require(msg.sender == tx.origin). However, preventing a contract is an anti-pattern with security and interoperability considerations.
require(msg.sender == tx.origin) will need revisiting when account abstraction is implemented.
Checking if a callee is a contract
As #Luke points out in a comment, there is no general on-chain way to find out about a callee. If you want to "call" an address, there's no general way to find out if that address is a contract, EOA, or an address that a new contract can be deployed on, or if it's a CREATE2 address.
One non-general way that works for some callees: you can have a mapping on-chain that stores addresses of known EOAs or contracts. (Just remember that for an address without any on-chain history, you can't know if it's an EOA or an address that a contract can be deployed on.)
This isn't something you can query from within a contract using Solidity, but if you were just wanting to know whether an address holds contract code or not, you can check using your geth console or similar with eg:
> eth.getCode("0xbfb2e296d9cf3e593e79981235aed29ab9984c0f")
with the hex string (here 0xbfb2e296d9cf3e593e79981235aed29ab9984c0f) as the address you wish to query. This will return the bytecode stored at that address.
You can also use a blockchain scanner to find the source code of the contract at that address, for example the ecsol library as shown on etherscan.io.
Edit: Solidity has changed since this answer was first written, #manuel-aráoz has the correct answer.
There is no way in solidity to check if an address is a contract. One of the goals of Ethereum is for humans and smart contracts to both be treated equally. This leads into a future where smart contracts interact seamlessly with humans and other contracts. It might change in the future , but for now an arbitrary address is ambiguous.
If you want to use nodejs to confirm, you can do this:
const Web3 = require('web3')
// make sure you are running geth locally
const web3 = new Web3(new Web3.providers.HttpProvider('http://localhost:8545'))
is_contract = async function(address) {
res = await web3.eth.getCode(address)
return res.length > 5
}
is_contract('your address').then(console.log)
From openzeppeling Address.sol library, it has this function:
pragma solidity ^0.8.1;
function isContract(address account) internal view returns (bool) {
// This method relies on extcodesize/address.code.length, which returns 0
// for contracts in construction, since the code is only stored at the end
// of the constructor execution.
return account.code.length > 0;
}
isContract will return false for the following types of addresses:
an externally-owned account
a contract in construction
an address where a contract will be created
an address where a contract lived, but was destroyed
What you can do, granted you have the information at hand.
If the transactions sender address was null or unoccupied then you can tell if the address is a contract account or an EOA (externally owned account).
i.e. when sending a create contract transaction on the network then the receive address in the transaction is null/not used.
Reference from github:
https://github.com/ethereum/go-ethereum/wiki/Contracts-and-Transactions
Hope this helps.
If you are checking whether the caller is an EOA rather than a contract:
Short answer:
require(tx.origin == msg.sender);
tx.origin is a reference of the original address who initiates this serial function call, while msg.sender is the address who directly calls the target function. Which means, tx.origin must be a human, msg.sender can be a contract or human. Thus, if someone calls you from a contract, then the msg.sender is a contract address which is different from tx.origin.
I know most contracts may use #Manuel Aráoz's code, which works in most cases. But if you call a function within the constructor of a contract, extcodesize will return 0 which fails the isContract check.
NOTE: DON'T use tx.origin under other circumstances if you are not clear about what it represents because .