Blockchains represent a powerful tool for transparency, interoperability, and global non-violent consensus. When we add the ability to write software and create programs directly on a blockchain, a whole new set of opportunities opens up to us. Chains like Ethereum, Cardano, EOS, and more are testing these smart contract realities while chains like Steem are staying focused to do just one thing (tokenizing the web by enabling social media applications) and do it well. The jury is still out as to which approach is best, but I see value both ways. What we're doing with @eosdac and the DAC Chain Initiative in the future may involve using EOSIO as a base and then include DAC enabling functionality on a system-contract level for the whole chain.
Exciting stuff, but one thing I believe isn't talked about enough is who is actually managing and verifying these smart contracts? How do we know the code we run on a blockchain actually matches the code we think we're running? One of the great benefits of a DAC (Decentralized Autonomous Community) is how multisignature permissions can be used to distribute the management according to the will of the token holders in the community. As such, all changes to the code are done as multisignature requests so the elected custodians can approve or deny them according to the intentions of the voters.
This is also how changes are made to EOSIO system contracts today by the block producers. Unfortunately, many are not familiar with how to verify proposed system contract updates. That's what this post is about.
It's totally geeky and only for a small subset of people who want to know how to validate a blockchain smart contracts on EOSIO proposed as a multisignature transaction.
Here's the video I put together walking through the process. It's about 12 minutes long.
Here are some of my notes to go along with the video:
First off, environment set up. I use this little script so I don't have to specify the url from my cleos each time.
ā mainnet cat cleos.sh
#!/bin/bash
/Users/lukestokes/Documents/workspace/eosDAC/chains/mainnet/bin/cleos/cleos --url https://eu.eosdac.io "$@"
Make sure you have the abi_from_hex binary:
Using this patch: https://gist.github.com/elmato/4fce5bd325ca56bf037f4f906d0a67ae
The patch may not apply cleanly, but the key is to add these lines to the CMakeLists.txt file:
+add_executable( abi_from_hex abi_from_hex.cpp )
+target_include_directories( abi_from_hex PRIVATE ${Boost_INCLUDE_DIR} )
+target_link_libraries( abi_from_hex PRIVATE eosio_chain fc ${Boost_LIBRARIES} )
Have JQ installed: https://stedolan.github.io/jq/
Get the exact version of compiler used to compile the contract.
In this example, we're using cdt 1.3.2
git clone https://github.com/EOSIO/eosio.cdt.git
cd eosio.cdt
git checkout v1.3.2
./build.shCompile the source code involved
git clone https://github.com/eosdac/dacmultisigs.git
cd dacmultisigs
eosio-cpp --abigen dacmultisigs.cpp -o dacmultisigs.wasmget the hash of the compiled code
sha256sum dacmultisigs.wasm
Example:
d6337efc0f19baef5c282dbc5163baabd9cb583cfa4eb19191c031758952b72c dacmultisigs.wasm
get the hash of the code in the multisig transaction:
./cleos.sh multisig review mryeateshere multisigcode | jq -r '.transaction.actions[0].data.code' | xxd -r -p | sha256sum
d6337efc0f19baef5c282dbc5163baabd9cb583cfa4eb19191c031758952b72c -Hurray! They match. :)
compare the ABIs by extracting the abi from the multisig:
./cleos.sh multisig review mryeateshere multisigcode | jq -r '.transaction.actions[1].data.abi' | ./eos/abi_from_hex | jq '' > multisigcode-abi.json
Compare it with what is on github:
diff -w multisigcode-abi.json ../../github/dacmultisigs/dacmultisigs.abi
1a2
> "____comment": "This file was generated with eosio-abigen. DO NOT EDIT Mon Nov 19 14:00:39 2018",
3d3
< "types": [],
127a128
> "types": [],
162a164
> "type": "storedproposal",
165,166c167
< "key_types": [],
< "type": "storedproposal"
---
> "key_types": []
170,172c171
< "error_messages": [],
< "abi_extensions": [],
< "variants": []
---
> "abi_extensions": []
Note, some of the keys may be out of order and in some cases you may see extra empty keys like error_messages and variants above, but that should make no difference.
With that, you've verified that the code in the github you compiled yourself matches what is being proposed as a multisignature transaction.
Stuff like this is currently way to geeky and difficult for most people to care about. At the same time, as our world becomes more and more defined by the software that runs it, we all have to take some responsibility to ensure the code we're trusting in can actually be trusted.
