Ethernaut project brainstorming and prioritization

Hello everybody!

Many of you have showed interest in contributing to our beloved Ethernaut project. Since we’re a few (@paulinablaszk, @scammi, @redragonx, @obernardovieira, @frederickalcantara) I think the best thing is to brainstorm what could be done and once we have a list of initiatives, start distributing tasks :slight_smile:

So, I’d start by mentioning:

  • Reviewing pull requests
  • Reviewing issues
  • Levels development
  • Writing walkthroughs or guides (this can be both step by step solutions or just reading material to get ready for the challenges)

what else can we do?


Hi, thanks for the message.
Defenetly good idea to start on PRs and issues.

Since I did a few levels of ethernaut recently (and I still have some to do), one of the things that didn’t felt too good was the fact that it’s still in solidity 0.4.x.

But this is urgent I think so.


Hi, I agree with @obernardovieira - updating to solidity 0.5 is a good idea.
I am during my game too so I can write some tips or guides to each level, but I am considering what form would be most useful (considering that several of them have already been created). Any suggestions?
I was also thinking about introducing guidelines for levels (from general to more detailed) which the player can “discover” in turn if necessary, but it costs him points (or something like that).

I like as well the idea of updating Ethernaut to ZeppelinOS (issue #94).


Depending on what kind of tips they are, you can create a “tip list” as a thing, maybe proposing changs to an existing guide or simply create your own.

This is an interesting approach, I’m personally not a fan of the whole points thing but I can see how it can help people. I really liked the “reading materia” idea (it think it was @scammi’s?), for you to read before jumping into the levels, to make sure you’re prepared.

Great, I just added it to the project’s board:

This is an important one! Why don’t you create the issue so I add it to the board?

Should we go through the issues and pick the ones we care about the most?

1 Like

+1 to porting to solidity > 0.5.0
Another easy task for anyone starting to contribute is to write a “setting up development environment” guide, as they go doing this themselves.


I just added @scammi and @paulinablaszk as collaborators on the main repository so you can work directly on the project board. Please assign yourself tasks (so we don’t step into each other’s feet) and make sure to move the issues through the kanban (to do / in progress / review / done) so we’re fully synced :slight_smile:


What I liked about crypto zombies is the idea that you are notified if you made an error or that you succeed. I like that aspect of it. I think there should be some overview on how to keep things secure. Like what Consensys has.

1 Like

I agree that “read before” material is a nice idea because if people want to learn (and I think that they mainly playEthernaut) they don’t usually look for ready-made solutions.
Personally, I can work on Solidity 0.5 or ZeppelinOS but maybe I will wait for others before assigning the tasks. @martriay do you have other suggestions about your workflow? (each team has its own rules and preferences and I would like to fit in well)


Unless @obernardovieira wants to tackle 0.5 (since it was his idea), I’d say we should start there. If he’s going to take it, @paulinablaszk you can go after migrating to zos (gigantic!).

As of the workflow, I’d say we can discover what works the best on the go :slight_smile:

The only thing I have to add is that we should have a thorough review system. I think having 1 collaborator reviewing every PR (even if it’s from another collaborator) will be enough. In the beginning maybe @ajsantander or I will be checking these reviews to make sure we’re respecting the original style of the project regarding code, wording and vision (this is, being hacky, presenting a challenge, giving few hints, etc).

We’ll know more about this whenever we see something we don’t like, then we will have a better idea of the underlying style we had in our heads :zap:

1 Like

One good thing about software (actually thanks to git) is that everything can be undone, so I’ll quote facebook in here (sorry): move fast and break things. We can undo them :slight_smile:

On a side note, this applies to code rather than memory, now we have Ethereum and other state-sharing computers which changes the paradigm a bit :stuck_out_tongue:


Hey, thanks.
I’ll love to work on the migration to 0.5, but I’ll be offline for the next five days, so maybe someone else can start it and then I’ll take another task, no worries.


Thanks for the heads up! Good luck and let us know if you’re up to help when you come back :slight_smile:

@paulinablaszk can you tackle 0.5 then?

1 Like


For now I’ll finish the translating language PR and review the rest of the PR’s in queue.
Right now I’m doing the final touches to the new level switch.


Yes, sure :slight_smile: As you’ve said zos is the “big thing” so it’ll be even better for me to start with solidity 0.5


Excellent! So, we have:

This is exciting, sounds like a plan :rocket:

@frederickalcantara you showed interest in joining the project as well, are you in?


@martriay thanks for the great motivation! Finally, you’ve pushed this project forward :slight_smile:


Sounds great. I would love to see more use of Ethernaut. It’s a great resource for learning about smart contract security. Plus it’s fun.


I’m still interested, sorry I’ve been busy the past few days.

1 Like

Wow. This is incredible! Thanks to @martriay and everyone involved in this!!!

Regarding the update to Solidity 0.5.x, keep in mind that this involves redeploying contracts, which means having new addresses for contracts. Every update of a level would have a new address for that matter, and http links to levels may break. Also, browser cache would no longer remember that a player has passed that level.

So our options are (in order of difficulty):

  1. We can just not care about this for now and simply update. It’s testnet anyway :man_shrugging:
  2. Modify ethernaut and factories to use create2 so we can keep addresses constant. This would also mean that base levels would need to be selfdestructible. This option is a quick and easy upgradeability option ideal for the situation I think, because it doesn’t matter if we kill contract state on upgrades. The main Ethernaut contract would not be upgradeable this way though.
  3. Make factories and levels upgradeable via create2 and Ethernaut upgradeable via zOS proxies.
  4. Make everything upgradeable with zOS proxies. This is of course the most powerful solution, but could be overkill.

Good question! I need a moment to analyze it…

In addition updating to Solidity 0.5 will be connected with:

  1. Problem with some levels for example level 2 “Fallout” (we have to change Fal1out function for the constructor).
  2. Need to update project dependencies - should it be a separate issue? (I have already changed some for example “zeppelin-solidity” to “openzeppelin-solidity”, but there will be a lot more)