Update OPEN_PROBLEMS/DECENTRALIZED_DATA_DELIVERY_MARKETS.md

Co-authored-by: Jorge Soares <547492+jsoares@users.noreply.github.com>

Author: 2 people

OPEN_PROBLEMS/DECENTRALIZED_DATA_DELIVERY_MARKETS.md

@@ -236,7 +236,7 @@ The area of graph forming for Decentralised Data Delivery Markets revolves aroun
     *   every copy has a different “asking” price (defined by the cryptoeconomic model) and delivery latency, and
     *   every miner achieves different performance and has a different reputation profile.
 
-In order to achieve the above goals the system needs to have an architectural structure, that is, where do end-users connect (e.g., to a retrieval miner, or to a separate content resolution system), which entity in the architecture makes content resolution and request forwarding decisions and finally, which entity(ies) has(ve) the required knowledge to forward requests to the closest (to the requesting user) copy, _aka_ nearest replica routing.
+In order to achieve the above goals, we need to answer certain architectural questions: where do end-users connect (e.g., to a retrieval miner, or to a separate content resolution system), which entity in the architecture makes content resolution and request forwarding decisions and finally, which entity(ies) has(ve) the required knowledge to forward requests to the closest (to the requesting user) copy, _aka_ nearest replica routing.
 
 We generally consider that retrieval miners are relatively powerful devices with local storage dedicated to storing hot copies of the content, high uptime (close to zero churn) and ideally public IP (i.e., reachable from anywhere). The architecture should ideally be able to take advantage of storage in less-powerful and more ephemerally-connected end-user devices, such as laptops and mobile phones - this is discussed as a different area further down. Although not a strict requirement, this is what will make the decentralised storage network take the full benefit of planetary-scale unused storage.