TIP-694: Enhance Verification of Transaction Limitation at Consensus Layer

[lxcmyf]

tip: 694
title: Enhance Verification of Transaction Limitation at Consensus Layer
author: [email protected]
discussions-to: https://github.com/tronprotocol/tips/issues/694
status: Draft
type: Standards Track 
category: Core
created: 2024-10-24

Simple Summary

This TIP aims to impose restrictions on account creation transactions, excessively large transactions, multi-result transactions, and near-expiry transactions at the consensus layer to enhance the consistency and stability of transaction processing.

Motivation

As the TRON network evolves, its security and efficiency continue to improve. Recently, we have identified that although restrictions are already in place for scenarios such as account activation transactions, excessively large transactions, multi-result transactions, and near-expiry transactions, these restrictions have yet to be elevated to the consensus layer, posing potential security risks. While these scenarios do not compromise the chain's asset security and data consistency, they may impact network efficiency. This proposal aims to optimize these scenarios at the consensus layer to further enhance the efficiency and stability of TRON.

Rationale

This document addresses four scenarios:

• By limiting the size of account creation transactions, bandwidth consumption is more reasonably managed.
• Strengthening the verification of near-critical transaction sizes avoids situations where transactions within a block may exceed the maximum transaction limit.
• Strictly validating the length of the transaction result list to ensure it aligns with the number of contracts, although inconsistency does not pose a consensus issue.
• Implementing a stricter filtering mechanism for expired transactions to prevent near-expiry transactions from potentially occupying network bandwidth.

Implementation

The specific optimizations for transaction processing at the consensus stage are implemented as follows:

1. Account creation transactions have a size limit: If a transaction has not been packaged and its size, excluding transaction results and signatures, exceeds a default threshold of 1000 bytes (modifiable through proposal voting), an exception for an overly large transaction will be thrown.
2. When transactions approach the 500KB critical size, verification is conducted during broadcasting and P2P stages: considering the result as the maximum size, if the total size (including the actual transaction body) exceeds the limit, an exception for an overly large transaction will be thrown.
3. Limiting the transaction result list: calculate the size of each result excluding ContractRet, plus an estimated maximum ContractRet size; if this exceeds 64KB, an exception will be thrown. Additionally, redundant results are verified and removed to ensure alignment with the number of contracts.
4. Stricter restrictions on near-expiry transactions: the expiry time of transactions is changed from being required to be greater than the head block time to being required to be greater than the slot time of the next block.
   To ensure high consistency and optimized efficiency in transaction processing at all stages, including the consensus stage, we will implement this optimization logic through a proposal, thereby further enhancing the consistency and effectiveness of transaction processing.

Backward Compatibility

After implementing this optimization, there will be no impact on the consistency of existing transaction behaviors, ensuring high consistency in transaction processing during broadcasting, P2P, and consensus stages.

[GuipaiQigong111]

Glad to see this improvement.

[endiaoekoe]

I have 2 questions for this propsal ,as below:

i.What's the practical impact of changing from "less than head block time" to "less than next block slot time"?Will this affect time-sensitive scenarios like cross-chain transactions?

ii.How much overhead will these additional validations(consensus verification) add to transaction processing?

[xxo1shine]

@lxcmyf I also have two questions：

1. The modification involves multiple places. I want to know how many proposals are used to control it?
2. Account creation transactions have a size limit. Why are there no size limits for other transactions?

[lxcmyf]

@endiaoekoe
This is mainly done to avoid occupying network resources during the broadcast of transactions that are close to expiration. The verification conditions have become stricter and the overhead is very low.

[lxcmyf]

@xxo1shine
These verifications can be done with one proposal.The creation of account transactions, under specific scenarios, can result in unreasonable bandwidth consumption, hence this restriction is implemented.

[CooperDepp]

This tip aims to limit at the consensus layer, so what layer are these limitations exists currently? Would you explain the architecture please, I do not have a picture.

[lxcmyf]

@CooperDepp
As is well known, the lifecycle of a transaction is divided into the creation, signing, broadcasting, packaging, and confirmation of the transaction. The packaging and confirmation of the transaction are carried out at the consensus layer, during which the transaction is also verified.

[GrothenDI]

The account in 'Simple Summary' means smart contract account?

[CooperDepp]

@CooperDepp As is well known, the lifecycle of a transaction is divided into the creation, signing, broadcasting, packaging, and confirmation of the transaction. The packaging and confirmation of the transaction are carried out at the consensus layer, during which the transaction is also verified.

So you are meaning that previously the transaction limitations were only carried out in creation, or signing or broadcasting part, and now this TIP aims to add verification of the limitation in the packaging and confirmation part, correct?

[lxcmyf]

The account in 'Simple Summary' means smart contract account?

It is not limited to smart contract accounts alone.

[CarlChaoCarl]

@lxcmyf

Hello, I have two questions after reading through this:

1. Regarding points 1, 2, and 3, I’m wondering how transactions are handled after an exception is thrown.
2. Additionally, if the threshold is controlled by a proposal and then lowered, would that have any impact?

[toptalent0921]

Hi Team.
I hope my opinions will be helpful to you.

1. I think you have to define strict limits on the size of individual transactions.
   Implement automatic checks during the broadcasting phase to ensure transactions do not exceed predefined size thresholds, which could help mitigate issues of network congestion.

2. I think you have to allow for batch processing, where multiple transactions can be combined into a single transaction and processed together, reducing overhead and improving overall throughput.

3. I think you have to optimize signature verification methods to reduce computational overhead.
   This could involve implementing more efficient cryptographic algorithms or hardware acceleration for signature validation.

4. I think you have to develop a prioritization mechanism for transactions based on factors such as fee paid, age of the transaction, or reputation of the sender.
   This could ensure that more important transactions are processed first during times of high volume.

[abele1688]

Good

[lxcmyf]

@CooperDepp As is well known, the lifecycle of a transaction is divided into the creation, signing, broadcasting, packaging, and confirmation of the transaction. The packaging and confirmation of the transaction are carried out at the consensus layer, during which the transaction is also verified.

So you are meaning that previously the transaction limitations were only carried out in creation, or signing or broadcasting part, and now this TIP aims to add verification of the limitation in the packaging and confirmation part, correct?

Yes, to be precise, it's actually during the packaging process.

[lxcmyf]

@lxcmyf

Hello, I have two questions after reading through this:

1. Regarding points 1, 2, and 3, I’m wondering how transactions are handled after an exception is thrown.
2. Additionally, if the threshold is controlled by a proposal and then lowered, would that have any impact?

Exception throwing is handled in the same way as the previous implementation. If you don't control it through proposals, do you have a better way?

[lxcmyf]

Hi Team. I hope my opinions will be helpful to you.

1. I think you have to define strict limits on the size of individual transactions.
   Implement automatic checks during the broadcasting phase to ensure transactions do not exceed predefined size thresholds, which could help mitigate issues of network congestion.
2. I think you have to allow for batch processing, where multiple transactions can be combined into a single transaction and processed together, reducing overhead and improving overall throughput.
3. I think you have to optimize signature verification methods to reduce computational overhead.
   This could involve implementing more efficient cryptographic algorithms or hardware acceleration for signature validation.
4. I think you have to develop a prioritization mechanism for transactions based on factors such as fee paid, age of the transaction, or reputation of the sender.
   This could ensure that more important transactions are processed first during times of high volume.

At present, Tron has targeted restrictions and verifications for special types of transactions, and other improvements may be the direction Tron will strive for in the future.

[S1ep]

What is the 'head block' in 'near-expiry transactions'?

[GrothenDI]

The account in 'Simple Summary' means smart contract account?

It is not limited to smart contract accounts alone.
Why normal account creation could have the risk of exceeding size limitation.