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
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.
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).
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.
+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
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.
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
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
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
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
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.
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.
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):
We can just not care about this for now and simply update. It’s testnet anyway
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.
Make factories and levels upgradeable via create2 and Ethernaut upgradeable via zOS proxies.
Make everything upgradeable with zOS proxies. This is of course the most powerful solution, but could be overkill.
In addition updating to Solidity 0.5 will be connected with:
Problem with some levels for example level 2 “Fallout” (we have to change Fal1out function for the constructor).
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)
