LogoLogo
v2.x (Stable)
v2.x (Stable)
  • What is Boost?
  • Features
  • Components
    • boostd
      • Repository
      • GraphQL API
      • JSON-RPC API
      • SQLite metadata database
    • Local Index Directory
      • Index types
      • Dependencies
      • Initialisation
    • boostd-data
    • YugabyteDB
    • booster-http
    • booster-bitswap
    • libp2p Protocols
  • Hardware requirements
    • YugabyteDB
  • Installation
  • New Boost Setup
  • Configuration
    • UI Settings
    • HTTP Transfer limit
    • Deal Filters
    • Remote CommP
    • Legacy Deal configuration
    • HTTP indexer announcement
    • Manual Publish Storage Deal Message
  • Monitoring
    • Setting up a monitoring stack for Boost
  • Storing data on Filecoin
  • Retrieving data from Filecoin
    • HTTP retrieval
    • Advanced Configuration of booster-http
    • Bitswap retrieval
  • Backup and Restore
  • Tutorials
    • How to upgrade from Boost v1 to Boost v2
    • How to re-index unsealed pieces that are flagged by LID in Boost v2
    • How to upgrade from v2.0.0 to v2.1.0
    • How to upgrade from v2.1.x to v2.2.0
    • Start and stop Boost processes
    • How to store files with Boost on Filecoin
    • Using filters for storage and retrieval deals
    • Migrate from Lotus to Boost
    • How to onboard data using DDO deals
  • Troubleshooting
  • Experimental Features
    • FVM Contract Deals
    • Direct Deals
    • Data Segment Indexing
  • FAQ
  • Need help?
Powered by GitBook
On this page
Edit on GitHub
Export as PDF
  1. Components

boostd

This page details the Boost SP daemon - boostd

PreviousComponentsNextRepository

Last updated 2 years ago

The boostd executable runs as a daemon alongside a Lotus full node and Lotus miner. The daemon exposes a libp2p interface for storage and retrieval deals. It performs on-chain operations by making API calls to the Lotus node. The daemon hands off downloaded data to the Lotus miner for sealing via API calls to the Lotus miner.

boostd has a web interface for fund management and deal monitoring. The web interface is a React application that consumes a GraphQL interface exposed by the daemon.

Storage Deal Flow

The typical flow for a Storage Deal is:

  1. The Client puts funds in escrow with the Storage Market Actor on chain.

  2. The Client uploads a CAR file to a web server.

  3. The Client sends a storage deal proposal to Boost with the URL of the CAR file.

  4. Boost checks that the client has enough funds in escrow to pay for storing the file.

  5. Boost accepts the storage deal proposal.

  6. Boost downloads the CAR file from the web server.

  7. Boost publishes the deal on chain.

  8. The client checks that the deal was successfully published on chain.

Boost exposes a libp2p interface to listen for storage deal proposals from clients.

Boost communicates with the Lotus node over its JSON-RPC API for on-chain operations like checking client funds and publishing the deal.

Once the deal has been published, Boost hands off the downloaded file to lotus-miner for sealing.