Ethereum DApp: The ProjectThis project's only purpose is to demonstrate my skills as Blockchain and DApp developer. |
|
I have started this project during the COVID-19 crisis with the goal of finding remote positions in the world of decentralized ledgers and applications. Due to the drop of activities related to the pandemic and the quarantine, it was a good opportunity for me to trigger the career change I was thinking about for a long time. From embedded system and electronic engineering to blockchain technologies seems to be a long journey but in fact it isn't, because when we look at the DLT and DApp from the EVM and Bytecode point of view it is much more related to low-level hardware and mathematic than just software programming. And as an experienced C# developer I am able to navigate through all the technical aspects of the DLT technology and I find this domain very interesting and inspiring.
Another thing is, that I think my experience with embedded system and RFID can be very valuable in this technology, because beside cryptocurrencies and tokenization I don't see much future for the DLT without their electronic counterparts in the physical world. There is a huge potential in the Supply Chain industry and Assets Management coupled with IoT devices for example, Digital Identity with biometric readers, or Payments and Commerces with PoS systems. All of these electronic devices should be blockchain-capable without breaking its benefits of enhanced security, better transparency and stronger resiliency.
This project is composed of smart contracts running on the Ethereum platform and a web application hosted on Azure. It is a games and scoreboard manager where users can find a list of games, register to play some of them and save their scores inside the blockchain. It is a quite a good use-case to leverage the advantages of the blockchain technology because it requires several levels of access (players can only play and update their name, managers are responsible for the games, and the games can save scores) and the data are cannot be altered, it is protected by the tampered-resistant nature of blockchains .
The smart contract has been developed for the Ethereum platform using Truffle and Ganache from the Truffle Suite. The editor used was Visual Studio Code.
It is written in Solidy and compiled with the version 0.5.15. Open Zeppelin's contracts are used for features like Access Controls, Safe Arithmetic and more.
It has been fully tested with Truffle (it uses Mocha testing framework and Chai for assertions). Due to the modular approach used, each contract of the hierarchy had its own set of Javascript files to validate all the functionalities and inheritance. Since it is not a commercial product but a demonstration project, no actions have been taken to reduce to code size or manage maintenance. For example, many functions could be removed and we could read the data directly using the public getter or even with eth.getStorageAt().
- Owner only
- This is the most restrictive case, access is granted only the account initiating the transaction matches the owner's account. It is implemented using Open Zeppelin for critical functions like managing the games, the access controls and contract itself.
- Public access
- This is the less restrictive case because there are no restrictions at all, access is always granted whatever the account initiating the transaction is. It is only used for reading data from the DApp like the list of games and players, their score etc....
- Restricted access
-
This is the most complex case because it requires signing the data payload on the client side and verifying the signature in the smart contract. It is mandatory when some user's transactions require to be validated by an authority, for example saving the score (because we don't want the user to choose its own score, it comes from the game) or adding/renaming user. For these reasons, we restrict the interaction with the DApp via only the authorized front-ends.It is implemented using SH3 hashing and ECDSA signature algorithms from the Ethereum cryptography, and Open Zeppelin.
- SecuredPortal.sol
- It implements the access control mechanism mentioned above, with the Ownable and Roles libraries from Open Zeppelin.
- GamesPlayable.sol
-
Inherits SecuredPortal.sol and add the features:
- Add/Remove and query Games.
- Add/Query Players. (Players are registered per games)
- GamesRecordable.sol
-
Inherits GamesPlayable.sol and add the features:
- Save/Update Scores and Progress for Players per Games.
- Query Scores and Progress either separately or together.
- Generate Events whenever the Name, Scores or Progress of a user is updated.
- GamesPageable.sol
-
Inherits GamesRecordable.sol and add the features:
- Build and maintain a paginated list of ranks for each Games, after each Scores update.
- Query the position of specific Player.
- Query any pages of ranks.
- Generate Events every time a rank is updated.
In a real situation where we would like to implement such DApp for managing real games and players, we would implement it totally differently because we would focus on keeping the deployments and transactions costs to the lowest possible, and maybe create non-fungible tokens to monetize the game. For example we could create a custom token representing the scores, which can be only mined by authorized accounts, and we would try to keep the minimum of on-chain data by leveraging the log system and maybe operating a private blockchain in background or a standard database to save non-essential data. We could also run some nodes so the Front-ends would connect to them and maintain the rankings and historical data. They are plenty of potential architectures but for the sake of demonstration, this system is performing its duty as it is.
Even though this is a demonstration project for DApp development, I should provide a way to interact with it without having the user to install a full client like Geth and send commands via CLI. I could create a console or graphic client which uses Geth in background and provides the user with a better interface, but the user would still have to install 2x applications and be able to operate a blockchain client which requires a technical background and sometimes sync dozen of gigabytes of data... The best option for the user would be to interact via his own web browser without revealing the private key of his account, so the most suitable solution is the famous Metamask and its integrated wallet. It is not a perfect solution because it suffers from Infura's quota limitations when used for DApp interactions with higher data throughput. But for demonstration purpose the advantages outweighs the limitations, and the user should simply wait a few minutes when he experiences the error: "Network request failed".
Until now I was using almost exclusively the Truffle Suite, with Open Zeppelin and a bit of Remix IDE), I didn't build the front-end with Drizzle as one would expect, simply because i am not a big fan of javascript. I am initially embedded developer with electronic engineering background so I prefer strongly-typed, structured and compile-able language like C or C++. Outside the embedded world my favorite language is C# so I have used this language and .Net platform to develop the front-end.
This website is a Blazor application (based on asp.net core technology), and it uses Nethereum and Metamask to access the Ethereum blockchain and interact with the DApp. It is hosted on Azure with the cheapest subscription plan so it may experience some downtime when the quota is exceeded. From the technical point of view there is not much to say about it, the bridge between Metamask and Blazor is done using Javascript Interop and the application is server-side only for the sake of simplicity. If it would be a commercial product, I would separate the client-side and server-side components and I would implement several other wallets than Metamask, but it is not the scope of this project. Also, I would listen to the events emitted be the DApp and I would create a better UI because as you can notice I am not graphic designer, I am only using the Bootstrap toolkit and a few components from Syncfusion to speed up the development time (Modal dialog and Datagrid to be exact) with their Community License.
for the first release there is no real game yet, only a random number (it actually exists as a game, it is called a slot machine), because the main purpose of this project is about blockchain development to show my qualifications to potential customers. So I will work on the game at the very end, it will be made with Unity and the Nethereum.Unity library. I will create or modify one or several games for single-player which are lightweight, secured (not cheat-able) and fun to play of course.
This project is a launching pad for the exploration of more DLT with different architectures and consensus mechanisms. I have already deployed a private Ethereum blockchain with Proof-of-Authority consensus on Azure and I could propose it together with the 4x Ethereum Testnets (Ropsten, Kovan, Rinkeby and Goerli), but the operating cost is still too high for a demonstration project. For the same reason I do not propose the Ethereum MainNet because it would incur real costs for the users (real Ether).
Here is the non-exhaustive list of the platforms I am going to investigate, with a special interest in the non blockchain-based DLT like IOTA and Hashgraph because as I said before, I am very interested in the integration of real-world electronic devices with DLT. All these projects seem promising, some are using the same programming language than Ethereum (Solidity) so I may be able to reuse some source code, and I will have to implement the related wallets in addition to Metamask.
Knowing these platforms will bring additional knowledge and competencies that will be highly beneficial for me, because this project's only purpose is to demonstrate my skills as Blockchain and DApp developer.