#2 The search for finding smart contracts
Since the last blog we had an idea for a great proof of concept with blockchain as its core for the data storage. However, we quickly got to a challenge: How to find smart contracts when you don’t have the address at the moment?
We started writing an application in C# using Nethereum to access the Geth client running our private blockchain. Quickly we came to the realisation that finding a contract of which you don’t know the address is not an easy feat.
Basically the address of a contract can be seen as the place it exists. So with the address you can call functions on the instance of a contract. Though, without the address you could just as well be calling a function on air. So we needed a way to look up the addresses of the contracts we deployed.
Possibility one is looping from block 0 to the last block looking for transactions that deploy a contract. Looping through all the blocks is feasible in the beginning but it will become more and more taxing with the life time of the blockchain. If you have three hundred blocks you can envision that looping is somewhat doable, but with a hundred thousand blocks it will take a lot of time. So this wasn’t the way to go.
We needed a solution which was faster than looping and didn’t require storing all the addresses of the deployed contracts in something off-chain, due to the fact that we want the chain to be our main source of data. We don’t want a decentralized application with a centralized database to find data on the blockchain.
Possibility two is using the eth.filter methods on the web3 protocol, however, we could not figure out how to use them to find the addresses of the contracts that were deployed. If anyone can explain this to us please do so in the comments on this post.
So the search for finding contracts continued. Eventually we got the idea that we could place the addresses of all the contracts within a contract, an addresslist. In this way we only needed to keep one address somewhere off-chain, like a config file, and with that find all the other addresses.
We combined that with a way for each contract to describe itself to the caller so every contract can be found and uses almost nothing more than the ethereum blockchain itself.
But how do you let a contract describe itself? Through the magic of inheritance! We made it so that all my contracts inherit a MasterContract which has the ABI (Application Binary Interface) and a type string. These two values must be set when a child of MasterContract is instantiated. So every time we get an address from the addresslist we can get it as a MasterContract and with that get the ABI. Using that ABI we can again get the contract but now as the proper contract it is.
You can see it as an analog to C#’s objects, in C# everything inherits from the class “object” so everything can be instantiated as an “object”. However, if you know the type it is under the hood, you can cast it to the proper type. Here everything is a “MasterContract” from which you can get which type it is under the hood and with that instantiate it.
With the addresslist and the inheritance of MasterContract we have a base for building most of the functionality of our first proof of concept with blockchain as it’s core. Now we go on to the meat and potatoes of building the application: Adding more functionality!
If you found this blog post helpful, don’t forget to give us a clap. And also if you can help us with using eth.filter write it in the comments!
