Feed Layer

How to use pod as a layer for publishing data with associated timestamp

The feed layer is a flexible mechanism for decentralised applicationss to publish data on pod, associating each post with an approximate timestamp. This can be useful for a variety of use cases, such as decentralized social networks for posting user-generated content, L2 sequencers posting block data, or NFT marketplaces broadcasting metadata about NFTs.

Smart Contract Definition

The feed layer organizes data streams into feeds. A feed_id acts as a namespace, allowing different applications or streams of data to be categorized and filtered efficiently when reading logs. For example, one feed maybe social media posts, while another images uploaded to an album. Each post is uniquely identified by a post_id, which is derived from the feed_id, the sender's address, and the post content. Votes are recorded on-chain, and events are emitted when posts are created and voted on, allowing external applications to track activity on the feeds.

Below is the interface of the contract that implements this system:

pragma solidity ^0.8.25;

contract RankedFeed {
    mapping(bytes32 => uint256) public votes;
    mapping(address => mapping(bytes32 => bool)) public voted;
    
    event PostCreated(bytes32 indexed feed_id, bytes32 indexed post_id, address indexed poster, bytes post_data);
    event PostVoted(bytes32 indexed feed_id, bytes32 indexed post_id, address indexed voter);
    
    function createPost(bytes32 feed_id, bytes calldata post_data) external;
    function votePost(bytes32 feed_id, bytes32 post_id) external;
    function votes(bytes32 post_id) external view returns (uint256);
}

Posting Data

To create a new post, a user calls the createPost function on the contract. This operation emits a PostCreated event that announces the new post and includes the associated post_id.

Since pod does not have blocks, when send a transaction you don't wait for a particular number of confirmations, instead you wait for the receipt to be returned, which will typically be available right after sending the transaction.

use pod_sdk::{PodProvider, Wallet};
use alloy_sol_types::sol;
use alloy_contract::SolCallBuilder;
use alloy_core::types::*;
use alloy_primitives::B256;
use std::error::Error;

sol! {
    contract RankedFeed {
        function createPost(bytes32 feed_id, bytes calldata post_data) external;
    }
}

async fn create_post(provider: &PodProvider, contract_address: Address, feed_id: B256) -> Result<(), Box<dyn Error>> {
    let post_data = b"Hello, this is a post!";
    
    let contract = RankedFeed::new(contract_address, &pod_provider);
    let call = contract.createPost(feed_id, post_data.into()).send().await?;
    let tx_hash = call.tx_hash();
    let response = provider.get_transaction_receipt(*tx_hash).await?;
    if let Some(receipt) = response {
        println!("post created with tx hash: {}", receipt.transaction_hash);
    }
    Ok(())
}

Voting Posts

Users can vote on posts to rank content in a decentralized way. Voting follows a simple rule: each user can vote only once per post. This ensures that the voting mechanism remains fair and prevents vote manipulation.

Example

use pod_sdk::{PodProvider, Wallet};
use alloy_sol::sol;
use alloy_core::types::*;
use alloy_primitives::B256;
use std::error::Error;

sol! {
    contract RankedFeed {
        function votePost(bytes32 feed_id, bytes32 post_id) external;
    }
}

async fn vote_post(provider: &PodProvider, wallet: &Wallet, contract_address: Address, feed_id: B256, post_id: B256) -> Result<(), Box<dyn Error>> {
    let contract = RankedFeed::new(contract_address, provider.clone());
    let call = contract.votePost(feed_id, post_id).send().await?;
    let tx_hash = call.tx_hash();
    let response = provider.get_transaction_receipt(*tx_hash).await?;
    if let Some(receipt) = tx.get_receipt().await? {
        println!("Voted on post with receipt: {:?}", receipt);
    }
    Ok(())
}

Listing Posts

Posts are tracked via the PostCreated event, which can be fetched and verified. Pod provides additional metadata with logs, allowing verification that the logs were signed by the expected committee members, without having to rely on the RPC server for safety.

Each validator signs a timestamp when confirming an event. The confirmation_time() function returns the median timestamp from all validators, giving an approximate time of occurrence.

use pod_sdk::{PodProvider, Committee};
use alloy_core::types::*;
use alloy_core::log::Filter;
use std::error::Error;

sol! {
    event PostCreated(bytes32 indexed feed_id, bytes32 indexed post_id, address indexed poster, bytes post_data);
}

async fn list_posts(provider: &PodProvider, committee: &Committee, feed_id: B256, rpc_is_trusted: bool) -> Result<(), Box<dyn Error>> {
    let filter = Filter::new().event_signature(PostCreated::SIGNATURE).topic1(feed_id);
    let logs = provider.get_verifiable_logs(&filter).await?;
    for log in logs {
        if rpc_is_trusted || log.verify(committee)? {
            println!("Verified post at {:?}: {:?}", log.confirmation_time(), log);
        }
    }
    Ok(())
}

Light client support

Logs generated by pod can also be verified by light clients, such as smart contracts deployed in other blockchains. For example, there may be a smart contract deployed to Ethereum that pays a little reward for every post posted to Pod on a particular feed_id.

The logs returned by get_verifiable_logs can generate proofs for such smart contracts by calling the function generate_multi_proof. This proof can be submitted to a smart contract that verifies them by using the Solidity SDK.

Conclusion

On pod, logs can be verified against committee attestations, ensuring authenticity without relying solely on an RPC provider. Verified logs can also be used to generate Merkle proofs, which can be posted to a smart contract on Ethereum for validation using pod’s Solidity SDK. This allows external chains to verify pod events securely, making it a powerful tool for decentralized applications that require cross-chain data availability.