4

Say there is a smart contract that involves a buyer and seller. Anyone can instantiate this contract but eventually two parties, the buyer and seller, will register with the contract. A seller would like to create a service that invites buyers to accept contracts with them, so they create a (centralized) web site that instantiates new contracts on the server whenever a buyer is interested, and then shares the address of the new contract with the buyer so that they can register through a transaction on the blockchain.

Given this model, how does one prevent a malicious user from draining the seller's funds by repeatedly triggering contract creation through the website with no intention of registering as a buyer?

Is there any way to prevent or discourage that attack while maintaining the constraint that the seller is instantiating the contract?

Improve this question
3
  • Have you found an answer to this question ? Do you need more information ?
    – Nicolas Massart
    Jun 7 '16 at 17:19
  • 1
    Thanks! I have given the question more thought and I think I have a workable solution. It involves the user paying a small ether deposit as you suggested but then also storing constructor params to instantiate the contract on-chain, thus eliminating trust that the seller will instantiate the contract with the correct parameters. This reduces the attack risk to only the gas required for storage of the params (or even just a hash of the params) rather than the gas for a full contract instantiation. Your answer was a helpful first step. I can write up a fuller answer that includes this extension.
    – Raine Revere
    Jun 7 '16 at 17:42
  • Yes please ! Don't hesitate to put code in it :)
    – Nicolas Massart
    Jun 7 '16 at 17:48
1

I don't think this problem is related to the Ethereum part of what you describe but only to the classical web part. On Ethereum network, to interact with the contract other than just reading states, a user have to pay fees, this will prevent any spam use and even if the user spams the contract, the fuel will come from its account. In what you describe, the user that pays the fees and interact with the contract seems to be the website on wich the end user is connected. Thus it's the web site that is in charge of preventing the end user to drain all the fuel by making it call the contract repeatedly. A end user registration on the site should be enough to fix this. If you fear users that creates multiple accounts, you could request a small ether deposit or buying some tokens you can create for your own purpose when the user creates an account.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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