Nimbus ETH2.0 Security Audit Request for Proposal

Introduction

We at Status would like to announce a Request for Proposals (RfP) for a new type of external security review of Nimbus, an ETH2.0 implementation in the Nim programming language. We expect this engagement to differ from typical time-boxed security audits in that we want to incentive the security community to focus attention on both the ETH2.0 development process and the Nim language itself (proxied through our implementation) over an extended period of time, in hopes of raising the bar of security across our entire codebase. Ideally this will encourage the security community to become more integrated into these projects, thus proactively increasing security and long-term success.

Status is an organization dedicated to providing an interface to web3. We build on all layers of the technology stack, from infrastructure development to user-facing decentralized applications, all of which culminates with the Status application. The Status application is a super-app combining a web3 browser, a cryptocurrency wallet and key management system, and a secure messaging network. For blockchain access, we leverage the Ethereum blockchain network to provide trustless decentralized application access, and various feature integration. For messaging, we leverage the Waku network, a fork of Ethereum's Whisper network, which is a gossip based, encrypted, ephemeral message passing protocol.

This article describes the Nimbus project in detail, the scope of the security assessment, the deliverables expected, and a suggested timeline.

This post also provides guidelines on vendor selection criteria and indemnification structure, along with detailed bidding instructions.

Project Description

Nimbus is a leading Ethereum 2.0 implementation developed using Nim, which prioritizes a low resource footprint and embedded use. We expect major deployments of ETH2.0 in embedded environments such as routers and infrastructure, as well as mobile consumption of ETH2.0 services - as such, we are developing Nimbus to be embedded in other applications, such as the Status mobile app, as well as being run as a standalone Beacon Chain node and validator client.

The Nim Beacon Chain project (NBC) forms a major component in a wider framework of web3 services being researched and developed by Status that also cover distributed, censorship-resistant storage and private communications.

Resources

• NBC - Main github repository for Beacon Chain project
• Project proposal - Initial project proposal, covering all areas of web3 including computation, storage and communication.
• Architectural overview - Architectural overview of main NBC components
• ETH2.0 spec - Ethereum 2 specification

The current focus of the development team is to implement and optimise the Ethereum 2.0 specification, available here. Ethereum 2.0 is to be shipped in three distinct phases:

Phase 0 - Beacon Chain: Introduction of Casper FFG, the Proof-of-Stake consensus mechanism used by Ethereum 2.0.
Phase 1 - Shard Chains: Deployment of shard chains (focusing on data availability, consensus and construction on the shard chain's data).
Phase 2 - Execution Environments: Introduction of state execution engines to allow for arbitrary smart contracts.

Security Assessment Scope

The scope of this security engagement includes the review, in stages, of the following Nimbus components:

Network core (leveraging the libp2p framework):
    Discovery protocol (discv5)
    Publish/Subscribe protocol (gossipsub)
    Ethereum 2 Request/Response protocol
    SSZ - (De)serialization & tree hashing
    Wire encryption
ETH2 Specification core:
    State transition logic
    Signature verification
    Epoch finalisation and justification
    Reward processing
    Eth1 data processing
    Fork choice logic
    Block processing and production
    Attestation processing and production
    Block synchronization
    Peer pool management
Validator core and user experience:
    Block/attestation signing
    Slash-prevention mechanisms
    RPC API
    Accounts management & key storage
    Command Line Interface (CLI)

The assessment will focus on identifying vulnerabilities that can lead to the following (non-exhaustive list):

Denial-of-service conditions
Remote code execution
Data integrity loss
Underflows and overflows
Consensus splits
Operations pool halt
Unspecified/unexpected client behaviour

The selected vendor(s) will be provided with specific Git commit hashes (one commit per relevant repository) at the start of the engagement, which will be the target of the assessment. Note that due to the length of the engagement, we expect changes to the codebase to be made over time.

Overall Engagement Description

We aim to have long lasting engagements with the security community at large. This is for many reasons. We would rather start to develop relationships that are not transactional in nature, but collaborative, as ETH2 is a collaborative project across the ecosystem. From a practical perspective, we expect the early part of the engagement to be broad as vendors familiarize themselves with the codebase, resulting in generally applicable best practices.

The entire process can be summarized as follows:

1. Broadcast: Status releases RfP (this post)
2. Gather: Vendors within the community submit one or more proposals detailing the level of effort on various focus areas, or, on the entire scope
3. Deliberate: Status coordinates internally to decide which proposal(s) are accepted, and crafts a unified plan based on proposal resources and desires.
4. Propose: Status announces a plan detailing vendor selections. This will include vendor assignments, scope, and  collaboration suggestions.
5. Commence: Vendor(s) accept and work begins

The proposed timeline of the working part of the engagement is a span of approximately 4 months, broken up into 3 "phases" of focus, or stages. Each phase is described by a single or collaborative vendor assessment, followed by a break for developer response and mitigation, followed by a review phase from the assessment team. Optionally, Status will then summarize findings and publish the results in a broadly digestable format, i.e.:

Each phase is expected to incorporate lessons learned from previous phases. In that light, it should be noted that the codebase may be changing up until the point of the beginning of the phase.

NOTES:

• * The summarizations are meant to both help the community understand the work that was done, as well as distill useful lessons that can be learned by other ETH2.0 implementation teams. This phase will overlap with the following phases as to not disrupt the on-going assessment.

Deliverables

• Github issues on the Github repository for every security concern found as per our recommended Github issue process we've outlined.

Status will provide a summarization report regarding the issues submitted during a given phase, subject to review by the respective vendor(s) before publication.

Vendors are welcome to submit proposals with alternative timelines, especially if they feel as though they can perform a satisfactory job in a similar timeframe, with the goal of finding a way to incorporate the security community into the ETH2.0 development process and establish long term relationships.

Furthermore, the Status team will be available at all times to answer questions and comments during the assessment period in order to expedite their work and minimize wasted time.

Indemnification and Fee Structure

Based on the timeline of this audit, the chosen vendor will be expected to submit 2 invoices

• a first invoice of 50% of the total engagement fee at the start of the engagement
• a second invoice of 50% of the total engagement fee at the end of the engagement, after the 2 day reviewing period and summary report has been delivered

The vendor will be given the option to be paid via bank transfer or with a carefully placed paper bag in a location chosen by us or in the following crypto-currencies (or Digital Tokens):

• Status Network Token (SNT)
• Ether (ETH)
• Dai (DAI)
• Bitcoin (BTC)

The value of Digital Token described under the agreement will be the value of that Digital Token in Fiat Money at NYSE closing time (4 PM EST) on the day prior to the due date as described at https://www.coingecko.com

Selection Criteria

The vendor selected by Status will have significant expertise in the areas necessary to meet the needs and requirements set forth in this RfP. Particularly:

Experience with reviewing software written in statically compiled programming languages (Nim/C/C++/Rust);
Experience with reviewing large codebases;
Experience with advanced cryptographic primitives such as BLS signatures;
Experience with distributed systems and blockchain technology;
Experience with low-level networking protocols;
Experience with using the Nim programming language in a security and performance critical context;

We welcome vendors to submit proposals based on partial expertise of the given list. Status will attempt to match vendors together on appropriate parts of the audit based on domain expertise.

Additional information, such as engagement team qualifications, CVs, and third party references, may be requested by Status.

The Status team is supported by compiler and langauge developers for the Nim language, and has several team members on board that have contributed to its development, and are ready to support the vendor.

Bidding Instructions

Upon reception of this Request for Proposal, vendors are expected to confirm receipt and intention to bid on the engagement.

A vendor should express their desire to either isolate their focus on a specific part of the codebase or particular phase, or be present throughout the entire engagement. Furthermore, a vendor may express their opinions on how they feel one should approach such a large codebase if it is not in line with this document's proposed methods. Status will take into consideration such opinions when deliberating on all received proposals.

A vendor should also detail their entrance requirements from Status, as well as specific areas they do not have significant expertise in. Status will use this information and attempt to provide appropriate entrance material for the engagement, as well as match vendors together to maximize required expertise within a given phase.

Proposals must be submitted by bidders before May 24th, 12 PM EST. Status will take 1 week to deliberate and respond to vendor(s).

Proposals must be sent in PDF format to the following email address: security@status.im

This PGP key can be used to encrypt the proposal (optional).

Vendors can request more information via email (security@status.im). Pre-bid meetings with vendors can also be arranged if required.

Conclusion

We at Status strongly believe in a lasting security culture, and understand its importance to the long-term success of Ethereum and the Nim programming language.

We are looking for sustainable relationships with the security community, and are actively looking for ways to include them into the Ethereum 2.0 development process. With the launch of Ethereum 2.0 being spread between several phases, we want to cultivate efficient communication between both groups. This is our first attempt at building this relationship and cultivating overall collaboration between Ethereum 2.0 developers and the security community, and we expect to continue and improve this process from the lessons learned within this experience.

Status is happy to answer any questions bidders may have. Bidders should feel free to send any queries/questions to the following email address: security@status.im.