1. Understand the basic idea behind a Smart Contract
Smart Contract. A relatively new term that is used for a wide variety of things, in a tremendous amount of different contexts. But at its core, it always means the same:
• Contract: A binding agreement between two or multiple parties on how certain situations should be handled.
• Smart: Being made in a clever way. Having some intelligent (non-dumb) behaviour of its own.
When relating to distributed ledgers (block chains and otherwise), a Smart Contract is a piece of functionality that manages itself. Or more accurately: is managed by all maintainers of the ledger collectively.
This means that everyone can agree on the current state of the agreement outlined in a Smart Contract, without any disputes being possible.
Now, because most important systems in the real world can be modeled, at some level, as a managed agreement between parties, it is possible to automate these interactions in this distributed way.
2. Be aware of the strengths and weaknesses of a Smart Contract
The major strength of a Smart Contract is that it is completely immutable: Its state is always well-defined, and once created, the agreements that lie within (in essence: its code) can never be altered. But this is also right away its largest drawback: It is impossible to perform bugfixes or feature improvements, because you can only ever publish a Smart Contract once.
This is a large problem. Cryptocurrencies in the value of millions of euros have been lost because of various programming mistakes that were not seen before the Smart Contract was published. And also, it goes against the open world model: It is impossible to make your product ready for the future if you are unable to adapt it once new possibilities and innovations become available.
3. Smart Contracts can be split
This problem is however ‘solved’ in the couple of ledgers out there that allow Smart Contracts to work in a Turing-Complete way: being able to call, depend on and even create each-other. Solved? No, not totally. While this means that it is possible to create a fixed base contract that calls into the latest of an ever-evolving number of ‘versioned’ Smart Contracts, this does mean that anyone who uses these is again completely dependent on the logic of this latest versioned contract to be correct: In other words, they are fully dependent on the author of that contract being honest in the latest version of the code. Because in many distributed projects, trust is actually something that we want to reduce or eliminate entirely, this solution is usually not good either.
Rather, in practice, a combination of the two approaches is the most proper:
• Use a fully fixed interface for the parts of the project that need to be completely set in stone without depending on trust.
• Use a versioned interface for the parts of the projects that need to improve and extend.
Also, by not forcing people to only be able to use the latest version of versioned contract, you give them a lot more freedom, and give them more certainty that the code they have checked and are interacting with today, will still function properly and according to their terms tomorrow.
As outlined in my previous blog article, we did choose Ethereum for the FintechFans project. But observant readers will notice that nothing in above section is Ethereum-specific: It is true for all Smart Contract-supporting ledgers.
The splitting of Smart Contracts in this way is something that is still done way too infrequently, while it is such a natural thing to do.
So how have we structured our Smart Contracts?
For FintechFans, we have split our functionality in three separate contracts:
1. The FintechCoin Contract.
This Smart Contract is an ERC20-compliant token. It is completely immutable, which means that it will only be published once, and that everyone can be certain that their tokens will not vanish overnight. It is heavily based on the well-known and tested OpenZeppelin framework for building Smart Contracts in Ethereum, which makes us very confident that its source code is correct.
2. The Tokensale Contract
The Tokensale Contract will only be used during the public tokensale: It will receive Minting rights from the FintechCoin contract, which means that the only way FintechCoin will be able to be made, is by following the rules of the Tokensale Contract (which are the token creation rules mentioned in the Whitepaper).
The Tokensale Contract also closely follows the implementation of crowdsale contracts as outlined in the OpenZeppelin framework.
When the token sale is finished, minting will be turned off. Only then will FintechCoin be able to be traded.
3. The Marketplace Contract
The Marketplace will be implemented in one more contract. Certain actions will require the user to spend some FintechCoin (more precisely: approve the Marketplace Contract to spend a certain amount for them)
This contract will be versioned: We will release new versions once new functionality is finished. People wil not be forced to use the new version, so it is possible to check the source code of the new version first before using it. We will use Semantic Versioning to release new versions of this Contract, and we will build in a call to check if a new version of the contract exists, allowing you to optionally automate moving to a new contract version, or notify the administrator of other applications that use the Marketplace under the hood to manually upgrade.
I hope this gives some insight in how we are going to build the FintechFans Decentralized Marketplace. Let us know if you have any additional questions!
CTO at FintechFans