After we showed you some guidelines and techniques for developing Smart Contracts (Part One), we want to compare different methods of deploying a Smart Contract. This part is highly dependent on the type of contract you want to deploy. Once again, we use our example Contract from Part One for demonstration purposes, a Smart Contract that holds the public keys of a group of users associated with a course ID. For the comparison, we will design the contract in different ways.

Test Scenario

To compare the different methods for deployment we showed earlier, we’re going to prepare eight variants of our Smart Contract adjusted for the different methods (see the table below for details of the Variants).

Variant	Description
A	One Contract per course, saving of the public keys from the user in an Array in the Smart Contract.
B	One contract for all the courses, saving the public keys of the users in a mapping with course ID and the belonging array of public keys.
C	One Contract per course, saving of the public keys from the user in the log file via the event function.
D	One contract for all the courses, saving the public keys of the users and the course ID in the log via the event function.
E	variant A with the Factory pattern.
F	variant A with the Clone Factory pattern.
G	variant C with the Factory pattern.
H	variant C with the Clone Factory pattern.

We simulate five courses with between 20 and 40 students. For each variant, we deploy the necessary contracts and deploy 10 public Keys. The cost for the remaining 140 keys will be calculated based on the cost of the 10 deployed keys. For the keys, we use the public key of a 512-Bit RSA key in the Format x.509. The testing will be performed on the Rinkeby Testnet. From our System with the Course System, we know that an ID for a course is 4 digits long. The linked GitHub repository contains the source code for the 8 variants of the Smart Contract (https://github.com/mschuster/bcam_feedback_smartcontracts).

Results

After executing our test scenario, we come to the conclusion that variant D is the cheapest for saving 150 public keys for five courses (the table below shows the total cost for the variants).

Variant	Total Cost in Eth	Total Cost in Euro
A	0,06040635	61,32 €
B	0,0552133	56,05 €
C	0,0154453	15,68 €
D	0,01216535	12,35 €
E	0,06759345	68,61 €
F	0,06042722	61,34 €
G	0,02114105	21,46 €
H	0,01658626	16,84 €
		Euro – ETH – Price: 1,015.07 Date: 30. June. 2022 – 08:55

We can see that the cost for the Variants with the Event functionality (Variant C and D) is considerably cheaper in storing the information than the variants where we store the information directly in the Smart Contract (Variant A and B). Variant B and D where we use just one Smart Contract for all the information are also cheaper than their corresponding variants A and C. This is because in our case the cost for deploying the contracts stays roughly the same, so we can’t save cost this way and the price for saving a new key is the same between both variants. This results in higher cost for Variant A and C because both variants accumulate cost with the deployment of every course. Using the normal Factory pattern doesn’t offer any advantage in our case, we have additional cost for deploying the factory contract and every contract that is deployed via the factory is a bit more expensive because they need some additional code, so they work properly. The Clone Factory Pattern is a bit more interesting in our case, it still causes higher cost, although the deployment of the clones is much cheaper than deploying them the standard way, the cost for saving the keys is a bit more expensive which cancel out the saving for the deployment. The linked file has the full annotated data from the experiment if you want to dive deeper in the findings (https://docs.google.com/spreadsheets/d/18VsFfT_f1j3Poxtab-Vn0hXNOvDT6KVc622XQByOo-w/edit?usp=sharing).

Conclusion

Depending on the use case for the Smart Contract, there is a high potential for saving cost when it is deployed. For our use case, it would be cheapest to use the variant D where we save the information in one contract with the event function, because we don’t have a requirement that other Smart Contracts need to access this information, we could deploy the contract this way. Unfortunately, there can’t be made a general recommendation for deploying the Smart Contract, you will have to check the requirements and expectations for your Smart Contract to find the best way for deployment.