As a developer, Ethereum keeps you on your toes. On the plus side, you constantly learn something new and the thrill of the “aha” moments is undeniable. Today, I want to talk about an interesting scenario that we ran into at Roll with the . This is a story with a happy ending but also a warning to other developers to handle this scenario gracefully. old Gnosis multisig wallet Note: This is not a vulnerability in the old Gnosis multisig. Rather, developers using this contract need to put in some extra work. Transaction Failure on Ethereum Transaction failures are not uncommon on Ethereum. There could be a number of reasons for it – from hitting an assertion to trying to take actions that the smart contract explicitly forbids (say, trying to run an admin or owner function without being the admin or owner). However, for most regular users, the most common transaction failure is the gas limit. Because Ethereum is , it needs to address the , i.e. make sure every program on Ethereum finishes running. Gas is a workaround to address this. Every transaction has a gas limit. If the gas limit is hit, the transaction is reverted. Turing Complete halting problem It is not hard to find these transactions on Ethereum. Here is an example and how it looks like on Etherscan. You’ll notice two things – The “Status” is “Fail”In the “To” field has the error description – “Warning! Error encountered during contract execution [Out of gas]” If you’ve been developing on Ethereum, you’ll notice this is a common occurrence. The solution here is to resubmit the transaction with a higher gas limit and move on. Status Success but Out of Gas? What we encountered was a transaction where the “Status” is “Success” but the transaction still ran out of gas. Huh? Here’s what that looked like on Etherscan. confirmTransaction on old Gnosis Multisig Let’s dig in here and see what’s happening behind the scenes. The main call we make when confirming a transaction on the old Gnosis multisig wallet is . This is how it looks – confirmTransaction confirm public
        owner transaction not {
        confirmations = ; ;
        execute ;
    } function Transaction( ) uint transactionId Exists( . ) msg sender Exists( ) transactionId Confirmed( , . ) transactionId msg sender [ ] transactionId [ . ] msg sender true Confirmation( . , ) msg sender transactionId Transaction( ) transactionId As you’ll see, this function is doing two things – Add a confirmation to the transaction (e.g. if you set up a 3-of-5 multisig and this was the second confirmation, the status would go from 1-of-5 to 2-of-5) Execute the transaction (for the same 3-of-5 multisig, this would execute the transaction during the third confirmation i.e. when the status goes from 2-of-5 to 3-of-5) These are not handled atomically, which means . This is exactly what happened in our case. it is possible for the confirmation to succeed and the execute to fail This is important to note for a few reasons. Firstly, . If you try, it will just end up failing. The reason is that the transaction is trying to add a confirmation first. If the transaction is already confirmed, then it will simply fail. See the function you cannot get out of this situation by resubmitting the transaction with a higher gas limit isConfirmed public
        constant
        returns (bool)
    {
        uint count = ; (uint = ; <owners. ; ++) { (confirmations[transactionId][owners[ ]])
                count += ; (count == required) ;
        }
    } function isConfirmed (uint transactionId) 0 for i 0 i length i if i 1 if return true Second and most importantly, do not try to submit a new multisig transaction. This could result in a double-spend! A naive and tempting way to handle this situation would be to say, “Well, I guess the transaction didn’t go through and I cannot resubmit it. Let me send a new transaction”. Don’t do this. To understand why, here’s a hypothetical. Say you have a contract with a call that does some computation and pays out someone’s salary. This is controlled by an old Gnosis multisig wallet as 2-of-3, so both CEO and CFO need to sign off. paySalary Say you run into the above situation and the transaction doesn’t seem to go through (you check on the blockchain that indeed the Ether or DAI have not been transferred) and naively submit a new transaction with a different transaction id. In the above scenario, the older transaction will be in confirmed state but not executed state, while the new transaction will be both confirmed and executed. This means the recipient can then call on the contract and be paid twice – essentially a double-spend. So this is a bad way to handle things. executeTransaction The Schrödinger State In the scenario outlined above, the transaction ended up in a confirmed state, but not executed. Essentially, the transaction is in the following state isConfirmed: true executed: false Your application needs to be able to handle this “intermediate” state the right way. Handling this Failure the Right Way So how should this failure case be handled? You should explicitly call the function on the contract with the transaction id of the original transaction. Here is the function executeTransaction execute public
        owner confirmed(transactionId, msg.sender)
        not { (is ) {
            Transaction storage txn = transactions ;
            txn.executed = ; (external ) ; { ;
                txn.executed = ;
            }
        }
    } function Transaction( ) uint transactionId Exists( . ) msg sender Executed( ) transactionId if Confirmed( ) transactionId [ ] transactionId true if _call( . , . , . . , . ) txn destination txn value txn data length txn data Execution( ) transactionId else ExecutionFailure( ) transactionId false Calling the function above will ensure that the original transaction is executed. Be sure to provide sufficient gas for this call. Check your Data If you use the old Gnosis multisig wallet in your application, it would be wise to check the data on your contract. You can loop through all the transaction ids and look at the following values: and . Unfortunately, you cannot get the value via a Web3 call (there is no function provided). isConfirmed executed executed isExecuted If you come across any transaction that is in the state , that’s where you need to pay attention. isConfirmed: true executed: false If you find such a transaction, you can make a call to revoke a confirmation that is not yet executed by calling . This is the function revokeConfirmation revoke public
        owner confirmed(transactionId, msg.sender)
        not {
        confirmations = ; ;
    } function Confirmation( ) uint transactionId Exists( . ) msg sender Executed( ) transactionId [ ] transactionId [ . ] msg sender false Revocation( . , ) msg sender transactionId

The Case for Alternate Systems of Money in Today's World

Read My Stories

Too Long; Didn't Read

CTA: Download the FREE AI Productivity Shift report

Transaction Failures in The Old Gnosis Multisig Wallets [How To Fix It]

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

The Case for Alternate Systems of Money in Today's World

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

The Case for Alternate Systems of Money in Today's World

(1/100) Crypto Countdown: Golem

A Research Report on the Trader $JOE DeFi Platform

07/03/2018: Biggest Stories in the Cryptosphere

05/02/2018: Biggest Stories in the Cryptosphere

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps