Project Title: New Full Tutorial for Near in Rust.
One-liner: Tutorial Repository for developing Near Contracts in Rust
Project Summary: : There are many great tutorials about creating NEAR contracts in Rust. This project isn’t intended to be a replacement to any of those. Instead, it will be detailed examples about the features of Rust using NEAR contracts. Several times when the compiler gives an error, a new developer may feel compelled to just try making changes until the error go away.
This tutorial will show all possible implementations for all kinds of features in rust. Including ownership, modules, traits, generics, enums and so on. That way it can work as reference for aspiring rustaceans.
Project Members: Lucas Lemos, Matias Wald
Period: May 01 → May 31
Extra : Project is written in Brazilian Portuguese. Translations to English and Spanish are also being made by Matias Wald.
The following list are the results obtained by me:
Week 13
- I gave Matias around 2000 lines of tutorial to translate last week. I’m letting the github repository still as I make the latest lessons locally. Lesson 6-3 is almost done though. It’s easier to organize both of our changes when we deliver in big packages.
- Lesson 6-3 explains what the ‘?’ operator does. It has a function that simulates some random computation. Something similar to “increase a counter 500-20000 times according to a random value” . The function will consume gas in the process. Calculate the remaining available gas . Then return most of it back to the caller .
- It’s a very small example. But explains some useful things: How to organize error management in a clean way, and how to control computing costs .
- Studying all the changes that near-sdk-rs 4.0 full release will bring. It will be released next month. So will only update the tutorials by then.
- Also was studying ways to optimize compile times in web-assembly projects . Had an idea for a new possible grant project. Front-end languages like svelte , react and vue are optimized for Web-2 . It isn’t the best option for Web-3. So what if we created a front-end language designed for the blockchain? It’s more of a research idea at the moment. But if we use the latest updates to browser and web-assembly development. This could be a front-end language that is cheaper to maintain, easier to share, easier to develop and way more effective than any front-end language that came during the Web-2 era.
- I would need a working prototype to show what I mean about the possible grant project. It might fail in the end. But it’s worth the attempt… I think.
- I still intend to make Youtube / Odysee video classes. My voice is not loud enough for good quality classes. So maybe I should use text-to-speech instead.
- This saturday I gave support to a fellow developer on the subject of rust smart contracts. He has a grant project. Was in Near group, but wasn’t in Near University. So, after the lesson, I suggested him joining for Near NCD and going for Office Hours for both Near Discord and Near University discord groups. Won’t say his name because I forgot to ask his permission. But if he finds this report, wish him the best.
Edit: Changed my mind from using text-to-speech in the course.
Edit2: Changed my mind about lesson 6-3. A useful example is better. So instead it will be a smart contract for a game. It creates sub-accounts for each player. The main smart contract holds data about all games. Each sub-account holds data about each player, and represents the runtime for each player. No player can directly call their sub-account. Instead they will be redirected from the main account by receiving a promise.
Week 14
- Studied a lot about cryptography standards and Zero Knowledge Proofs for Rust.
- The lesson 6-3 will be a prototype for a rogue-like game. Not only it will explain escaping errors in Rust. But could also be used for developing production level games in the blockchain.
- A rogue-like is a genre of games similar to the original “Rogue” from 1980. In summary, it’s a game where the character runs on several small, randomly generated levels. The character gets randomly generated items, and randomly generated obstacles. There are several games of this style made up to this day. One highly well received is “Hades”, from Super Giant Games, with 173.215 steam reviews of today, 98% of them are positive.
- This prototype is going to be very simple. It won’t have a game for real. Only the back-end of a game. Will be composed by:
- Creating and accessing a user account;
- Creating and checking characters;
- Loading a game stage;
- Validating the match after it is done;
- Experience rewards for the characters after they have completed a match;
- A high score system;
- As mentioned above, a user loads a stage for a character, plays the stage in the browser, then send the report to the blockchain again for validation. The need for validation exists to make it harder to cheat on the game.
- For validation the game simply returns a replay of the match. Each stage should have a limit time (like 3 to 5 minutes) to avoid high computing costs. The replay has information on everything that happened during the match. The key for validation is for it to be as low-cost as possible.
- Low cost validation is possible with good planning. A character can only do one thing at a time. If character is standing still, it is still standing still for that time. If a character attacks, the character will be doing that animation for that specific time (like 0.5 seconds). It is possible to make a low cost validation report that way.
- One of the important things about validation is to avoid cheating. People could send reports of other players. They could use software to simulate the game and return the best result possible. The reason for validation is not to stop people from cheating. But to make it way harder to do so.
- To stop people from simulating the game and sending several replays in a low spam of time. We could have a limitation on the time of the contract. If the match was loaded now, and the replay is completed in 1 minute, there’s no way the report is going to be sent in less than 1 minute.
- To stop sending replays of others. We could make the smart contract generate a unique match for each player (some kind of hashing in the random seed maybe) at each time. That way we know that the match is unique and can’t be replicated.
- Still unsure how the final version of the project is going to be.
Week 15
- “near-sdk-rs” “4.0.0” was released. Studied the changes from “3.1.0”.
- Applied the changes to lesson 6-3, thanks to the new macro
#[handle_result], the functions are looking so much more clean!
Week 16
- Finished lesson-6-3 implementation for almost everything. But still need to implement match generation and match validation.
- Pushed the latest version to github. Link:
https://github.com/On0n0k1/Tutorial_NEAR_Rust/tree/main/PT-BR/lesson_6_enums/lesson_6_3_game_score. - Started a discussion in near-sdk-rs github asking if it would be a good idea if I made loom videos explaining the implementation of near-sdk-rs examples. They liked the idea. So I will start making the loom videos next week.