Verifiable Deployment of Smart Contracts

Marvin Kruse
weeve's World
Published in
4 min readMay 9, 2018

In Solidity, there is the concept of a so-called factory. A factory is a smart contract that is able to deploy other smart contracts — contrary to the “traditional” way of deploying a smart contract all by yourself, without any other smart contracts being involved in the process. The concept of a factory gives way for many innovative and cool things to be built, with factories being used in various ways in projects that exist in the Ethereum space.

What’s so special about these factories?

The concept of factories is nothing new, but the way in which they are being used is constantly evolving. Currently, dynamic code factories are being used quite often, which is basically a smart contract with a function that is accepting a dynamically-sized byte array (this would be the bytecode of a compiled smart contract). This function will then deploy this code as a smart contract onto the blockchain.

These kind of factories are called dynamic since they are not limited to a single variant of a smart contract that can be deployed and they don’t even need to store the contracts bytecode for themselves before deploying it (which is good — we don’t want to clutter our dearest blockchain too much, do we?).

How does verified deployment come into play here?

Dynamic factories are a very convenient way of including libraries, saving gas and avoiding unnecessary data lying around on the blockchain — but we wanted to go one step further. Since the code that is being deployed through a dynamic factory is often stored off-chain and then included in a transaction, we can’t make use of the trustless nature of the blockchain in this case: we need to verify that the code that will be deployed is valid and trusted — otherwise a malicious network participant could easily spawn manipulated contracts leading to the loss of data and/or tokens.

What we call “verified deployment” is a verification method based on a hash of the contracts code, analogous to checksums. If you download a program from an alternative source in the internet you can make sure that this really is the original program through a hash-based checksum. The programs’ code will be hashed directly in the smart contract — and due to the deterministic nature of hashing and the trustworthy nature of computation on the Ethereum Virtual Machine the validity of the program can unquestionably be proven.

How is Weeve utilizing this?

The concept of a checksum-aided factory is being used in the Weeve Network as we are hashing the smart contracts code before deploying it to the blockchain through our factory. If the hash is valid (e.g. is contained in a constantly maintained list of “trustworthy” hashes of registry- or marketplace-variants) the corresponding smart contract will be deployed and activated through our factory. We implemented a specific initialisation-function in our registries and marketplaces that can only be called by its deploying factory. Only if this function was successfully called (by the factory) the corresponding registry or marketplace can be used and is active. This enables us to create a curated list of registries and marketplaces whose code is trustworthy and has been reviewed.

Explaining “verifiable deployment” with an example

To get more familiar with the concept of verifiable deployment let’s take the creation of a new registry for cars as an example:

  1. Alice wants to create a new registry for cars on the Weeve Network and selects the modules that she wants in her registry through our web interface
  2. Supposing Alice has enough WEEV (Weeve token) staked as a collateral for her new registry, a transaction containing the parameters and the code of the new registry is sent to the weeveFactory contract
  3. The weeveFactory hashes the contract code and checks whether this hash in contained in the list of trustworthy registry code-bases.
  4. Supposing that this check succeeds and the code is valid, the weeveFactory then deploys and initialises the new new registry (while using the necessary libraries in the process)
  5. The new registries’ address is stored in the weeveFactory and Alice is now able to use her new car registry according to her parameters
An example of our factory deploying a new registry

How are the participants of the Weeve Network benefitting from this?

If you are accessing a curated list of marketplaces and registries you can be sure that the underlying code of them is working as intended. No-one has tampered with the code and there won’t be any hidden backdoors in the smart contract.

Is there already an implementation online?

We are hosting the Weeve Network’s code publicly on GitHub since we think that especially in the world of smart contracts there shouldn’t be any secrets. Every smart contract that we are currently working on is on there, ready to be peer-reviewed!

Just go to our GitHub and have a look for yourself. If you have any questions, suggestions or you just want to chat about the development itself feel free to head over to our gitter channel — we really appreciate any feedback and discussion!

--

--

Marvin Kruse
weeve's World

building and auditing software for a decentralized future at @byterocket . Ethereum advocate, part-time nerd.