Skip to content

Latest commit

 

History

History
32 lines (29 loc) · 3.5 KB

tip-694.md

File metadata and controls

32 lines (29 loc) · 3.5 KB
tip: 694
title: Enhance Verification of Transaction Limitation at Consensus Layer
author: lxcmyf@gmail.com
discussions-to: https://github.com/tronprotocol/tips/issues/694
status: Final
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.