Apply to Audit Polkadot's Runtime

Introduction

The Web3 Foundation (W3F) supports technologies and applications in the fields of the decentralized web, particularly those which utilize modern cryptographic methods to safeguard decentralization, to the benefit and for the stability of the Web3 ecosystem.

W3F has contracted Parity Technologies to develop the first implementation of the Polkadot Runtime. This implementation consists of a number of Runtime Modules as well as Runtime Macros that transform them into the actual Runtime Rust code. W3F is looking for auditors to develop a threat model as well as identify any potential security vulnerabilities in the Library as well as any of the Modules.

The Web3 Foundation will continue the work to secure software implementations related to Polkadot, this means that an additional goal of this audit is to identify potential long-term collaborators who are able to build up a comprehensive understanding of the protocol. We are looking for proposals which show potential for understanding of such long term support.

This RFP document sets out the bidding instructions, requirements and deliverables for auditors who wish to submit a proposal to undertake this contract.

Description of the Polkadot Runtime

The Polkadot Runtime determines the functionality of the blockchain state machine in Polkadot, logic such as transaction verification, balance transfers and governance are determined by it. This logic is represented by a Wasm blob, which is compiled from Rust code. The Runtime is composed of a collection of modules from the Substrate runtime module library (SRML), as well as Polkadot specific modules. These modules are written as Rust source code and processed through Rust macros which generate the expanded Rust code that compiles to Wasm.

The Polkadot Runtime Environment (PRE) is the outer shell of the Polkadot protocol. It handles the networking layer between the nodes in the network, the consensus logic and the execution of the Wasm Runtime. It will serve light clients and handle RPC requests. The first implementation of the PRE can be found in Substrate.

This audit will only cover the Polkadot Runtime and not the PRE.

Scope of the audit

The focus of this audit is the Runtime of Polkadot mostly composed of modules from the SRML. The audit should verify the logic of the modules and assess the framework for constructing the Wasm output.

Modules that are used in the Polkadot Runtime:

SRML Support:

• Macros used to compile Runtime Modules to expanded Rust code

Wasm build script

SRML Modules:

• Balances
• Consensus
• Council
• Democracy
• Executive
• Finality Tracker
• Grandpa
• Indices
• Session
• Staking
• Sudo
• System
• Timestamp

Polkadot Modules:

• Claims
• Curated Grandpa
• Parachains

The modules to be audited (listed above) shall be the latest version of the code located in the SRML and Polkadot Runtime repositories.

Threat model

For the scope of this audit we assume that underlying Polkadot Runtime Environment is solid and implemented in accordance with specification.

We also assume that the actual machine running the code is not compromised.

Under those assumptions, we’re interested in making sure that Polkadot Runtime doesn’t misbehave with any input conditions possible (paying most attention to the inputs which can be potentially under attackers’ control, i.e. transactions executed in the Runtime).

We can (non-exhaustively!) separate potential misbehaviors into two major classes: performing unauthorized actions and denial of service.

Performing unauthorized actions

The worst-case scenario in this category would be an attacker gaining control over the whole Runtime, for example by exploiting vulnerabilities in the Runtime upgrade module and forcing all the nodes to accept the compromised update. But the class itself is of course wider than that, and potential threats also include attacker being able to modify storage in a way which was not intended, bypass authorisation of other protected functions of the Runtime, violating invariants which are assumed to be true during Runtime invocation and so on.

Denial of service

This category covers any situation in which Polkadot Runtime ceases to execute blocks, be it because of putting the chain into illegal state with no recourse, provoking unbounded work (not necessary an infinite loop, just an unexpectedly heavy set of computations which might lead to block producer and consumer nodes “being late” for their other duties), or some other reasons.

Deliverables

The chosen auditor(s) shall supply W3F with an audit report of the PR as implemented in Substrate by Parity Technology. The final format and content of the audit report will evolve over the life of the audit. It is expected that the auditors work closely with Web3 Foundation and Parity Technologies during the audit.

• The audit report should focus on delivering an analysis and evaluation of the security of implementation of the above mentioned layers. Specifically we want to understand the threat model as well as specific issues that result from it.
• Ideally, the report follows in its sections the breakdown of the above-mentioned components, namely:
• Runtime Module Framework section
• Individual Module sections

Selection criteria

The selection of the auditor(s) is based on the received proposal as evaluated according to W3F’s own understanding. W3F may contact third parties to request references or request additional information from the bidder.

The following criteria will be taken into account when selecting the auditor(s). It is expected that proposals will include all of the information below. When experience is asked for, this applies to both the proposing auditing company or team as a whole, as well as the individual members of the team.

• Experience in auditing large codebases
• Experience with distributed systems and cryptography
• Experience with the Rust programming language
• Experience with auditing blockchain technology
• Any planned usage of subcontractors or other external assistance
• Expected timeline
• All-in cost of the audit, including a detailed breakdown of resources and expenses

Timeline and Process

Upon receipt of this document, bidders are requested to confirm their intention to attend a pre-bid call for clarification of questions (Zurich time).

Any timelines listed for the auditor activity are just a suggestion and may be reasonably extended within the proposal. Please note than any extensions to the final report deadline, needs to be agreed upon with W3F no later than 2 weeks prior to the final report deadline

Conclusion

We are looking to build long-term relationships with auditors who can work proactively with us on the security of Polkadot Runtime as well as other Web3 technologies.

If you are interested please send us an email to audit@web3.foundation with your proposal and we will reach out to you to arrange a conversation. When indicating your interest, please be sure to include all of the information requested in the Selection Criteria section above.