2

I would like to develop a contract in solidity and a DApp. However, I do not want anyone to be able to execute the certain public function if they are not using the DApp that is associated with the smart-contract. Furthermore, I want the frontend user to pay for all the GAS fees.

Can this be done, and how ?

Improve this question
1
  • Did you discover a good solution for this?
    – Trent
    Nov 24, 2021 at 21:03

2 Answers 2

Reset to default
4

You can include in your contract a key that only your app know, but... the Ethereum net make public the smart contracts code, then I dont know how you can avoid decrypting the communication between the app and the contract.

Maybe if you dont verify the contract the code of it stay hidden.

Other solution I can think is to create 2 contracts, where the second contract functions only can called from the first if conditions occur. (For example, the msg.sender its registered in a previous mapping....)

Hope it helps too :)

Improve this answer
4
  • Yes, the only way I can see it is if I don't verify the contract, the code will stay hidden. However, I don't know if I can hide the code since it can be decompiled. Maybe have a bunch of methods that do the same thing so that only DApp knows which one is the right one to call and which one is fake? Second solution would be OK if the first contract acts as a DApp... but the thing is I need to use a DApp to save wasting money on GAS.
    – Damir Olejar
    Mar 20, 2021 at 1:53
  • I did some quick coding and it turns out that you can have a second contract, with a view (to save the gas) and that you can pass the key + address and verify the key with the second (private) contract. Now the problem is that we must make sure that the same key cannot be passed twice, without altering the state of the second contract. It would have to be a simple cryptography but strong enough so it can't be easily broken. I would accept your answer but am afraid that it is not complete for others to take it as a solution. The solution itself should be kept a secret and is useless if broken.
    – Damir Olejar
    Mar 20, 2021 at 4:36
  • 1
    I think you can control the key will passed twice saving key and state in a mapping. For ex. "mapping(address => bool) allowedToCall;"
    – JTCon
    Mar 20, 2021 at 10:49
  • Yes, but I don't want to waste gas on it :) so maybe the block.number can be used to generate and confirm the key...
    – Damir Olejar
    Mar 20, 2021 at 11:34
1

Contracts evaluate signed transactions from users. They don't evaluate how the user composed the transaction or signed it. From a human perspective, it is helpful if a UI guides the user, composes the transaction and offers it for signing but, typically, this is of no concern to the contract.

Contracts need to guard their internal integrity regardless of what any UI sends them. It is always an indicator that a design defect probably exists if the contract's internal security relies on restricting the users to a certain interface. This is a variant of strategies that try to prevent other contracts from using the contract, which is similarly almost always an error.

If the contract is indifferent to the origin of a valid transaction and it rejects everything that isn't allowed, then it shouldn't matter which interface is used or the nature of the user. That approach protects the system from possible developer error in future front-ends. It enables novel interactions with other contracts (composition) or even the creation of UIs and APIs by third parties which is usually a sign of traction.

Hope it helps.

Improve this answer
8
  • So, the answer is "No" ?
    – Damir Olejar
    Mar 20, 2021 at 1:43
  • "is always an indicator that a design defect probably exists". - Nope. Just because we may not envision the valid use-case scenario, it does not indicate a defect. The defect is then in the network for not allowing such a scenario. Also, the word defect is not the right one to use. Try "constraint".
    – Damir Olejar
    Mar 20, 2021 at 2:15
  • In case my meaning wasnt clear. A contract that relies on a particular user interface probably has a vulnerability.
    – Rob Hitchens
    Mar 20, 2021 at 5:04
  • You can definitely control access to certain senders which can be externally owned accounts or other trusted contracts. You won't know if they are sending raw transactions, using a DIY UI or the intended UI. It can be server with a signing key (EOA), which looks like a user with a known address from the contracts perspective.
    – Rob Hitchens
    Mar 20, 2021 at 5:09
  • If that's what you want, check out Ownable.sol in the open zeppelin contracts repo.
    – Rob Hitchens
    Mar 20, 2021 at 5:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.