DAOhub Verification of 0xbb9bc244d798123fde783fcc1c72d3bb8c189413

Firstly, it’s really important that all future DAOs’ source code gets verified before the creation phase begins in earnest. So far over 1,537,000 Ether has been sent to The DAO’s smart contract at the time of posting, and 99% of the DAO Token Holders are basically trusting the creator as they do not know the source code that the contract is running is correct.

The following post will:

Describe the verification of github.com/slockit/DAO smart contract to 0xbb9bc244d798123fde783fcc1c72d3bb8c189413 and 0x4a574510c7014e4ae985403536074abe582adfc8
Discuss the steps that are required to fully verify that this contracts including the curators multisig (0xda4a4626d3e16e094de3225a751aab7128e96526).

We are assuming that the base contract is secure. This assumption is justified due to the community verification and a private security audit; validating this assumption is outside the scope of this post.

Part 1: Transactions that will echo for eternity

It all started with two transactions. The first transaction which created 0x4a574510c7014e4ae985403536074abe582adfc8 which should match the bytecode of DAO_Creator contract. This contract is used to create a new DAO in the case of a split. If an attacker replaced this with something else it could prevent users from splitting, undermining the security of DAO.

The second transaction created the DAO contract (0xBB9bc244D798123fDe783fCc1C72d3Bb8C189413). This is the contract DAO Token Holders will interface with directly and obviously needs to be verified as well.

We need to confirm that the bytecode in these transactions matches the bytecode produced when compiling the github.com/slockit/DAO. Things get a bit wild when trying to confirm this. It turns out that Solidity sometimes changes the order functions are placed in the bytecode. Iteration over a set of AST nodes leads to the lack of a deterministic output, this is being corrected as we speak.

One interesting approach by Jordi Baylina, was to brute force compile until a match was found. However this did not work.

An honorable mention goes to Matt who was working with us to reproduce the bytecode, he spent hours on this and was incredibly helpful. Lefteris Slock.it’s Lead Technical Engineer was also invaluable , coordinating with Christian Reitwießner on the optimizer being non-deterministic. This is now fixed in this PR. Also everyone on the #art_of_the_DAO channel on the Slock.it Slack (Request an invite at http://slack.slock.it:3000) were extremely helpful and our complete conversations can be found in these archives . Watch as I slowly lose my mind trying to find why the bytecode kept changing.

All the verification glory goes to psdev who used the Ethereum Wallet finding that if you compile and then force a recompile (delete just one character and retype it) it causes the compiler to enter the state is was in just before the actual deployment happened. To deploy do the following:

1. Compile the `Token.sol`, `ManagedAccount.sol`, `TokenCreation.sol` and `DAO.sol` (order is important) into one file removing the import calls. Like (here)[https://gist.github.com/colm/31abc56875b1216468c0df86fbd29bdd]

2. Install mist 0.7.2, sync and go to testnet

3. Go to CONTRACTS -> DEPLOY NEW CONTRACT

4. Paste the code into the SOLIDITY CONTRACT SOURCE CODE text box

5. The Wallet will need time to compile the contract in the background. Wait for it to finish.

6. Delete one character and retype it. This will cause the compilation to start again.

7. Under SELECT CONTRACT TO DEPLOY Select DAO.

8. Use the constructor values as seen here

9. You can then compare by clicking DEPLOY, highlighting the bytecode and copying.

10. Go to the second transaction. Open your browser’s find (CTRL+f) and paste the bytecode here. It should match.

11. Go to step 7 select DAO_Creator , click deploy and compare with the first transaction.

We found that these bytecodes matched for DAO_Creator and DAO contracts. Produced by the Ethereum Wallet 0.7.2 using this method. It’s important that you confirm this as well and tell the community. Don’t just believe me. CHECK! If it matches, tell people. Comment and confirm. This will increase everyone’s confidence. Maybe try geth instead of etherscan.io and confirm the bytecode matches.

After this success Matt found that it is also possible to verify with browser soliditiy if you toggle the optimizer checkbox on/off it till result in the code being compiled. Confirmed with v0.3.2–2016–05–01-bee80f1.

Part 2: Curators

Firstly, we need to confirm that their multisig contract is secure (reviewing the code is outside the scope of this post. But since its based upon the original wallet and the changes were so small it should be trivial to verify) and confirm that its bytecode matches the bytecode used to create the multisig.

The code this multisig is based upon compiles to match the bytecode.

This was compiled with the same version of the Ethereum Wallet used for the DAO contract. The contract has the same bytecode. The constructor parameters were not verified as it is only important that all the addresses currently registered belong to one of the curators.

To fully verify this contract we need ensure that the CURATORS have control of 0xda4a4626d3e16e094de3225a751aab7128e96526 multisig. To do this we need a public reputation system or at least verified identities. A suitable method seems to be to contact each curator asking them to take a picture with the address they used with the multisig.

Hopefully we can update this post with pictures of all the happy curators and their addresses ;-)

LIST:

Verified:

Taylor Gerring 0xcee96fd34ec793b05ee5b232b0110eac0cc3327e