Filecoin Docs
BasicsStorage providersNodesNetworksSmart contractsReference
  • Welcome to Filecoin Docs
  • Basics
    • What is Filecoin
      • Crypto-economics
      • Blockchain
      • Storage model
      • Storage market
      • Retrieval market
      • Programming on Filecoin
      • Networks
    • The blockchain
      • Actors
      • Addresses
      • Blocks and tipsets
      • Consensus
      • Drand
      • Proofs
    • Assets
      • The FIL token
      • Wallets
      • Metamask setup
      • Get FIL
      • Transfer FIL
    • Interplanetary consensus
    • How storage works
      • Filecoin plus
      • Storage onramps
      • Filecoin and IPFS
    • How retrieval works
      • Basic retrieval
      • Serving retrievals
      • Saturn
    • Project and community
      • Forums and FIPs
      • Filecoin compared to
      • Filecoin FAQs
      • Related projects
      • Social media
      • The Filecoin project
      • Ways to contribute
  • Storage providers
    • Basics
      • Quickstart guide
    • Filecoin economics
      • Storage proving
      • FIL collateral
      • Block rewards
      • Slashing
      • Committed capacity
    • Filecoin deals
      • Storage deals
      • Verified deals
      • Filecoin programs and tools
      • Snap deals
      • Charging for data
      • Auxiliary services
      • Return-on-investment
    • Architecture
      • Software components
      • Storage provider automation
      • Sealing pipeline
      • Sealing rate
      • Sealing-as-a-service
      • Network indexer
    • Infrastructure
      • Storage
      • Network
      • Backup and disaster recovery
      • Reference architectures
    • Skills
      • Linux
      • Network
      • Security
      • Storage
      • Sales
      • Industry
    • PDP
      • Prerequisites
      • Install & Run Lotus
      • Install & Run YugabyteDB
      • Install & Run Curio
      • Enable PDP
      • Use PDP
  • Nodes
    • Implementations
      • Lotus
      • Venus
    • Full-nodes
      • Pre-requisites
      • Basic setup
      • Node providers
    • Lite-nodes
      • Spin up a lite-node
  • Smart contracts
    • Fundamentals
      • The Filecoin Virtual Machine
      • Filecoin EVM runtime
      • ERC-20 quickstart
      • Roadmap
      • Support
      • FAQs
    • Filecoin EVM-runtime
      • Actor types
      • Address types
      • FILForwarder
      • Difference with Ethereum
      • How gas works
      • Precompiles
    • Programmatic storage
      • Aggregated deal-making
      • Direct deal-making
      • Cross-Chain Data Bridge(CCDB)
      • Data replication, renewal and repair (RaaS)
      • RaaS interfaces
    • Developing contracts
      • Get test tokens
      • Remix
      • Hardhat
      • Foundry
      • Solidity libraries
      • Call built-in actors
      • Filecoin.sol
      • Direct deal-making with Client contract
      • Using RaaS
      • Verify a contract
      • Best practices
    • Advanced
      • Wrapped FIL
      • Oracles
      • Multicall
      • Multisig
      • FEVM Indexers
      • Cross-chain bridges
      • Aggregated deal-making
      • Contract automation
      • Relay
  • Networks
    • Mainnet
      • Explorers
      • RPCs
      • Network performance
    • Calibration
      • Explorers
      • RPCs
    • Local testnet
      • Get test tokens
    • Deprecated networks
  • Reference
    • General
      • Glossary
      • Specifications
      • Tools
    • Exchanges
      • Exchange integration
    • Built-in actors
      • Protocol API
      • Filecoin.sol
    • JSON-RPC
      • Auth
      • Chain
      • Client
      • Create
      • Eth
      • Gas
      • I
      • Log
      • Market
      • Miner
      • Mpool
      • Msig
      • Net
      • Node
      • Paych
      • Raft
      • Start
      • State
      • Sync
      • Wallet
      • Web3
  • Builder Cookbook
    • Overview
    • Table of Contents
    • Data Storage
      • Store Data
      • Retrieve Data
      • Privacy & Access Control
    • dApps
      • Chain-Data Query
      • Oracles
      • Cross-Chain Bridges
      • Decentralized Database
Powered by GitBook
LogoLogo

Basics

  • Overview
  • Crypto-economics
  • Storage model
  • Reference

Developers

  • The FVM
  • EVM-runtime
  • Quickstart
  • Transfer FIL

Contact

  • GitHub
  • Slack
  • Twitter
On this page
  • Self-hosted RaaS
  • In the example of replication:
  • In the example of renewal:
  • In the example of repair
  • Aggregator-hosted RaaS

Was this helpful?

Edit on GitHub
Export as PDF
  1. Smart contracts
  2. Programmatic storage

RaaS interfaces

Specifications for RaaS interfaces.

RaaS has a base and full interface to enable replication, renew and repair of storage deals.

Self-hosted RaaS

RaaS refers to replication, renewal and repair as a service, for data stored in storage deals on Filecoin. Developers can leverage the self-hosted RaaS to provide RaaS features, within their storage solution, using the RaaS Starter Kit.

Self-hosted RaaS requires 4 components:

  • The Client who has data to upload

  • An Aggregator platform (a type of storage solution) that receives the Client’s data and makes a storage deal on Filecoin

  • The RaaS node, hosted by the developer, that checks if the storage deal requires replication, renewal and/or repair

  • The RaaS DealStatus smart contract that the RaaS node executes checks with

In the example of replication:

  1. The client generates a CID for the data and requests the RaaS node to store data.

  2. The RaaS node takes the client’s data and makes the storage deal onto Filecoin.

  3. The client registers a replication job to the RaaS node and defines the number of replicas of their data to store, by calling the /register_jobs API on the RaaS node (e.g. “This data needs to have a minimum of 10 copies on the network”).

  4. The RaaS node periodically checks the client data’s CID for its deal status on Filecoin.

    • The RaaS node requests deal status with the DealStatus smart contract, via getActiveDeals(CID) and checks if the client’s data is stored with the accurate number of replicas.

    • The DealStatus smart contract returns the information of active deals to the RaaS node.

  5. If the number of replicas does not match the client’s requirements, the RaaS node is notified.

  6. The RaaS node fetches the data via its CID and resubmit a request to create new storage deals (repeat step 2).

  7. When the client requests for retrieval of data, it queries the RaaS node, which will fetch the data from the storage provider on Filecoin or provide an IPFS pinned copy (depends on how RaaS node is setup to store the data).

In the example of renewal:

  1. The client generates a CID for the data and requests the RaaS node to store data.

  2. The RaaS node takes the client’s data and makes the storage deal onto Filecoin.

  3. The client registers a renewal job to the RaaS node and defines the renewal threshold for the data’s storage deal, by calling the /register_jobs API on the RaaS node (e.g. renew storage deals that are 1 month away from expiry).

  4. The RaaS node periodically checks the client data’s CID for its deal status on Filecoin.

    • The RaaS node requests deal status with the DealStatus smart contract, via getExpiringDeals(CID) and checks if any of its active deals is expiring.

    • The DealStatus smart contract returns the information of expiring deals to the RaaS node.

  5. If deals with the client’s data are expiring, the RaaS node is notified.

  6. The RaaS node fetches the data via its CID and resubmit a request to create new storage deals (repeat step 2).

  7. When the client requests for retrieval of data, it queries the RaaS node, which will fetch the data from the storage provider on Filecoin or provide an IPFS pinned copy (depends on how RaaS node is setup to store the data).

In the example of repair

  1. The client generates a CID for the data and requests the RaaS node to store data.

  2. The RaaS node takes the client’s data and makes the storage deal onto Filecoin.

  3. The client registers a repair job to the RaaS node and defines the repair threshold for the data’s storage deal, by calling the /register_jobs API on the RaaS node (e.g. “this deal needs repairing if it is not proven active for X epochs”).

  4. If the deal ID and corresponding deal sector are not being actively proven for X epochs, the deal will require repairing.

  5. The RaaS node fetches the data via its CID and resubmit a request to create new storage deals (repeat step 2).

Aggregator-hosted RaaS

PreviousData replication, renewal and repair (RaaS)NextDeveloping contracts

Last updated 6 months ago

Was this helpful?

The RaaS node periodically checks with , if the deal ID and corresponding miner, is actively being proven by the miner on Filecoin. The node calls StateMarketStorageDeal, with provided deal and miner IDs.

Check out the to build your own RaaS interface.

The aggregator-hosted RaaS refers to a solution that requires an aggregator to host all the components of RaaS and provides a seamless interface to the client. is the first FVM project to provide an aggregator-hosted RaaS, via its SDK.

Lotus
RaaS starter kit
Lighthouse.storage
Was this page helpful?