# L2’s Navigating EIP-4844 – KYVE's Role in Ensuring Long-Term Data Management Source: https://x.com/KYVENetwork/status/1767224043269189714?s=20 Kiwi News: https://news.kiwistand.com/stories/L2s-Navigating-EIP-4844-KYVEs-Role-in-Ensuring-Long-Term-Data-Management?index=0x65ef37b6045f5b8a21bd0d3d31db057d2e408987c0dce58947f85979a225bd324123812e Submitted by 0xf9f9...736D on 2024-03-11 UTC, 1 upvote, 0 comments ## Summary KYVE argues that Ethereum L2s need a decentralized way to keep their historical blob data retrievable after EIP-4844 goes live on mainnet, since Ethereum will no longer manage that data. KYVE describes itself as a Layer-1 chain offering data rollups-as-a-service, with validated blobs stored permanently and mostly for free. The article says a running Arbitrum integration on KYVE's Sepolia devnet archives and validates Arbitrum blobs, and that the blobs are stored on KYVE's Storage Provider, a free alternative to Arweave, during testing. ## Article @ethereum's upcoming milestone of finally having EIP-4844 on mainnet represents a significant step forward and promises improved performance and scalability. However, for L2s, this means their historical data will no longer be managed by Ethereum, and now they must proceed with caution and preparation to ensure that their blobs can still be retrieved after a month, in the best case forever, without relying on central entities storing them. Preferably before this major change, an infrastructure should be in place to recover data from blobs when needed without depending on a few nodes that don't prune the blobs. This is especially important for backup plans and to be ready in case blobs become more expensive than expected. As Vitalik recently stated: “The purpose of the Ethereum consensus protocol is not to guarantee storage of all historical data forever. Rather, the purpose is to provide a highly secure real-time bulletin board, and leave room for other decentralized protocols to do longer-term storage.” @KYVENetwork is this decentralized solution, storing any blobs permanently and validating them all in a fully decentralized way. KYVE itself is a Layer-1 chain that provides data rollups-as-a-service (DRaas), ensuring that the historical data of chains and apps is permanently accessible, principally for free, without being dependent on or having to trust a central entity. Getting Technical: KYVE’s Validation & Archiving Structure The validation and archiving of the data (e.g. Blobs) takes place in data pools which are secured by KYVE's own Proof of Stake blockchain. In summary, uploaders are collecting data from their own independent data source (e.g. their own Arbitrum node), storing them on a decentralized storage provider like Arweave, and submitting them for validation in the data pool so that other network participants (validators) can verify it. This process takes place in rounds, whereby part of the data is validated (e.g. all blobs for slot 4000000-4001000). If the majority of validators reach a consensus on the data, the hash and the storage ID of the data are saved on the KYVE Chain. If the majority rejects the proposed data of the uploader of the round, the round is repeated, and the uploader is penalized in the form of a slash. For further information about the KYVE architecture, visit our docs: https://docs.kyve.network How To Retrieve The Data Data consumers can then easily use the validated data without needing to trust KYVE or other intermediaries to further build decentralized applications or for analytical purposes. To access the trustless data, the storage ID of the requested data can be obtained directly from the KYVE chain to download it. After downloading, the hash of the local copy can be compared with the validated data hash in the chain to ensure that the data is valid. To make this process more comfortable for data consumers, KYVE provides the following solutions: Trustless-RPC: The easiest way to obtain the data mocking the /eth/v1/beacon/blob_sidecars/{block_id} endpoint of a Beacon node by using the validated data by KYVE. Thereby, it’s possible to spin up an RPC providing all historical blobs without any storage requirements. ELT-Pipeline: The KYVE ELT-Pipeline built with Airbyte allows data consumers to load the validated data into the destination of your choice (e.g. BigQuery or Postgres) with a few clicks. Running Example: Arbitrum Putting KYVE’s decentralized data solutions to the test, there is already a running integration on KYVE’s devnet, archiving onto and validating blobs of @arbitrum on the Sepolia network. You can take a closer look at the pool itself under the following link: https://app.korellia.kyve.network/#/pools/86 Or by using the following endpoints provided by KYVE: Query blobs by slot: https://data.services.kyve.network/beacon/blob_sidecars?l2=arbitrum&slot_number=4474281 Query slots by block: https://data.services.kyve.network/beacon/blob_sidecars?l2=arbitrum&block_height=5404450 Please note: In order to remove operating costs during this testing phase, the blobs are being stored on the KYVE Storage Provider, a free alternative to Arweave. L2s’ Time To Rely On KYVE Long story short, instead of relying on costly, unreliable, centralized solutions, Ethereum L2s can easily create a custom data rollup on KYVE, letting KYVE’s decentralized network manage their data so they can continue scaling. Join KYVE.