Shared Storage Architecture

[ogenev]

Problem Statement

Trin requires a unified approach to manage both persistent (eternal) and temporary (ephemeral) data storage across multiple network components.

We face several key challenges:

• Efficiently managing data across both eternal and ephemeral storage tiers
• Enabling seamless data migration between storage types when needed
• Providing consistent storage access for multiple networks (History, Beacon, and eventually State)

Proposed Solution

This issue outlines an architecture for a shared storage service that addresses these challenges by:

• Centralizing storage management through a common service interface
• Supporting commands from all networks through a unified client
• Maintaining logical separation while sharing physical infrastructure
• Enabling network-specific operations through a flexible command system

The proposed architecture provides a balance between resource efficiency and operational independence, allowing each network component to maintain its unique storage requirements while benefiting from shared infrastructure.

Shared Storage Architecture

Architecture Components

StorageClient

• Provides a common API for both History and Beacon networks
• Handles communication with the StorageService through async commands
• Supports different storage key types and combinations

StorageService

• Central service managing all storage operations
• Contains both eternal storage (IdIndexedV1Store) and ephemeral storage (EphemeralV1Store)
• Processes commands from multiple networks
• Runs background maintenance tasks

Storage Interaction Flow

1. History Network

• Uses HistoryContentKeys directly
• Can store data in either eternal or ephemeral storage based on needs
• Sends commands through the StorageClient

2. Beacon Network

• Internally maps its BeaconContentKeys to HistoryContentKeys
• Uses ephemeral storage exclusively
• Interacts with the same StorageClient as History network

3. Command Processing

• StorageClient receives requests from both networks
• Forwards commands to StorageService via channels
• StorageService executes operations on appropriate stores
• Results returned through response channels

Key Benefits

• Single Service Architecture: One service manages all storage needs
• Shared Infrastructure: Common client and service for both networks
• Flexible Storage Options: Different store types for different data requirements
• Clean API Separation: Networks don't need to know internal storage details
• Efficient Resource Usage: Shared connection pools and background tasks

[KolbyML]

Internally maps its BeaconContentKeys to HistoryContentKeys

I don't think this will still be desired as the EL Header can't be generated from the LightClientUpdate

[ogenev]

We’ll validate this proposed design once we finalize the Ephemeral header specifications and gain a clearer understanding of the store’s requirements. We may come to something simpler that doesn't require a lot of refactoring.

[morph-dev]

I have one idea that I want to document somewhere and I don't know where is the best place. So I'm putting it here as it seems like a relevant location (but it's not necessary related to this logic).

We probably want to keep some ephemeral stuff in memory, and flush it periodically to disk. It would be good if we would have mechanism to catch Ctrl+C and do "graceful shutdown" (where we can flush things to disk before trin fully closes).