Penetration Test Report (Consensys): orchid audit 2019 10

Orchid Network Protocol Audit
1 Summary Date November 2019
2 Audit Scope
Lead Auditor Gonçalo Sá
3 System Overview
Co-auditors Steve Marx
4 Key Observations/Recommendations
5 Security Specication
5.1 Actors
5.2 Trust Model
5.3 Important Security Properties
6 Issues
6.1 Staking node can be inappropriately removed from the tree Critical ✓ Fixed
6.2 Veriers need to be pure, but it’s very dicult to validate pureness Medium
✓ Fixed
6.3 Simplify the logic in OrchidDirectory.pull() Medium ✓ Fixed
6.4 Remove unnecessary address payable Minor Won't Fix
6.5 Use consistent staker , stakee ordering in OrchidDirectory Minor
✓ Fixed
6.6 Use more descriptive function and variable names Minor Won't Fix
6.7 In OrchidDirectory.step() and OrchidDirectory.lift() , use a signed
amount Minor Won't Fix
6.8 Document that math in OrchidDirectory assumes a maximum number of
tokens Minor ✓ Fixed
6.9 Unneeded named return parameter Minor ✓ Fixed
6.10 Improve function visibility Minor ✓ Fixed
7 Tool-Based Analysis
7.1 MythX
7.2 Ethlint
7.3 Surya
8 Sūrya’s Description Report
8.1 Files Description Table
8.2 Contracts Description Table
8.3 Legend
Appendix 1 - Disclosure
1 Summary
ConsenSys Diligence conducted a security audit on Orchid Labs’ network protocol, more
specically, the Ethereum smart contracts that are part of the bigger network protocol
codebase.
Orchid Labs was founded with a mission to create a more open and more accessible
internet. As part of this quest they created the Orchid network protocol, a truly
decentralized VPN service.
The way the Orchid network achieves true decentralization is by allowing anyone to join the
network as a bandwidth provider and anyone to use the service as an end user. This
permissionless environment is achievable with the usage of programmatic, probabilistic
micropayments on top of Ethereum, the focus of this audit.
2 Audit Scope
This audit covered the following les:
File SHA-1 hash
contracts/curator.sol 5ea6c8374cec289bcf4dfe1adb3bb157ca9bab74
contracts/directory.sol 811ab3b049d570c4236ee965d76ed1a9f5cb929e
contracts/location.sol 1ea56960f41ca3a299c4fd35fab9ef1fdd494d5b
contracts/lottery.sol e63f3c86b3abba57d0a7e3ca36436bfee4d9ac1b
contracts/token.sol faf15f117ac160641adfe56c2a01ad14bff931f3
The audit activities can be grouped into the following three broad categories:
1. Security: Identifying security related issues within the contract.
2. Architecture: Evaluating the system architecture through the lens of established
smart contract best practices.
3. Code quality: A full review of the contract source code. The primary areas of focus
include:
Correctness
Readability
Scalability
Code complexity
Quality of test coverage
3 System Overview
Orchid network is comprised of two main on-chain components, OrchidDirectory and
OrchidLottery . They both play important roles in setting up the proper incentives for the
correct functioning of the bandwidth market of the VPN product.
OrchidDirectory keeps track of staked OXT tokens (Orchid’s native token). The staked
amounts are held in a binary tree that allows for easy weighted random selection by
clients. Clients then purchase bandwidth from the selected stakee.
OrchidLottery is an implementation of probabilistic micropayments. These are used to
stream payments to bandwidth providers.
These two components are completely independent of each other and meant to be used
for the VPN client in different stages of the product usage.
A rough outline of the usage ow pertaining to these on-chain components is as follows:
1. The VPN client starts by engaging with an Ethereum client that runs the selection
routine for the nodes by running code present in OrchidDirectory . This step can
remain fully trustless by asking the Ethereum client (which may be untrusted) for
merkle proofs of the selected storage blocks (and the blocks themselves). This
effectively makes OrchidDirectory.scan() , which performs the random weighted
selection, more of a reference implementation than a fundamental part of the staking
infrastructure.
2. After the trac route is set up, clients need to be able to pay for packets of data as
they’re being forwarded. This requires a payment system that enables low-cost
micropayments. This is made possible (i.e., trustlessly enforced) by the
OrchidLottery smart contract, a probabilistic micropayments implementation.
OrchidLottery holds the end user’s funds that are meant to be disbursed to
bandwidth providers, as well as an escrow amount to be burned as a penalty in the
case of insucient available payment funds.
A probabilistic micropayment is a message, signed by the payer, that behaves very much
like a lottery ticket. It entitles the recipient of the message to a possible payment of a
certain amount with a given probability. This payment is enforced on-chain. Although each
payment is probabilistic, over a large number of such payments, the actual amount paid
trends towards the expected value.
Creating these probabilistic micropayments is done oine and is computationally
inexpensive, so it can be used to pay for a continuous stream of packets without disruption
or the need to wait for on-chain conrmations.
4 Key Observations/Recommendations
The usage of the Ethereum blockchain within the Orchid network protocol is an
exceptional example of decentralized coordination with on-chain enforcement. 
The formal modeling of Orchid’s network market in the presented whitepaper is
impressively thorough and shows the amount of consideration and thought that went
into the product planning.
The code lacks detailed documentation. The whitepaper explains the algorithms at a
high level, but there is no documentation that explains the code itself. A good start
would be clear variable and function names as well as explanatory code comments.
A good test suite enables the early suppression of bugs and protection against future
bugs introduced by composability, i.e., adding new features to the code that breaks
some security assumption of a previously written section. The codebase is lacking in
tests.
Good code coverage helps immensely to catch control ow errors. While high code
coverage gives no guarantees of algorithmic correctness, a lack of coverage usually
allows for control ow bugs to exist. Two issues found during the audit would have
been discovered during development by measuring code coverage. The Diligence
team recommends integrating a code coverage tool and achieving 100% code
coverage.
5 Security Specication
This section describes, from a security perspective, the expected behavior of the system
under audit. It is not a substitute for documentation. The purpose of this section is to
identify specic security properties that were validated by the audit team.
5.1 Actors
The relevant actors are as follows:
VPN users – Users nd providers via the directory and purchase bandwidth from
those providers via micropayments.
Bandwidth providers – Providers are advertised in the directory and sell bandwidth via
micropayments.
Stakers – To mitigate certain kinds of attacks, the VPN software prefers bandwidth
providers with more Orchid tokens (OXT) at stake. Stakers stake their tokens to
increase the likelihood that a given bandwidth provider will be selected.
Micropayment funders – Anyone can establish a fund for micropayments.
Micropayment signers – Signers authorize micropayments. There are potentially
many signers for a given fund.
Orchid – Orchid itself deploys the smart contracts but retains no special privileges.
5.2 Trust Model
In any smart contract system, it’s important to identify what trust is expected/required
between various actors.
None of the participants need to trust Orchid because Orchid retains no special
privileges after contract deployment.
A micropayment funder authorizes certain signers to act on their behalf, and those
signers must be trusted by the funder to spend up to the total amount in the fund.
Users and bandwidth providers need to trust each other very little. The risk for