Filecoin
Protocolos Put y Get
Context
Figure 7 appears at the end of Section 4.4 (Guarantees and Requirements) and presents the complete formal algorithm listings for the Put (storage) and Get (retrieval) protocols in the Filecoin DSN. It is the primary technical reference for how clients and miners execute the data exchange layer of the protocol, covering both the Market (order submission/matching) and Exchange (data transfer) sub-phases.
What This Figure Shows
The Put Protocol section defines AddOrders (submitting a transaction to the ledger and waiting for inclusion), MatchOrders (checking the Storage Market orderbook for compatible counterpart orders), SendPiece (client-side: identifying the miner, sending the piece, receiving a signed deal order, and validating it), and ReceivePiece (miner-side: verifying the bid order, storing the piece, creating and signing a deal order, and returning it). The Get Protocol section defines AddOrders (gossip-based, no ledger submission), MatchOrders (checking piece ID and price against the retrieval orderbook), SendPiece (miner-side: creating a deal order, setting up a micropayment channel, sending each data block with its Merkle path, and collecting signed receipts), and ReceivePiece (client-side: verifying the deal order, verifying each Merkle path against the expected root hash, and sending signed receipts as payment).
Significance
Figure 7 operationalizes the key architectural distinction between Storage and Retrieval Markets: storage orders are on-chain and binding (funds and space are locked), while retrieval orders are off-chain gossip (no upfront commitment), with fairness achieved via incremental micropayments and Merkle-path verification instead of trusted third parties. The use of Merkle paths for incremental retrieval verification is a direct application of content-addressing that ensures data integrity without requiring the client to have the full file first.
