Onboarding with "Kakarot Workshop Issues"

[danilowhk]

The idea of "Kakarot Workshop Issues" are issues that will be dedicated completely to Workshops/Onboarding, and an initial idea is to have 4 levels:
-Easy
-Medium
-Hard
-Super Sayajin Mode

(It is the model that LambdaClass used in their Workshop and I believe it was amazing!)

These issues should not have a major change on the current codebase, not urgent, but it is something that would be nice if implemented.

A lot of times, the biggest barrier for contributors, especially in their first PR/first contact, more than technical difficulties is how they feel about the project especially when they think "I can't do it", or "the code base is too complex" or "I am still a beginner". So the goal of "Kakarot Workshop Issues" is that by going through the experience of having their First PR Merged in Kakarot they will realize, that actually they can do it or is just a matter of time until they can if they try.
I believe "Kakarot Workshop Issues" is important not only for Kakarot, but for the entire Starknet Ecosystem, as what we want is not for them to be only confident in contributing to Kakarot, but any Open Source contribution to Starknet.

That being said, here are some ideas for what could be some Easy, Medium, Hard, and Super Sayajin Kakarot Workshop Issues:

Easy:

• Rename variables, add comments on a specific part of the code base, and do some easy refactoring/organization.

Medium:

• Add Extra tests for already existing opcodes

Hard:

• Refactoring of more complex parts of the code base

Super Sayajin:

• Implementations that are necessary for Kakarot but not urgent.

What do you guys think? Please share what would be possible Kakarot Workshop Issues and share it here, our first Workshop could be with the Basecamp and we can transform all the ideas into issues by then.

[TotalPizza]

Super Sayajin
(implementation is actually relatively easy/short, but it implies some more complex understanding of how transaction on ethereum work. You don't need to understand how rlp works but knowing how to get the gasLimit parameter from the rlp-decoded transaction might take a bit for newbies)

Verifying gasLimit in the EOA.
Any given transaction that is sent to the EOA via the Kakaort-RPC includes the gasLimit among other information (like the nonce or signature). The transaction information is first verified by the __validate__ function and if that did not revert/assert it is executed by the __execute__ function.
Inside of the validate function we should check whether the gasLimit provided by the caller is actually within the valid range. The valid range is: 21000 <= x <= 30000000.
It needs to be checked for both the legacy and default transaction type.
Looking at how the signature is currently validated should help in the implementation of this feature.

Resources:
https://ethereum.org/en/developers/docs/gas/
https://ethereum.org/en/developers/docs/transactions/
https://openethereum.github.io/Transactions-Queue

Optional follow up quest (Medium) --> for this feature, add a test to the unit tests that verifies that the transaction would be rejected when an invalid gasLimit is set. Once again looking at the existing signature validation check should help.

[TotalPizza]

We removed GasLimit, so this doesn't work anymore

[TotalPizza]

Easy

Some functions in the ./src/kakarot/eoa/library.cairo file are missing comments describing their functionality, parameters and return types.

Make sure you understand what is happening within these functions and add commentary above the function name (comments inside of the functions should not be required).

Use the Natspec style of commenting:
https://docs.soliditylang.org/en/v0.8.17/natspec-format.html

Looking at the commentary above the other functions in the relevant file should help you understand how the comments should be structured