Introduce blob transaction

[zijpe]

Simple Summary

According to core feature of Ethereum Dencun upgrade, EIP-4844: Shard Blob Transactions, this proposal would involve introducing a new Blob type transaction.

Background

Ethereum's Dencun upgrade introduced EIP-4844 (Proto-Danksharding), implementing a new transaction type to the Ethereum blockchain ecosystem. This feature specifically targets Layer 2 scaling solutions known as Rollups, enabling them to settle transactions on the main Ethereum chain with dramatically reduced costs and improved efficiency.

Motivation

In order to be compatible with the new features of Ethereum Dencun upgrade, it is proposed to introduce Blob transactions.

[zijpe]

Currently, I noticed that the demand for rollups on TRON appears limited. Additionally, introducing blob transactions presents potential concerns:

• Blob transactions would place large data in the mempool, creating DoS vulnerability risks similar to transactions with extensive calldata
• This proposal would significantly increase bandwidth requirements for TRON nodes

[troncommons]

Currently, I noticed that the demand for rollups on TRON appears limited. Additionally, introducing blob transactions presents potential concerns:

• Blob transactions would place large data in the mempool, creating DoS vulnerability risks similar to transactions with extensive calldata
• This proposal would significantly increase bandwidth requirements for TRON nodes

Yes, for the first concern, perhaps we can define such transactions at a reasonable price to prevent malicious attacks.
and for the second, database stress test is necessary to evaluate the performance impact

[Federico2014]

How do you store Blob transactions? Will it result in state bloating?

[zijpe]

How do you store Blob transactions? Will it result in state bloating?

This is an important consideration. According to EIP-4844, each block contains a maximum of approximately 6 blobs, and these blob data are only retained for around 18 days before being pruned from the chain. These limitations help control state bloat.

[Bellgin]

I do not think TRON need Blob for now. EIP - 4844 is for its very specific needs and ETH ecosystem which is different. I'm sure its not TRON's priorities.

[Federico2014]

This is an important consideration. According to EIP-4844, each block contains a maximum of approximately 6 blobs, and these blob data are only retained for around 18 days before being pruned from the chain. These limitations help control state bloat.

But how do we recover the history of the Block transaction if necessary? Is there any way to back up the Blob data?

[bladehan1]

This is an important consideration. According to EIP-4844, each block contains a maximum of approximately 6 blobs, and these blob data are only retained for around 18 days before being pruned from the chain. These limitations help control state bloat.

But how do we recover the history of the Block transaction if necessary? Is there any way to back up the Blob data?

The proof of blob data is stored on the main chain. The L2 chain has the original data, which can be reassembled into blob data. If the proof is satisfied, it can be considered as the original blob data.

[zijpe]

TRON differs from Ethereum in that it doesn't have the separation between consensus and execution layers. Therefore, I believe that if we want to implement blob transactions, we need to reconsider how the Sidecar Protocol should be implemented - whether we should maintain consistency with Ethereum's approach or adopt a simpler method more aligned with TRON's characteristics.

If we choose a different path, we also need to consider how this will impact future support for Danksharding DAS, which the Ethereum sidecar protocol was designed to accommodate.

[simbadMarino]

Even though TRON doesn't share the same scalability issues compared to Ethereum we should prepare for a future in which third party tech companies want to have their own L2 to control goverance but at the same time want to leverage TRON's L1 security (Take Soneium by Sony as reference)

By introducing blob transactions we can effectively make TRON appealing for Rollups by significantly reducing fees.

[Federico2014]

Blob transactions are mainly used by L2 Rollups, which have two categories: optimistic rollups and zk rollups. For zk rollups, we need to consider the timeout restrictions, as in issue. We may need to support the zk-Snark-based applications before introducing the blob transactions.

[troncommons]

Blob transactions are mainly used by L2 Rollups, which have two categories: optimistic rollups and zk rollups. For zk rollups, we need to consider the timeout restrictions, as in issue. We may need to support the zk-Snark-based applications before introducing the blob transactions.

I agree with you—it might be better to support rollups on TRON first, followed by blob transactions.

To move forward, we should outline the current state of rollups on TRON, explain why supporting them is necessary, and propose a clear path for optimizing their implementation.