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.
Related
I have a function that needs to call the transfer method on another contract.
I want the transfer method to be called from the address of the original caller and not the contract.
Is it possible?
This is the code:
function buyGameBundle(string calldata id) external nonReentrant {
structGameBundles memory currentItem = _gameBundles[id];
require(currentItem.exists == true, "bundle does not exists");
require(currentItem.totalSupply > 0, "there are no more bundles left");
if (currentItem.cost > 0) {
erc20.transfer(_feesAccount, currentItem.cost);
}
currentItem.totalSupply = currentItem.totalSupply.sub(1);
_gameBundles[id] = currentItem;
emit BuyGameBundle(_msgSender(), id, currentItem.cost);
}
erc20.transfer(_feesAccount, currentItem.cost);
Your current code performs a message call (docs). Another name for the same thing is an EVM call. It uses storage of the target contract, and the msg.sender is your contract (not the original transaction sender).
If you want the msg.sender to be the original transaction sender (the user), you need to use a delegatecall (docs). But... a delegatecall uses storage of the caller (your contract; not the called contract), so it's mostly useful for proxy contracts.
For security reasons, it's not possible to execute a function in a target contract, using the target contract storage and msg.sender of the original sender.
If it were possible, you could theoretically steal tokens from anyone who doesn't/can't verify your contract source code. Example:
usdt.transfer(attacker, usdt.balanceOf(victim));
weth.transfer(attacker, weth.balanceOf(victim));
// ...
Needing to transfer funds from someone is such a common pattern that it is built right into the ERC20 specification, and is used in almost every DeFi contract ever.
What you need to use is transferFrom() rather than transfer(). It takes a "from" address as the first parameter, and if the sending user has approved your contract to move their funds, then the call will succeed.
In your case the transfer line would change to:
erc20.transferFrom(msg.sender, _feesAccount, currentItem.cost);
The sender will need to approve your contract first.
Here are the ERC20 specifications.
https://eips.ethereum.org/EIPS/eip-20
If you are using ERC20s and want to transfer another account's tokens from within a seperate contract, the correct method to use is transferFrom. This requires an allowance to be given to the contract in which transferFrom is being called. This is done using approve or increaseAllowance (the latter is recommended).
In general, however, if you wish to call another contract's method in the context of the current contract, i.e. with the same msg.sender (amongst other things), you can use delegatecall. See https://docs.soliditylang.org/en/v0.8.11/types.html#address for more details.
I want to look at libraries that can implement crypto functions to validate digital signatures.
There's no built-in function to validate signatures in Daml. All signature validation happens through the signatory declaration on templates which should be flexible enough via various patterns to handle signatures validation however you need.
It would be helpful to understand what you're trying to achieve with signature verification.
In cryptocurrencies, public cryptographic primitives are needed since public keys define the identity, in other words the signatures need to be verifiable publicly. In Daml this is usually not needed, since party defines the identity and most information is inherently private to some group. As such, public verification isn't a common use case.
One way to use cryptographic primitives alongside Daml is to have clients of the Ledger API(s) sign and verify signatures. For example, if I want to authenticate that a specific human is performing an action based on a smart card in their possession, part of the workflow could include:
a party verifier create a random nonce as a challenge which is written to a contract
a party alice use her smart card to sign the nonce and submitting the signature as a choice parameter
party verifier validate the signature in order to progress the workflow
If you are using DAML, below is the code to accept crypto coin issued, here you can add your conditional verify or check coinAgreement.issuer go here
For e.g. verify he is both issuer and owner
coinIssuerVerify <- queryFilter #coinIssuerVerify issuer
(\cI -> (cI.issuer == issuer) && (cI.owner == owner))
template CoinIssue
with
coinAgreement: CoinIssueAgreement
where
signatory coinAgreement.issuer
controller coinAgreement.owner can
AcceptCoinProposal
: ContractId CoinIssueAgreement
do create coinAgreement
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. :)
I wasn't sure what to search for as I don't which subject matter this fits in.
What I have in mind is sort of like JS Promise.all([...]).then() but for cloud functions.
For ex. function A depends on the successful completion of functions B and C which are not aware of each other and run concurrently.
I assume something like this is not available natively?
The only thing I can think if is keeping some sort of persistent register and an intermediate function which fires on completion of both B and C and checks if the group has completed and triggers A when they have.
It's not possible with Cloud Functions alone. The system is stateless - there is no "memory" of what happens with each function invocation.
What you would have to do is involve another product to retain state that would be responsible for triggering the third function after the first two complete. One way to implement this is using a Firestore document to store the completion status of each function. Functions B and C will have to agree on some share unique ID that identifies their work. That ID could be used as the ID of the document in a collection that stores the completion state of each function - the functions would have to write their status to that doc before completion. Then you could write a Firestore trigger that gets invoked when a document in that collection changes. The function would then examine the document to see if B and C are complete, and process to run A.
In this post, I suggested to use the ScriptDB as an intermediate storage for global data of a Container Extension code. I wrote a sample code for my answer but the sample throws the error: You do not have permission to call query (line X) exception in a ScriptDb.getMyDb().query(...); line. I created the following simpler example demonstrating the problem. The code, both getDBSize and getSource functions, is permitted to use the ScriptDB by running it in the editor. The getDBSize function is executed without any problem by pressing the Run button in the Spreadsheet Script Manager Dialog. The getSource function works everywhere.
I published the Spreadsheet for the example - link. It is impossible to share the code for view, but it is possible to output it in a cell, the cell B3 contains exactly bellow code.
How is possible to permit the Spreadsheet Code to have access to the ScriptDB?
function getDBSize() {
var db = ScriptDb.getMyDb();
var result = db.query({});
var count = result.getSize();
return count;
}
function getSource() {
return this.toSource();
}
The problem is that you're trying to run this function as a spreadsheet custom function, and custom functions are way more limited than all examples on the Container Extension page you linked.
But, from a theoretical point of view, custom functions as well as simple event handlers (e.g. onEdit, onOpen), can not access anything that requires the user account or is associated with the user, only "generic" methods. For example, UrlFetchApp, open the current spreadsheet, or read ScriptProperties.
So, in thesis, querying a ScriptDb should be possible, since it's a generic call and has nothing to do with the active user, it's analogous to ScriptProperties. I don't see a workaround that would actually let you query the db, but you could use ScriptProperties instead. You can easily save and retrieve any object you would save on ScriptDb by using JSON.stringify and .parse. Of course, I'm not comparing ScriptDb capabilites with ScriptProperties, it's just a workaround.
Anyway, this seems like a good candidate for an enhancement request on our issue tracker.