DDN Fundamentals
This page provides an overview of Decentralized Distribution Networks associated with SHARE.
A DDN (Decentralized Distribution Network) is very similar to a CDN. It is a layer on top of the traditional notion of a Content Delivery Network that comprises a collection of stateless microservices. These services are responsible for maintaining access control for the underlying CDN. Note that a DDN is a collection of endpoints, and not a single endpoint instance. These endpoints each interact with various blockchains and are largely chain agnostic by way of injection of the chain ID at request time (e.g. the chain ID and cryptographic signature of the caller are included in the HTTPS request). Instead of pointing to a CDN or IPFS gateway for content (e.g. the image, song or video that your contract maps to) each PFA smart contract points to a DDN endpoint. This is how SHARE PFAs conditionally render content, while still adhering to the ERC-721 specification.
DDN endpoints are intentionally lightweight and therefore work well with serverless architectures, meaning anyone can package the code and run their own instance of a DDN endpoint or fleet. DDN endpoints still read encrypted content bytes from persistent storage such as a CDN or IPFS, but the bytes they stream to consumer facing applications are dependent on the state of the associated PFA contract on a blockchain. Specifically, they depend on the presence and block timestamp of access grants and licenses recorded on chain within the PFA.
This renders the protocol decentralized by a multi-cloud strategy. An off-the-shelf, SHARE provided DDN microservice endpoint may be selected for contracts, and there's nothing preventing anyone from packaging the DDN code and running it in a different Cloud, or on their own machine. There's no interruption to the contract or to end users, as owners can update the contract to point to a new DDN endpoint at any time. For example, this function on PFA smart contracts can be called by the owner at any time to switch service providers:
oss/PFAUnit.sol at 0e2c5e132ae3d824eb4e344c53858faee1583d57 · formless-eng/oss
GitHub
SHARE PFA mutable tokenURI which maps to DDN of choice.
The DDN interface is an HTTPS interface:
get
https://share-ddn.formless.xyz
/v1
ERC-721 conditional metadata rendering using on-chain contract state.
curl https://share-ddn-micro.formless.xyz/v1?contractAddress=0x8FB6F45E1D5D237932C0CB4CB7E3DEE95530954E\&networkId=80001
In the request above, the blockchain address 0xD433e00E15aB2B2CBFb451a8E73946f14fD80B2C and associated signature can be sent to a DDN endpoint, which is the
tokenURI of the PFA contract. Since no transaction was sent to the corresponding PFA at address 0x8FB6F45E1D5D237932C0CB4CB7E3DEE95530954E for access, the DDN returned the ERC-721 compliant metadata associated with a preview of the content. Once an access transaction is made on the contract, a grant will be recorded on chain and the DDN will instead stream the actual content to the verified caller using a TTLd byte stream over HTTPS. The stream expires after the contracts grant TTL. The access function on the PFA comes from the IPFA interface discussed previously in Pay-For-Access (PFA) Smart Contracts:
/// @notice If called with a value equal to the price per access
/// of this contract, records a grant timestamp on chain which is
/// read by decentralized distribution network (DDN) microservices
/// to decrypt and serve the associated content for the tokenURI.
function access(uint256 tokenId, address recipient) external payable;
Note that the HTTPS GET request to the DDN endpoint includes a signature, which is a standard message, cryptographically signed using the private key of the requester. This is used within the DDN implementation to verify the identity of the caller. If the signature is incorrect, the endpoint will not attempt to read contract state and will instead always return a preview.
In the Share Protocol DDN implementation, the plaintext message to be signed is the string "Signing this message verifies your wallet address and authenticates the use of Share application services."
If a 3rd party would like to provide DDN services, or if a creator would like to host their own DDN endpoint, there are different incentives. Note that a creator would likely never run an entire DDN, instead they may opt to run a single stateless endpoint that is associated with their smart contract, but it is unlikely that they would like to run an entire network unless they are an infrastructure level partner offering this as a service (this would be the 3rd party case).
If a creator would like to run their own stateless microservice, the conventional incentive is that they are not dependent on the FORMLESS provided service. This means they have custody of their own data, keys, and compute but can still interact with the protocol smart contracts. If a 3rd party would like to provide DDN services to their customers, they'd be incentivized by charging their customers for the ability to use their DDN layer which communicates with SHARE.
Last modified 2mo ago