So, we've finally released what is the first version of our Nim-based Ethereum 2 client to the wild - Nimbus - it's been a long, sometimes winding, but mostly fun road to get there.
To give you an idea, Ethereum 2 is a peer-to-peer network consisting of thousands of nodes that coordinate a shared state, and where thousands (roughly 70000+ at the time of writing) of stake-based votes are cast and disseminated to participants around the globe every few seconds to select a block that represents the head in a DAG or chain of blocks.
The application is built on top of libp2p (a peer-to-peer networking framework), BLS (elliptic curve cryptography scheme) and a number of other fun pieces - everything audited by multiple security firms to ensure the safe operation of the network together with 3 other implementations of the same specification.
All code goes trough review, CI and several staging environments before being released to users, to ensure consistency and quality - the graphs are actually quite pretty to watch - you can see the flow of blocks and votes, the peers connecting and disconnecting, etc etc across several versions - but the nicest thing of all is that everything is available as open-source using friendly licenses.
Based on this experience, we've written an auditor guide that goes over the features of Nim from a secure coding point of view - this guide however is somewhat focused on Nimbus itself and its architecture.
To complement it, we're now producing a slightly more general style guide that covers some of the things we've learned the past 3 years of working with Nim code - gotchas, common sources of bugs and security issues - things that often pop up in code reviews, specially with people new to the project - we will be publishing somewhere when it's ready, but until then, do enjoy the PR and see if there's anything we've gotten wrong or missed!
Happy to answer any questions as well about the process we use and some of the tradeoffs.
Adding the link to the Nim style guide because I did not found it in the first post.
And dropping a few comments...
For instance:
1.1. Language features
1.1.1. `import` a minimal set of modules using explicit paths.
1.1.2. `export` all modules whose types appear in public symbols of the current module.
1.1.3. Prefer specific imports.
1.1.4. Avoid include.
For instance: Why Annotate each module with a top-level {.push raises: [Defect].}?
In the previous example, not all readers will understand what this does...
For example, in the Import, export example, the reader can find:
1.1.5. Prefix modules imported from Nim standard library with `std/`.
1.1.6. Use full path name when importing "external" modules.
1.1.7. Use relative path when importing "local" dependencies.
This is very good read
Thanks!
name or a number
Good point - https://github.com/status-im/nim-style-guide/issues/2
Give explanations why.
Yes, that is indeed the main point of the pro/con section - it will expand over time.
Be didactic.
We're happy to take patches and issues for when this wasn't the case - ie many rules come with a deeper "Practical notes" section that go into more detail (in addition to the top-level explanation that just gives the guideline, for those that don't really care), but some things we've simply gotten used to - if there are any rules that are confusing, do let us know.
Give examples but don't add new rules in the code.
Yeah, there's room for improvement here - giving rules in the code gives them more of an informal air which is used for "small" things that perhaps aren't _that important but exist mainly to establish consistency.
readers should be able to comment/argument about a rule
this would be nice, but comes with increased maintenance costs to find software and hosting that supports it - for now, there are PR's and issue trackers to help, both of which we're monitoring.
Good feedback, thanks again.
Guide is now live:
https://status-im.github.io/nim-style-guide/
readers should be able to comment/argument about a rule
Added an "edit on github" button at least, where everyone's invited to submit PR's