2

Lets say I have a contract with a bunch of individual properties. For example, a person with a firstName and lastName field.

A user of a dapp wants to change both fields, which would take two individual transactions.

This is problematic from a UX perspective, since its possible that one of the transactions succeeds while the other fails, and the user must be made aware of it.

This becomes more problematic when changes are codependent. Consider a user who wants to change the firstName of a person CONDITIONAL on the lastName changing.

Is it possible to chain these independent transactions into a single all or nothing transaction?

|improve this question
2

In the example you give, it would be easier just to design the contract such that both fields could be updated with one transaction. For example, in pseudo-Solidity:

bytes32 firstName;
bytes32 lastName;

function setName(bytes32 first, bytes32 last) {
  firstName = first;
  lastName = last;
}

A transaction with the setName function cannot partially execute. It will succeed completely or fail completely.

|improve this answer
  • This is acceptable if there's 2 fields, but the example is just a dumbed down version. In reality there may be dozens or fields. For example if there were 10 fields, you would need 10 factorial setters for each combination of fields. – Aakil Fernandes Jun 24 '16 at 20:03
1

WARNING: Use of marty contracts may open you up to tx.origin phishing. Please familiarize yourself with https://github.com/ethereum/solidity/issues/683

One possible, albeit hacky, solution is to create a "martyr" contract. Such a contract would have the multiple transactions in its instantiation code followed by a selfdestruct.

contract PersonMartyr{
    function PersonMartyr(){
        var person = Person(0x..)
        person.setFirstName(...);
        person.setLastName(....);
        selfdestruct(msg.sender);
    }
}
|improve this answer
  • 2
    This is pretty much the standard way to do it. – Vitalik Buterin Feb 24 '16 at 11:10
  • @VitalikButerin interestingly the only way to use martyr contracts like this is to check tx.origin instead of msg.sender. Which looks like it may open up a whole can of worms like in the Mist wallet phishing issue – Aakil Fernandes Jun 24 '16 at 19:47
1

I built QueueBot, which when deployed will allow a user to queue up multiple individual transactions into a single all or nothing transaction.

https://github.com/SafeMarket/QueueBot#queuebot

|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.