search

filecoin-project / devgrants

👟 Apply for a Filecoin devgrant. Help build the Filecoin ecosystem!
Other
377 stars 308 forks source link

go-nitro Hardening #1508

Closed geoknee closed 11 months ago

geoknee commented 1 year ago

Open grant proposal: go-nitro Hardening

Name of Project: go-nitro Hardening

Proposal Category: integration-adoption

Proposer: @geoknee

(Optional) Technical Sponsor: @patrickwoodhead

Do you agree to open source all work you do on behalf of this RFP and dual-license under MIT or APACHE2 licenses?: Yes

Project Description

The ultimate goal of the go-nitro project is to integrate our flavour of state channel micropayments with the Filecoin retrieval market — be that directly with storage providers and/or secondary services such as Saturn. Before that can happen, we need to de-risk integrations such as with Lotus (a critical piece of Filecoin infrastructure controlling real funds) by comprehensively handling sad-path scenarios.

This proposal builds on the work completed during previous go-nitro grants https://github.com/filecoin-project/devgrants/issues/348, https://github.com/filecoin-project/devgrants/issues/936. The aim of this follow-on grant is

To shore up a comprehensive set of security guarantees offered to the user by the go-nitro state channel network client. This includes allowing the software to gracefully cope with various “sad paths” including: unexpected loss of power, as well as inactive and malicious counterparties.

The guarantee offered will be: “your go-nitro client will ensure that, as long as you remain sufficiently online and are able to submit blockchain transactions, you will be able to recover your funds in a finite amount of time irrespective of the actions of others. Moreover, go-nitro will help you do this efficiently without wasting gas fees”.

The grant is proposed to START on 24 April 2022. The deliverable dates are based on an estimate of the scale of the work (in developer days) and the number of developers assigned to that milestone.

Value

The importance of using multi-hop payments in the Filecoin retrieval market is clearly laid out in the retrieval market roadmap. Multihop channels leverage existing channels between peers in a payment network, and do not require new connections to be setup on chain. Virtual channel constructions (Nitro protocol’s killer feature) offer a key advantage over the HTLC multihop construct present (but unused) in Filecoin payment channels; once Alice & Bob construct a virtual channel through an intermediary Ingrid, Alice can pay Bob without involvement from Ingrid. We’ve proved out the “happy path” of virtual channels in our previous grants.

Virtual channels are safe by construction, but only if users and intermediaries have the software to help them recover from things going wrong. Therefore the value of this grant will be to implement new features and off-chain protocols to allow users to recover their funds in the case of a loss of power, data or communications — by falling back to transacting on the blockchain. Even beyond these unhappy cases, we will build a “watchtower” module to protect users from a narrow range of anticipated malicious activity by counterparties. We will to demonstrate these capabilities in our testing environment.

The risk of not having these functionalities built out is severe, and includes situations where funds locked in the state channel network could be stolen or double-spent.

We have designed our core protocol and engineering roadmap with this body of work in mind, so we perceive there to be a relatively low risk from the point of view of successfully implementing the grant. For more information please see the Sad path part of our docs website.

Deliverables

  1. Implementing a durable store for valuable off-chain data. go-nitro will be able to recover from a loss of power on the machine it runs on.

  2. Adding a “re-sync” module. go-nitro will be able to recover from dropped messages.

  3. Adding a “challenge” module. go-nitro will be able to recover from long-term peer inactivity.

  4. Adding a “watchtower” module. go-nitro will be able to recover from peer malice / arbitrary misbehaviour.

  5. Subjecting on and off chain components to an internal security audit. The go-nitro will undergo a thorough code review, with the results published on our docs website.

Development Roadmap

1. Implementing a durable store

In state/payment channel protocols, funds are locked on chain and can only be unlocked with data held by off-chain parties. go-nitro currently has only a non-durable store for off chain messages, which we call the MemStore. This means that closing the process which runs go-nitro (as could happen during a loss of power or system crash, or simply by the user shutting down their computer) results in data loss and therefore the potential for loss of funds.

Deliverables:

  1. A store implementation which replaces the existing MemStore.
  2. An integration test showing the go-nitro client can be restarted at any moment and
    • continue running as usual (e.g. closing a channel which was opened before the restart).
    • suffer no loss of funds
  3. Optimizations to reduce the footprint of the store on disk, including reducing the storage of unnecessary data.
  4. Documentation explaining configuration of this new store, including a discussion of risk / performance tradeoffs . For example, writing some data to the store less frequently in order to speed up protocol completion. We will include performance reports generated through our testground infrastructure.

We will aim to complete this milestone by START + (4 weeks) = May 22nd 2023

This milestone will be owned by @lalexgap.

Unknowns:

  1. How do we deal with or prevent a corrupt store?
  2. How to migrate existing stores following a change in DB schema?

2. Re-sync module

Even with a durable store, it is possible for clients to become “out of sync”. In this context, that means that go-nitro peers are still online, still wishing to cooperate but unable to due to corrupt or missing data. That might be due to an imperfectly durable store, an imperfect messaging transport or a short period of dropped network access. The re-sync module will serve as the first step to try and resolve the situation and get off chain protocols going again.

Deliverables:

  1. A module for re-synchronizing go-nitro clients who have suffered from data loss. It will consist of a protocol for requesting latest information from peers and kickstarting any protocols that may have stalled.
  2. An integration test using a faulty message service or other mechanism to put clients in the bad situation described above; and which asserts on the clients resuming off chain operation after some time.

We will aim to complete this milestone by START + (6 weeks) = June 5th 2023

This milestone will be owned by @kerzhner.

3. Challenge module

In the current version of go-nitro peer inactivity is not detected and results in funds being locked in a channel. We will fix this so that after some timeout or user signal, go-nitro kicks into action to recover funds on chain.

Importantly, we will optimize for a threat model which assumes it is much more likely that a virtual channel peer would become inactive than it is for an intermediary. Intermediaries have higher incentives to stay online (e.g. their reputation) , and will likely run in data centers with high uptime. Clients will use their good relationship with their intermediary to reduce the amount of on-chain transactions required to recover.

Deliverables:

  1. A new off-chain protocol (or modification to an existing off-chain protocol) which automatically detects inactivity according to some configuration, and then recovers money (through a combination of on and off chain actions). In particular, “retired” virtual channels should be finalized on chain and defunded off chain.
  2. An integration test running in our testground environment which “kills” an end-user node at an opportune moment, and shows all other parties recovering their funds in a finite amount of time

We will aim to complete this milestone by START + (8 weeks) = 19th June 2023

This milestone will be owned by @geoknee.

Unknowns:

4. Watchtower module

The on-chain challenge method (and associated go-nitro module in Milestone 3) gives power to participants to “take each other to court”.

This is an important protection, but one that invites malicious / false claims. Although the protocol will swiftly reject any challenge that does not have sufficient “support” — for example, a unanimous round of signatures from all parties — there is still a risk. A malicious or faulty peer can submit stale challenges (meaning for a “supported state” which has been superseded by more recent agreements) and thereby lay claim to funds “already spent” off-chain.

We will enhance the go-nitro client to detect challenges on chain and respond with a proof of the newer agreement. This will lead to the stale challenge being cancelled (”thrown out of court”).

Deliverables:

  1. A new protocol defend which is spawned automatically by go-nitro when:
    1. a challenge goes on chain
    2. it was not generated by this client
    3. it risks an unfavourable outcome finalizing (that is to say, I have the ability to challenge with a more favourable outcome).
  2. An integration test running in testground which shows a go-nitro client responding appropriately to a malicious challenge

We will aim to complete this milestone by START + (4 weeks) = May 22nd 2023

This milestone will be owned by @lalexgap.

5. Internal audit

We want to increase the confidence we have in both our abstract protocol and in our implementation of it. So we will put what we have done through some of the following tests:

Deliverables:

  1. An internal audit of our solidity codebase and public writeup.
  2. An internal audit of our Go codebase and public writeup.

The audits may make use of tools such as MythX and Pyrometer. We will make the most of our good relationship with the Consensys Diligence team and the results (report available on demand) of a full external audit they performed for us on an older implementation of our protocol.

We will aim to complete this milestone by START + (8 weeks) = 3 July 2023

This milestone will be owned by @niloCK.

Total Budget Requested

M1: 20 developer days

M2: 30 developer days

M3: 40 developer days

M4: 20 developer days

M5: 40 developer days

Total: 150 developer days

A developer day is costed at our usual rate (see previous grants).

Maintenance and Upgrade Plans

Team

Team Members

George Knee @geoknee

Colin Kennedy @nilock

Alex Gap @lalexgap

Mike Kerzhner @kerzhner

Team Website

Magmo Website

Relevant Experience

Collectively, Magmo has more than 15 years of experience thinking about state channels! As mentioned above, we successfully shipped a virtual funding protocol implementation in Typescript (powering Web3Torrent) and have already successfully built out most of our Golang implementation in a previous Filecoin Grant. We have some experience building some of these features into previous versions of our software (in other languages). We also have experience in stress testing our protocol for security — see https://blog.statechannels.org/breaking-state-channels/ ; as well as smart contract audits and fuzzing campaigns.

Our team has a healthy mix of academic backgrounds as well as software engineering backgrounds. We've successfully delivered two Open Grants with the Filecoin Foundation, and have multiple touchpoints with the wider Protocol Labs network (Filecoin Virtual Machine Early Builder Cohort members, libp2p users, testground users and contributors).

Team code repositories

https://github.com/statechannels

ErinOCon commented 1 year ago

HI @geoknee, thank you for your patience! We have an interest in moving forward with this proposal. Can you confirm the grant total required to complete this work?

geoknee commented 1 year ago

That's great to hear @ErinOCon! I have sent you the total via slack.

ErinOCon commented 11 months ago

Hi @geoknee, I have closed this item as the proposal is no longer under consideration. Should you have questions for our team in the future, please feel welcome to connect at grants@fil.org.