FeverTokens smart contract architecture

What are smart contracts?

Smart contracts are the backbone of Dapps (decentralized applications). They are pieces of code stored on the blockchain that contain functions which can be invoked and executed, through transactions, by whoever has the adequate role. Once deployed, a smart contract is identified by its address, which you can think of as the IP address of a server.

‍

So why are smart contract different from any regular programs running on servers?

The particularity of smart contracts is that once the code is compiled and stored on the blockchain, which makes it immutable. This means that the implemented functionalities and their underlying logic cannot be changed or altered. Hence, users can expect the code to behave as expected once deployed, just like a “contract” between the developers and the users.

The other specificity of smart contracts is decentralization. Smart contracts are stored on the blockchain, which is a network of computers/servers connected to each other and governed by a protocol. This level of decentralization ensures security and prevents censorship. Indeed, since there is no central authority, everyone is free to interact with a smart contract and invoke its functions, as long as they have the adequate role. In terms of security, unlike conventional programs or applications that are subject to denial-of-service (DoS) attacks, attackers will have to take down the entire blockchain network if they want to take down a smart contract.

Smart contracts have also democratized application deployment. If you want to deploy a regular application, you will have to either buy your own server or rent one from a cloud provider. In both cases, you will have recurrent expenses, either for maintaining your own server or paying the cloud provider for usage. With smart contracts, developers don’t need to worry about paying for the infrastructure to keep their “program” up and running. They only pay a one-time fee for deploying the smart contract(they pay for the storage of the compiled code), while the users pay for executing a particular function of the smart contract (they pay for the processing power to run the code).

‍

Why upgradeable smart contracts?

Remember we said smart contracts were immutable? What if developers made a mistake and want to fix the code post-deployment? What if they need to upgrade that code? In normal settings, this would require deploying a new smart contract, generate anew address, and make sure that all users redirect their transaction to that address. Well, this is where upgradeable smart contracts come into play. Such smart contracts can be upgraded to new versions while keeping the same address (pretty cool, hein).

The idea is quite simple: instead of interacting directly with the smart contract that holds the logic, users interact with a proxy which keeps track of the states[1] and delegate function calls to the logic contract called "implementation". This way, the address to which transactions are made remains immutable, while the logic behind can be modified by simply changing the implementation address.

Note that, since we have separated the logic (functions) from the storage (states), the same implementation/logic can be used by multiple proxies/users.

‍

‍

At FeverTokens, our mission is to democratize the use of smart contracts by removing both technological and financial barriers. That is why we rely on a sophisticated and secure upgradeable architecture, which implements the right governance (based on Role Based Access Control - RBAC, a topic we will cover in a separate article).

In particular, such an architecture saves deployment costs for our users. Indeed, gas fees for deployment are proportional to the size of the smart contract, and since FeverTokens already covers the cost of deploying the implementations that contain all functions and logic, users only pay for deploying the proxies, which only cost around one-tenth of a full implementation.

‍

Why do we leverage the Diamond standard?

As the business logic behind a Web3 application might evolve and become more complex, users will need to add more functionalities into their smart contracts. One can argue that upgradeable smart contracts can do the trick by simply upgrading the smart contract to a new version that contains these new functionalities.

This seems straightforward until we hit the 24 KB size limit of deployed byte code, which sets a limit on the amount of code a smart contract can contain and caps the functionalities that can be implemented. But what if, instead of having one implementation that holds the entire logic and functionalities, we leverage multiple implementations each with a set of functions with a proxy that routes and delegates calls to the appropriate implementation. This is called the diamond standard.

The diamond standard is an innovative smart contracts architecture that will revolutionize Web3 by opening unlimited possibilities for Dapp development. The idea is to divide features across multiple smart contracts called facets [2]. By doing so, developers have more flexibility to add, remove, or upgrade functionalities to their application by wrapping a set of specific functions into a facet that will be invoked by a proxy.

‍

Developing a smart contract from scratch can be very challenging. In most cases, end-users need standard functionalities in their smart contracts, so they end up copy-pasting functions from other smart contracts and eventually mess things up while trying to make all this borrowed code work together.

With FeverTokens, we help both no-code users and developers divide and conquer. Instead of copy-pasting functions, they use our independent, reusable, and secure packages [3] to compose their diamond smart contract and fulfil the application logic. Further, beside our own packages, users will be able to browse through our store and find more packages with custom functionalities offered by other blockchain developers. Users can also develop their own tailored package which they can deploy through our platform, and eventually list it in our store to monetize it.

I will spare you the technicalities for now, but we are preparing an upcoming article to explain how packages and our store will function in detail.

Meanwhile, our team is working relentlessly to ship this new package architecture and enable real smart contract composability. Our goal is to bring together blockchain developers and all kind of creators to build the next generation Web3 applications without thinking of deployment, infrastructure, or code.

Focus on your business/app logic, we take care of the rest.

By Moe Toub Co-founder and CTO @ FeverTokens

--------------------------------------------------------------

[1] States are the persistent global variables used by the smart contract functions that are stored in the blockchain. They can store the balance of a particular address, the owner of an NFT, or any other data that must be persisted through function calls.

[2] The term facet is borrowed from diamonds, hence the name of the standard. Diamonds have multiple facets that reflect light. Likewise, the diamond smart contracts have multiple facets that "reflect" functionality.

[3] Packages are independent and secure facets deployed by FeverTokens team. Each package encapsulates a set of functionalities that users can configure into their DApps such as random minting, oracle, multi-token payment, etc.