Cadence Contracts Architecture

INTRODUCTION

FlowBetPalace is fully on-chain secure and scalable application , the open-source contract repo is this: https://github.com/flowBetPalace/cadence.git.

Our architecture is defined as a Resources Based architecture, due to our aplication uses resources created by the contract for almost everything, resources are a powerfull feature of cadence that let us increase the security and scalability, so we decided to take adventage of it.

The aplication has one smart contract called FlowBetPalace and its main function is create the needed resources that stores the data of the aplication. This contract works hand to hand with the account storage where the contract code is stored.

Afterwards we will go deeper on how we implement this.

The next image shows a basic illustration of how the resources are stored in each account, from FlowBetPalace account to client user account.

HOW DO WE USE THE RESOURCES?

Since resources are an incredible innovation way to manage the data , In FlowBetPalace we have decided to store the data on resources and access directly to them for almost every needed action. We have 5 resources that can be created(Bet,ChildBet,UserBet,UserSwitchBoard,Admin).

before to go deep and explain every resource functionality, I would like to explain the differences between a Bet and a ChildBet.

In our application , the Bet is the event and the childBets are the bets that you can add to every event. Right now you can be thinking, why we called this resource Bet and not Event. Thats a nice question, but since our app is focoused in a betting site we found more apropiated call it like this.

As an example for this, a Bet would be the a race event and the childBets are the possible bets that user can create. Since one Bet can have multiple childBets, the race could have one childbet of who wins the match and otherbet of who has the fastest lap.

Now, what's the function of each resource?

Bet: this resource is created by the contract, can be created multiple times and and is stored in the account storage that owns the contract code. Bet resource have a very small but important utility, create childBets. The track of each created bet is made in the smartContract, wich will contains all createdBets data stored in array and dictionaries for filter it.

ChildBets: this resource is created by the Bet resource , can be created multiple times and is stored in the account storage that owns the contract code. Some people will be saying why do we store this on storage instead of make bet storage this childbets, the answer is easy, scalability. Since childBets will be accessed frequently, the process speeed of interacting with them is faster than storing them on bet resources. This is due to you can only interact with a resource one time, so if 2 users are trying to access a diferent child bet that is stored in a bet, the second one will have to wait the transaction of the first one finish just to wagger a different childBet. So like this we make transaction times faster, users only will have to wait a user have finished interacting with the reference of each resource for interact with, also like this we interacting with references and capabilities, in the other method we would be moving resources, and thats slower. Its utility is high and critical since this resource track the funds betted on the childbet, algorithmically calculate the odds of every option, let user wagger on that childBet, and give prizes to winners.

UserBet: Each user will have the possibility withput restrictions to wagger on each childBet. This wagger process will send the amount of flow that the user wants to wagger to the childBet, and the childBet will be giving back a UserBet resource as receipient of the wagger, this UserBet stores crucial data, as the amount waggered, childBet unique identifier, choosenOption, etc etc,... This makes that the childBet stores 0 data about each UserBet and each User stores all the data. In other programing languages paradigms this would be an insecure solution, but in Cadence its not, this is the perfect solution for this application, also giving the users more security about his bets, giving him security of that he stores the recipient and nothing can heppen to his wagger, he will always have the receipient of hte wagger for when he wants to withdraw the funds.

UserSwitchBoard: this resource is created by the smart contract and given to each client user, its function is store the UserBets resources.Also this UserSwitchboard have the capacity to provide data of the UserBets he have. By the other hand the switchboard resource only allows to interact with them to the switchBoard account owner.

Admin: This resource is created by the smart contract and given to the admin account, wich will give him allowance to create bets.