Proposed Solution Sample

• Topics: Proposed Solution
• Pages: 5
• Words: 1135
• Date added: April 30, 2020

In this section, we will discuss all the architectural and design components of our proposed solution.

3.1 System Overview

Blockchain 2.0 technology (i.e., smart contract) has enabled a distributed P2P network between non-trusting peers without a third-party intermediary. We aim to apply the knowledge of Ethereum blockchain and smart contract for finding solutions to real world issues. This task is to develop a decentralized social network application based on Ethereum blockchain along with the use of InterPlanetary File System as the distributed storage service and hence bring merits to the current social media network architecture. The task also includes providing a straightforward, content-based rewards system for the users in order to compensate them for the quality content they contribute to the platform.

3.2 Architecture Design

The Smart Contract of this application will manage the entire transactions of the DApp (See Appendix). The user will have to register once initially with his/her wallet/account address and this user address will be stored in a mapping in the smart contract. Each account on the application will be bound to a single account address only, in order to avoid creation of multiple accounts from same address. This smart contract will be deployed on Ethereum Virtual Machine and the frontend UI will interact with users. Hence, the entire system forms a three-level architecture where the frontend UI is responsible for user interaction while the web3 and IPFS libraries are responsible for API calls from frontend client to the backend blockchain and the IPFS storage respectively. Figure 2 shows a complete view of the system structure. At the top is the frontend UI, which is in charge of receiving user input for registration data, posts data and messages and passing them to the web3 library and IPFS library. The web3 library then interacts with underlying Ethereum blockchain system for function calls, contract deployment and fund transfers. IPFS library is invoked when the user creates a post with an image or video, or when the user sends a message in the chat system of the application. The image, video or chat messages are stored on the IPFS data storage and a IPFS hash is returned which is stored on blockchain as record data.

Fig – 2: System Architecture

3.3 Application Design

The entire system comprises of three main components, namely the backend Ethereum blockchain, IPFS storage and frontend web UI. When the client starts, the user can register into the application only if he/she is not already registered. This is handled by the users mapping and frontend. If the account address of user already exists in the users mapping, the frontend registration is disabled, else the frontend sends a transaction along with 0.002 Ether (the cryptocurrency of Ethereum blockchain) to the blockchain and a new user account is registered with the application. This amount goes into the contract balance and it enables the contract to reward the users based on the likes (or upvotes) their content gets. It also discourages malicious actors to get registered on the application.

Fig – 3: Process for registering

While creating a new post (see Figure 4), if an image or video is uploaded by the user along with the post, the frontend client loads the image or video into a byte array and sends the byte data to IPFS storage endpoint through IPFS library. When the data storage is successful, it returns the corresponding IPFS hash in return. This hash is stored on the blockchain and is later used to retrieve the image or video when required. All the post data along with creator’s address, image/video IPFS hash and current timestamp is sent as a transaction to the blockchain along with an amount of 0.001 Ether to the blockchain and the post is created. Other users can now like (upvote) or comment on the post.

Fig – 4: Process for creating post

As Solidity does not support passing of complex data structures like array of strings, the messages of chat system of the application are stored as a single string with delimiters to indicate separate messages. When the user wants to send a message in the chat system (see Figure 5), it first retrieves the previous messages stored as byte data on the IPFS storage using the IPFS hash of chat messages stored on the blockchain. The frontend client converts the byte data into string, appends the current message and again sends it to IPFS storage endpoint in the form of byte array. The IPFS hash returned is then replaced and stored on the blockchain.

Fig – 5: Process for sending message

3.4 Rewards System

When the user creates a post, other users of the application can view and upvote the post if they like the content. Each upvote generates a single token in the application account of the creator. This token count can be seen in the UI profile section of the user. These tokens can be redeemed into Ethers from the platform itself. The funds are directly transferred to the account address from the contract balance. Each token when redeemed gives 0.0001 Ether. Thus, the cost of creating a new post is recovered when the user receives 10 upvotes on his post. More upvotes would ensure that the one-time registration cost is also recovered. This makes the rewards system purely content dependent. Content creators are rewarded only based on how much their content is liked by other users of the application.

3.5 Smart Contract Design

The Smart Contract of this DApp consists of two main components: one is the User structure array and the other is the Post structure array. The User structure array stores data of all registered users of the application. The data comprises of components like user’s name, account address, count of the posts he/she has created, total tokens and redeemable tokens. The name and account address are recorded when the user registers initially on the application, while the count of posts is incremented with every new post created by the user. The redeemable tokens show the number of tokens that can be redeemed into Ether. Once redeemed, the corresponding number is decremented from the redeemable tokens. Total tokens and redeemable tokens are incremented every time the creator receives an upvote on any of his/her posts.

Another component is the Post structure array which stores entire data of posts that are uploaded by the users on the platform. It includes the content created by the user consisting of text, images or videos in the form of IPFS hash, creator’s address, timestamp, comments string and mapping which stores the users’ addresses who have liked (upvoted) the post. When a user upvotes a certain post, the user’s address is stored in this mapping so as to ensure that he/she would not like the same post again.