Why can't this etherum tx input data be decoded? - ethereum

If you go to this transaction page on etherscan, scroll down to the Input Data section and click the Decode Input Data button- it gives you nothing, which I can only assume means that etherscan was unable to decode the input data given the ABI for that contract.
My question is, why? What is special about that contract/ABI (or really any contract like this one) that would prevent the transaction from being decoded?

The called function signagure is 0xfaa916d3, the rest of the data are arguments. The contract ABI doesn't define any function that would translate to the 0xfaa916d3 signature. Which means that the fallback function was called.
In this case, the fallback function acts as a proxy, creates an internal transaction and delegates the call to the target contract (which can theretically do the same or create multiple other internal transactions, etc.)
However, Etherscan currently only compares the signature to the ABI of the root transaction recipient and ignores the internal transactions recipients' ABIs in the "Decode input data" feature.
Why? My guess is that it's easier to scan just one level, and not that high priority to implement and account for all the edge cases such as multiple internal calls with the same signature. But you'd need to ask them for the real reason. :)

Related

How to detect contract creation timestamp in Ethereum blockchain nodes?

I am trying to detect timestamp in Ethereum node but there are no methods/functions.
How do we find this?
I am getting swap logs and parsing them but couldn't find direct way to detect contract creation date.
Contract creation date is not available using a direct method.
Blockchain explorers usually collect it the following way:
They scan every transaction on every block on the chain
If the transaction receipt contains non-null contractAddress property, it means that this transaction deployed a contract.
Time of the transaction (and effectively time of the contract deployment) is available as part of the block in which the tx was produced
This is quite complicated. There is no method to get the Transaction that deployed the Contract.
First of all, there are multiple ways to deploy a contract:
Via the Deployment Transaction, here you will get the contractAddress in the tx receipt.
Via another contract, with create2/create method. For example in this way Uniswap: Factory Contract creates Pair contracts. And there is no API in RPC to find out this type of deployment. You need a node that can return such "Internal Calls".
There are some workarounds. In your case, do you just need the timestamp? Then you have just to find the block when the contract was deployed.
The archive node.
Use binary search to find the block number, when eth_getCode returns not the empty data, and the previous one is empty.
Get the timestamp of the block.
If you need the transaction:
Use the previous method to find the block
Load transactions and their receipts.
Search for a Deployment Transaction, which has your contractAddress in the receipt.
If not found, almost always the contract emits an Event when creating another contract. So look into the address, data and topics to match your contract address of every log entry.
Not a universal workaround: if you know the Event which gets emitted in the constructor or by the parent's contract, you can search for it with getPastLogs.
You can use the 3rd party API, like https://docs.etherscan.io/api-endpoints/contracts to get the Get Contract Creator and Creation Tx Hash. After that:
Get the blockNumber from transaction fetched by txHash.
Get the timestamp from block fetched by blockNumber.

How to encode input data on etherscan when trigger a non open source smart contract?

I have deployed a smart contract on Ethereum. When I triggered it, function name and params were displayed on etherscan. How can I hidden these infomation?
enter image description here
Etherscan uses a dictionary that translates the function signature to a function name (in your case 0x38ed1739 to swapExactTokensForTokens(uint256,uint256,address[],address,uint256)).
If you don't want them to translate the function name, you'll need to rename your contract functions (it's definition and all places that call them) to some gibberish such as kdjgklfdjiwefw(uint256,uint256,address[],address,uint256).
Be aware that external contracts might want to call your functions by their name that they expect (such as swapExactTokensForTokens) and they will not be able to if a function with this name doesn't exist.
If you want to prohibit Etherscan showing the translations but NOT rename your functions - there's currently no way to do that.

How can one obtain the message from state-reverting exception using ethereum clients, when self did not broadcast transaction?

Suppose an ethereum smart contract has external function "foo" whose logic has state-reverting exception require(1 == 0, 'error: you broke the simulation!');.
If ethereum-client A broadcasts transaction "txA" which is a function call on foo, how can ethereum-client B access the state-reverting message corresponding to "txA"?
edit: by "how can", I mean how can a developer practically enable ethereum-client B to access this data. i.e. Can you please point me in the direction of the correct (lower-level.. not webui) api/rpc call from a particular tool?
Clearly this is possible since block explorers provide such messages for failed transactions. I read through some of the source of etherscan, but their javascript is minimized and not easily readable.
Thanks in advance!
See this: https://ethereum.stackexchange.com/questions/39817/are-failed-transactions-included-in-the-blockchain
Failed transactions often are included in the chain.
What you sometimes see, if you're using e.g. MetaMask, is a popup saying "this transaction will fail" that happens before the transaction is sent to the chain. This is MetaMask trying to be helpful and prevent you wasting gas. But you can force send the transaction anyway, and you'll get a failed/reverted transaction posted on-chain (like this one for this Solidity source).
So to answer the original question, if TxA was posted on-chain, then client B will process it and get the revert message itself. If TxA was not posted on-chain, then there is no record of it.

Hiding input variables from ever being recorded in a transaction

I'm working on something, just a proof of concept, where people are rewarded for sharing metadata about their IP location. In this case (please ignore the code errors for now), someone would submit their ip, I would send it to an oracle that would resolve it and send back metadata about the ip, then would send the address and metadata to another contract.
This is the naive attempt at pseudo code (or non-compiling, at least) I've come up with:
pragma solidity ^0.4.0;
import "github.com/oraclize/ethereum-api/oraclizeAPI.sol";
contract IpMeta is usingOraclize {
uint public metadata;
function Metadata(bytes32 _ipAddress) public {
update(_ipAddress);
}
function __callback(bytes32 myid, string result) public {
if (msg.sender != oraclize_cbAddress()) revert();
bytes32 ipMetadata = result;
/* send address and result to another contract */
}
function update(bytes32 ipAddress) public payable {
oraclize_query("URL", "xml(https://ipresolver.com?ipresolve=" . ipAddress . ")");
}
}
The goal here is to allow people to prove something about their IP address (country, provider, etc) without the actual IP address being stored with the wallet address in the transaction or anywhere else. Is there a way to hide input data? I'm at a loss on research, and it seems like it would be a really useful function if possible. The im/practicalities of anything other than how to keep input data hidden or inaccessible aren't important.
Thanks,
Mark
The EVM is essentially a network composed of nodes of computers. Anyone can run their own node and your smart contract code will get run on those computers if they have a valid node that can receive the transactions. And since the data will also get transmitted to those computers, the owner that sees the code running in his/her computer will eventually have the power to look into the process getting run(by overseeing network, inspecting memory, etc.).
So from my understanding, the difficulty of doing this depends on the implementation of a Ethereum node. Actually Ethereum's protocols handles some level of security by encrypting the p2p connection. However, what makes all these obsolete in your context is that, the input data is serviced and revealed by services like etherscan(random example). I think it's still possible to achieve want you want, but it will only be a workaround and it will be difficult.
I think of Ethereum and its EVM as a transparent computer, basically the data it receives and sends are not secure at all. If you want to achieve security, that's the thing to achieve in somewhere else, for example process the ip related jobs in some other secure place(trusted 3rd party), then store the data without ip onto the blockchain. That's the best I can think of.

When we call a solidity function via web3js , how does the code flows along with data formats during all the process

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)